RFC 8901: Multi-Signer DNSSEC Models
In plain English — editorial summary, not part of the RFC
Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service. Deploying DNSSEC in such an environment may present some challenges, depending on the configuration and feature set in use. In particular, when each DNS provider independently signs zone data with their own keys, additional key-management mechanisms are necessary. This document presents deployment models that accommodate this scenario and describes these key-management requirements. These models do not require any changes to the behavior of validating resolvers, nor do they impose the new key-management requirements on authoritative servers not involved in multi-signer configurations.
Document record
- Document ID
- RFC8901
- Published
- September 2020
- Authors
- S. Huque; P. Aras; J. Dickinson; J. Vcelak; D. Blacka
- Status
- INFORMATIONAL
- Stream
- IETF
- Area
- ops
- Pages
- 13
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 3412Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)Updated
December 2002
- RFC 2572Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)Obsoleted
April 1999
- RFC 8976Message Digest for DNS ZonesCurrent
February 2021
- RFC 8749Moving DNSSEC Lookaside Validation (DLV) to Historic StatusCurrent
March 2020
- RFC 9077NSEC and NSEC3: TTLs and Aggressive UseCurrent
July 2021
- RFC 8683Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise NetworksCurrent
November 2019
- RFC 9276Guidance for NSEC3 Parameter SettingsCurrent
August 2022
- RFC 8509A Root Key Trust Anchor Sentinel for DNSSECCurrent
December 2018
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?