Reduce # of Authoritative DNS Points of Failure for IBM Cloud Services

Using API Connect as an example, access to this is provided via generic FQDNs which all customers use. These FQDNs actually rely on multiple Authoritative DNS providers which increases their likelihood to fail.

This is the opposite of what would be expected - i.e. it would be normal to see multiple Authoritative DNS vendors involved but implemented for redundancy - not implemented as points of failure as they are currently.

An example was that our Synthetic Monitoring detected that IBM Cloud was affected by the recent Dyn issue - https://www.dynstatus.com/incidents/508dclpb101q

An example would be that 'api.us-south.apiconnect.appdomain.cloud' relies on 2 third party Authoritative DNS vendors:

1) Dyn at the domain level i.e. 'appdomain.cloud'

2) An IBM branded version of Cloudflare DNS at the subdomain delegation level i.e. 'apiconnect.appdomain.cloud'

The older style FQDNs like 'api.us.apiconnect.ibmcloud.com' which were created before the Cloudflare integration are also relying in turn on different Authoritative DNS vendors 

3) Akamai DNS at the domain level i.e. 'ibmcloud.com'

4) Softlayer DNS at the subdomain delegation level i.e. 'apiconnect.ibmcloud.com'

The best way to visualise these dependencies is by performing a dig +trace.