Skip to main content

Security Considerations for RFC5011 Publishers

Document Type Expired Internet-Draft (dnsop WG)
Expired & archived
Authors Wes Hardaker , Warren "Ace" Kumari
Last updated 2019-01-17 (Latest revision 2018-07-16)
Replaces draft-hardaker-rfc5011-security-considerations
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Additional resources Mailing list discussion
Stream WG state Held by WG
Document shepherd Tim Wicinski
Shepherd write-up Show Last changed 2018-07-06
IESG IESG state Expired (IESG: Dead)
Action Holders
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Adam Roach
Send notices to Tim Wicinski <>

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


This document extends the RFC5011 rollover strategy with timing advice that must be followed by the publisher in order to maintain security. Specifically, this document describes the math behind the minimum time-length that a DNS zone publisher must wait before signing exclusively with recently added DNSKEYs. This document also describes the minimum time-length that a DNS zone publisher must wait after publishing a revoked DNSKEY before assuming that all active RFC5011 resolvers should have seen the revocation-marked key and removed it from their list of trust anchors. This document contains much math and complicated equations, but the summary is that the key rollover / revocation time is much longer than intuition would suggest. This document updates RFC7583 by adding an additional delays (sigExpirationTime and timingSafetyMargin). If you are not both publishing a DNSSEC DNSKEY, and using RFC5011 to advertise this DNSKEY as a new Secure Entry Point key for use as a trust anchor, you probably don't need to read this document.


Wes Hardaker
Warren "Ace" Kumari

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