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.
NOTICE TO EU RESIDENTS: per EU Data Protection Policy, if you wish to remove your personal information from the IBM ideas portal, please login to the ideas portal using your previously registered information then change your email to "email@example.com" and first name to "anonymous" and last name to "anonymous". This will ensure that IBM will not send any emails to you about all idea submissions