Strategy #3 for Automating DNS
Using the DNS of your Cloud Provider
Amazon, Azure and other cloud providers provide native DNS services which are a good choice for automation. Unlike BIND-based solutions, cloud DNS services offer a modern, native API and improved performance.
However, cloud DNS services they are not enterprise-wide solutions. Each cloud provider has its own DNS system, and no cloud provider offers an on-premise DNS solution. The result is a hybrid, enterprise DNS system without the ability to orchestrate processes among heterogeneous environments. DevOps teams must interface with and maintain multiple, disparate DNS systems.
Pros:
Cloud-native API, high performance (no reliance on BIND).
DNS changes propagate fast.
Some traffic management - for example, ability to route traffic based on load and capacity.
Cons:
Cloud DNS solutions do not extend easily (or at all) to on premise infrastructure. As long as you have some systems running on-premise, you’ll need to maintain a local DNS system, which does not provide the same automation capabilities.
Each cloud provider has its own DNS solution, with its own API and proprietary features. If you operate on more than one cloud, this creates a steep learning curve and additional integration effort.
If you choose to centralize all DNS activity on one cloud provider, all DNS requests will need to go to that cloud first, then to other locations, incurring high latency.
Smart traffic management features will only work on the same cloud provider. For example, in a hybrid cloud scenario, you cannot use the public cloud’s DNS service to distribute traffic between private/public cloud based on current load.