“We can solve any problem by introducing an extra level of indirection.” – Butler Lampson
1. DNS is a hierarchy. Use it to show logical groupings.
Fully-qualified domain names (FQDNs) like pussinbootsthemovie.com are great examples of what happens when you don’t take advantage of the hierarchy in DNS. Wouldn’t pussinboots.dreamworks.com be just as easy? Or, frankly, just avoid the issue and do what Disney does: http://disney.com/cars/.
What if all your company’s desktops were in .desktop.company.com? Would that help assign permissions to them? Or your engineering group had all their stuff in .eng.company.com? Test hosts in .test.company.com? Would having all your services at your DR site in .dr.company.com help to manage, monitor, and use them? I’m not saying that any of this would help, but, in my opinion, it’s worth thinking about.
Also, remember that DNS resolvers can be set to search specific domains, which, in certain cases, might help with testing, project-specific DNS, DR, deployments, cloning, etc. What if all your DR servers searched .dr.company.com first, while all your test ones searched .test.company.com? Would that solve any problems, or just make things more complex?
2. A single IP address can have multiple DNS A, AAAA, and CNAME records.
3. Use service names.
Adding a CNAME record, or additional A & AAAA records, for calendar.company.com (my hypothetical example service): 15 minutes.
Not having to reconfigure all desktops when the calendaring app moves from voldemort.atl.company.com to hermione.ord.company.com, but instead just changing one DNS record: priceless.
Being able to test & practice in parallel against the new instance on hermione.atl.company.com before the cutover: priceless.
Not having to reconfigure all your monitoring & management systems because they refer to service names: priceless.
Not having to buy or generate all new SSL certificates because of a move: priceless.
Being able to fail back quickly by changing the DNS record: priceless.
Not having your users know the servers are named after Harry Potter: priceless.
4. Remember that DNS records get cached.
DNS records are cached by your OS and by your DNS server when you look them up, and the amount of time they are cached for is controlled by something called the Time To Live, or TTL, value. The default for this is often 86400 seconds, or 24 hours, but can be set to whatever you want.
This means that if you look up calendar.company.com and you get the result 192.168.55.29, that result will be cached. For the next 24 hours the answer you get will still be 192.168.55.29, even if you changed the record. If you are making changes and want clients to get new DNS information more rapidly you have two options: manually clear the DNS caches, or set the TTL lower so it does the work for you.
You need to change the TTL in advance, so it takes effect. TTLs are only checked when the entry expires, so if your TTL is 24 hours, you need to change the TTL to the new value more than 24 hours before you plan to do the work. 48 hours before I do work like this I have the TTL changed to 300 seconds (you can set the TTL on a per-record basis). I do the work and wait 300 seconds for clients to get the update. Later, when I know everything is fine, I set the TTL back to the default.
It’s worth noting that a TTL of zero (0) isn’t defined. Sometimes a resolver library will take it as an instruction to not cache the record, sometimes the resolver library will apply its default TTL. It’s best to set the TTL to something like 300 seconds.
5. Round-robin DNS isn’t a good load-balancing mechanism.
On paper, round-robin DNS seems like an easy way to spread the load between multiple servers, but if one of those servers is down some clients will see outages as they are told to connect to the unavailable host. Round-robin DNS only works well with protocols and applications that have robust failover capabilities built in, and frankly, that isn’t too many of them. Sendmail/SMTP is an example of one. Sure, a workaround could be to quickly change the DNS record to remove the offending IP, but the cache and TTL might work against you. Yes, you could fix that by permanently set the TTL to something low. Or you could arrange for a working host to take over the IP of the dead one.
With all that trouble, though, it’d just be easier to get some real load balancing going, like with HAproxy or Linux Virtual Server, and do it right.
6. Don’t expose your internal structure to end users.
When it comes to end users, simplicity is your goal. Complex service names and hierarchy are to help admins & IT people, not end users. One site that fails in that regard is IBM’s web site, as it redirects users to www-03.ibm.com, www-304.ibm.com, www-935.ibm.com, etc. So what happens when I bookmark one of those and it’s down? Or you want to retire it? Now www-03.ibm.com has to become a service name. Seems like an inelegant mess that the sysadmins are now stuck supporting for eternity, and for a company that wants to sell me services to make my IT infrastructure simpler it’s a bad message (if only subliminal).
7. Not using DNS is not an effective security measure.
Every system administrator should be familiar with “security through obscurity.” This is a great example of it. Besides, attackers don’t need your host name — they just use your IP addresses to scan and attack you. This line of thinking also assumes the attackers are external threats, and not already on the inside (malware, disgruntled employee, advanced persistent threat, etc.).
Sure, you can leak some information through DNS records (location, purpose, etc.), but in my experience it’s better to have DNS set up in a useful way and invest in proper firewalling to keep the bad guys out than use the absence of names as a protective measure.
It’s also possible to restrict DNS responses, or run internal-only domains, if that seems like a good option, but I’d probably spend my time on excellent firewall configurations.
8. Read RFC 1178, “Choosing a Name for Your Computer.”
Written in 1990, some of the suggestions are antiquated. For example, I actually like the idea of naming corporate desktops after people, in contrast to the suggestion to avoid naming things after yourself. Many other ideas, like “don’t expect case to be preserved,” are timeless. I don’t know what the deal is with PenIsland.net, but I could see how someone might have assumed case-sensitivity. Ouch.
DNS was built as a fix for our finite human memory, so we don’t need to remember big tables of IP addresses. It is also a powerful tool for adding a layer of abstraction between services and their consumers. It’s your tool to use, so use it to your advantage, human!
Thanks to Ethan Banks (@ecbanks) for the motivation to finish writing this. And yes, the title of this post is a DNS pun.
