[dns-operations] Truncation query
ray at isc.org
Mon Feb 6 15:14:26 UTC 2017
On 06/02/2017 14:47, Peter van Dijk wrote:
> 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 18.104.22.168 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.
Another factor is that RFC 6891 (EDNS) requires that a server supporting
EDNS actually send back an OPT RR in the response.
Notwithstanding then that this particular CPE doesn't support EDNS, it
would be impossible to find that OPT RR if the section counts are wrong.
RFC 2181 appears to allow for "hard truncation", but it's not 100% clear
about whether the "may" in the text quoted below is giving servers
permission to truncate like that, or warning clients that it might just
"Where TC is set, the partial RRSet that would not completely fit may
be left in the response."
More information about the dns-operations