Robert MacLean

The Zen of Hosting: Part 11 - DNS

Published on Estimated reading time: 2 minutes

The last of the hurdles to overcome for deployment was the running of the DNS server. This was because we ran on a private IP range internally and used ISA to match external IP addresses and ports to the services we wanted to publish (i.e., NAT). This essentially allowed us to lower the attack surface, as we only exposed what was needed, and also enabled us to mix and match servers to the same IP—thereby reducing our IP address usage.

This setup also meant that we needed not only DNS servers to help internal servers and staff locate other servers and services but also external servers to allow users on the "big bad" Internet to find them. There was so much duplication of work in this configuration deployment scenario, as you had to create records on a best-case scenario of two servers and, in the worst case, four servers—and configure them differently. This also increased the area for mistakes considerably. The upside was that internal staff did not need to leave the LAN and return via the Internet or even go through the external firewalls. We could also use different domain names internally and externally, which was great for testing and development and only publishing when needed.

What I do not understand is why the DNS server team at Microsoft cannot take a leaf from MSCRM 4.0's IFD deployment and allow you to specify what the internal IP range is while also letting you set A/CNAME records for both internal and external IP ranges. This way, when an internal IP requests resolution, it returns the internal A/CNAME records, and for non-internal requests, it returns the external A/CNAME record. This is such a logical feature that Bind has offered for ages—so come on, Microsoft, steal another idea from Linux😉

One of the design choices for the DNS structure was a concept of mine called IP address abstraction. The idea of DNS is to abstract away IPs, but in normal configurations, you end up with loads of A records—and the moment you need to change IPs, you spend days updating them across all records. IP address abstraction means taking a core domain name and creating a single A record for each IP you have.

Examples:

Then, everywhere else, you use CNAMEs pointing to those names, regardless of the domain.

Example:

The advantage is that if the IPs ever change, you update them in one place, and the change reflects everywhere—yet the end-user experience remains exactly the same as with traditional DNS.