Implementation/design considerations for enterprise DNS?

Question

I work at a big organization (thousands of servers, hundreds of physical locations, a half dozen data centers consolidating somewhat in the near future) that is looking at revisiting many aspects of the network infrastructure and the server hosting environment.

One of the areas where I've been asked to provide input is the DNS implementation. The biggest beef that I have is that we don't support split-horizon or split-view DNS. Internet-facing devices are named host.example.com and intranet devices and admin interfaces are labeled host.example.customtld. This causes alot of grief for people implementing services that face the internet and intranets.

Is there anything that the SF community can offer as a suggestion for getting more out of DNS? Any horror stories to avoid? Innovative ideas that saved alot of work?

Answer 1

Implementing split-view DNS will save a lot of grief (for people implementing services that face the internet and intranets) and thus work (for you). With BIND, it's trivial to set up.

Of course, if you're not running BIND then it may be more work.

And if The Powers That Be say "Thou shalt not use split-view" then you're screwed.

Answer 2

Have you considered anycast DNS at all? This question, among others, gives a little more information on it. Anycast allows you to advertise the same IP prefix from multiple locations in your network, with client systems being routed to the (logically) closest instance of a service.

A few benefits:

• All clients can use the same resolver IP address, regardless of their physical location. This greatly simplifies configuration management.
• Failover/resilience can be provided automatically; if you make your routing advertisements conditional on the DNS server being functional and accepting queries, then whenever a server fails, its routes will be withdrawn automatically. Clients will then be routed to the next 'closest' instance of the service, without the need for any reconfiguration.
• Anycast also allows you to scale out horizontally very easily; as all clients can target the same IP address regardless of location, bringing a new server online becomes trivial.

Answer 3

You're probably aware that it's good practice (and sometimes required) to have at least two DNS servers for every domain (or LAN, or organizational unit, or whatever). There's a common misconception that one of those two servers must be the "master" and the others must be "slaves." If you have multiple LANs (or subdomains) and each has its own pair of DNS servers, you'll have a nightmare trying to manage all the master servers scattered around your organization.

So here's the tip: it's not true that one of the two DNS servers has to be a master. The real requirement is that both should be authoritative. That's different.

There's nothing wrong with both authoritative servers being slaves. In fact, I do that quite frequently, even for small domains. Having authoritative slave servers frees me up to do some interesting things.

Let's say I have two existing DNS servers (A and B) and want to migrate A's data over to a new server, C, and get rid of A. Here are the steps:

1. Set up C as a slave to A. It copies over all the zone files. (Or you can copy them manually if you want to preserve your nice formatting.)
2. Update DHCP so that clients query B and C. Now you have two slaves servers (B and C) that are being authoritative for your domain.
3. Re-configure C as the master.
4. Re-configure B to slave from C.
5. Let things settle down for a day or so.
6. Disable DNS on A.

Another trick is to use only your slaves as the authoritative servers. The master server isn't used by clients and exists only to hold the master zone files. The slaves get their zone files from the master, which might be tucked away behind a firewall to help prevent tampering. You could have one single master that all slaves (across your whole organization) pull from, eliminating the administrative overhead of managing multiple masters.