[Dnsmasq-discuss] Insecure DS reply received, do upstream DNS servers support DNSSEC?
simon at thekelleys.org.uk
Wed Aug 28 23:03:47 BST 2019
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 → 220.127.116.11 DNS 81 Standard query 0x56e3 DS google.com OPT
> 8 0.009033 18.104.22.168 → 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 → 22.214.171.124 DNS 83 Standard query 0x8ade DS google.com OPT
> 195 31.309053 126.96.36.199 → 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, 188.8.131.52 and 184.108.40.206
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
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.
More information about the Dnsmasq-discuss