Date: 15 Feb 2003 04:29:44 -0000
From: "D. J. Bernstein" <djb@cr.yp.to>
Message-ID: <20030215042944.95101.qmail@cr.yp.to>
| * The BIND company's ``AXFR clarifications'' try to eliminate the
| RFC 1034 database-consistency requirements, allowing data for the
| same class+name+type to vary across zones, contrary to RFC 1034,
| sections 4.2.1 and 4.2.2.
Most of your arguments aren't worth replying to. This one looks like
it has merit on first glance. But when examined closely it doesn't.
The database consistency requirements in 1034 *have* to be requirements
imposed upon the operators of the DNS, not the software, as there is
no mechanism in existence which allows the software to ensure this
consistency.
The issue here is "glue" records copied into a parent zone from a child.
If the parent and child are in the same server, the software is able to
ensure that the glue records in the parent are identical to what is in
the child zone - that's what early BIND software did, and I am guessing
that is what your server does. From a naïve point of view, this looks
to be a good thing.
On the other hand, if the parent and child are operating in different
servers then there's nothing that causes the glue in the parent to be
the same as the records in the child - I have long wished that there
could be (by having the parent actually go query the child, repeatedly)
but for scaling and other reasons, it simply wouldn't work.
Now for your average query this turns out to not matter (which is how
BIND got away with being broken for so long) - a query to a server that
holds both zones will receive its answer using the data that is the child
zone (the zone that actually holds the record in question, or the nearest
parent of that) and so will (assuming the query requests it, one way or
another) get the data (which is glue in the parent) from the child zone.
A query addressed to a parent which doesn't also hold the child zone will
get the glue as added in the parent zone, unaffected by whatever might be
in the child.
Well - most of the time. And this is where the problems arise, and why
AXFR is relevant to all of this. If the server for only the parent
did a zone transfer from the server that is also a server for the child
zone, then (using the zone smashing style of earlier BIND) the transfer
it gets contains the records from the child zone, instead of what was
actually configured into the parent zone.
On the other hand, a different server for the parent zone alone, which
did its AXFR from a server that was configured with the parent zone data
and had never seen the child zone (or is a server configured manually
itself, with only the parent zone), would have only the configured glue.
Now we have two servers for the parent only, giving out different answers,
from the same zone, with the same serial number. That's simply
unacceptable, and wrong, and always has been. Early BIND had even worse
problems in this area, but they're not relevant here - except that I
certainly hope that no-one is going to come out of the woodwork and
say that because (10 years ago) 99% of the nameservers were running BIND4
that the DNS specs must be "clarified" to document the way that BIND4
worked ... which is the logical conclusion of some of the arguments that
are being made here.
Even ignoring any issues with doing incremental zone transfers, it is
important that a resolver be able to pick any of several different servers
for a zone, with confidence that it will receive the same answer (if it
receives an answer at all). If the server selected also happens to be a
server for a child zone that would eventually need to be queried anyway,
that's fine, just avoids an extra query getting from parent to child.
But with incremental zone transfer it is essential that there is a well
defined version of what is the content of the zone, so that the clients
of those protocols can sanely apply updates - most particularly when the
server for the (incremental) transfer isn't one fixed system, but can
be any of several others.
That is, DNS database consistency is important, but (unless we were to ever
create some other method of ensuring it) it is the operators who have to
make it happen - DNS software, at least using the DNS protocols as defined,
simply cannot, and more, must not, attempt to achieve this on the user's
behalf - doing so causes worse problems that not.
Tools to ensure that the parent domain has the correct glue, where glue
is needed, and to keep that correctly up to date when the child zone
makes changes would be a very worthwhile thing to create and make
available. But they're not related to AXFR, which transfers one zone
from one server to another, and must do that without causing the zone
to change (perhaps as it is transferred along a chain of many servers).
kre