[atlas] Request to test TCP and UDP to the root servers separately.

[Changing my From: address to the one used in my subscription, to avoid
sender filters.]

philip.homburg at ripe.net:
> Why does packet reordering lead to reassembly failures?

That's what I would like to know too. :-) I have noticed it (with
tcpdump), but I haven't had the the time to drill into what essentially
has to be a kernel reassembly problem, or incorrect coding of the
fragment headers. There are lots of small ones and zeroes, and deep
hacking is needed to reach a solid conclusion, and time is a scarece
resource.

> At the moment we also don't have code for capturing fragments. That
> may be non-trivial to add.

Understood.

May I suggest a middle ground test, which might be easier for you to
implement, and which might still give some useful feedback.

First send a nomal UDP DNS query, without DNSSEC and without any EDNS(0)
features, and aim for a purposely a small DNS response. That will test
normal UDP connectivity. (This you already do, but ensure that the
expected response is small.)

Then send a TCP DNS query. That will test normal TCP connectivity. (This
you obviously already do.)

Finally, send a UDP DNS query, with EDNS(0) with a large (but reasonable
- maybe 4k?) buffer size, the DO bit set, and many "bells and whistles",
to purposely tickle the server to produce a large answer. If you don't
receive a parseable DNS response for this, something along the path
generates problems for you (fragmenting unit, intermediate firewall, or
reassebmly unit), and that in itself is interesting information (me
thinks). It may even be that the responding server sets the IP "DF"
(don't fragment) bit, which unfortunately seems to be default in some
Linux distributions.

Or maybe you test this already? ;-)

				Cheers,
				  /Liman