[bind10-dev] Zone loading requirements, take 1

[Shane Kerr]

Evan,

Thanks for looking at this!

On Friday, 2012-03-02 16:37:32 +0000, 
Evan Hunt <each at isc.org> wrote:
> > * In principle one can load a zone with data at the same name as a
> >   CNAME. It's not supposed to be allowed, but I can imagine an
> >   administrator wanting to serve such a zone anyway. What does BIND
> > 9 do if this happens? What should we do?
> 
> The zone won't load in BIND 9.

There is "won't load" and "won't load, really I mean it". So, even if
you can't coerce BIND 9 to load a zone file with such data, what
happens when BIND 9 is acting as a secondary? Does it still refuse to
accept the zone? If not, what answers do you get?

I'm kind of inclined to think that a CNAME should "hide" the other
RRtypes at that name, in a way similar to an NS record "hiding" longer
names.

> > * If no TTL is specified at all, RFC 1035 is ambiguous. I have
> >   specified this as a warning, and we use 3600. I think this is what
> >   BIND 9 does, but I'm not sure.
> 
> It logs a warning and uses SOA MINTTL if the SOA happens to be the
> first thing in the file; otherwise it rejects the file.

According to RFC 2308 we see:

   The SOA minimum field has been overloaded in the past to have three
   different meanings, the minimum TTL value of all RRs in a zone, the
   default TTL of RRs which did not contain a TTL value and the TTL of
   negative responses.

   Despite being the original defined meaning, the first of these, the
   minimum TTL value of all RRs in a zone, has never in practice been
   used and is hereby deprecated.

   The second, the default TTL of RRs which contain no explicit TTL in
   the master zone file, is relevant only at the primary server.  After
   a zone transfer all RRs have explicit TTLs and it is impossible to
   determine whether the TTL for a record was explicitly set or derived
   from the default after a zone transfer.  Where a server does not
   require RRs to include the TTL value explicitly, it should provide a
   mechanism, not being the value of the MINIMUM field of the SOA
   record, from which the missing TTL values are obtained.  How this is
   done is implementation dependent.

So BIND 9's behavior makes sense. I've updated 3.3.25 to be mostly the
same as this.

> > * I looked through all 11 tests that BIND 9 has for zone loading.
> > We'll have a few more. ;) One test confuses me:
> >  [...]
> >    How can this possibly load properly? Doesn't the first record of
> > a zone have to be an SOA record? (And yes the comment for the
> >    configuration is wrong, it is test 10 not test 9.)
> 
> There is no "first" record.  By convention we put the SOA first and NS
> after, and both are required, but they don't need to be in any
> particular order.

Hm... RFC 1035 pre-dates the SHOULD/MUST/MAY language of modern RFCs,
and maybe this particular recommendation has been superseded, but it
seems to indicate that actually the SOA should be the first record in
section 5.2:

   2. Exactly one SOA RR should be present at the top of the zone.

> The reason that test works is that it's not a zone-loading test, it's
> a masterfile-parsing test.

Ah, right. Are there any explicit zone loading tests that you know of?

Thanks again for answering,

--
Shane