stealth server
Danny Mayer
mayer at gis.net
Thu Jul 12 16:20:01 UTC 2001
Kevin Darcy wrote:
> Brad Knowles wrote:
>
> > At 6:32 PM -0400 7/6/01, Kevin Darcy wrote:
> >
> > >> Uh, yes. Every change to the zone requires a change to the
> > >> serial number.
> > >
> > > 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.
> >
> > And I recently went through this issue with Paul Vixie. I
> > distinctly recall him saying that the serial number needed to be
> > updated with every change to the zone, regardless of what the RFCs
> > might say.
> >
> > When you want the complete proper answer, going to the documents
> > written by the experts is only the next-best thing to going directly
> > to the experts themselves.
>
> You said "Every change to the zone requires a change to the serial number". Let's
> be clear, then, that "requires" in that sentence means "conforms to Vixie's vision
> of DNS if and only if it generates ..." rather than "MUST, according to the RFC's,
> generate...". A subtle distinction, perhaps, but an important one if you're trying
> to skewer a vendor for their product's lack of standards-compliance.
>
> - Kevin
Is RFC 2136 Section 3.6 explicit enough for you (the definition of primary
master server is in Section 1)?
3.6 - Zone Identity
If the zone's SOA SERIAL is changed by an update operation, that
change must be in a positive direction (using modulo 2**32 arithmetic
as specified by [RFC1982]). Attempts to replace an SOA with one
whose SERIAL is less than the current one will be silently ignored by
the primary master server.
If the zone's SOA's SERIAL is not changed as a result of an update
operation, then the server shall increment it automatically before
the SOA or any changed name or RR or RRset is included in any
response or transfer. The primary master server's implementor might
choose to autoincrement the SOA SERIAL if any of the following events
occurs:
(1) Each update operation.
(2) A name, RR or RRset in the zone has changed and has subsequently
been visible to a DNS client since the unincremented SOA was
visible to a DNS client, and the SOA is about to become visible
to a DNS client.
(3) A configurable period of time has elapsed since the last update
operation. This period shall be less than or equal to one third
of the zone refresh time, and the default shall be the lesser of
that maximum and 300 seconds.
(4) A configurable number of updates has been applied since the last
SOA change. The default value for this configuration parameter
shall be one hundred (100).
It is imperative that the zone's contents and the SOA's SERIAL be
tightly synchronized. If the zone appears to change, the SOA must
appear to change as well.
Danny
More information about the bind-users
mailing list