[Dnsmasq-discuss] malformed DNS packets with edns0 enabled

[Petr Menšík]

Can you share any of such recorded packets? The existing pcap file would 
be useful. isc.org is example of signed name with TTL=300. If you have 
names you don't want to share publicly only, please send them to me. I 
am RHEL maintainer, but haven't noticed a behaviour you are describing. 
It sounds like worth investigation. I doubt any state of TTL should make 
requests different.

Do I understand it correctly you have enabled a dnssec validation? If 
you see those on RHEL derivative, consider please filling a bug on 
bugzilla.redhat.com. Even if not using rhel directly, it should be fixed 
there.

Have you tried a CentOS 9 version also?

On 08. 07. 22 19:17, James Brown via Dnsmasq-discuss wrote:
> Hello:
>
> We use dnsmasq as a local caching resolver (binding to ::1) and are 
> currently upgrading some systems to EL8 (Rocky Linux 8 specifically, 
> which is a rebuild of Red Hat 8). We've noticed that a fairly 
> significant fraction of name resolutions fail when `|option edns0|` is 
> enabled in /etc/resolv.conf and dnsmasq is being used; that is to say, 
> when resolv.conf looks like
>
> |option edns0
> nameserver ::1|
>
> These failures manifest for queries issued very close to a TTL expiry 
> (that is to say, if you request a name X with a TTL of 300 seconds, 
> then wait 299.99 seconds, then request X again, it will fail about ½ 
> of the time).
>
> I've tried backporting dnsmasq 2.86, but it shows the same behavior.
>
> I used tcpdump to capture the actual request issued and the Wireshark 
> protocol analyzer says that dnsmasq is emitting malformed DNS queries.
>
> The query from libc to dnsmasq looks correct and the "additional 
> records" portion of the packet contains the following bytes:
>
> 00 00 29 04 b0  00 00 00 00 00 00
>
> Based on my reading of EDNS0, this looks right (domain name is 0 bytes 
> long and is the root domain; packet type is 0x29 == 41).
>
> However, on failed requests, the packet sent from dnsmasq to the 
> upstream DNS server ends with the following "additional records" section:
>
> c0 0c 00 05 00 01 00 00 0c e4 00
>
> This looks like a compressed label, since it starts with 0xc...? Which 
> doesn't make any sense to put in the OPT section?
>
> The rest of the query looks fine.
>
> Neither add-mac nor add-subnet is set, and edns-packet-max is set to 4096.
>
> If I turn off dnsmasq and send queries directly to the upstream 
> nameserver, I don't ever see any of these "c00c" packets emitted, so 
> I am pretty confident that these bad bytes are coming from dnsmasq itself.
>
> Has anyone ever seen anything like this? I'm glad to privately share 
> pcaps if that would help.
>
> James Brown
> Infrastructure Architect
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

-- 
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20220711/ff3aa01f/attachment.htm>