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 http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=fef2f1c75eba56b7355cbe729e4362474d558aa4 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 records. I'm currently testing this live here, and I'd appreciate it if you could give it a whirl too. Cheers, Simon. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
