Re: axfr-clarify on the move again

[gson@nominum.com (Andreas Gustafsson)]

Kenji Rikitake writes:
> > Please define what you mean by "uniqueness of DNS RR integrity" and
> > 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.

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.

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

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.

> > 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".
> 
> I will try to describe the definitions by referring to the following
> explanation.
> [...]
> -- 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, 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
> fundamental basis of Internet security as a set of distributed system.

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.

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

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.

> > Also, please define the property of "uniqueness of AXFR-transferred
> > 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.

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, 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/>