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 


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»:


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.


Dnsmasq-discuss mailing list

Reply via email to