[dns-operations] DNS over TCP response fragmentation

[Paul Vixie]

if the dns responder uses write() or send() or sendto() for the two 
octets of framing length, rather than writev() or sendmsg(), the 
kernel's default will be to "push" each buffer as a segment. that's 
where the one- or two-octet segments are probably coming from. this 
default can usually be changed by a socket-level system call. but even 
with writev() or sendto() older kernels (such as those in appliances and 
middle boxes) to treat each "iov" element as a separate buffer to be 
sent in a separate segment. and even if the dns responder does 
everything it can to avoid these small and/or separate segments, the 
kernel may have old congestion-window calculation. see also the first 
answer to this stackexchange question:

https://networkengineering.stackexchange.com/questions/54915/initial-tcp-congestion-window-sizes

congestion window doesn't show up on the wire so it won't be in the 
.pcapng file you sent. usually we estimate congestion window by looking 
at what size segments a sender transmits.

this survey is very interesting and deserves its own campaign. you might 
reach out to the MANRS+ team at ISOC to see if they want to take this on.

vixie

re:

Jan Petto wrote on 2023-10-03 02:25:
> Hello,
> 
> my name is Jan Petto and I am currently studying computer science at TU 
> Darmstadt, Germany. During the research for my thesis, I have found some 
> odd behavior regarding DNS over TCP, which neither I nor my supervisor 
> can explain. I am hoping somebody here can tell me what I am observing:
> 
> 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.
> 
> Kind regards,
> Jan
> 
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> 


-- 
P Vixie