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
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
