Felix von Leitner writes:
> I don't understand your point about axfr-clarify-01 under the "What is
> allowed in a zone?" heading. I think you removed too much context.
Suppose there's a delegation from the heaven.af.mil zone:
heaven.af.mil SOA ...
heaven.af.mil NS ...
moon.heaven.af.mil NS ...
full.moon.heaven.af.mil ...
There are (at least) two zones here:
* the heaven.af.mil zone, which is authoritative for the
heaven.af.mil records, and
* the moon.heaven.af.mil zone, which is authoritative for
moon.heaven.af.mil and (presumably) full.moon.heaven.af.mil.
In the words of RFC 1034, section 4.2: ``After all cuts are made, each
group of connected name space is a separate zone. The zone is said to be
authoritative for all names in the connected region.''
Is a zone completely described by its authoritative records? No. A zone
can---and sometimes must---include records copied from other zones. For
example, the heaven.af.mil server needs to know the moon.heaven.af.mil
NS record. That record isn't part of the authoritative heaven.af.mil
data; it's part of the authoritative moon.heaven.af.mil data.
axfr-clarify-01 prohibits zone-transfer servers providing records ``from
the authoritative data of zones other than the one being transferred.''
For example, it prohibits the heaven.af.mil server from providing the
moon.heaven.af.mil NS record. This is ludicrous; it breaks delegations
in transferred zones.
Now, that isn't what the BIND company meant to say. What they really
want is to force everybody else to imitate a stupid mistake in BIND 9.
Namely, BIND 9 (on both the server side and the client side) reportedly
rejects non-authoritative records that are not
(1) NS records for which the parent node is in the zone,
(2) A records that those NS records point to,
(3) AAAA records that those NS records point to, or
(4) A6 records that those NS records point to.
For example, if the full.moon.heaven.af.mil record is included in the
heaven.af.mil zone, BIND 9 might or might not reject it, depending on
exactly what the record types and contents are.
There are many ways to see why this rule is flawed. Here's the easiest.
What happens if the IETF adds another address type beyond A/AAAA/A6?
Answer: a zone administrator who adds a record of that type causes a
complete zone-transfer failure with older versions of BIND 9. This is
even worse than the situation in http://cr.yp.to/djbdns/newtypes.html,
because it kills the whole zone transfer, not just the new records.
Now, the BIND company didn't explain that rule in their document. They
can't. They're trying to slip this past everybody as a ``clarification''
of how the ``fielded DNS server software'' works. Nobody would fall for
it if the document imposed rules relating to silly experiments like A6.
So the BIND company gave us the ridiculous axfr-clarify-01 rule. When I
pointed out how dumb that rule was, they replaced it with a horribly
unclear rule in axfr-clarify-02:
An RR is associated with a zone by being loaded from the master file
of that zone at the primary master server, or by some other,
equivalent method for configuring zone data. ... The transfer MUST
NOT include any RRs that are not associated with the zone, such as
RRs associated with zones other than the one being transferred.
My questions about the meaning of that rule remain unanswered.
> I wouldn't read it as prohibiting a single configuration file; the term
> "master file for that zone" in the djbdns context just means data.cdb,
That's certainly how the software is supposed to work, and it seems to
be a reasonable interpretation of ``associated'': the records for
moon.heaven.af.mil and full.moon.heaven.af.mil are associated with two
zones, heaven.af.mil and moon.heaven.af.mil.
However, the axfr-clarify-02 rule then contradicts itself:
MUST NOT include
any RRs that are not
associated with the zone ----- Sounds okay so far: the
moon.heaven.af.mil NS record
such as RRs associated with is associated with heaven.af.mil.
zones other than
the one being transferred. ----- Wait a minute! The record is
also associated with
moon.heaven.af.mil!
Is the moon.heaven.af.mil NS record allowed, or is it prohibited? What
about the record for full.moon.heaven.af.mil? How do we figure this out
from axfr-clarify-02?
The axfr-clarify-02 language presumes, incorrectly, that a record cannot
be ``associated'' with two zones simultaneously. To make sense of this,
you have to switch from the DNS standards' consistent-database model to
BIND 9's fractured-database model:
* Under RFC 1034, the Domain Name System has a single node named
full.moon.heaven.af.mil. The records at that node are copied to
any place that they're needed. If a copy isn't exact, the copying
mechanism has failed and should be fixed.
* According to BIND 9, the Domain Name System has two separate nodes
for ``full.heaven.af.mil in the heaven.af.mil zone'' and
``full.heaven.af.mil in the moon.heaven.af.mil zone.'' According to
BIND 9, those nodes are allowed to be different, and everybody else
has to change their software to keep track of the difference.
This is a rather fundamental change in the semantics of DNS, a change
incompatible with a huge amount of widely deployed software---yet the
BIND company claims that it's a ``clarification'' codifying ``existing
practice'' in accordance with the ``fielded DNS server software''!
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago