Data served by DNS servers sometimes needs to be updated. Some administrators may add or remove the odd record once in a blue moon, others require very frequent updates, sometimes in the order of hundreds of updates per second.
If your DNS servers dole out data directly out some sort of relational database
system or LDAP directory server, adding a record can be as simple as an
INSERT or an
ldap_add operation. (My book discusses this extensively.)
As a BIND user (and one that does not use an SDB/DLZ database/LDAP back-end) you maintain DNS data in a zone master file which you typically modify with your favorite editor or generate from a data source, remembering to update the zone’s SOA serial number, etc.
I’ve always been a fan (and here is proof! :-) of RFC 2136 which allows me to update a zone dynamically using DNS UPDATE, but in the course of the past months, I’ve met a number of people who seem to distrust Dynamic DNS updates (DDNS), so I asked the experts for their opinion.
I got a lot of replies, most of which were off-list, (follow the thread to read the on-list replies), all from people who really know their DNS. :) Let me try to summarize.
- Dynamic DNS (DDNS) is very much alive, particularly with organizations who sign their zones with DNSSEC. It can be argued that DDNS is the only sane method of updating a signed zone, at least until DNSSEC In-line Signing shows up in the upcoming BIND 9.9 release.
- Some Top-level Domains (TLD) use DDNS to update their zones. (I’ve previously
incorrectly stated that
.COMuses DDNS.) For example
.UK, and a few others. (
.UKhas nicely documented what they did.)
- RIPE NCC uses DDNS to provision zones with about 500k delegations in them.
- An interesting use of DDNS was mentioned privately: an organization monitors availability of some servers and uses DDNS to update an A/AAAA record to point to the currently preferred server.
- One person reported they do frequent updates to multiple zones, each with over a million records.
- And here is one verbatim quote: “DDNS is essential if you want to update any large zone frequently, just as IXFR is essential for updating large zones among slave servers.”
- Several people confirmed they have custom-made programs which determine a change-set from a database back-end and send out DDNS updates to their servers.
- Chris Thompson of Cambridge has an interesting story.
One person I regard highly said he thought corporate users don’t like DDNS because of “lack of decent audit trails, versioning, and access controls”. Admittedly, keeping a zone file in a version control system does allow me to rather easily back-out of changes if needed, on the other hand, changes are recorded in the server’s journal file (but are quite difficult to reverse out of).
My stance is as follows:
- DDNS in BIND is very stable. Updates bump the
IXFRallows slave servers to very quickly pull in the change-set.
- Distributing TSIG or SIG(0) keys required for updates is difficult (even within an organization) and should be avoided where possible.
- Try to front DDNS updates with some sort of RESTful interface to which you can add any flavor of authentication/authorization system.
- It is worth experimenting a bit to speed up large amounts of updates.