[dns-operations] DNS request for ./NS with two extra bytes at the end

[P Vixie]

The robustness principle is diametrically wrong. We must be ultra conservative in what we accept, to put back pressure on silly bugs before they can gain market share.

⁣Get BlueMail for Android ​

On May 25, 2022, 22:58, at 22:58, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
>[This has no operational consequences, it is just idle curiosity.]
>
>A server receives a few packets/second coming from several IP
>addresses and querying ./NS (like in priming, or may be in some
>reflection attacks). The server was never a root server, of course.
>
>What is interesting is that all these packets have two extra bytes at
>the end, after the class. The UDP length is correct, but the DNS
>content is not. I don't show you the output of tshark, because it
>ignores these extra bytes (but you can see them with Wireshark or
>other tools). I attached a small pcap.
>
>The source IP addresses (which may be spoofed) are all registered in
>China.
>
>Did anyone see these requests?
>
>Side question: what should the receiver do? tshark, as I said, drops
>these extra bytes, Wireshark flags no error (but displays the
>bytes). I did not test them with various DNS servers to see how they
>react. Ignoring the extra bytes in the name of the robustness
>principle? Instead, at least one DNS library rejects the packet as
>malformed.
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>dns-operations mailing list
>dns-operations at lists.dns-oarc.net
>https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20220526/778b76db/attachment.html>