Experience with DDNS (RFC 2136)
cet1 at cam.ac.uk
Thu Oct 6 19:26:48 UTC 2011
On Oct 6 2011, Jan-Piet Mens wrote:
>[ pardon the possible duplicate ]
>I'm a fan of RFC 2136 Dynamic DNS and, if I think it appropriate for a
>particular use case, sometimes suggest DDNS to customers. I often have
>a hard time convincing people to use DDNS and am doubted regarding its
>stability and/or performance.
>I'm looking for success (or failure) stories to back up my statement :)
>For example, I seem to recall hearing the .COM zone uses DDNS for
>updates (90 million records, isn't it?).
>Are you willing to share the stories of your DDNS deployments, maybe
>including approximate number of zones, records, update frequencies,
We converted all our regular DNS updating operations to use dynamic
updates in May 2005, for those zones for which we[*] are master.
That's currently 58 zones (many of them small, the largest is cam.ac.uk
with c. 50000 non-DNSSEC RRs) but would have been a few more then
before our reverse zone consolidation exercise.
We have never regretted this. We did have some Windows 2000 DNS Server
stealth slaves that had to be given "provide-ixfr no" settings because
they ****ed up applying incremental transfers, but they've all gone now
(thank $DEITY). We already had most of the input to our DNS zone content
generated from an external database (even more so now), but I don't
think that was critical. Deciding to write a "compare two zone files
and generate nsupdate input to convert one to the other" Perl script
I used to worry about drift, and I do still compare the zones with
what they ought to be from time to time, but usually the only issues
have derived from quick-and-dirty manual nsupdate operations bypassing
our regular procedures. The only significant exception I recall is a
problem to do with apex NS records, because BIND just ignores the
attempt to remove the last one. Our scripts allow for that now.
At that time we were only updating the zones once a day, in the small
hours, as the reload operation after replacing the zone files was a
major performance hiccup. Using dynamic update isn't the only thing
that has improved matters since then, of course, but it's certainly
one of them. We have a 4-hour update cycle now, and it's not the BIND
end of things that currently discourages us from speeding that up
Signing (some of) our DNS zones, which we started in 2009, would
have been much more difficult if we hadn't already been using dynamic
updates. And if we had done it anyway, it would have pushed us in
quite the wrong direction, using only dnssec-signzone to generate
We do of course have a backup mechanism to completely replace a zone
with new content (and sign it if necessary). That's the only situation
in which we use "freeze" and "thaw" operations on a zone.
In summary: stop thinking of the zone files used by named as human-
editable objects (and use "masterfile-format raw" while you are at it).
Use update operations for (very nearly) everything.
[*] in the absence of my long-sig, which I don't use on this list:
"we" is the University Computing Service in the University of
Email: cet1 at cam.ac.uk
More information about the bind-users