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: [email-masked] (Andreas Gustafsson)
Date: Fri, 22 Nov 2002 11:29:29 -0800 (PST)

[[email-masked] has once again been removed from list of recipients.]

> disapprove A6, please do NOT approve such an idea, again.

I'm sorry, but I'm unable to make sense of this message - it is vague
to the degree that I can't even tell for sure if it is a statement for
or against axfr-clarify.  I'm guessing against, but I can't defend the
draft until I understand what you actually mean by your criticism.

Please define what you mean by "uniqueness of DNS RR integrity" and
explain how it is "assured by the RFC1034 model".

Please explain how the axfr-clarify draft "breaks" this, and exactly
how that will "significantly hamper the fundamental security of the
current non-cryptographic DNS".

Also, please define the property of "uniqueness of AXFR-transferred
data" and explain how the "fundamental security" depends on it.

-- 
Andreas Gustafsson, [email-masked]

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

---

From: Kenji Rikitake <[email-masked]>
Date: Sat, 23 Nov 2002 12:54:38 +0900

Dear Andreas: 

I do not want to involve in the definition game you have proposed, since
I do not want to waste time of the readers.  I'll keep it concise just
for the fairness and showing my respect for your offering to defend your
argument, and to give the answers you requested to me:

Yes, I am against axfr-clarify.  I 100% support Daniel J. Bernstein's
argument on this issue.  Please reread
http://cr.yp.to/djbdns/axfr-clarify.html
for the details.  

Please allow me repeat this:

RFC1034 Section 2.2. on DNS design goals:

-- quote --

   - The primary goal is a consistent name space which will be used
     for referring to resources.  In order to avoid the problems
     caused by ad hoc encodings, names should not be required to
     contain network identifiers, addresses, routes, or similar
     information as part of the name.

-- unquote --

My argument is that: allowing an RR to have two or more inconsistent
(not equal to each other) contents, by allowing different contents of
RRs in two or multiple zones, is inconsistent with this design goal, and
is against DNS semantics.  

I would refrain from engaging in future arguments on this issue.

I appreciate your response, Andreas.

// Kenji Rikitake

---

From: Kenji Rikitake <[email-masked]>
Date: Sat, 23 Nov 2002 16:21:58 +0900

Dear readers: please allow me once again to explain.  One of my friends
told me I must make a fair acceptable of Andreas's argument.

In the message <[email-masked]>
at Fri, Nov 22, 2002 at 11:29:07AM -0800,

> explain how it is "assured by the RFC1034 model".

Uniqueness of DNS RR integrity: a RR, whereever it is stored, in a DNS
cache or a DNS server, is the same as the other copies.

Assurance of the RFC1034 model: See RFC1034 Section 2.2 as I mentioned
in a previous message.  It says "names should not be required to contain
network identifiers, addresses, routes, or similar information as part
of the name."

> current non-cryptographic DNS".

I will try to describe the definitions by referring to the following
explanation.

As written in the axfr-clarify-04 draft of Section 4 on Zone Data,
(I could not obtain the -05 draft due to the deletion from the
Internet-Draft mirrors in my house), it says that:

-- quote --

   The slave MUST associate the RRs received in a zone transfer with the
   specific zone being transferred, and maintain that association for
   purposes of acting as a master in outgoing transfers.

-- unquote --

This means if you have two different master servers inconsistent with
each other, the slave received data from those servers, should keep the
inconsistency as is.  This will significantly hamper at least the
consistency of the replicated DNS databases.  The DNS consistency is a
fundamental basis of Internet security as a set of distributed system.

DJB's dnscache has an effective heuristic algorithm which he is
explained in the Section of "Parents and Discrepancies" of
http://cr.yp.to/djbdns/axfr-clarify.html to eliminate this sort of
inconsistency, which is actually doing *good* for keeping DNS as
consistent as possible.  By this draft, this sort of heuristics is
denied.  This is unacceptable.

> data" and explain how the "fundamental security" depends on it.

The uniqueness of AXFR-transferred data is described by the consistency
(i.e., being equal byte-to-byte) between the RRs received by a slave
server from two or more different master servers is maintained.

The fundamental security: the reliability and robustness of the current
DNS as a whole.

I hope I make sense this time.

// Kenji Rikitake

---

From: Kenji Rikitake <[email-masked]>
Date: Sat, 23 Nov 2002 16:28:44 +0900

Corrections:

In the message <[email-masked]>
at Sat, Nov 23, 2002 at 04:21:36PM +0900,

> told me I must make a fair acceptable of Andreas's argument.

'a fair acceptance' instead of 'a fair acceptable'

> inconsistency as is.  This will significantly hamper at least the

'those server, MUST keep the' instead of '
'those server, should keep the' is correct.

Please excuse me for the errors.

// Kenji Rikitake

---

From: [email-masked] (Andreas Gustafsson)
Date: Sat, 23 Nov 2002 16:17:52 -0800 (PST)

> cache or a DNS server, is the same as the other copies.

I agree that this should be the goal, but the DNS protocol does not
itself enforce consistency of glue data between parent and child - it
is achieved through the operational procedure of copying glue records
from child to parent.

> network identifiers, addresses, routes, or similar information as part

That text is about a completely unrelated issue - it is talking about
the names themselves, not about the data they are associated with.  It
is simply noting that naming schemes like UUCP bang paths (e.g.,
uunet!mcvax!santra), where the very name of a host contains
information about how to reach it, are a bad idea.  I think we all
agree on that, but it is not what we are talking about here.

> [...]
> each other, the slave received data from those servers, MUST keep the
> inconsistency as is.

Yes, though I must stress that we are specifically talking about
inconsistencies between the master of a parent and the master of a
child, not about inconsistencies between multiple masters for the same
zone.

