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