Subject: Re: do implementations discard the response when TC is set?

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Aug 2004 02:20:58 -0000

The deployed AXFR protocol allows servers to repeat records. Clients are
responsible for removing duplicates.

BIND 8 repeats records. BIND 9 doesn't. (My software doesn't.) Both
behaviors are permitted by the protocol.

Vixie claims that I said BIND 9 ``misinterpreted the AXFR spec.'' Vixie
says he didn't find my ``argument'' very ``convincing.''

But I never said anything of the sort. BIND 9's behavior is permitted by
the existing protocol. Interoperability doesn't demand either behavior.
It's up to the implementor to consider database format, speed, etc.

The problem was with the BIND company's AXFR ``clarifications'' (e.g.,
axfr-clarify-02), which said that each record ``MUST be transmitted
exactly once.'' That's not a ``clarification''; it's not a codification
of ``existing practice''; it's not a description of ``the fielded DNS
server software.'' It's BIND 9's private implementation decision being
misrepresented as an Internet protocol. It violates Section 6 of RFC
2119. It is not necessary for interoperability.

This is just one example of the problems in the AXFR ``clarifications'';
see http://cr.yp.to/djbdns/axfr-clarify.html. People interested in how
AXFR actually works should read http://cr.yp.to/djbdns/axfr-notes.html.

Vixie says that BIND 9 will ``track the RFC's.'' Well, gee: when the
BIND company sits around publishing RFCs that say ``All DNS software
must make these implementation choices, because we've made these choices
for BIND 9,'' is it a surprise that BIND 9 is tracking the RFCs?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

--
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: Pekka Savola <[email-masked]>
Date: Sun, 29 Aug 2004 11:41:53 +0300 (EEST)

On Sat, 28 Aug 2004, Paul Vixie wrote:
> I have no knowledge of BIND9's behaviour.  I suspect that it's the same
> as what I describe for BIND8.  But I mostly stopped writing code a few
> years ago, and the reason I didn't describe BIND9's behaviour above is
> not that it's known by me to be different, but because I don't know it.

OK, thanks for acking that.  Let's hear if those responsible will 
comment.

> > Are there plans to change the behaviour, or are there specific good
> > reasons to do so?
> 
> ISC's position is that we'll track the RFC's.  The current behaviour is
> our interpretation of what the current RFC's tell, or imply, us to do.
> If a new RFC comes along, or if someone argues convincingly that our
> interpretation is wrong, then BIND will be changed.

It's already in the RFC. RFC 2181 section 9 second paragraph says
(second sentence):

   Where TC is set, the partial RRSet that would not completely fit may
   be left in the response.  When a DNS client receives a reply with TC
   set, it should ignore that response, and query again, using a
   mechanism, such as a TCP connection, that will permit larger replies.

i.e., ignoring the response is a "should".

> > This has some implications as it may lead to inconsistent data which
> > cannot be retrieved in any other (when used for particular type of
> > glue) way getting into the caches.
> 
> Please explain.  This is a strong area of interest for me, since BIND4's
> berzerkness about caching is what caused me to have to start working on it
> in the first place.  (I didn't always know what was wrong, but I knew what
> I didn't like.)

I have tried to explain this in draft-ietf-dnsop-ipv6-issues-09.txt, 
section 4.4, but it still requires revision to spell it out properly.

The problem is that there is glue which may not be otherwise
retrievable.  If only part of that is told and cached (due to
truncation, and not discarded and fetched in entirety w/ TCP), it
might be that the caches include incomplete or inconsistent
information about glue.  And if you consider that the incomplete glue
could be missing v4 records and v6 is unreachable, or missing v6
records and v4 is unreachable, it would be possible to get to the
situation where you will not be able to reach the authoritative
resolvers because some of the cached incomplete records do not work
(for some resolvers at least), but if you had the complete
information, it would work.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings