[dns-operations] Truncation query
Peter van Dijk
peter.van.dijk at powerdns.com
Mon Feb 6 14:47:05 UTC 2017
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/
More information about the dns-operations
mailing list