ietf
[Top] [All Lists]

Re: axfr-clarify breaking RFC 1034

2003-02-19 02:54:43
    Date:        19 Feb 2003 05:44:54 -0000
    From:        "D. J. Bernstein" <djb(_at_)cr(_dot_)yp(_dot_)to>
    Message-ID:  
<20030219054454(_dot_)19702(_dot_)qmail(_at_)cr(_dot_)yp(_dot_)to>

  | In the situation under discussion, one server has both zones, so that
  | server _can_ guarantee RFC 1034 consistency---and my server _does_.
  | (BIND 8 also does, to some extent. BIND 9 doesn't.)

There are two requirements (in this general area) on servers in the DNS.
One is that two servers for the same zone give the same answers to the
same questions (except in the interval between an update to one server
and its being made known to the other, during which time the SOA serial
numbers will differ).   (AXFR is one such possible question).

Second, glue records should be copied from the authoritative zone to the
parent, so they are the same in both zones.   Again, there is necessarily
going to sometimes be a delay between when the child zone is updated and
when the parent is updated.

Your reading of the requirements means that in order to shorten the
delay in the second case, in some circumstances, you're willing to generate
cases where the first incompatibility (servers for the same zone returning
different answers) will exist, without the serial numbers differing (and
with no defined method of reconciling the issue - that is, there is no
way of knowing which answer is the "correct" one).

In the parent/child case, if there is a difference, the child's answers are
correct by definition.   In the "different zones after an update" case, the
server with the higher serial number is correct, the lower is out of date.
In the case we have been discussing, the answers differ, both servers are
serving the same zone, the serial numbers are the same, which answer should
be used?   How can anyone guess?

Just about everyone here seems to be convinced that the (negligible) gain
to be gained from forcing the parent and child to contain the same records
in the cases where that is feasible is not worth the kind of problems this
can cause to the first requirement (which in hard cases can actually be
difficult to fix without manual intervention - it won't always just "fix
itself" though normal correct operation of the servers).   The requirements
you're insisting upon enforcing in your servers trivially fix themselves
when the parent zone is updated (remember you assume that if the human
doesn't do that, any problems are of their own making...)

If you have a proposal for some method to actually cause the parent/child
delegation to *always* be compatible (glue in parent matches records in child,
always), then please don't keep it a secret, I'd really like to see it.

Until then, assuming that this will always be true, and writing off all
other cases as "configuration error, anything is allowed to happen" is
inappropriate.

kre




<Prev in Thread] Current Thread [Next in Thread>