[dns-operations] Truncation query

[Peter van Dijk]

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.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/