Subject: Re: axfr-clarify on the move again

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Nov 2002 20:43:08 -0000

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

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 19 Nov 2002 22:44:11 +0100

D. J. Bernstein wrote:

<SNIP>
>    (4) A6 records that those NS records point to.

<SNIP>

> because it kills the whole zone transfer, not just the new records.

<SNIP>

> Nobody would fall for

Lots of snipps, just to remind you that A6 has been moved to
experimental
and that you won't find it in 99.9999% of current actively deployed
systems.
Check http://cr.yp.to/djbdns/killa6.html which you wrote some time ago
:)

Greets,
 Jeroen

---

From: Kenji Rikitake <[email-masked]>
Date: Fri, 22 Nov 2002 15:27:54 +0900

To the readers of this mail:

I would like to urge that the database structure of BIND MUST NOT define
the semantics of DNS.  Breaking the RFC1034 model which assures the
uniqueness of DNS RR integrity will significantly hamper the fundamental
security of the current non-cryptographic DNS, which is still heavily
dependent of the uniqueness of AXFR-transferred data.  If you all
disapprove A6, please do NOT approve such an idea, again.

// Kenji Rikitake

---

From: Jonathan de Boyne Pollard <[email-masked]>
Date: Sat, 23 Nov 2002 11:18:40 +0000

DJB> Nobody would fall for it if the document imposed rules relating
DJB> to silly experiments like A6.
              ***********

JM> Lots of snipps, just to remind you that A6 has been moved to
JM> experimental [...]

It's pretty fair assumption that he had already remembered.