[Dnsmasq-discuss] Insecure DS reply received, do upstream DNS servers support DNSSEC?

[Tore Anderson]

Dnsmasq seems to have a bug where it will return an incorrect Bogus validation verdict for domains that in reality are Insecure. The bug does not appear to impact Secure domains, at least I have not observed that happening.

When the bug occurs, the error «Insecure DS reply received, do upstream DNS servers support DNSSEC?» is logged.

While the message imply there is something wrong with the upstream DNS server, I do not believe this to be the case, as the other resolvers I have tested (systemd-resolved, Unbound, Knot Resolver and PowerDNS Recursor) do not have any problems with it.

For what it's worth, the upstream DNS server does also perform DNSSEC validation on its own, it will for example refuse to look up dnssec-failed.org unless the Checking Disabled flag is set in the query and correctly set the AD flag when looking up Secure domains. It runs BIND 9.9.5-3ubuntu0.19-Ubuntu, according to a version.bind CH TXT query. BIND's DNSSEC support is considered to be mature, as far as I know.

My /etc/dnsmasq.conf file contains the following:

bind-interfaces
conf-file=/usr/share/dnsmasq/trust-anchors.conf
dnssec
listen-address=127.0.0.1
log-queries
no-hosts
no-resolv
server=84.208.20.110
server=/lan/192.168.1.1

If I trigger the bug by starting Dnsmasq and attempting to look up google.com immediately after, the following messages are logged:

aug. 24 10:36:50.136188 sloth.fud.no dnsmasq[9948]: listening on lo(#1): 127.0.0.1 port 53
aug. 24 10:36:50.136595 sloth.fud.no dnsmasq[9948]: started, version 2.80 cachesize 150
aug. 24 10:36:50.136605 sloth.fud.no dnsmasq[9948]: compile time options: IPv6 GNU-getopt DBus no-i18n IDN2 DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile
aug. 24 10:36:50.136620 sloth.fud.no dnsmasq[9948]: DNSSEC validation enabled
aug. 24 10:36:50.136633 sloth.fud.no dnsmasq[9948]: configured with trust anchor for <root> keytag 20326
aug. 24 10:36:50.136639 sloth.fud.no dnsmasq[9948]: configured with trust anchor for <root> keytag 19036
aug. 24 10:36:50.136648 sloth.fud.no dnsmasq[9948]: using nameserver 192.168.1.1#53 for domain lan (no DNSSEC)
aug. 24 10:36:50.136655 sloth.fud.no dnsmasq[9948]: using nameserver 84.208.20.110#53
aug. 24 10:36:50.136673 sloth.fud.no dnsmasq[9948]: cleared cache
aug. 24 10:36:51.146834 sloth.fud.no dnsmasq[9948]: query[A] google.com from 127.0.0.1
aug. 24 10:36:51.146983 sloth.fud.no dnsmasq[9948]: forwarded google.com to 84.208.20.110
aug. 24 10:36:51.149917 sloth.fud.no dnsmasq[9948]: dnssec-query[DS] com to 84.208.20.110
aug. 24 10:36:51.151816 sloth.fud.no dnsmasq[9948]: dnssec-query[DNSKEY] . to 84.208.20.110
aug. 24 10:36:51.153947 sloth.fud.no dnsmasq[9948]: reply . is DNSKEY keytag 59944, algo 8
aug. 24 10:36:51.153991 sloth.fud.no dnsmasq[9948]: reply . is DNSKEY keytag 20326, algo 8
aug. 24 10:36:51.154245 sloth.fud.no dnsmasq[9948]: reply com is DS keytag 30909, algo 8, digest 2
aug. 24 10:36:51.154304 sloth.fud.no dnsmasq[9948]: dnssec-query[DS] google.com to 84.208.20.110
aug. 24 10:36:51.156153 sloth.fud.no dnsmasq[9948]: dnssec-query[DNSKEY] com to 84.208.20.110
aug. 24 10:36:51.158387 sloth.fud.no dnsmasq[9948]: reply com is DNSKEY keytag 17708, algo 8
aug. 24 10:36:51.158430 sloth.fud.no dnsmasq[9948]: reply com is DNSKEY keytag 30909, algo 8
aug. 24 10:36:51.158576 sloth.fud.no dnsmasq[9948]: Insecure DS reply received, do upstream DNS servers support DNSSEC?
aug. 24 10:36:51.158602 sloth.fud.no dnsmasq[9948]: reply google.com is BOGUS DS
aug. 24 10:36:51.158637 sloth.fud.no dnsmasq[9948]: validation google.com is BOGUS
aug. 24 10:36:51.158671 sloth.fud.no dnsmasq[9948]: reply google.com is 172.217.21.174

I am attaching a PCAP containing the above exchange between Dnsmasq and my ISP's DNS server 84.208.20.110.

I have also observed the issue occurring while using public DNS servers like 4.2.2.2 instead of 84.208.20.110.

My final observations is that it only happens intermittently. If I keep retrying the above lookup for google.com, it will eventually succeed and give the correct Insecure verdict.

Tore
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dns.pcap
Type: application/vnd.tcpdump.pcap
Size: 3412 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20190824/46f169aa/attachment.pcap>