Conflicting Requirements for Multi-Cloud DNS: Lessons from the Trailblazers
As a Systems Engineering Manager at Infoblox, I meet organizations of varying sizes, regions and verticals on the West Coast of the US almost daily. It gives me a great opportunity to hear and discuss how they manage and implement changes to their networks, to accommodate new business initiatives and user requests.
In almost every meeting, at some point we move past “traditional” network requirements and start discussing “Cloud,” and what it means for managing IP addresses and namespaces in a cloud environment.
I consistently hear some requirements from our customer contacts, out of different teams who are also involved in the deployment, transition, and operation of the Cloud.
These requests do not exist in a vacuum. They align with the business goals of maximizing profits, brand awareness, customer satisfaction and employee morale. Below are the most common requirements, organized by the teams who usually request them.
Cloud and Automation Team
- Flexible APIs that select the right IP address for a resource given certain criteria, and create and delete DNS records as virtual resources are created and destroyed.
- DNS servers should be “near” their clients, to minimize DNS-induced application latency.
- Replication of changes should be as fast as possible from one DNS server to others.
- DNS should be as redundant and robust as possible, following the infrastructure and network architecture. Some prefer to run DNS only in the Data Centers while others extend functionality to other locations such as branch offices, stores, factories, and warehouses.
- IP address space inventory should be automatically maintained.
- IP inventories should also contain as much data on active IPs as possible. At a minimum, the MAC address should be tracked, and ideally other data as it applies (physical or virtual switchport, activity timestamps, etc.).
Windows/Active Directory/Microsoft Team
- DNS “can’t break” Active Directory: DNS infrastructure must support secure dynamic DNS updates (based on GSS-TSIG) and SRV records, and some other RFC-defined functions (e.g., zone transfers and conditional forwarders)
- DNS replication must, at least, be as fast as AD replication; it cannot introduce delays in Active Directory.
- Ensure DNS is doing its best to protect itself from attacks.
- Prevent DNS from serving malware.
- Log data for resolution and changes are always welcome (though not many organizations yet take advantage of this data).
- Role-Based Access Control for IP and namespaces. Users should only be able to read/write the resources they own and no others (global read-only access may be ok).
The benefits of Infrastructure As-a-Service (IaaS) towards business goals seem undeniable, at least in principle. However, alongside these benefits come new challenges, many of those directly related to DNS resolution and IP address inventory and management, and the requirements outlined above.
Some of these challenges are (not in prioritized order):
- IP and network address inventories for Clouds (public and private) are rarely synchronized with “central” inventories. This creates different issues. At best, there is no visibility across the border of Multi-Cloud Environments, creating multiple points of management and inventory. At worst, automation brings higher chances of IP duplication, one of the hardest issues to troubleshoot, with unpredictable symptoms.
- Most Cloud platforms (both on-premises and IaaS) offer some level of DNS resolution and automation, which will appear to be convenient and appealing. However, these DNS services are not RFC-compliant and do not support functions that are mostly taken for granted (like DDNS updates and DNS Zone Transfers), and these gaps make them hard to integrate with the DNS namespace and servers already existing in most private networks.
- Legacy internal DNS servers have challenges of their own: ISC BIND does not support redundancy in the Primary/Master DNS server for a given zone (not out of the box at least). Windows Server DNS can only replicate the DNS zone data as fast as some AD replication settings will allow. It then takes much longer than expected for a new virtual resource to be resolvable across all the DNS servers.
In short, most freeware/embedded DNS and IPAM solutions will force a compromise between RFC compliance and API/Automation functionality. This is not a surprise, as DNS and IPAM are usually implemented after the fact (if at all), and only to ensure that their specific solution works.
Commercial DNS/DHCP/IP Address Management vendors have solutions that address these challenges to varying degrees, so the customers (we have been speaking to) have come away with some lessons on defining (or redefining) the DNS and IPAM strategy to accommodate Cloud:
- Incorporate automated IP and DNS provisioning from a dedicated/specialized system as early as possible in the Cloud deployment process. Built-in IP and DNS provisioning solutions are rarely RFC-compliant (see one of the challenges above).
- As a backup and complement to the above, make sure to have an automated discovery mechanism to populate existing virtual resources (subnets, assigned IP addresses, etc.) into the IP inventory and even better, into the corresponding DNS zone(s).
- Work with DNS/DHCP/IPAM vendors that have had solutions in the market for at least a couple of software revisions. Cloud brings a lot of changes, but any previous experience should help in most cases when it comes to deployment, configuration, and troubleshooting.
At Infoblox, we’ve been keeping an eye on these and many more requirements and use cases, and are very proud of the solutions our customers can deploy with minimal compromises. We have also seen many different integration points coming from customers and automation vendors, who have capitalized on our rich APIs to enable evolving workflows and use cases.
I would love to hear from you any other challenges you may be facing as your business becomes more cloud-friendly. Leave a comment below to continue the conversation.