Organizing Your DNS?

Neil Watson asks: "In previous organizations I've kept track of IPs, hostnames and DNS entries by using a single hosts file. I used a script (h2n) to convert the hosts file to DNS entries (BIND). Thus, all information was available in a single text file. For Microsoft Active Directory servers, we had that system's DNS server simply forward all of its requests to the BIND server. Now, I find myself at another organization. This network is considerably larger, with more name servers. The control of IPs, hostnames and DNS entries is somewhat loose, and it is starting take its toll. How do you organize all of your DNS information in order to easily assign and track all of the entries?"

Comments

1. Consolidate Authority - 2. Install a frontend

[jgaynor]

It seems to me that most of your problems can be solved with a little politcal weight-throwing.

This network is considerably larger, with more name servers. The control of IPs, hostnames and DNS entries is somewhat loose, and it is starting take its toll.

The number of nameservers is irrelevant as long as they're master/slave. Are each of these NS boxen run by a different business unit/department? If so, find the group with the organizational proponency for DNS (probably you) and demand that they be given full control. Assign a hostmaster for your organization and funnel ANY and ALL dns changes through him/her/it. Authority for subdomains can still be given out, but force a signed waiver to cover your ass when they shoot themselves in the foor by running 2k3 AD as a production NS service.

Once this is done you'll probably want to ditch the flat-file approach and run some sort of frontend. It guarantees that when your hostmaster eventually quits you wont have to find another expensive geek. I used to run the webmin plugin for BIND, but stopped once I saw what a security nightmare webmin was. Don't have much experience with anything else besides custom solutions but nictool and oDNS have their supporters.

Extend the hosts file metaphor

[Zocalo]

You don't say how many domains you are dealing with, but unless it's something obscene then getting all your zones to include one "gold" server on their NS list is a good start. The zone files themselves then provide all the IP information you might need on the hosts, especially if you also include HINFO or TXT records for your hosts. Ideally this would be the SOA for all the domains, and not used for anything other than acting as authoritive DNS for secondaries that would handle the actual queries although if you are delegating administration on subdomains that might not be practical. Note that on BIND (and presumably other DNS servers), your listed "authoritive" DNS servers, including the SOA if you wish, can actually be slaves to a "hidden" server or servers that only they can query, which can be very useful in designing a management structure.

Depending on how many people are updating the zones, what kind of security you need on that, and how many zones you actually have then start looking at GUI/web based frontends and database backends. Personally, I'd try and assign a few designated hostmasters to administer all DNS changes centrally, but if that meets objection and you don't have or can't get enough weight to overrule it it's not a major problem. There are plenty of quite decent web based GUIs out there to interface with the zone files directly or things like SQL and LDAP based backends, pretty much all of the better ones allow you to apply access control somewhere in the implementatation. If you are considering a database based backend though, be very careful about your selection and implementation if there are any dynamic zones (especially Active Directory, since you mention Windows) in the mix!

Re:hehe

[Anonymous Coward]

That's just plain argument by assertion, and this is just plain ad-hominum attack.

I suggest that careful editing of configuration files such as a host file processed by h2n might not be a bad approach. Of course, one is allowed to write additional scripts or programs to check configuration file syntax, consistency and the like, and to make it easier to manage large zones. One could even use make to cause the generation, application, and activation of appropriate DNS zones. Or not. If you can't type, those GUI point-and-click things are right handy.