[dns-operations] Recommended zone serial number format for over 100 changes / day

Mike Hoskins (michoski) michoski at cisco.com
Fri Apr 1 13:41:03 UTC 2016


On 4/1/16, 9:14 AM, "dns-operations on behalf of Ray Bellis"
<dns-operations-bounces at dns-oarc.net on behalf of ray at isc.org> wrote:


>On 31/03/2016 18:12, Matthew Ghali wrote:
>
>> If your data is in constant flux, shoehorning it into a constant series
>> of point-in-time snapshots seems pointless and inefficient. This is
>> probably why Route 53 doesn't bother supporting zone transfers.
>
>AFAIK Route 53 doesn't bother supporting zone transfers because it's not
>supported by the underlying software (djbdns).

I think it's more of a roadmap thing...  all about priority.  Having used
djbdns for a decade or so in a past life, it does support zone transfers
-- just not zone-transfer.  His argument is not anti-transfer but more why
invent a new potentially insecure mechanism when you have rsync (to each
there own), but even beyond that you've got stuff like axfrdns which calls
out:

"Zone-transfer clients rely on zone serial numbers changing for every zone
modification. tinydns-data uses the modification time of the data file as
its serial number for all zones. Do not make more than one modification
per second."

Simply use mtime of the zone file and batch any sub-second updates...  I
have been doing this with hundreds of zones, at least a few of which are
DDNS with thousands of clients, and not had any problems aside from some
tools balking at the serial format.  Really, you have to see tools as a
useful data point not the ultimate authority when you know you are doing
nothing wrong.  :-)

Taking route53 in context (have used them for several years now as well,
though on a much smaller scale) -- "an API for everything" is the cloud
mantra.  If I'm a developer in a small/modern IT shop looking for a DNS
service to support my cloud services, an API makes sense.  They've said
they will consider adding transfer support, I'm guessing it's just not a
top priority based on their primary audience.  Maybe if/when they do, they
can share how they solve sub-second updates.  ;-)





More information about the dns-operations mailing list