[dns-operations] DNS over TCP response fragmentation

[Petr Špaček]

On 03. 10. 23 11:25, Jan Petto wrote:
> For my research, I am sending DNS requests over TCP to many different 
> recursive DNS servers all over the world. A significant portion of these 
> servers is sending the DNS response in two separate TCP segments, even 
> though it would easily fit into one packet. Only after my client has 
> acknowledged the first segment, the second part of the response is sent. 
> The first TCP segment always contains only one or two bytes, never more.
> 
> I know a DNS message sent over TCP is prefixed by a two-byte field 
> containing the message length. My first thought was that the first TCP 
> segment contains this length field, and the second segment contains the 
> DNS message, but then I discovered cases where only one of the two 
> length bytes was contained in the first segment. In any case, sending 
> the message length as a separate packet does not make much sense to me 
> from an application design perspective. Maybe this is some sort of 
> attack mitigation?
> 
> I have attached a packet capture containing two such examples. You can 
> reproduce the behavior with any DNS client, e.g. dig:
> 
> # dig example.org +tcp @100.37.202.139
> 
> Also attached is a list of public DNS server IP addresses, where I have 
> observed this behavior. They were found via scans of the IP address 
> space, I have no affiliation with these servers.
> 
> I would greatly appreciate any input as to why so many servers are 
> sending their responses in such a way.

I bet it's just suboptimal implementation on some SOHO router or 
something like that.

There are two things at play, I believe:
- Responder apparently does not use TCP_CORK (see "man tcp") or a 
userspace equivalent.
- Kernel is very relatex when it comes to TCP protocol segmentation. 
Nothing prescribes that TCP streams MUST be segmented in some sort of 
optimal way.

-- 
Petr Špaček
Internet Systems Consortium