CINXE.COM
draft-ietf-dnsop-rfc7958bis-06 - DNSSEC Trust Anchor Publication for the Root Zone
<!DOCTYPE html> <html data-bs-theme="auto" lang="en" prefix="og: http://ogp.me/ns# article: http://ogp.me/ns/article#"> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <title> draft-ietf-dnsop-rfc7958bis-06 - DNSSEC Trust Anchor Publication for the Root Zone </title> <meta name="viewport" content="width=device-width, initial-scale=1"> <link href="https://static.ietf.org/fonts/inter/import.css" rel="stylesheet"> <link href="https://static.ietf.org/fonts/noto-sans-mono/import.css" rel="stylesheet"> <link rel="stylesheet" href="https://static.ietf.org/dt/12.28.2/ietf/css/ietf.css"> <link rel="stylesheet" href="https://static.ietf.org/dt/12.28.2/ietf/css/select2.css"> <script src="https://static.ietf.org/dt/12.28.2/ietf/js/theme.js"></script> <style> .inline { display: inline; } </style> <meta property="og:title" content="DNSSEC Trust Anchor Publication for the Root Zone"> <meta property="og:url" content="https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/"> <link rel="canonical" href="https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/"> <meta property="og:site_name" content="IETF Datatracker"> <meta property="og:description" content="The root zone of the global Domain Name System (DNS) is cryptographically signed using DNS Security Extensions (DNSSEC). In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA uses to distribute the DNSSEC trust anchors. This document obsoletes RFC 7958."> <meta property="og:type" content="article"> <meta property="og:image" content="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-card.png"> <meta property="og:image:alt" content="Logo of the IETF"> <meta property="article:section" content="IETF - Internet Engineering Task Force"> <meta property="og:image:type" content="image/png"> <meta property="og:image:width" content="1200"> <meta property="og:image:height" content="630"> <meta name="twitter:card" content="summary_large_image"> <meta property="article:author" content="Joe Abley"> <meta property="article:author" content="Jakob Schlyter"> <meta property="article:author" content="Guillaume Bailey"> <meta property="article:author" content="Paul E. Hoffman"> <link rel="alternate" type="application/atom+xml" title="Document changes" href="/feed/document-changes/draft-ietf-dnsop-rfc7958bis/"> <meta name="description" content="DNSSEC Trust Anchor Publication for the Root Zone "> <script type="module" crossorigin="" src="https://static.ietf.org/dt/12.28.2/assets/embedded-e653257c.js"></script> <link href="https://static.ietf.org/dt/12.28.2/assets/create-pinia-singleton-091c62b7.js" type="text/javascript" crossorigin="anonymous" rel="modulepreload" as="script" /> <link href="https://static.ietf.org/dt/12.28.2/assets/Scrollbar-7de50899.js" type="text/javascript" crossorigin="anonymous" rel="modulepreload" as="script" /> <link rel="apple-touch-icon" sizes="180x180" href="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor-180.png"> <link rel="icon" sizes="32x32" href="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor-32.png"> <link rel="icon" sizes="16x16" href="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor-16.png"> <link rel="manifest" href="/site.webmanifest"> <link rel="mask-icon" href="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor-mask.svg" color="#ffffff"> <meta name="msapplication-TileColor" content="#ffffff"> <meta name="theme-color" content="#ffffff"> <script src="https://static.ietf.org/dt/12.28.2/ietf/js/ietf.js"></script> </head> <body class="navbar-offset position-relative" data-group-menu-data-url="/group/groupmenu.json"> <noscript><iframe class="status" title="Site status" src="/status/latest"></iframe></noscript> <div class="vue-embed" data-component="Status"></div> <a class="visually-hidden visually-hidden-focusable" href="#content">Skip to main content</a> <nav class="navbar navbar-expand-lg fixed-top bg-secondary-subtle"> <div class="container-fluid"> <a class="navbar-brand" href="/"> <img alt="IETF Logo" class="d-lm-none me-2" src="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor-white.svg" > <img alt="IETF Logo" class="d-dm-none me-2" src="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor.svg" > Datatracker </a> <div class="collapse navbar-collapse" id="navbar-collapse"> <ul class="nav navbar-nav flex-nowrap"> <li class="nav-item dropdown"> <a href="#" class="nav-link dropdown-toggle" role="button" data-bs-toggle="dropdown" aria-expanded="false"> Groups </a> <ul class="dropdown-menu mt-n1"> <li class="dropdown-header">By area/parent</li> <li class="dropend group-menu group-parent-2010"> <a class="dropdown-item dropdown-toggle " href="/wg/#ART"> Apps & Realtime </a> </li> <li class="dropend group-menu group-parent-1008"> <a class="dropdown-item dropdown-toggle " href="/wg/#GEN"> General </a> </li> <li class="dropend group-menu group-parent-1052"> <a class="dropdown-item dropdown-toggle " href="/wg/#INT"> Internet </a> </li> <li class="dropend group-menu group-parent-1193"> <a class="dropdown-item dropdown-toggle " href="/wg/#OPS"> Ops & Management </a> </li> <li class="dropend group-menu group-parent-1249"> <a class="dropdown-item dropdown-toggle " href="/wg/#RTG"> Routing </a> </li> <li class="dropend group-menu group-parent-1260"> <a class="dropdown-item dropdown-toggle " href="/wg/#SEC"> Security </a> </li> <li class="dropend group-menu group-parent-2412"> <a class="dropdown-item dropdown-toggle " href="/wg/#WIT"> Web and Internet Transport </a> </li> <li class="dropend group-menu group-parent-7"> <a class="dropdown-item dropdown-toggle " href="/program/"> IAB </a> </li> <li class="dropend group-menu group-parent-3"> <a class="dropdown-item dropdown-toggle " href="/rg/"> IRTF </a> </li> <li class="dropend group-menu group-parent-2309"> <a class="dropdown-item dropdown-toggle " href="/adm/"> IETF LLC </a> </li> <li class="dropend group-menu group-parent-1876"> <a class="dropdown-item dropdown-toggle " href="/rfcedtyp/"> RFC Editor </a> </li> <li class="dropend"> <a class="dropdown-item dropdown-toggle " href="/group/"> Other </a> <ul class="dropdown-menu ms-n1"> <li> <a class="dropdown-item " href="/ag/">Active AGs</a> </li> <li> <a class="dropdown-item " href="/area/">Active Areas</a> </li> <li> <a class="dropdown-item " href="/dir/">Active Directorates</a> </li> <li> <a class="dropdown-item " href="/iabworkshop/">Active IAB Workshops</a> </li> <li> <a class="dropdown-item " href="/program/">Active Programs</a> </li> <li> <a class="dropdown-item " href="/rag/">Active RAGs</a> </li> <li> <a class="dropdown-item " href="/team/">Active Teams</a> </li> </ul> </li> <li><hr class="dropdown-divider"></li> <li class="dropdown-header">New work</li> <li> <a class="dropdown-item " href="/group/chartering/"> Chartering groups </a> </li> <li> <a class="dropdown-item " href="/wg/bofs/"> BOFs </a> </li> <li> <a class="dropdown-item " href="/doc/bof-requests"> BOF Requests </a> </li> <li><hr class="dropdown-divider"></li> <li class="dropdown-header">Other groups</li> <li> <a class="dropdown-item " href="/group/concluded/"> Concluded groups </a> </li> <li> <a class="dropdown-item " href="/list/nonwg"> Non-WG lists </a> </li> </ul> </li> <li class="nav-item dropdown"> <a href="#" class="nav-link dropdown-toggle" role="button" data-bs-toggle="dropdown" aria-expanded="false"> Documents </a> <ul class="dropdown-menu mt-n1"> <li> <a class="dropdown-item " href="/doc/search"> Search </a> </li> <li> <a class="dropdown-item " href="/doc/recent"> Recent I-Ds </a> </li> <li> <a class="dropdown-item " href="/submit/"> I-D submission </a> </li> <li> <a class="dropdown-item " href="/doc/ad"> IESG dashboard </a> </li> <li><hr class="dropdown-divider"> </li> <li class="dropdown-header"> RFC streams </li> <li> <a class="dropdown-item " href="/stream/iab/"> IAB </a> </li> <li> <a class="dropdown-item " href="/stream/irtf/"> IRTF </a> </li> <li> <a class="dropdown-item " href="/stream/ise/"> ISE </a> </li> <li> <a class="dropdown-item " href="/stream/editorial/"> Editorial </a> </li> <li><hr class="dropdown-divider"> </li> <li class="dropdown-header"> Subseries </li> <li> <a class="dropdown-item " href="/doc/std"> STD </a> <a class="dropdown-item " href="/doc/bcp"> BCP </a> <a class="dropdown-item " href="/doc/fyi"> FYI </a> </li> </ul> </li> <li class="nav-item dropdown"> <a href="#" class="nav-link dropdown-toggle" role="button" data-bs-toggle="dropdown" aria-expanded="false"> Meetings </a> <ul class="dropdown-menu mt-n1"> <li> <a class="dropdown-item " href="/meeting/agenda"> Agenda </a> </li> <li> <a class="dropdown-item " href="/meeting/materials"> Materials </a> </li> <li> <a class="dropdown-item " href="/meeting/floor-plan"> Floor plan </a> </li> <li> <a class="dropdown-item " href="https://www.ietf.org/how/meetings/register/"> Registration </a> </li> <li> <a class="dropdown-item " href="/meeting/important-dates/"> Important dates </a> </li> <li> <a class="dropdown-item " href="/secr/sreq/"> Request a session </a> </li> <li> <a class="dropdown-item " href="/meeting/requests"> Session requests </a> </li> <li><hr class="dropdown-divider"> </li> <li class="dropdown-header"> Upcoming meetings </li> <li> <a class="dropdown-item " href="/meeting/upcoming"> Upcoming meetings </a> </li> <li><hr class="dropdown-divider"> </li> <li class="dropdown-header"> Past meetings </li> <li> <a class="dropdown-item " href="/meeting/past"> Past meetings </a> </li> <li> <a class="dropdown-item " href="https://www.ietf.org/how/meetings/past/"> Meeting proceedings </a> </li> </ul> </li> <li class="nav-item dropdown"> <a href="#" class="nav-link dropdown-toggle" role="button" data-bs-toggle="dropdown" aria-expanded="false"> Other </a> <ul class="dropdown-menu mt-n1"> <li> <a class="dropdown-item " href="/ipr/"> IPR disclosures </a> </li> <li> <a class="dropdown-item " href="/liaison/"> Liaison statements </a> </li> <li> <a class="dropdown-item " href="/iesg/agenda/"> IESG agenda </a> </li> <li> <a class="dropdown-item " href="/nomcom/"> NomComs </a> </li> <li> <a class="dropdown-item " href="/doc/downref"> Downref registry </a> </li> <li> <a class="dropdown-item " href="/stats/"> Statistics </a> <ul class="dropdown-menu mt-n1"> <li> <a class="dropdown-item " href="/stats/document/"> I-Ds/RFCs </a> </li> <li> <a class="dropdown-item " href="/stats/meeting/"> Meetings </a> </li> </ul> </li> <li> <a class="dropdown-item " href="/api/"> API Help </a> </li> <li> <a class="dropdown-item " href="/release/"> Release notes </a> </li> <li> <a class="dropdown-item " target="_blank" href="https://status.ietf.org"> System status </a> </li> <li><hr class="dropdown-divider"> </li> <li> <a class="dropdown-item text-danger " target="_blank" href="https://github.com/ietf-tools/datatracker/issues/new/choose"> <i class="bi bi-bug"> </i> Report a bug </a> </li> </ul> </li> <li class="nav-item dropdown"> <a href="#" class="nav-link dropdown-toggle" role="button" data-bs-toggle="dropdown" aria-expanded="false"> User </a> <ul class="dropdown-menu mt-n1 "> <li> <a class="dropdown-item " rel="nofollow" href="/accounts/login/?next=/doc/draft-ietf-dnsop-rfc7958bis/"> Sign in </a> </li> <li> <a class="dropdown-item " rel="nofollow" href="/accounts/reset/"> Password reset </a> </li> <li> <a class="dropdown-item " href="/accounts/settings/" rel="nofollow"> Preferences </a> </li> <li> <a class="dropdown-item " href="/accounts/create/"> New account </a> </li> </ul></li> </ul> </div> <div class="d-flex align-items-center"> <a class="nav-link text-danger d-none d-xl-inline me-xl-4" target="_blank" href="https://github.com/ietf-tools/datatracker/issues/new/choose"> Report a bug <i class="bi bi-bug"></i> </a> <a class="btn me-1 btn-warning d-none d-sm-block" rel="nofollow" href="/accounts/login/?next=/doc/draft-ietf-dnsop-rfc7958bis/"> Sign in </a> <label class="d-none d-md-block" aria-label="Document search"> <input class="form-control select2-field search-select" id="navbar-doc-search" data-select2-ajax-url="/doc/select2search/document/all/" type="text" data-placeholder="Document search"> </label> </div> <button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navbar-collapse" aria-controls="navbar-collapse" aria-expanded="false" aria-label="Toggle navigation"> <i class="navbar-toggler-icon"></i> </button> </div> </nav> <main class="pt-3 container-fluid" id="main"> <div class="row"> <div class="col mx-lg-3 ietf-auto-nav" id="content"> <noscript> <div class="alert alert-danger alert-ignore my-3"> <b>Javascript disabled?</b> Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality. </div> </noscript> <h1> DNSSEC Trust Anchor Publication for the Root Zone <br> <small class="text-body-secondary">draft-ietf-dnsop-rfc7958bis-06</small> </h1> <ul class="nav nav-tabs my-3"> <li class="nav-item"> <a class="nav-link active" href="/doc/draft-ietf-dnsop-rfc7958bis/"> Status </a> </li> <li class="nav-item"> <a class="nav-link " href="/doc/draft-ietf-dnsop-rfc7958bis/ballot/"> IESG evaluation record </a> </li> <li class="nav-item"> <a class="nav-link " href="/doc/draft-ietf-dnsop-rfc7958bis/writeup/"> IESG writeups </a> </li> <li class="nav-item"> <a class="nav-link " href="/doc/draft-ietf-dnsop-rfc7958bis/email/"> Email expansions </a> </li> <li class="nav-item"> <a class="nav-link " href="/doc/draft-ietf-dnsop-rfc7958bis/history/"> History </a> </li> </ul> <label class="my-1 fw-bold">Versions:</label> <nav class="mb-3"> <ul class="revision-list pagination pagination-sm text-center flex-wrap"> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-dnsop-rfc7958bis/00/" > 00 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-dnsop-rfc7958bis/01/" rel="nofollow"> 01 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-dnsop-rfc7958bis/02/" rel="nofollow"> 02 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-dnsop-rfc7958bis/03/" rel="nofollow"> 03 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-dnsop-rfc7958bis/04/" rel="nofollow"> 04 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-dnsop-rfc7958bis/05/" rel="nofollow"> 05 </a> </li> <li class="page-item active"> <a class="page-link" href="/doc/draft-ietf-dnsop-rfc7958bis/06/" > 06 </a> </li> </ul> </nav> <div id="doc-timeline"></div> <table class="table table-sm table-borderless"> <tbody class="meta align-top border-top"> <tr> <th scope="row">Document</th> <th scope="row">Type</th> <td class="edit"></td> <td> <span class="text-success">Active Internet-Draft</span> (<a href="/wg/dnsop/about/">dnsop WG</a>) </td> </tr> <tr> <td></td> <th scope="row">Authors</th> <td class="edit"> </td> <td> <span ><a title="Datatracker profile of Joe Abley" href="/person/jabley@strandkip.nl" >Joe Abley</a> <a href="mailto:jabley%40strandkip.nl" aria-label="Compose email to jabley@strandkip.nl" title="Compose email to jabley@strandkip.nl"> <i class="bi bi-envelope"></i></a></span>, <span ><a title="Datatracker profile of Jakob Schlyter" href="/person/jakob@kirei.se" >Jakob Schlyter</a> <a href="mailto:jakob%40kirei.se" aria-label="Compose email to jakob@kirei.se" title="Compose email to jakob@kirei.se"> <i class="bi bi-envelope"></i></a></span>, <span ><a title="Datatracker profile of Guillaume Bailey" href="/person/gubailey@microsoft.com" >Guillaume Bailey</a> <a href="mailto:gubailey%40microsoft.com" aria-label="Compose email to gubailey@microsoft.com" title="Compose email to gubailey@microsoft.com"> <i class="bi bi-envelope"></i></a></span>, <span ><a title="Datatracker profile of Paul E. Hoffman" href="/person/paul.hoffman@icann.org" >Paul E. Hoffman</a> <a href="mailto:paul.hoffman%40icann.org" aria-label="Compose email to paul.hoffman@icann.org" title="Compose email to paul.hoffman@icann.org"> <i class="bi bi-envelope"></i></a></span> </td> </tr> <tr> <td></td> <th scope="row">Last updated</th> <td class="edit"></td> <td> 2024-09-23 <span class="text-body-secondary">(Latest revision 2024-09-04)</span> </td> </tr> <tr> <td></td> <th scope="row">Replaces</th> <td class="edit"> </td> <td> <a href="/doc/draft-bash-rfc7958bis/" title="DNSSEC Trust Anchor Publication for the Root Zone">draft-bash-rfc7958bis</a> </td> </tr> <tr> <td></td> <th scope="row"> RFC stream </th> <td class="edit"> </td> <td > Internet Engineering Task Force (IETF) </td> </tr> <tr> <td></td> <th scope="row"> Intended RFC status </th> <td class="edit"> </td> <td> Informational </td> </tr> <tr> <td></td> <th scope="row"> Formats </th> <td class="edit"> </td> <td> <div class="buttonlist"> <a class="btn btn-primary btn-sm" target="_blank" href="https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc7958bis-06.txt"> <i class="bi bi-file-text"></i> txt </a> <a class="btn btn-primary btn-sm" target="_blank" href="https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc7958bis-06.html"> <i class="bi bi-file-code"></i> html </a> <a class="btn btn-primary btn-sm" target="_blank" href="https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc7958bis-06.xml"> <i class="bi bi-file-code"></i> xml </a> <a class="btn btn-primary btn-sm" href="/doc/html/draft-ietf-dnsop-rfc7958bis-06"> <i class="bi bi-file-code"></i> htmlized </a> <a class="btn btn-primary btn-sm" target="_blank" href="/doc/draft-ietf-dnsop-rfc7958bis/06/bibtex/"> <i class="bi bi-file-ruled"></i> bibtex </a> <a class="btn btn-primary btn-sm" target="_blank" href="/doc/bibxml3/draft-ietf-dnsop-rfc7958bis-06.xml"> <i class="bi bi-file-code"></i> bibxml </a> </div> </td> </tr> <tr> <td></td> <th scope="row"> Reviews </th> <td class="edit"> </td> <td> <div class="review-assignment-summary"> <a href="/doc/review-ietf-dnsop-rfc7958bis-06-secdir-telechat-wierenga-2024-09-12/"> SECDIR Telechat review by Klaas Wierenga</a> <span class="badge rounded-pill text-bg-success text-wrap"> <i class="bi bi-"></i> Ready </span> </div> <div class="review-assignment-summary"> <a href="/doc/review-ietf-dnsop-rfc7958bis-06-dnsdir-telechat-spacek-2024-09-06/"> DNSDIR Telechat review by Petr 艩pa膷ek</a> <span class="badge rounded-pill text-bg-success text-wrap"> <i class="bi bi-"></i> Ready w/nits </span> </div> <div class="review-assignment-summary"> <a href="/doc/review-ietf-dnsop-rfc7958bis-05-dnsdir-telechat-spacek-2024-09-02/"> DNSDIR Telechat review (of -05) by Petr 艩pa膷ek</a> <span class="badge rounded-pill text-bg-success text-wrap"> <i class="bi bi-"></i> Ready w/issues </span> </div> <div class="review-assignment-summary"> <a href="/doc/review-ietf-dnsop-rfc7958bis-04-dnsdir-telechat-spacek-2024-08-27/"> DNSDIR Telechat review (of -04) by Petr 艩pa膷ek</a> <span class="badge rounded-pill text-bg-success text-wrap"> <i class="bi bi-"></i> Almost ready </span> </div> <div class="review-assignment-summary"> <a href="/doc/review-ietf-dnsop-rfc7958bis-03-genart-lc-romascanu-2024-08-02/"> GENART Last Call review (of -03) by Dan Romascanu</a> <span class="badge rounded-pill text-bg-success text-wrap"> <i class="bi bi-"></i> Ready w/issues </span> </div> <div class="review-assignment-summary"> <a href="/doc/review-ietf-dnsop-rfc7958bis-03-artart-lc-hollenbeck-2024-07-29/"> ARTART Last Call review (of -03) by Scott Hollenbeck</a> <span class="badge rounded-pill text-bg-success text-wrap"> <i class="bi bi-"></i> Ready w/nits </span> </div> <div class="review-assignment-summary"> <a href="/doc/review-ietf-dnsop-rfc7958bis-03-secdir-lc-wierenga-2024-08-01/"> SECDIR Last Call review (of -03) by Klaas Wierenga</a> <span class="badge rounded-pill text-bg-info text-wrap"> <i class="bi bi-info-lg"></i> Has nits </span> </div> <div class="review-assignment-summary"> <a href="/doc/review-ietf-dnsop-rfc7958bis-03-dnsdir-lc-spacek-2024-07-31/"> DNSDIR Last Call review (of -03) by Petr 艩pa膷ek</a> <span class="badge rounded-pill text-bg-warning text-wrap"> <i class="bi bi-exclamation-lg"></i> On the right track </span> </div> <div class="review-assignment-summary"> <a href="/doc/review-ietf-dnsop-rfc7958bis-00-dnsdir-early-obser-2024-02-06/"> DNSDIR Early review (of -00) by Florian Obser</a> <span class="badge rounded-pill text-bg-success text-wrap"> <i class="bi bi-"></i> Ready w/nits </span> </div> </td> </tr> <tr> <td> </td> <th scope="row"> Additional resources </th> <td class="edit"> </td> <td> <a href="https://github.com/paulehoffman/draft-bash-rfc7958bis" title="GitHub Repository"> GitHub Repository </a> <br> <a href="https://mailarchive.ietf.org/arch/browse/dnsop/?q=draft-ietf-dnsop-rfc7958bis"> Mailing list discussion </a> </td> </tr> </tbody> <tbody class="meta border-top"> <tr> <th scope="row"> Stream </th> <th scope="row"> <a href="/doc/help/state/draft-stream-ietf/"> WG state </a> </th> <td class="edit"> </td> <td> <span class=""> Submitted to IESG for Publication </span> </td> </tr> <tr> <td></td> <th scope="row"> Document shepherd </th> <td class="edit"> </td> <td> <span ><a title="Datatracker profile of Suzanne Woolf" href="/person/swoolf@pir.org" >Suzanne Woolf</a> <a href="mailto:swoolf%40pir.org" aria-label="Compose email to swoolf@pir.org" title="Compose email to swoolf@pir.org"> <i class="bi bi-envelope"></i></a></span> </td> </tr> <tr> <td></td> <th scope="row"> Shepherd write-up </th> <td class="edit"> </td> <td> <a class="btn btn-primary btn-sm" href="/doc/draft-ietf-dnsop-rfc7958bis/shepherdwriteup/"> Show </a> <span class="badge rounded-pill text-bg-secondary">Last changed 2024-07-12</span> </td> </tr> </tbody> <tbody class="meta border-top"> <tr> <th scope="row"> IESG </th> <th scope="row"> <a href="/doc/help/state/draft-iesg/"> IESG state </a> </th> <td class="edit"> </td> <td> <span class=""> RFC Ed Queue </span> </td> </tr> <tr> <td></td> <th scope="row"> Action Holders </th> <td class="edit"> </td> <td> <div> <span class="text-body-secondary"> (None) </span> </div> </td> </tr> <tr> <td></td> <th scope="row"> Consensus boilerplate </th> <td class="edit"> </td> <td> <span class="text-success" title="Whether the document is the result of a community consensus process as defined in RFC 5741"> Yes </span> </td> </tr> <tr> <td></td> <th scope="row"> Telechat date </th> <td class="edit"> </td> <td> <span class="text-body-secondary"> (None) </span> </td> </tr> <tr> <td></td> <th scope="row"> Responsible AD </th> <td class="edit"> </td> <td> <span ><a title="Datatracker profile of Warren "Ace" Kumari" href="/person/warren@kumari.net" >Warren "Ace" Kumari</a> <a href="mailto:warren%40kumari.net" aria-label="Compose email to warren@kumari.net" title="Compose email to warren@kumari.net"> <i class="bi bi-envelope"></i></a></span> </td> </tr> <tr> <td></td> <th scope="row"> Send notices to </th> <td class="edit"> </td> <td> <a href="mailto:benno@NLnetLabs.nl">benno@NLnetLabs.nl</a>, <a href="mailto:suzworldwide@gmail.com">suzworldwide@gmail.com</a> </td> </tr> </tbody> <tbody class="meta border-top"> <tr> <th scope="row"> IANA </th> <th scope="row"> <a href="/doc/help/state/draft-iana-review/"> IANA review state </a> </th> <td class="edit"> </td> <td class="text-success"> IANA OK - No Actions Needed </td> </tr> <tr> <th scope="row"> </th> <th scope="row"> <a href="/doc/help/state/draft-iana-action/"> IANA action state </a> </th> <td class="edit"> </td> <td> No IANA Actions </td> </tr> </tbody> <tbody class="meta border-top"> <tr> <th scope="row"> RFC Editor </th> <th scope="row"> <a href="/doc/help/state/draft-rfceditor/"> RFC Editor state </a> </th> <td class="edit"> </td> <td> EDIT </td> </tr> <tr> <td></td> <th scope="row"> Details </th> <td class="edit"> </td> <td> <div> <a href="https://www.rfc-editor.org/queue2.html#draft-ietf-dnsop-rfc7958bis"> Publication queue entry </a> </div> </td> </tr> </tbody> </table> <div class="buttonlist"> <a class="btn btn-primary btn-sm" href="mailto:draft-ietf-dnsop-rfc7958bis@ietf.org?subject=Mail%20regarding%20draft-ietf-dnsop-rfc7958bis"> <i class="bi bi-envelope"> </i> Email authors </a> <a class="btn btn-primary btn-sm" href="mailto:dnsop@ietf.org?subject=Mail%20regarding%20draft-ietf-dnsop-rfc7958bis"> <i class="bi bi-envelope"> </i> Email WG </a> <a class="btn btn-primary btn-sm" href="/ipr/search/?submit=draft&id=draft-ietf-dnsop-rfc7958bis" rel="nofollow"> <i class="bi bi-lightning"> </i> IPR </a> <a class="btn btn-primary btn-sm" href="/doc/draft-ietf-dnsop-rfc7958bis/references/" rel="nofollow"> <i class="bi bi-arrow-left"> </i> References </a> <a class="btn btn-primary btn-sm" href="/doc/draft-ietf-dnsop-rfc7958bis/referencedby/" rel="nofollow"> <i class="bi bi-arrow-right"> </i> Referenced by </a> <a class="btn btn-primary btn-sm" href="https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc7958bis-06.txt" rel="nofollow" target="_blank"> <i class="bi bi-exclamation"> </i> Nits </a> <a class="btn btn-primary btn-sm" href="https://mailarchive.ietf.org/arch/search/?q=%22draft-ietf-dnsop-rfc7958bis%22" rel="nofollow" target="_blank"> <i class="bi bi-search"> </i> Search email archive </a> </div> <div class="card mt-5"> <div class="card-header"> draft-ietf-dnsop-rfc7958bis-06 </div> <div class="card-body"> <pre>Network Working Group J. Abley Internet-Draft Cloudflare Obsoletes: 7958 (if approved) J. Schlyter Intended status: Informational Kirei AB Expires: 8 March 2025 G. Bailey Independent P. Hoffman ICANN 4 September 2024 DNSSEC Trust Anchor Publication for the Root Zone draft-ietf-dnsop-rfc7958bis-06 <span>Abstract</span> The root zone of the global Domain Name System (DNS) is cryptographically signed using DNS Security Extensions (DNSSEC). In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA uses to distribute the DNSSEC trust anchors. This document obsoletes RFC 7958. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/. Source for this draft and an issue tracker can be found at https://github.com/paulehoffman/draft-bash-rfc7958bis. <span>Status of This Memo</span> This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. <span>Abley, et al. Expires 8 March 2025 [Page 1]</span> <span>Internet-Draft Root Zone Trust Anchor Publication September 2024</span> Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 March 2025. <span>Copyright Notice</span> Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. <span>Table of Contents</span> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2. IANA DNSSEC Root Zone Trust Anchor Format and Semantics . . . 4 2.1. XML Syntax . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. XML Semantics . . . . . . . . . . . . . . . . . . . . . . 5 2.3. XML Example . . . . . . . . . . . . . . . . . . . . . . . 7 3. Root Zone Trust Anchor Retrieval . . . . . . . . . . . . . . 8 3.1. Retrieving Trust Anchors with HTTPS and HTTP . . . . . . 8 3.2. Accepting DNSSEC Trust Anchors . . . . . . . . . . . . . 9 3.3. Changes in the Trust Model for Distribution . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4.1. Security Considerations for Relying Parties . . . . . . . 10 4.1.1. validUntil . . . . . . . . . . . . . . . . . . . . . 10 4.1.2. Comparison of Digest and a publickeyinfo . . . . . . 10 4.1.3. Different Outputs from Processing the Trust Anchor File . . . . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Changes from RFC 7958 . . . . . . . . . . . . . . . 13 Appendix B. Historical Note . . . . . . . . . . . . . . . . . . 13 Appendix C. Acknowledgemwents . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 <span>Abley, et al. Expires 8 March 2025 [Page 2]</span> <span>Internet-Draft Root Zone Trust Anchor Publication September 2024</span> 1. Introduction The global Domain Name System (DNS) is described in [RFC1034] and [RFC1035]. DNS Security Extensions (DNSSEC) are described in [RFC9364]. In the DNSSEC protocol, Resource Record Sets (RRSets) are signed cryptographically. This means that a response to a query contains signatures that allow the integrity and authenticity of the RRSet to be verified. DNSSEC signatures are validated by following a chain of signatures to a "trust anchor". The reason for trusting a trust anchor is outside the DNSSEC protocol, but having one or more trust anchors is required for the DNSSEC protocol to work. The publication of trust anchors for the root zone of the DNS is an IANA function performed by ICANN, through its affiliate Public Technical Identifiers (PTI). A detailed description of corresponding key management practices can be found in [DPS]. This document describes the formats and distribution methods of DNSSEC trust anchors that is used by IANA for the root zone of the DNS. Other organizations might have different formats and mechanisms for distributing DNSSEC trust anchors for the root zone; however, most operators and software vendors have chosen to rely on the IANA trust anchors. The formats and distribution methods described in this document are a complement to, not a substitute for, the automated DNSSEC trust anchor update protocol described in [RFC5011]. That protocol allows for secure in-band succession of trust anchors when trust has already been established. This document describes one way to establish an initial trust anchor that can be used by [RFC5011]. This document obsoletes [RFC7958]. 1.1. Definitions The term "trust anchor" is used in many different contexts in the security community. Many of the common definitions conflict because they are specific to a specific system, such as just for DNSSEC or just for S/MIME messages. In cryptographic systems with hierarchical structure, a trust anchor is an authoritative entity for which trust is assumed and not derived. The format of the entity differs in different systems, but the basic idea, the decision to trust this entity is made outside of the system that relies on it, is common to all the common uses of the term "trust anchor". <span>Abley, et al. Expires 8 March 2025 [Page 3]</span> <span>Internet-Draft Root Zone Trust Anchor Publication September 2024</span> The root zone trust anchor formats published by IANA are defined in Section 2. [RFC4033] defines a trust anchor as "A configured DNSKEY RR or DS RR hash of a DNSKEY RR". Note that the formats defined here do not match the definition of "trust anchor" from [RFC4033]; however, a system that wants to convert the trusted material from IANA into a Delegation Signer (DS) RR can do so. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. IANA DNSSEC Root Zone Trust Anchor Format and Semantics IANA publishes trust anchors for the root zone as an XML document that contains the hashes of the DNSKEY records and optionally the keys from the DNSKEY records. This format and the semantics associated are described in the rest of this section. Note that the XML document can have XML comments. For example, IANA might use these comments to add pointers to important information on the IANA web site. XML comments are only used as human-readable commentary, not extensions to the grammar. The XML document contains a set of hashes for the DNSKEY records that can be used to validate the root zone. The hashes are consistent with the defined presentation format of a DS resource. The XML document also can contain the keys and flags from the DNSKEY records. The keys and flags are consistent with the defined presentation format of a DNSKEY resource. Note that the hashes are mandatory in the syntax, but the keys are optional. 2.1. XML Syntax A RELAX NG Compact Schema [RELAX-NG] for the documents used to publish trust anchors is: <span>Abley, et al. Expires 8 March 2025 [Page 4]</span> <span>Internet-Draft Root Zone Trust Anchor Publication September 2024</span> datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes" start = element TrustAnchor { attribute id { xsd:string }, attribute source { xsd:string }, element Zone { xsd:string }, keydigest+ } keydigest = element KeyDigest { attribute id { xsd:string }, attribute validFrom { xsd:dateTime }, attribute validUntil { xsd:dateTime }?, element KeyTag { xsd:nonNegativeInteger { maxInclusive = "65535" } }, element Algorithm { xsd:nonNegativeInteger { maxInclusive = "255" } }, element DigestType { xsd:nonNegativeInteger { maxInclusive = "255" } }, element Digest { xsd:hexBinary }, publickeyinfo? } publickeyinfo = element PublicKey { xsd:base64Binary }, element Flags { xsd:nonNegativeInteger { maxInclusive = "65535" } } 2.2. XML Semantics The TrustAnchor element is the container for all of the trust anchors in the file. The id attribute in the TrustAnchor element is an opaque string that identifies the set of trust anchors. Its value has no particular semantics. Note that the id element in the TrustAnchor element is different than the id element in the KeyDigest element, described below. The source attribute in the TrustAnchor element gives information about where to obtain the TrustAnchor container. It is likely to be a URL and is advisory only. <span>Abley, et al. Expires 8 March 2025 [Page 5]</span> <span>Internet-Draft Root Zone Trust Anchor Publication September 2024</span> The Zone element in the TrustAnchor element states to which DNS zone this container applies. The element is in presentation format as specified in [RFC1035], including the trailing dot. The root zone is indicated by a single period (.) character without any quotation marks. The TrustAnchor element contains one or more KeyDigest elements. Each KeyDigest element represents the digest of a past, current, or potential future DNSKEY record of the zone defined in the Zone element. The values for the elements in the KeyDigest element are defined in [RFC4034]. The IANA registries for these values are described in [RFC9157]. The id attribute in the KeyDigest element is an opaque string that identifies the hash. Note that the id element in the KeyDigest element is different than the id element in the TrustAnchor element described above. The validFrom and validUntil attributes in the KeyDigest element specify the range of times that the KeyDigest element can be used as a trust anchor. The KeyTag element in the KeyDigest element contains the key tag for the DNSKEY record represented in this KeyDigest. The Algorithm element in the KeyDigest element contains the DNSSEC signing algorithm identifier for the DNSKEY record represented in this KeyDigest. The DigestType element in the KeyDigest element contains the DNSSEC digest algorithm identifier for the DNSKEY record represented in this KeyDigest. The Digest element in the KeyDigest element contains the hexadecimal representation of the hash for the DNSKEY record represented in this KeyDigest. The publickeyinfo named pattern in the KeyDigest element contains two mandatory elements: the base64 representation of the public key for the DNSKEY record represented in this KeyDigest, and the flags of the DNSKEY record represented in this KeyDigest. The publickeyinfo named pattern is optional and is new in this version of the specification. It can be useful when IANA has a trust anchor that has not yet been published in the DNS root, and for calculating a comparison to the Digest element. <span>Abley, et al. Expires 8 March 2025 [Page 6]</span> <span>Internet-Draft Root Zone Trust Anchor Publication September 2024</span> 2.3. XML Example The following is an example of what the trust anchor file might look like. The full public key is only given for the trust anchor that does not have a validFrom ttime in the past. <?xml version="1.0" encoding="UTF-8"?> <TrustAnchor id="E9724F53-1851-4F86-85E5-F1392102940B" source="http://data.iana.org/root-anchors/root-anchors.xml"> <Zone>.</Zone> <KeyDigest id="Kjqmt7v" validFrom="2010-07-15T00:00:00+00:00" validUntil="2019-01-11T00:00:00+00:00"> <!-- This key is no longer valid, since validUntil is in the past --> <KeyTag>19036</KeyTag> <Algorithm>8</Algorithm> <DigestType>2</DigestType> <Digest> 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 </Digest> </KeyDigest> <KeyDigest id="Klajeyz" validFrom="2017-02-02T00:00:00+00:00"> <KeyTag>20326</KeyTag> <Algorithm>8</Algorithm> <DigestType>2</DigestType> <Digest> E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D </Digest> <PublicKey> AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4Rg WOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQ uCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj /EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Ap xz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXG Xws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= </PublicKey> <Flags>257</Flags> </KeyDigest> <!-- The following is called "KSK-2024" as a shorthand name --> <KeyDigest id="Kmyv6jo" validFrom="2024-07-18T00:00:00+00:00"> <KeyTag>38696</KeyTag> <Algorithm>8</Algorithm> <DigestType>2</DigestType> <Digest> 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16 </Digest> </KeyDigest> </TrustAnchor> <span>Abley, et al. Expires 8 March 2025 [Page 7]</span> <span>Internet-Draft Root Zone Trust Anchor Publication September 2024</span> The DS RRset derived from this example would be: . IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D . IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16 Note that this DS record set only has two records. The potential third record, the one that would have included the key tag 19036, is already invalid based on the validUntil attribute's value and is thus not part of the trust anchor set. The DNSKEY RRset derived from this example would be: . IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU= Note that this DNSKEY record set only has one record. One potential second record, the one that would have been based on the key tag 19036, is already invalid based on the validUntil attribute's value and is thus not part of the trust anchor set. The other potential second record, the one that would have been based on the key tag 38696, does not contain the optional publickeyinfo named pattern and therefore the DNSKEY record for it cannot be calculated. 3. Root Zone Trust Anchor Retrieval 3.1. Retrieving Trust Anchors with HTTPS and HTTP Trust anchors are available for retrieval using HTTPS and HTTP. In this section, all URLs are given using the "https:" scheme. If HTTPS cannot be used, replace the "https:" scheme with "http:". The URL for retrieving the set of hashes in the XML file described in Section 2 is <https://data.iana.org/root-anchors/root-anchors.xml>. <span>Abley, et al. Expires 8 March 2025 [Page 8]</span> <span>Internet-Draft Root Zone Trust Anchor Publication September 2024</span> 3.2. Accepting DNSSEC Trust Anchors A validator operator can choose whether or not to accept the trust anchors described in this document using whatever policy they want. In order to help validator operators verify the content and origin of trust anchors they receive, IANA uses digital signatures that chain to an ICANN-controlled Certificate Authority (CA) over the trust anchor data. It is important to note that the ICANN CA is not a DNSSEC trust anchor. Instead, it is an optional mechanism for verifying the content and origin of the XML and certificate trust anchors. The content and origin of the XML file can be verified using a digital signature on the file. IANA provides a detached Cryptographic Message Syntax (CMS) [RFC5652] signature that chains to the ICANN CA with the XML file. This can be useful for validator operators who have received a copy of the ICANN CA's public key in a trusted out-of-band fashion. The URL for a detached CMS signature for the XML file is <https://data.iana.org/root-anchors/root-anchors.p7s>. Another method IANA uses to help validator operators verify the content and origin of trust anchors they receive is to use the Transport Layer Security (TLS) protocol for distributing the trust anchors. Currently, the CA used for data.iana.org is well known, that is, one that is a WebTrust-accredited CA. If a system retrieving the trust anchors trusts the CA that IANA uses for the "data.iana.org" web server, HTTPS SHOULD be used instead of HTTP in order to have assurance of data origin. 3.3. Changes in the Trust Model for Distribution IANA used to distribute the trust anchors as a self-signed PGP message and as a self-issued certificate signing request; this was described in [RFC7958]. This document removes those methods because they relied on a trust model that mixed out-of-band trust of authentication keys with out-of-band trust of the DNSSEC root keys. Note, however, that cryptographic assurance for the contents of the trust anchor now comes from the web PKI or the ICANN CA as described in Section 3.2. This cryptographic assurance is bolstered by informal comparisons made by users of the trust anchors, such as software vendors comparing the trust anchor files they are using. <span>Abley, et al. Expires 8 March 2025 [Page 9]</span> <span>Internet-Draft Root Zone Trust Anchor Publication September 2024</span> 4. Security Considerations This document describes how DNSSEC trust anchors for the root zone of the DNS are published. Many DNSSEC clients will only configure IANA- issued trust anchors for the DNS root to perform validation. As a consequence, reliable publication of trust anchors is important. This document aims to specify carefully the means by which such trust anchors are published, with the goal of making it easier for those trust anchors to be integrated into user environments. Some of the methods described (such as accessing over the web with or without verifying the signature on the file) have different security properties; users of the trust anchor file need to consider these when choosing whether to load the set of trust anchors. 4.1. Security Considerations for Relying Parties The body of this document does not specify any particular behavior for relying parties. In specific, it does not say how a relying party should treat the trust anchor file as a whole. However, some of the contents of the trust anchor file require particular attention for relying parties. 4.1.1. validUntil Note that the validUntil attribute of the KeyDigest element is optional. If the relying party is using a trust anchor that has a KeyDigest element that does not have a validUntil attribute, it can change to a trust anchor with a KeyDigest element that does have a validUntil attribute, as long as that trust anchor's validUntil attribute is in the future and the KeyTag, Algorithm, DigestType, and Digest elements of the KeyDigest are the same as the previous trust anchor. Relying parties SHOULD NOT use a KeyDigest outside of the time range given in the validFrom and validUntil attributes. 4.1.2. Comparison of Digest and a publickeyinfo A KeyDigest element can contain both a Digest and a publickeyinfo named pattern. If the Digest element would not be a proper DS record for a DNSKEY record represented by the publickeyinfo named pattern, relying parties MUST NOT use that KeyDigest as a trust anchor. A relying party that wants to make such a comparison needs to marshall the elements of the DNSKEY record that became the DS record using the algorithm specified in Section 5.1.4 of [RFC4034]. <span>Abley, et al. Expires 8 March 2025 [Page 10]</span> <span>Internet-Draft Root Zone Trust Anchor Publication September 2024</span> Relying parties need to implement trust anchor matching carefully. A single trust anchor represented by a KeyDigest element can potentially change its Digest and KeyTag values between two versions of the trust anchor file, for example when the key is revoked or the flag value changes for some other reason. Relying parties which fail to take this property into account are at risk of using an incorrect set of trust anchors. 4.1.3. Different Outputs from Processing the Trust Anchor File Relying parties that require the optional publickeyinfo named pattern to create trust anchors will store fewer trust anhcors than those that only require a Digest element. Thus, two systems processing the same trust anchor file can end up with a different set of trust anchors. 5. IANA Considerations Each time IANA produces a new trust anchor, it MUST publish that trust anchor using the format described in this document. IANA MAY delay the publication of a new trust anchor for operational reasons, such as having a newly-created key in multiple facilities. When a trust anchor that was previously published is no longer suitable for use, IANA MUST update the trust anchor document accordingly by setting a validUntil date for that trust anchor. The validUntil attribute that is added MAY be a date in the past or in the future, depending on IANA's operational choices. More information about IANA's policies and procedures for how the cryptographic keys for the DNS root zone are managed (also known as "DNSSEC Practice Statements" or "DPSs") can be found at https://www.iana.org/dnssec/procedures (https://www.iana.org/dnssec/ procedures). [RFC7958] defined id-mod-dns-resource-record, value 70, which was added to the the "SMI Security for PKIX Module Identifier" registry. This document no longer uses that identifier. 6. References 6.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/rfc/rfc1034>. <span>Abley, et al. Expires 8 March 2025 [Page 11]</span> <span>Internet-Draft Root Zone Trust Anchor Publication September 2024</span> [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/rfc/rfc1035>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/rfc/rfc4033>. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/rfc/rfc4034>. [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, <https://www.rfc-editor.org/rfc/rfc5011>. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/rfc/rfc5652>. [RFC7958] Abley, J., Schlyter, J., Bailey, G., and P. Hoffman, "DNSSEC Trust Anchor Publication for the Root Zone", RFC 7958, DOI 10.17487/RFC7958, August 2016, <https://www.rfc-editor.org/rfc/rfc7958>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. [RFC9157] Hoffman, P., "Revised IANA Considerations for DNSSEC", RFC 9157, DOI 10.17487/RFC9157, December 2021, <https://www.rfc-editor.org/rfc/rfc9157>. [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, February 2023, <https://www.rfc-editor.org/rfc/rfc9364>. 6.2. Informative References <span>Abley, et al. Expires 8 March 2025 [Page 12]</span> <span>Internet-Draft Root Zone Trust Anchor Publication September 2024</span> [DPS] Root Zone KSK Operator Policy Management Authority, "DNSSEC Practice Statement for the Root Zone KSK Operator", n.d., <https://www.iana.org/dnssec/procedures>. [RELAX-NG] Clark, J., "RELAX NG Compact Syntax", 2002, <https://www.oasis-open.org/committees/relax-ng/compact- 20021121.html>. <span>Appendix A. Changes from RFC 7958</span> This version of the document includes the following changes: * There is a significant technical change from erratum 5932 <https://www.rfc-editor.org/errata/eid5932>. This is in the seventh paragraph of Section 2.2. * Added the optional publickeyinfo named pattern with two mandatory elements, PublicKey and Flags. * Removed the certificates and certificate signing mechanisms. * Removed the detached OpenPGP signature mechanism. * The reference to the DNSSEC Practice Statement [DPS] was updated. * Say explicitly that the XML documents might have XML comments in them. * Clarified the use of the detached CMS signature. * Updated the IANA Considerations section to indicate requirements on IANA. * Simplified the description of using the validFrom and validUntil attributes. * Added new security considerations. * There was a bit of editorial cleanup. <span>Appendix B. Historical Note</span> The first KSK for use in the root zone of the DNS was generated at a key ceremony at the ICANN Key Management Facility (KMF) in Culpeper, Virginia, USA on 2010-06-16. This key entered production during a second key ceremony held at an ICANN KMF in El Segundo, California, USA on 2010-07-12. The resulting trust anchor was first published on 2010-07-15. <span>Abley, et al. Expires 8 March 2025 [Page 13]</span> <span>Internet-Draft Root Zone Trust Anchor Publication September 2024</span> The second KSK for use in the root zone of the DNS was generated at key ceremony #27 at the ICANN KMF in Culpeper, Virginia, USA on 2016-10-27. This key entered production during key ceremony #28 held at the ICANN KMF in El Segundo, California, USA on 2017-02-02. The resulting trust anchor was first published on 2018-11-11. More information about the key ceremonies, including full records of previous ceremonies and plans for future ceremonies, can be found at <https://www.iana.org/dnssec/ceremonies>. <span>Appendix C. Acknowledgemwents</span> Many pioneers paved the way for the deployment of DNSSEC in the root zone of the DNS, and the authors hereby acknowledge their substantial collective contribution. RFC 7958 incorporated suggestions made by Alfred Hoenes and Russ Housley, whose contributions are appreciated. <span>Authors' Addresses</span> Joe Abley Cloudflare Amsterdam Netherlands Email: jabley@cloudflare.com Jakob Schlyter Kirei AB Email: jakob@kirei.se Guillaume Bailey Independent Email: guillaumebailey@outlook.com Paul Hoffman ICANN Email: paul.hoffman@icann.org <span>Abley, et al. Expires 8 March 2025 [Page 14]</span> </pre> </div> </div> </div> </div> </main> <footer class="col-md-12 col-sm-12 border-top mt-5 py-5 bg-light-subtle text-center position-sticky"> <a href="https://www.ietf.org/" class="p-3">IETF</a> <a href="https://www.ietf.org/iesg/" class="p-3">IESG</a> <a href="https://www.iab.org/" class="p-3">IAB</a> <a href="https://www.irtf.org/" class="p-3">IRTF</a> <a href="https://www.ietf.org/llc/" class="p-3 text-nowrap">IETF LLC</a> <a href="https://trustee.ietf.org/" class="p-3 text-nowrap">IETF Trust</a> <a href="https://www.rfc-editor.org/" class="p-3 text-nowrap">RFC Editor</a> <a href="https://www.iana.org/" class="p-3">IANA</a> <a href="https://www.ietf.org/privacy-statement/" class="p-3 text-nowrap">Privacy Statement</a> <div class="small text-body-secondary py-3"> <a class="mx-2" href="/release/about">About IETF Datatracker</a> <span class="mx-2"> <a href="https://github.com/ietf-tools/datatracker/releases/tag/12.28.2"> Version 12.28.2 (release - 7ecf23e) </a> </span> <a class="mx-2" href="https://status.ietf.org" target="_blank">System Status</a> <span class="mx-2 text-danger"> <i class="bi bi-bug"></i> Report a bug: <a class="text-reset" target="_blank" href="https://github.com/ietf-tools/datatracker/issues/new/choose">GitHub</a> <a class="text-reset" href="mailto:tools-help@ietf.org">Email</a> </span> </div> </footer> <script src="https://static.ietf.org/dt/12.28.2/ietf/js/d3.js"> </script> <script src="https://static.ietf.org/dt/12.28.2/ietf/js/document_timeline.js"> </script> <script src="https://static.ietf.org/dt/12.28.2/ietf/js/select2.js"></script> <script> $('#navbar-doc-search').on('select2:select', function (e) { window.location.href = e.params.data.url; }); </script> <script type="text/javascript"> var _paq = window._paq || []; _paq.push(['disableCookies']); _paq.push(['trackPageView']); _paq.push(['enableLinkTracking']); (function() { var u="//analytics.ietf.org/"; _paq.push(['setTrackerUrl', u+'matomo.php']); _paq.push(['setSiteId', 7]); var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0]; g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s); })(); </script> <noscript><p><img src="//analytics.ietf.org/piwik.php?idsite=7" style="border:0;" alt="" /></p></noscript> <script>(function(){function c(){var b=a.contentDocument||a.contentWindow.document;if(b){var d=b.createElement('script');d.innerHTML="window.__CF$cv$params={r:'8e972f7d794d40b9',t:'MTczMjc2MzY0My4wMDAwMDA='};var a=document.createElement('script');a.nonce='';a.src='/cdn-cgi/challenge-platform/scripts/jsd/main.js';document.getElementsByTagName('head')[0].appendChild(a);";b.getElementsByTagName('head')[0].appendChild(d)}}if(document.body){var a=document.createElement('iframe');a.height=1;a.width=1;a.style.position='absolute';a.style.top=0;a.style.left=0;a.style.border='none';a.style.visibility='hidden';document.body.appendChild(a);if('loading'!==document.readyState)c();else if(window.addEventListener)document.addEventListener('DOMContentLoaded',c);else{var e=document.onreadystatechange||function(){};document.onreadystatechange=function(b){e(b);'loading'!==document.readyState&&(document.onreadystatechange=e,c())}}}})();</script></body> </html>