On 17/11/15 11:01, Michał Kępień wrote: > --- > When dnsmasq is running with DNSSEC validation enabled, it returns > SERVFAIL when trying to resolve any record within a zone which uses a > signing algorithm it doesn't understand. This behavior doesn't play > nicely with RFC 4035, section 5.2: > > If the resolver does not support any of the algorithms listed in an > authenticated DS RRset, then the resolver will not be able to verify > the authentication path to the child zone. In this case, the > resolver SHOULD treat the child zone as if it were unsigned. > > My reading of the above is that e.g. if a resolver encounters a zone for > which there is a single DS with a signing/hashing algorithm it doesn't > understand, it should treat that zone as unsigned, not bogus. > > I would venture to say that this rule should not be applied solely to DS > records, but also to record signatures in general. A quick glance at > the latest src/dnssec.c shows that both validate_rrset() and > dnssec_validate_by_ds() return STAT_BOGUS when they are unable to > perform validation, no matter the reason. Meanwhile, if the hash_find() > call fails for all DS records for a given zone (or for all RRSIGs for a > given RRset), it simply means that dnsmasq doesn't know how to perform > validation, not that the data is outright bogus. The same holds true > for verify() which simply returns 0 when either signature verification > fails or the signature algorithm is not supported, which are two > distinct cases. > > This patch attempts to solve the issue by tracking how many of the > attempted validations failed due to unknown algorithms being used. It > probably needs some polishing and more thorough testing, but hopefully > conveys the idea. >
OK, I've done some more thinking about this. We have to be careful to distinguish between validating a DS RRset and using that DS RRset to prove that the DNSKEY RRset it refers to is valid. If we can't validate a DS RRset, either because its signature is wrong, or we don't speak the correct algorithm, then we can't use it to prove anything about the zone it refers to. I'll return to that case later. There's another case where the DS RRset is validated - we know it's good data, but we don't speak the hash algorithm is gives. In that case, we can treat the zone as insecure, in exactly the same way as if we have an NSEC record proving that the DS doesn't exist. 4035 says as much. If the validator does not support any of the algorithms listed in an authenticated DS RRset, then the resolver has no supported authentication path leading from the parent to the child. The resolver should treat this case as it would the case of an authenticated NSEC RRset proving that no DS RRset exists, as described above. (An interesting bit of RFC-ology this, my RFC quote is two paragraphs ahead of yours: they both refer to the same state, and say subtly different things.) This isn't what dnsmasq does at present, and I'll fix that, but I doubt it's the problem you've been seeing, since it's about hash algorithms. AFAIK there are no new hash algorithms out there. More likely the problem is that a zone is _signed_ with a new public-key algorithm (probably ECDSA) The following bit of 4035 might indicate that treating such data as unisgned is not correct. If for whatever reason none of the RRSIGs can be validated, the response SHOULD be considered BAD. If the validation was being done to service a recursive query, the name server MUST return RCODE 2 to the originating client. However, it MUST return the full response if and only if the original query had the CD bit set. Also see Section 4.7 on caching responses that do not validate. PS. Change for DS unknown hash is: http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=67ab3285b5d9a1b1e20e034cf272867fdab8a0f9 Cheers, Simon. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
