Signalling of DNS Security (DNSSEC) Trust Anchors
draft-wkumari-dnsop-trust-management-01

Abstract

[ Editor note: This originally included a mechanism to actually roll the keys (like RFC5011 does), but feedback from the Prague meeting indicated a strong preference for signalling only. ] This document describes a simple method for validating recursive resolvers to signal their configured list of DNSSEC trust anchors. This mechanism allows the trust anchor maintainer to monitor the progress of the migration to a new trust anchor, and so predict the effect before decommissioning the existing trust anchor. It is primarily aimed at the root DNSSEC trust anchor, but should be applicable to trust anchors elsewhere in the DNS as well. [ Ed note - informal summary: One of the big issues with rolling the root key is that it is unclear who all is using RFC5011, who all has successfully fetched and installed the new key, and, most importantly, who all will die when the old key is revoked. By having resolvers query for a special QNAME, comprised of the list of TAs that it knows about, we effectively signal "up stream" to the authoritative server. By querying for this name, the recursive exposes its list of TAs to this authoritative server. This allows the TA maintainer to gather information relating to the state of TAs on resolvers.] [ Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication.] [ This document is being collaborated on in Github at: https://github.com/wkumari/draft-wkumari-dnsop-trust-management. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests ]

Authors

Warren "Ace" Kumari
Geoff Huston
Evan Hunt
Roy Arends

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)