> This will significantly hamper at least the
> consistency of the replicated DNS databases.

The semantics specified in the draft do not cause any new
inconsistencies, they only preserve parent-child inconsistencies that
are already there, just as they will be preserved in the typical case
where the parent and child are hosted on physically separate servers.
Although it is possible to enforce parent-child consistency in the way
DJB proposes in the rare case where they happen to be hosted on the
same server, that is at the expense of consistency among the
authoritative servers for the parent zone ("parent-parent consistency"),
since not all the parent servers will have the child zone and therefore
the opportunity to "correct" their glue data.

> The DNS consistency is a

Parent-child glue consistency is not a security issue.  If it were,
then surely we ought to develop a method to guarantee that consistency
everywhere, not just in the rare case where they happen to be hosted
on the same server.

> denied.  This is unacceptable.

It may be doing some good for parent-child consistency, but at the
expense of breaking parent-parent consistency.

Note that from the perspective of a client querying (not AXFRing) the
combined parent-child slave server, there is no difference between the
axfr-clarify semantics and DJB's semantics - in both cases, a query
for the NS records at the delegation point will return the child's
records, as it should. The difference is only visible to downstream
parent-only slaves that transfer the parent zone from the combined
parent-child server, and to clients querying such a downstream server.
With the axfr-clarify semantics, that parent server will have the
parent NS records; with the DJB semantics, it will have the child NS
records.

> server from two or more different master servers is maintained.

I figured that's what you meant.  That's why I was confused as to
whether you were speaking for or against the draft, since the property
you describe is precisely the property the axfr-clarify draft is
trying to guarantee and the one DJB's server will violate.
-- 
Andreas Gustafsson, [email-masked]

---

From: Kenji Rikitake <[email-masked]>
Date: Sun, 24 Nov 2002 10:30:00 +0900

I should admit my knowledge is insufficient so my position is simply too
weak for claiming which strategy, of axfr-clarify, or DJB's, should be
chosen.  Please excuse me for being not able to contribute on the core
issue.  You can dismiss me from the further discussion.  On the other
issues of the axfr-clarify explained by Andreas, his points are well
understood.  I appreciate your time.

// Kenji Rikitake

In the message <[email-masked]>
at Sat, Nov 23, 2002 at 04:17:30PM -0800,

---

From: "D. J. Bernstein" <[email-masked]>
Date: 24 Nov 2002 09:14:20 -0000

Andreas Gustafsson writes:
> itself enforce consistency of glue data between parent and child

RFC 1034 and RFC 1035 make crystal clear that record sets in the Domain
Name System at any moment are indexed by class+name+type. Nothing else.

Does this semantic rule mean that copies of data around the Internet are
magically equalized if they have the same class+name+type?

Of course not. Most of the copying protocols have reliability problems,
producing accidental (though usually harmless) inconsistencies. Often
people deliberately introduce inconsistencies---for example, giving
different answers to different clients.

What, then, does the semantic rule mean?

The answer is simple: Implementations are free to store record sets by
class+name+type. If they're faced with two record sets of the same
class+name+type, they can throw one away. Three examples:

   1. Consider, once again, client differentiation, or ``views'' in BIND
      9: some servers store data by class+name+type+clientIP. Everybody
      else is free to assume that this doesn't happen. For example, a
      cache that uses two IP addresses for its outgoing requests, and
      receives different data under the same class+name+type on the two
      IP addresses, is under absolutely no obligation to keep track of
      both record sets.

   2. Consider, as a simpler example, the fact that different servers
      for a zone can have different data. Everybody else is free to
      assume that this doesn't happen. If I receive different record
      sets from the two servers, under the same class+name+type, I can
      use either one. I'm under no obligation to keep track of both
      record sets.

   3. Finally, getting back to the situation under discussion: It's
      certainly possible for a parent and a child to have different data
      for the same class+name+type. But everybody else is free to assume
      that this doesn't happen. If I receive different record sets from
      the two servers, under the same class+name+type, I can use either
      one. I'm under no obligation to keep track of both record sets.

In short, the fact that _you_ index your database by something more than
class+name+type does not oblige _me_ to do the same thing.

Andersson argues that the possibility of differing data means that
everyone else has to keep track of the differences. That argument is
clearly fallacious. I'm sure Andersson doesn't believe it himself: the
absurdity of the argument is obvious in situation #2, for example.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 25 Nov 2002 11:38:34 -0500

>Name System at any moment are indexed by class+name+type. Nothing else.

RFC 2181, Section 5.4.1., defines a differentiation between two RR 
sets matching the same {QNAME, QTYPE, QCLASS}.

>       IP addresses, is under absolutely no obligation to keep track of

An implementation choice, not part of the DNS protocol.

>       use either one. I'm under no obligation to keep track of both

RFC 2181, Section 5.4.1.

>       one. I'm under no obligation to keep track of both record sets.

RFC 2181, Section 5.4.1.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: "D. J. Bernstein" <[email-masked]>
Date: 25 Nov 2002 17:44:57 -0000

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  your subscription address is
  [email-masked], please post from it or
  fix subscription your subscription address! ]

> sets matching the same {QNAME, QTYPE, QCLASS}.

Learn to read. RFC 2181 is completely consistent with what I said. It
does _not_ require anybody to keep track of two record sets under the
same class+name+type. On the contrary: RFC 2181 suggests a particular
strategy for deciding which record set to throw away. The core of that
strategy is choosing child data over parent data, which is exactly what
I tell AXFR users to do.

I don't mean to suggest that I approve of (elective proposed standard)
RFC 2181. On the contrary: several parts of it, including this strategy
over-specification, are implementation details whose standardization
blatantly violates RFC 2119, and some parts of it are really bad ideas.
But it certainly doesn't contradict what I'm saying about axfr-clarify.