[dns-operations] Truncation query

[Florian Weimer]

On 03/15/2017 06:58 AM, Mark Andrews wrote:
> In message <2b6bf505-b437-8a27-0970-e2a3bb8d39f8 at redhat.com>, Florian Weimer wr
> ites:
>> On 02/06/2017 03:47 PM, Peter van Dijk wrote:
>>> 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 these packets are malformed because the header does not
>> match what's in the packet.
>>
>> But our BIND-derived stub resolver creates such packets if the
>> application calls one of the res_ lookup functions, TCP fallback
>> happens, and the response is larger than the caller-supplied buffer.  In
>> this case, the stub resolver just patches in the TC bit and truncates
>> the DNS message to fit the application-supplied buffer, without further
>> adjusting the DNS header.  And the truncation can happen in the middle
>> of a resource record.
>
> What a stub resolver does when passed a undersized buffer is a
> completely different senario to what a server does.

The application developer still has to parse the DNS message according 
to the DNS specification, so there is some overlap.

> Now if you are still on 16 bit hardware passing small response
> buffers is still appropriate but anyone running on 32 bit or larger
> hardware should be passing 65535 byte buffers.  That is what the
> protocol expects.  We went through and updated all the buffers in
> BIND 8 to 65535 byte buffers well over a decade ago.

I thought a resolution context in BIND needs around 20 KiB?  How is this 
possible if the packet receive buffer alone is 64 KiB?

I"m going to use MSG_PEEK and MSG_TRUNC to get an accurate size from the 
kernel and allocate a suitable sized buffer using malloc.  But that's 
probably not a good choice for high-performance servers.

Thanks,
Florian