stealth server

Barry Margolin barmar at genuity.net
Fri Jul 6 23:15:22 UTC 2001


In article <9i5f1v$c28 at pub3.rc.vix.com>,
Kevin Darcy  <kcd at daimlerchrysler.com> wrote:
>Sigh. I just went through this on namedroppers. To summarize, although it was
>clearly *intended* for the SOA.SERIAL to be incremented for every change to a
>zone, there is apparently nowhere in the RFC's where this is explicitly
>*mandated*, except in the context of describing optional features like
>AXFR/IXFR or Dynamic Update. So there's plenty of wiggle room for an implementor
>to say that it's not mandatory in the general case...

Sure.  If you're doing all your server synchronization using rsync,
SOA.SERIAL is irrelevant, so it would be silly for the RFC's to mandate
updating a field that's not even being used.  Or if a zone file is being
updated manually and the administrator forgets to increment the serial
number, are you going to report him to the Internet Police for being
non-RFC-compliant? :;

But if you want to support slave DNS servers that synchronize using the
standard DNS mechanisms (AXFR or IXFR), incrementing the serial# is the
only way to alert them that they need to pull over a transfer.  Thus, if
you profess that your software is interoperable with standard slave DNS
servers, it's a logical conclusion that you must increment the serial
number (not necessarily for every change, the Dynamic Update RFC describes
several reasonable approaches).

This tangent is a bit silly in this context, because W2K DNS is clearly not
intentionally flaunting this requirement.  It does increment the serial
number, and there's simply a bug (which they've acknowledged) that causes
it to forget where it was when the server is rebooted.  They're trying to
conform to expectations, they just didn't do a good job.

That doesn't make it any less annoying to slave operators like me, though.
I've been tempted to ask our Customer Care department to send out a message
to customers warning them not to upgrade from WinNT to Win2K if we're
slaving DNS from them.

BTW, Raptor also has a buglet like this.  When the US changed from daylight
savings time to standard time last fall, the serial numbers of all the
domains mastered by Raptor firewalls dropped by the same amount (10 or 100,
I think).  It looked to me like they generate their serial number from the
date and time, and when the local time fell back, so did all the serial
numbers!  When we came in Monday morning, our log was full of "serial# <
ours" errors for about a dozen customers.

-- 
Barry Margolin, barmar at genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.


More information about the bind-users mailing list