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@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
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
