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 → 18.104.22.168 DNS 81 Standard query 0x56e3 > DS google.com OPT > 8 0.009033 22.214.171.124 → 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 → 126.96.36.199 DNS 83 Standard query 0x8ade > DS google.com OPT > 195 31.309053 188.8.131.52 → 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, 184.108.40.206 and 220.127.116.11 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 Dnsmasqemail@example.com http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss