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


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

I'm currently testing this live here, and I'd appreciate it if you could
give it a whirl too.



Dnsmasq-discuss mailing list

Reply via email to