[dns-operations] DNS over TCP response fragmentation

[Ben Cox]

I would suspect this is caused by NO_DELAY being enabled (as it
should) and some code writing out the dns response buffer in two
parts. That server in the pcap appears to be running unbound 1.4.22:

[14:05:03] ben at metropolis:~$ dig -t txt -c chaos VERSION.BIND
@100.37.202.139 +short
"unbound 1.4.22"

I cannot reproduce this on a new version of unbound, so I assume this
is a bug/quirk with the older versions

On Tue, Oct 3, 2023 at 2:00 PM Jan Petto
<janpaul.petto at stud.tu-darmstadt.de> wrote:
>
> 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