[Changing my From: address to the one used in my subscription, to avoid sender filters.] philip.homburg@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