Re: [dns-operations] DNS request for ./NS with two extra bytes at the end
But you can return FORMERR. That said Microsoft used two bytes at the end of an AXFR request to signal multi record messages where accepted. These days it should be a EDNS option. -- Mark Andrews > On 27 May 2022, at 11:59, Frank Habicht wrote: > > On 26/05/2022 22:37, John Levine wrote: >> It appears that Brown, William said: >>> -=-=-=-=-=- >>> It made sense 40 years ago when it was written. In today’s security >>> environment, it does not. >> It made sense and still makes sense when you know what Postel meant. >> Be liberal in what you accept when the specification is ambiguous, not >> accept any random garbage and try to guess what it means. > > I also want to interpret it as "be resilient to anything thrown at you". > > Frank > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS request for ./NS with two extra bytes at the end
On 26/05/2022 22:37, John Levine wrote: It appears that Brown, William said: -=-=-=-=-=- It made sense 40 years ago when it was written. In today’s security environment, it does not. It made sense and still makes sense when you know what Postel meant. Be liberal in what you accept when the specification is ambiguous, not accept any random garbage and try to guess what it means. I also want to interpret it as "be resilient to anything thrown at you". Frank ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS request for ./NS with two extra bytes at the end
It appears that Brown, William said: >-=-=-=-=-=- >It made sense 40 years ago when it was written. In today’s security >environment, it does not. It made sense and still makes sense when you know what Postel meant. Be liberal in what you accept when the specification is ambiguous, not accept any random garbage and try to guess what it means. R's, John >From: P Vixie >Sent: Thursday, May 26, 2022 11:23 AM >To: Stephane Bortzmeyer >Cc: dns-operations@lists.dns-oarc.net >Subject: Re: [dns-operations] DNS request for ./NS with two extra bytes at the >end > >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. >Confidentiality Notice: This electronic message and any attachments may >contain confidential or privileged information, and is >intended only for the individual or entity identified above as the addressee. >If you are not the addressee (or the employee or >agent responsible to deliver it to the addressee), or if this message has been >addressed to you in error, you are hereby >notified that you may not copy, forward, disclose or use any part of this >message or any attachments. Please notify the sender >immediately by return e-mail or telephone and delete this message from your >system. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS request for ./NS with two extra bytes at the end
It made sense 40 years ago when it was written. In today’s security environment, it does not. From: P Vixie Sent: Thursday, May 26, 2022 11:23 AM To: Stephane Bortzmeyer Cc: dns-operations@lists.dns-oarc.net Subject: Re: [dns-operations] DNS request for ./NS with two extra bytes at the end 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. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS request for ./NS with two extra bytes at the end
--- Begin Message --- 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 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@lists.dns-oarc.net >https://lists.dns-oarc.net/mailman/listinfo/dns-operations --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS request for ./NS with two extra bytes at the end
I’ve not looked for these, but will look now… The additional two bytes seems to be the identifier in the DNS header, plus one, based on the two messages in the PCAP sample. Roy > On 26 May 2022, at 06:40, Stephane Bortzmeyer 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@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] DNS request for ./NS with two extra bytes at the end
[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. extra-bytes.pcap Description: application/vnd.tcpdump.pcap ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
