[dns-operations] Truncation query

[Mukund Sivaraman]

On Mon, Feb 06, 2017 at 03:47:05PM +0100, Peter van Dijk wrote:
> Hello Ray,
> 
> On 6 Feb 2017, at 15:25, Ray Bellis wrote:
> 
> > I can't find chapter and verse in the RFCs, and I'm trying to confirm
> > whether this packet returned by the DNS server in my Apple Airport
> > express is legal.
> > 
> > In my recursive resolve testing app I've asked for a 2k TXT RR, with
> > EDNS.   The reply has come back with TC=1, QDCOUNT=1, ANCOUNT=1, but
> > there is no answer in the packet.
> > 
> > 000000  ad d2 83 80 00 01 00 01 00 00 00 00 05 6c 61 72
> > 000010  67 65 03 72 63 74 03 69 73 63 03 6f 72 67 00 00
> > 000020  10 00 01
> > 
> > Should the server have set ANCOUNT=0 in this packet for it to be legal,
> > or should the presence of TC=1 be taken to mean that "all bets are off"
> > for everything after the question section?
> 
> My personal suggestion is to always ignore everything after the question
> section on a TC=1 response. However, not everybody feels this way. For
> example, if an auth replies to an 8.8.8.8 query with a badly truncated
> answer (i.e. the counts reflect the untruncated answer), it will send
> SERVFAIL to the client instead of switching to TCP. dnsdist grew the
> `truncateTC` function days after Google made this change :)
> 
> As I have understood the relevant RFCs, the counts should match what’s
> actually in the packet, and ‘harvesting’ data from a truncated response is
> allowed under limited circumstances. So if I have to guess, the packet you
> are seeing is not valid.

I agree that throwing away everything in the message when TC=1 is the
best (even though e.g., it is possible to determine that an answer
section RRset is complete in some cases).

Ray, Witold and I were chatting about this after Ray asked the
question. RFC 2181 section 9 contains:

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

The first sentence IMO seems to be about server behavior, going by the
section up to that paragraph.

It seems from this and what's in 1035 that truncation can occur in such
a way that partial contents are at the end of the DNS message (where
partial is not defined - whether it is truncated at an RR boundary or in
the middle). As per this, one might *assume* that with some
implementation, hard-truncation occurs at the point where the message up
to that point has already been rendered/written/sent and there's no
going backwards to back out the partial RRset or correct section counts.

Also note that EDNS requires OPT RR in a TC=1 reply.

BIND as resolver doesn't cache answers from a message when TC=1. It also
doesn't write incorrect section counts (afaik) for TC=1 messages.

		Mukund
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20170206/e2dba3ef/attachment.sig>