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 record that proved the non-existence of the DS record in the first place. These RFCs says the TTL on NSEC 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 resource record already in the cache»: https://tools.ietf.org/html/rfc8198 My ISP's name server does consistently include RRSIGs for the NSEC 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 Dnsmasqemail@example.com http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss