Subject: [dnsext] Request for clarification on Truncation

From: "George Barwood" <[email-masked]>
Date: Mon, 13 Jul 2009 23:33:25 +0100

(1) The original standard clearly considered that truncated responses might 
still be used by resolvers, but the more modern practice seems to be to 
always retry over TCP and to ignore any data in the truncated response.

Therefore, is it acceptable for servers to return nothing except the 
question, when truncating? And if it is acceptable, is this best practice : 
saving bandwidth, and possibly helping to ensure that the response 
sucessfully reaches the client? Or is there a significant deployment of 
resolvers that makes good use of truncated packets, thus avoiding fallback 
to TCP?

(2) It's clear that "additional section processing" does not cause 
truncation, instead the results of additional section processing are 
silently discarded if they do not fit, without setting the TC bit.

However, in a referral, the addition of glue records is apparently not 
"additional section processing" but rather "a special search", from RFC 1034 
:

"NS records cause both the usual additional section processing to locate
a type A record, and, when used in a referral, a special search of the
zone in which they reside for glue information."

It's fairly clearly an error to silently discard all the (necessary) glue, 
as this will probably lead to failure - it's unlikely resolvers will retry 
over TCP unless the TC bit is set.

But in fact current authoritative resolvers do silently discard some glue, 
and marking a non-EDNS response as truncated because a small amount of glue 
does not fit does not seem sensible.

So, how and where should the line be drawn?

( I apologise for bringing (2) up again, but so far there seems to have not 
even been a suggestion as to what is correct server behavior, let alone a 
consensus ).

--
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: Tue, 14 Jul 2009 01:57:39 +0000

> From: "George Barwood" <[email-masked]>
> Date: Mon, 13 Jul 2009 23:33:25 +0100
> 

what i used to try to do is assume that the second to the last non-empty
section is unaffected by truncation.  so if TC && ARCOUNT!=0 then the answer
and authority sections could be cached, whereas if TC && ARCOUNT==0 &&
NSCOUNT!=0 then the answer section can be cached, etc.  only if the response
doesn't include the data i actually needed would i force a TCP retry.

this turned out to be very hard to describe, so as far as i know, nobody
does it this way today, and no standards document explains how to do it.

> question, when truncating? And if it is acceptable, is this best
> practice: saving bandwidth, and possibly helping to ensure that the
> response sucessfully reaches the client? Or is there a significant
> deployment of resolvers that makes good use of truncated packets, thus
> avoiding fallback to TCP?

i think we should continue to send "full" truncated responses so that the
above logic can be used by those willing to try, and someday maybe
documented by someone willing to try.

> silently discarded if they do not fit, without setting the TC bit.

clear in the spec perhaps, but wrong in some implementations i know of.  if
i see TC && ARCOUNT!=0 && NSCOUNT!=0 i'm going to assume that truncation is
happening in the additional section not in the authority section.

> "additional section processing" but rather "a special search", from RFC
> 1034:
> 

if you get TC and are missing in-baliwick glue then that's an example of not
getting everything you needed and having to therefore retry with TCP.

> does not fit does not seem sensible.

insensible though it is, it happens.

> So, how and where should the line be drawn?

"Be liberal in what you accept, and conservative in what you send." -- jon

> even been a suggestion as to what is correct server behavior, let alone a 

every time i try to descibe "necessary glue" or "soft truncation" i get hurt.