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