[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-dnsext-axfr-clarify-05.txt

> 	This is *not* just a IXFR problem.  It causes problems with
> 	servers that don't support IXFR.  I would hate to see a
> 	implementor say "I don't need to do this because I don't
> 	support IXFR".
> 
> 	See <200211280030.gAS0UYgU009457@drugs.dv.isc.org> for
> 	a detailed example of a non IXFR related problem that is
> 	fixed by preserving the zones contents.

Forgetting for a moment about whether we can find a problem with it,
there's a standards track RFC (#2136) with something to say on the
matter of zone identity and zone ownership:

   7.10. ... Visible (to DNS clients) SOA SERIALs need
   to differ if the zone differs. ...

   7.18. Previously existing names which are occluded by a new zone cut
   are still considered part of the parent zone, for the purposes of
   zone transfers, even though queries for such names will be referred
   to the new subzone's servers.  If a zone cut is removed, all parent
   zone names that were occluded by it will again become visible to
   queries.  (This is a clarification of [RFC1034].)

   7.19. If a server is authoritative for both a zone and its child,
   then queries for names at the zone cut between them will be answered
   authoritatively using only data from the child zone.  (This is a
   clarification of [RFC1034].)

So, whether a server can implicitly edit the data at the zone cut is not
a matter of operational necessity or of personal taste.  It's a matter of
definitional correctness.  A zone's identity is what the primary master
says it is.  Implementations such as BIND4, BIND8, and (apparently) DJBDNS
who implicitly edit a zone's apex because they are also authoritative for
the parent zone, are wrong.  axfr-clarify is not what makes them wrong.
They are just plain wrong.  The fix to BIND4 or BIND8 is "upgrade to BIND9."

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>