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

From: Pekka Savola <[email-masked]>
Date: Sat, 28 Aug 2004 08:51:08 +0300 (EEST)

Paul, you leave a lot unstated, so I must query again ;-).

[Pekka Savola:]
>> When Paul said, "doesn't cache it", it could be read two ways: the 
>> resolver will use it locally (as long as it's not cached), or it 
>> won't be used at all (i.e., it's discarded).
>> 
>> Which is it?
>
>[Paul]
>in the case of BIND, TCP retry is done.  BIND8 will cache nonempty
>sections other than the last one, on the assumption that those
>sections were not truncated.  (so, TC indicates end-first truncation,
>not best-fit.)

Does your latter sentence imply that BIND4 and BIND9 will discard 
non-empty sections other than the last one (as specified as "should" 
in RFC2181 section 9)?  Or if not, what is done?

Are there plans to change the behaviour, or are there specific good
reasons to do so?

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.

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

--
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: Paul Vixie <[email-masked]>
Date: Sat, 28 Aug 2004 15:40:28 +0000

> Paul, you leave a lot unstated, so I must query again ;-).

Fine by me.  These are topics that "DNS Clarifications" might have covered.

> in RFC2181 section 9)?  Or if not, what is done?

BIND4's behaviour changed a lot.  4.9 and later certainly do the same
thing as I described for BIND8 above.  4.8 and earlier was berzerk --
it cached and reused everything, without regard for RRset boundaries.
For example, if there was deviance in the TTL across RRs within an
RRset, then each RR would expire separately, and BIND4.8 would continue
sending the shortened cached RRset in new answer/authority/additional
sections until finally the last RR expired at which point the RRset
would be re-fetched.  And the TC bit didn't affect caching at all --
everything in a response went into a cache, without regard for what
possible RRset-truncation may have occurred.  And when experienced
truncation while building an answer, it would set TC but possibly leave
a truncated RRset in the truncated section.  What a complete disaster.

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.

> Are there plans to change the behaviour, or are there specific good

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.  (Note that DJB's
arguments that we misinterpreted the AXFR spec weren't very convincing,
so anyone who was thinking of using that as a counterexample, shouldn't.)

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

---

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

---

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

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

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

> in the first place.  (I didn't always know what was wrong, but I knew what

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.