Hello, this is not a reply to any comment already made on this approach of "negative trust anchors". (I just posted a reply with RFC4641bis in the subject, about this)
It holds an alternative possibility to overcome the problem - for operators of validating name servers - of failing domains because of DNSSEC. The alternative is to have a parent regularly (no frequency defined) check the coherence of DS information they have against DNSKEY information it finds published. If the parent detects "security lameness" (term used in RFC4641bis) its possible reaction could be to remove the DS information. The draft of Negative Trust Anchors does not mention anything about informing the operator of the failing domain. But since a parent domain operator should "know" who operates the child domains, they can also actively inform (eg. send email to registered contact person). That way, somebody can start working on correcting the root cause. The advantage over negative trust anchor would be that this is more centrally managed : the action by the parent (remove DS) is visible (TTL permitted) to any validating name server. (the negative trust anchor needs to be configured by every validating NS, whose administrators bother to do so) I acknowledge that negative trust anchor applies to however the chain-of-trust starts (from the root-zone, or from some DLV). But since the root is DNSSEC'd since close to 2 years, I expect the DLV approach is less important anyway. While my company, as registry for .eu, does not do this (yet ?), we do validate DNSSEC information when submitted, prior to publishing it as DS records (only if validation yields success). So, we already decide not to publish wrong information (at one point in time). The suggestion to regularly verify again extends that behaviour from "not publishing if wrong" (at submission time) to "stop publishing if wrong" (as part of normal operation) (the contract with registrars states that information provided by registrars must be correct. If not, the contract allows for some reactions (like blocking a domain in case of fake identities, but - by extension - to correctness of DNSSEC information) Marc Lampo Security Officer EURid (for .eu) _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
