In message <121cdbc2-d68c-48ee-a56e-46c61fc21...@sidn.nl>, Moritz Muller writes : > > Hi, > > Together with my colleagues I have been stumbling upon a, for me, unclear > case when validating trust anchors. > > Assuming that a resolver has enabled DNSSEC validation and has the root > keys configured. > Additionally, it has configured manually a trust anchor for a TLD (that > has also published its DS in the root zone). > Now, for example due to a key rollover at the TLD, the manually > configured trust anchor of the TLD does not match the DS in the root > anymore. > > How should a resolver treat the signatures of this TLD? > The resolvers of BIND, Unbound, and PowerDNS seem to treat the signatures > of the TLD as bogus, but we didn't find any specifics in RFC 4034 and > 4035 that describe how resolvers should behave in this case. > Knot resolver treats them as NOERROR (according to the developers). > If we interpret section 4.3 of RFC 4035 then we would have assumed that > the signature must be treated as secure. > > Did we miss something, or is there indeed clarification needed? > > â Moritz
Firstly the TLD has mismanged the key rollover if this is the case assuming that it was expecting TA to be installed for it. It not the operator of the validator is in error. Secondly doing deepest match on trust anchors is the only secure way to prevent a parent overriding the child zone's security policy. Thirdly if you are doing split DNS and you want to enforce that you only get answers from a particular view you can use DNSSEC to reject leaked answers. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
