Re: [Dnsmasq-discuss] Insecure DS reply received, do upstream DNS servers support DNSSEC?
* Simon Kelley > I just pushed > > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=fef2f1c75eba56b7355cbe729e4362474d558aa4 > > Which makes the following changes: > > 1) No longer fail to validate a reply proving that a DS record doesn't > exist if RRs in the auth section other the the NSEC/NSEC3 records needed > for non-existence proof are not signed. > > 2) Use the TTL of the NSEC record when caching the non-existence of DS > records. > > I'm currently testing this live here, and I'd appreciate it if you could > give it a whirl too. Excellent. I've been running it for a few hours now, no problems whatsoever so far. In comparison, with HEAD^1, I could hardly use my computer for anything Internet-related. So this is very promising indeed. Thanks! Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Insecure DS reply received, do upstream DNS servers support DNSSEC?
On 29/08/2019 17:53, Tore Anderson wrote: > Hi Simon, > >> Now, it's certainly possible to verify that the DS record doesn't exist >> without relying on the data in the SOA record. BUT there is a problem: >> having determined securely that the DS record doesn't exist, dnsmasq >> caches that information, and it uses data from the SOA record to >> determine the time-to-live of that cache record. >> >> So, in theory, and attacker could replace the SOA record in the reply >> with one which gave, say, a very long TTL for the cached negative DS >> record. I don't know is that's real weakness, but if so, the solution >> may be not to cache the DS record if the SOA record is not signed. > > I think it is more logical to use the TTL of the NSEC[3] record that proved > the non-existence of the DS record in the first place. > > These RFCs says the TTL on NSEC[3] records should be identical with the SOA > minimum: > > https://tools.ietf.org/html/rfc4035#section-2.3 > https://tools.ietf.org/html/rfc5155#section-3 > > Also, this one «allows validating resolvers to respond with a negative answer > immediately if the name in question falls into a range expressed by an > NSEC[3] resource record already in the cache»: > > https://tools.ietf.org/html/rfc8198 > > My ISP's name server does consistently include RRSIGs for the NSEC[3] records > it answers with in the authority section, so the proof of non-existence is > Secure and it does come with a lifetime. > > Another approach would be to explicitly query for the SOA record (if its > RRSIG was not included in the authority section of the DS response to begin > with). My ISP's name server will consistently include the SOA RRSIG in the > answer section when answering such queries, for what it is worth. This should > allow Dnsmasq to determine that the SOA provided is Secure so it can safely > use its minimum field for the negative cache lifetime. > > Tore > That's very helpful, thanks. I just pushed http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=fef2f1c75eba56b7355cbe729e4362474d558aa4 Which makes the following changes: 1) No longer fail to validate a reply proving that a DS record doesn't exist if RRs in the auth section other the the NSEC/NSEC3 records needed for non-existence proof are not signed. 2) Use the TTL of the NSEC record when caching the non-existence of DS records. I'm currently testing this live here, and I'd appreciate it if you could give it a whirl too. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Insecure DS reply received, do upstream DNS servers support DNSSEC?
Hi Simon, > Now, it's certainly possible to verify that the DS record doesn't exist > without relying on the data in the SOA record. BUT there is a problem: > having determined securely that the DS record doesn't exist, dnsmasq > caches that information, and it uses data from the SOA record to > determine the time-to-live of that cache record. > > So, in theory, and attacker could replace the SOA record in the reply > with one which gave, say, a very long TTL for the cached negative DS > record. I don't know is that's real weakness, but if so, the solution > may be not to cache the DS record if the SOA record is not signed. I think it is more logical to use the TTL of the NSEC[3] record that proved the non-existence of the DS record in the first place. These RFCs says the TTL on NSEC[3] records should be identical with the SOA minimum: https://tools.ietf.org/html/rfc4035#section-2.3 https://tools.ietf.org/html/rfc5155#section-3 Also, this one «allows validating resolvers to respond with a negative answer immediately if the name in question falls into a range expressed by an NSEC[3] resource record already in the cache»: https://tools.ietf.org/html/rfc8198 My ISP's name server does consistently include RRSIGs for the NSEC[3] records it answers with in the authority section, so the proof of non-existence is Secure and it does come with a lifetime. Another approach would be to explicitly query for the SOA record (if its RRSIG was not included in the authority section of the DS response to begin with). My ISP's name server will consistently include the SOA RRSIG in the answer section when answering such queries, for what it is worth. This should allow Dnsmasq to determine that the SOA provided is Secure so it can safely use its minimum field for the negative cache lifetime. Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Insecure DS reply received, do upstream DNS servers support DNSSEC?
On 24/08/2019 18:47, Tore Anderson wrote: > Some more information: > >> When the bug occurs, the error «Insecure DS reply received, do upstream DNS >> servers support DNSSEC?» is logged. > > I think that the problem might be caused by this query in frames 7-8 of the > PCAP: > > 7 0.007426 192.168.1.155 → 84.208.20.110 DNS 81 Standard query 0x56e3 > DS google.com OPT > 8 0.009033 84.208.20.110 → 192.168.1.155 DNS 639 Standard query > response 0x56e3 DS google.com SOA a.gtld-servers.net NSEC3 RRSIG NSEC3 RRSIG > OPT > > There is no RRSIG record included that covers the SOA record (only the two > NSEC3 records) > > Occasionally (less than 5% of the time) my ISP's DNS server *does* include a > RRSIG for the SOA record, though: > > 194 31.307161 192.168.1.155 → 84.208.20.110 DNS 83 Standard query 0x8ade > DS google.com OPT > 195 31.309053 84.208.20.110 → 192.168.1.155 DNS 804 Standard query > response 0x8ade DS google.com SOA a.gtld-servers.net RRSIG NSEC3 RRSIG NSEC3 > RRSIG OPT > > When it does, Dnsmasq is able to answer the query successfully with the > correct Insecure verdict (and cache it). That looks like a good diagnosis to me. As a test, 1.1.1.1 and 8.8.8.8 both seem to include the RRSIG for the SOA record always, which is probably why this has not been noticed before. > > So the question then becomes: why does Dnsmasq require this RRSIG record, > when other validating resolvers apparently do not? It blindly verifies all the RRsets in the answer and auth sections, and determines that the answer is not secure if any fail validation. Since a reply to a DS query must to secure, by definition, that causes the error message. Now, it's certainly possible to verify that the DS record doesn't exist without relying on the data in the SOA record. BUT there is a problem: having determined securely that the DS record doesn't exist, dnsmasq caches that information, and it uses data from the SOA record to determine the time-to-live of that cache record. So, in theory, and attacker could replace the SOA record in the reply with one which gave, say, a very long TTL for the cached negative DS record. I don't know is that's real weakness, but if so, the solution may be not to cache the DS record if the SOA record is not signed. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Insecure DS reply received, do upstream DNS servers support DNSSEC?
Some more information: > When the bug occurs, the error «Insecure DS reply received, do upstream DNS > servers support DNSSEC?» is logged. I think that the problem might be caused by this query in frames 7-8 of the PCAP: 7 0.007426 192.168.1.155 → 84.208.20.110 DNS 81 Standard query 0x56e3 DS google.com OPT 8 0.009033 84.208.20.110 → 192.168.1.155 DNS 639 Standard query response 0x56e3 DS google.com SOA a.gtld-servers.net NSEC3 RRSIG NSEC3 RRSIG OPT There is no RRSIG record included that covers the SOA record (only the two NSEC3 records) Occasionally (less than 5% of the time) my ISP's DNS server *does* include a RRSIG for the SOA record, though: 194 31.307161 192.168.1.155 → 84.208.20.110 DNS 83 Standard query 0x8ade DS google.com OPT 195 31.309053 84.208.20.110 → 192.168.1.155 DNS 804 Standard query response 0x8ade DS google.com SOA a.gtld-servers.net RRSIG NSEC3 RRSIG NSEC3 RRSIG OPT When it does, Dnsmasq is able to answer the query successfully with the correct Insecure verdict (and cache it). So the question then becomes: why does Dnsmasq require this RRSIG record, when other validating resolvers apparently do not? > I have also observed the issue occurring while using public DNS servers like > 4.2.2.2 instead of 84.208.20.110. I now believe this was an unrelated problem, cf. https://mobile.twitter.com/toreanderson/status/1165225237115543554 Tore ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Insecure DS reply received, do upstream DNS servers support DNSSEC?
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 keytag 20326 aug. 24 10:36:50.136639 sloth.fud.no dnsmasq[9948]: configured with trust anchor for 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 dns.pcap Description: application/vnd.tcpdump.pcap ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
