Re: axfr-clarify on the move again

[gson@nominum.com (Andreas Gustafsson)]

[I'm responding to a message which was CC:d to namedroppers@ops.ietf.org,
iesg@ietf.org, and ietf@ietf.org, but which I have not yet seen appear on
namedroppers.  I'm omitting ietf@ietf.org from the list of
recipients since this discussion really doesn't belong there.]

Dan Berstein wrote:
> > 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.

No argument there.

> 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.

No, it does not.  It says that when transferring the heaven.af.mil
zone, the master server MUST provide the moon.heaven.af.mil NS records
that are present as non-authoritative data copied into the the
heaven.af.mil.zone.  What it prohibits is sending the authoritative
moon.heaven.af.mil NS records in the moon.heaven.af.mil zone instead
of, or in addition to, the non-authorative ones in the parent just
because the server happens to be authoritative for both 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.

That's completely false.  BIND 9 does not reject such records, and
never has.

> 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!

In the draft's terminology, a record is associated with exactly one
zone.  What you describe can be seen as there being two identical
moon.heaven.af.mil records, one associated with the parent zone and
one with the child zone, both configured using a single, shared line
in the data.cdb file.  The draft says the transfer includes the parent
copy, not the child copy, but in this case the distinction does not
matter since they are are identical; what matters is that the server
behaves as if the parent copy was transferred (even if only one record
is actually stored).  The case of full.moon.heaven.af.mil is similar.

It is not the intent of the draft to outlaw this or any other
configuration mechanism for primary master servers.  Being the primary
master, it defines the contents of the zones, and is free to do that
in whichever way it likes, including ways which enforce consistency
between parent and child at the delegation point or even ones that
define parents as containing the union of their children.

The draft is mainly concerned with the case where the server is a
*slave* for one or both of the zones involved (and may also act as a
master to downstream slaves).  In those cases, the contents of the
zones being slaved have been defined by someone else, and they should
be respected by the slave server and should be transmitted verbatim to
downstream slaves, and that includes non-authoritative parts for which
the slave server has conflicting authoritative data in a child zone.

> 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?

If your server defines the moon.heaven.af.mil zone as containing those
records in its non-authoritative (glue) data, then yes, transferring
them is allowed (and required).

> 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.

RFC1034 talks about copying "NS and glue RRs" to the parent, not
entire nodes.

>    * 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.

The vast majority of all delegations in the DNS are between physically
separate parent and child servers.  This means that even if you like
to think that there is a single conceptual "node" at the delegation
point, there are in fact two separate physical nodes, one at the
parent server and one at the child server.  In a correctly configured
delegation these nodes will have identical NS records, but in practice
they are often differences.  In terms of records other than NS, the
nodes are completely different - for example, the child has an SOA
record but the parent does not, and various DNSSEC related records
will be present in one but not the other or even differently in both.
In reality, the DNS *is* a fractured database.

Since the nodes are separate when the zones are on separate servers,
it makes sense for them to also be separate when they zones happen to
be on the same server.  RFC1035 goes as far as saying that the
"suggested data structure" for a name server has "Separate data
structures for each of the zones held by the name server".  BIND 4 and
BIND 8 failed to follow this suggestion and stored their data in a
single tree sharing a node between parent and child, and while this
did work in most cases, problems quickly became apparent as the IETF
DNS standards evolved.  For example, the incremental zone transfer
(RFC1995) protocol makes the implicit assumption that the zone data do
not spontaneously change, but with a shared node, that's exactly what
will happen to glue data in the parent as changes are made in the
child.  When a downstream IXFR slave receives a combination of AXFRs
and IXFRs from multiple masters, such spontaneous changes will cause
the IXFR protocol to get out of sync.

The DNSSEC protocol (RFC2065) even specifically requires that the
parent and child store different NXT records at the delegation point,
which is impossible to do if the node is shared.  A server using the
data structures of BIND 4 or BIND 8 simply will not meet the
requirements of these protocols, and this was one of the reasons why
BIND 9 was written in the first place.  This is a case of BIND being
changed because of the standards, not of the standards being changed
because of BIND.
-- 
Andreas Gustafsson, gson@nominum.com

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