RFC 4034 - Resource Records for the DNS Security Extensions

<!DOCTYPE html> <html data-bs-theme="auto" lang="en"> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <title> RFC 4034 - Resource Records for the DNS Security Extensions </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/document_html_referenced.css"> <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" /> <script src="https://static.ietf.org/dt/12.28.2/ietf/js/document_html.js"></script> <script src="https://static.ietf.org/dt/12.28.2/ietf/js/theme.js"></script> <link rel="alternate" type="application/atom+xml" title="Document changes" href="/feed/document-changes/rfc4034/"> <meta name="description" content="Resource Records for the DNS Security Extensions (RFC 4034, )" > <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"> <meta property="og:title" content="RFC 4034: Resource Records for the DNS Security Extensions"> <meta property="og:url" content="https://datatracker.ietf.org/doc/html/rfc4034"> <link rel="canonical" href="https://datatracker.ietf.org/doc/html/rfc4034"> <meta property="og:site_name" content="IETF Datatracker"> <meta property="og:description" content="This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]"> <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="Scott Rose"> <meta property="article:author" content="Matt Larson"> <meta property="article:author" content="Dan Massey"> <meta property="article:author" content="Rob Austein"> <meta property="article:author" content="Roy Arends"> <style> .diff-form .select2-selection__rendered { direction: rtl; text-align: left; } </style> </head> <body> <noscript><iframe class="status" title="Site status" src="/status/latest"></iframe></noscript> <div class="vue-embed" data-component="Status"></div> <div class="btn-toolbar sidebar-toolbar position-fixed top-0 end-0 m-2 m-lg-3 d-print-none"> <div class="dropdown"> <button class="btn btn-outline-secondary btn-sm me-1 dropdown-toggle d-flex align-items-center" id="bd-theme" type="button" aria-expanded="false" data-bs-toggle="dropdown" aria-label="Toggle theme"> <i class="theme-icon-active bi bi-circle-half"></i> </button> <ul class="dropdown-menu" aria-labelledby="bd-theme"> <li> <button type="button" class="dropdown-item d-flex align-items-center" data-bs-theme-value="light" aria-pressed="false"> <i class="me-2 opacity-50 theme-icon bi bi-sun-fill"></i> Light<i class="bi bi-check2 ms-auto d-none"></i> </button> </li> <li> <button type="button" class="dropdown-item d-flex align-items-center" data-bs-theme-value="dark" aria-pressed="false"> <i class="me-2 opacity-50 theme-icon bi bi-moon-stars-fill"></i> Dark<i class="bi bi-check2 ms-auto d-none"></i> </button> </li> <li> <button type="button" class="dropdown-item d-flex align-items-center active" data-bs-theme-value="auto" aria-pressed="true"> <i class="me-2 opacity-50 theme-icon bi bi-circle-half"></i> Auto<i class="bi bi-check2 ms-auto d-none"></i> </button> </li> </ul> </div> <button class="btn btn-outline-secondary btn-sm sidebar-toggle" type="button" data-bs-toggle="collapse" data-bs-target="#sidebar" aria-expanded="true" aria-controls="sidebar" aria-label="Toggle metadata sidebar" title="Toggle metadata sidebar"> <i class="bi bi-arrow-bar-left sidebar-shown"></i> <i class="bi bi-arrow-bar-right sidebar-collapsed"></i> </button> </div> <nav class="navbar bg-light-subtle px-1 fixed-top d-print-none d-md-none"> <a class="nav-link ps-1" href="/doc/rfc4034/"> RFC 4034 <br class="d-sm-none"> <span class="ms-sm-3 badge rounded-pill badge-ps"> Proposed Standard </span> </a> <button class="navbar-toggler p-1" type="button" data-bs-toggle="collapse" data-bs-target="#docinfo-collapse" aria-controls="docinfo-collapse" aria-expanded="false" aria-label="Show document information"> <span class="navbar-toggler-icon small"></span> </button> <div class="navbar-nav navbar-nav-scroll overscroll-none collapse pt-1" id="docinfo-collapse"> <div class="bg-light-subtle p-0"> <table class="table table-sm table-borderless small"> <tbody class="meta align-top"> <tr> <th scope="row"></th> <th scope="row">Title</th> <td class="edit"></td> <td>Resource Records for the DNS Security Extensions</td> </tr> </tbody> <tbody class="meta align-top "> <tr> <th scope="row">Document</th> <th scope="row">Document type</th> <td class="edit"></td> <td> <span class="text-success">RFC - Proposed Standard </span> <br>March 2005 <br> <a class="btn btn-primary btn-sm my-1" href="https://www.rfc-editor.org/errata_search.php?rfc=4034" title="Click to view errata." rel="nofollow"> View errata </a> <a class="btn btn-sm btn-warning" title="Click to report an error in the document." href="https://www.rfc-editor.org/errata.php#reportnew" target="_blank"> Report errata </a> <a title="Click to view IPR declarations." class="btn btn-warning btn-sm my-1" href="/ipr/search/?submit=draft&id=rfc4034">IPR</a> <div>Updated by <a href="/doc/html/rfc9077" title="NSEC and NSEC3: TTLs and Aggressive Use">RFC 9077</a>, <a href="/doc/html/rfc4470" title="Minimally Covering NSEC Records and DNSSEC On-line Signing">RFC 4470</a>, <a href="/doc/html/rfc6014" title="Cryptographic Algorithm Identifier Allocation for DNSSEC">RFC 6014</a>, <a href="/doc/html/rfc6840" title="Clarifications and Implementation Notes for DNS Security (DNSSEC)">RFC 6840</a>, <a href="/doc/html/rfc6944" title="Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status">RFC 6944</a></div> <div>Obsoletes <a href="/doc/html/rfc3090" title="DNS Security Extension Clarification on Zone Status">RFC 3090</a>, <a href="/doc/html/rfc3008" title="Domain Name System Security (DNSSEC) Signing Authority">RFC 3008</a>, <a href="/doc/html/rfc3445" title="Limiting the Scope of the KEY Resource Record (RR)">RFC 3445</a>, <a href="/doc/html/rfc2535" title="Domain Name System Security Extensions">RFC 2535</a>, <a href="/doc/html/rfc3655" title="Redefinition of DNS Authenticated Data (AD) bit">RFC 3655</a>, <a href="/doc/html/rfc3658" title="Delegation Signer (DS) Resource Record (RR)">RFC 3658</a>, <a href="/doc/html/rfc3755" title="Legacy Resolver Compatibility for Delegation Signer (DS)">RFC 3755</a>, <a href="/doc/html/rfc3845" title="DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format">RFC 3845</a>, <a href="/doc/html/rfc3757" title="Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag">RFC 3757</a></div> <div>Updates <a href="/doc/html/rfc3226" title="DNSSEC and IPv6 A6 aware server/resolver message size requirements">RFC 3226</a>, <a href="/doc/html/rfc3225" title="Indicating Resolver Support of DNSSEC">RFC 3225</a>, <a href="/doc/html/rfc2136" title="Dynamic Updates in the Domain Name System (DNS UPDATE)">RFC 2136</a>, <a href="/doc/html/rfc1035" title="Domain names - implementation and specification">RFC 1035</a>, <a href="/doc/html/rfc3597" title="Handling of Unknown DNS Resource Record (RR) Types">RFC 3597</a>, <a href="/doc/html/rfc2308" title="Negative Caching of DNS Queries (DNS NCACHE)">RFC 2308</a>, <a href="/doc/html/rfc1034" title="Domain names - concepts and facilities">RFC 1034</a>, <a href="/doc/html/rfc2181" title="Clarifications to the DNS Specification">RFC 2181</a>, <a href="/doc/html/rfc3007" title="Secure Domain Name System (DNS) Dynamic Update">RFC 3007</a></div> <div> Was <a href="/doc/draft-ietf-dnsext-dnssec-records/11/">draft-ietf-dnsext-dnssec-records</a> (<a href="/wg/dnsext/about/">dnsext WG</a>) </div> </td> </tr> <tr> <td></td> <th scope="row">Select version</th> <td class="edit"></td> <td> <ul class="revision-list pagination pagination-sm text-center flex-wrap my-0"> <li class="page-item"> <a class="page-link" href="/doc/html/draft-ietf-dnsext-dnssec-records-11" rel="nofollow"> 11 </a> </li> <li class="page-item rfc active"> <a class="page-link" href="/doc/html/rfc4034"> RFC 4034 </a> </li> </ul> </td> </tr> <tr> <td></td> <th scope="row">Compare versions</th> <td class="edit"></td> <td> <form class="form-horizontal diff-form" action="https://author-tools.ietf.org/iddiff" method="get" target="_blank"> <select class="form-select form-select-sm mb-1 select2-field" data-max-entries="1" data-width="resolve" data-allow-clear="false" data-minimum-input-length="0" aria-label="From revision" name="url1"> <option value="rfc4034"> RFC 4034 </option> <option value="draft-ietf-dnsext-dnssec-records-11" selected> draft-ietf-dnsext-dnssec-records-11 </option> <option value="draft-ietf-dnsext-dnssec-records-10"> draft-ietf-dnsext-dnssec-records-10 </option> <option value="draft-ietf-dnsext-dnssec-records-09"> draft-ietf-dnsext-dnssec-records-09 </option> <option value="draft-ietf-dnsext-dnssec-records-08"> draft-ietf-dnsext-dnssec-records-08 </option> <option value="draft-ietf-dnsext-dnssec-records-07"> draft-ietf-dnsext-dnssec-records-07 </option> <option value="draft-ietf-dnsext-dnssec-records-06"> draft-ietf-dnsext-dnssec-records-06 </option> <option value="draft-ietf-dnsext-dnssec-records-05"> draft-ietf-dnsext-dnssec-records-05 </option> <option value="draft-ietf-dnsext-dnssec-records-04"> draft-ietf-dnsext-dnssec-records-04 </option> <option value="draft-ietf-dnsext-dnssec-records-03"> draft-ietf-dnsext-dnssec-records-03 </option> <option value="draft-ietf-dnsext-dnssec-records-02"> draft-ietf-dnsext-dnssec-records-02 </option> <option value="draft-ietf-dnsext-dnssec-records-01"> draft-ietf-dnsext-dnssec-records-01 </option> <option value="draft-ietf-dnsext-dnssec-records-00"> draft-ietf-dnsext-dnssec-records-00 </option> </select> <select class="form-select form-select-sm mb-1 select2-field" data-max-entries="1" data-width="resolve" data-allow-clear="false" data-minimum-input-length="0" aria-label="To revision" name="url2"> <option value="rfc4034" selected> RFC 4034 </option> <option value="draft-ietf-dnsext-dnssec-records-11"> draft-ietf-dnsext-dnssec-records-11 </option> <option value="draft-ietf-dnsext-dnssec-records-10"> draft-ietf-dnsext-dnssec-records-10 </option> <option value="draft-ietf-dnsext-dnssec-records-09"> draft-ietf-dnsext-dnssec-records-09 </option> <option value="draft-ietf-dnsext-dnssec-records-08"> draft-ietf-dnsext-dnssec-records-08 </option> <option value="draft-ietf-dnsext-dnssec-records-07"> draft-ietf-dnsext-dnssec-records-07 </option> <option value="draft-ietf-dnsext-dnssec-records-06"> draft-ietf-dnsext-dnssec-records-06 </option> <option value="draft-ietf-dnsext-dnssec-records-05"> draft-ietf-dnsext-dnssec-records-05 </option> <option value="draft-ietf-dnsext-dnssec-records-04"> draft-ietf-dnsext-dnssec-records-04 </option> <option value="draft-ietf-dnsext-dnssec-records-03"> draft-ietf-dnsext-dnssec-records-03 </option> <option value="draft-ietf-dnsext-dnssec-records-02"> draft-ietf-dnsext-dnssec-records-02 </option> <option value="draft-ietf-dnsext-dnssec-records-01"> draft-ietf-dnsext-dnssec-records-01 </option> <option value="draft-ietf-dnsext-dnssec-records-00"> draft-ietf-dnsext-dnssec-records-00 </option> </select> <button type="submit" class="btn btn-primary btn-sm" value="--html" name="difftype"> Side-by-side </button> <button type="submit" class="btn btn-primary btn-sm" value="--hwdiff" name="difftype"> Inline </button> </form> </td> </tr> <tr> <td></td> <th scope="row">Authors</th> <td class="edit"> </td> <td> <span ><a title="Datatracker profile of Scott Rose" href="/person/scott.rose@nist.gov" >Scott Rose</a> <a href="mailto:scott.rose%40nist.gov" aria-label="Compose email to scott.rose@nist.gov" title="Compose email to scott.rose@nist.gov"> <i class="bi bi-envelope"></i></a></span>, <span ><a title="Datatracker profile of Matt Larson" href="/person/matt.larson@icann.org" >Matt Larson</a> <a href="mailto:matt.larson%40icann.org" aria-label="Compose email to matt.larson@icann.org" title="Compose email to matt.larson@icann.org"> <i class="bi bi-envelope"></i></a></span>, <span ><a title="Datatracker profile of Dan Massey" href="/person/masseyd@isi.edu" >Dan Massey</a> <a href="mailto:masseyd%40isi.edu" aria-label="Compose email to masseyd@isi.edu" title="Compose email to masseyd@isi.edu"> <i class="bi bi-envelope"></i></a></span>, <span ><a title="Datatracker profile of Rob Austein" href="/person/sra@hactrn.net" >Rob Austein</a> <a href="mailto:sra%40hactrn.net" aria-label="Compose email to sra@hactrn.net" title="Compose email to sra@hactrn.net"> <i class="bi bi-envelope"></i></a></span>, <span ><a title="Datatracker profile of Roy Arends" href="/person/roy.arends@icann.org" >Roy Arends</a> <a href="mailto:roy.arends%40icann.org" aria-label="Compose email to roy.arends@icann.org" title="Compose email to roy.arends@icann.org"> <i class="bi bi-envelope"></i></a></span> <br> <a class="btn btn-primary btn-sm mt-1" href="mailto:rfc4034@ietf.org?subject=rfc4034" title="Send email to the document authors">Email authors</a> </td> </tr> <tr> <td></td> <th scope="row"> RFC stream </th> <td class="edit"> </td> <td > <img alt="IETF Logo" class="d-lm-none w-25 mt-1" src="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor-white.svg" > <img alt="IETF Logo" class="d-dm-none w-25 mt-1" src="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor.svg" > </td> </tr> <tr> <td></td> <th scope="row"> Other formats </th> <td class="edit"> </td> <td> <div class="buttonlist"> <a class="btn btn-primary btn-sm" target="_blank" href="https://www.rfc-editor.org/rfc/rfc4034.txt"> <i class="bi bi-file-text"></i> txt </a> <a class="btn btn-primary btn-sm" target="_blank" href="https://www.rfc-editor.org/rfc/rfc4034.html"> <i class="bi bi-file-code"></i> html </a> <a class="btn btn-primary btn-sm" download="rfc4034.pdf" target="_blank" href="https://www.rfc-editor.org/rfc/pdfrfc/rfc4034.txt.pdf"> <i class="bi bi-file-pdf"></i> pdf </a> <a class="btn btn-primary btn-sm" target="_blank" href="https://www.rfc-editor.org/rfc/inline-errata/rfc4034.html"> <i class="bi bi-file-diff"></i> w/errata </a> <a class="btn btn-primary btn-sm" target="_blank" href="/doc/rfc4034/bibtex/"> <i class="bi bi-file-ruled"></i> bibtex </a> </div> </td> </tr> <tr> <td> </td> <th scope="row"> Additional resources </th> <td class="edit"> </td> <td> <a href="https://mailarchive.ietf.org/arch/browse/dnsext?q=rfc4034 OR %22draft-ietf-dnsext-dnssec-records%22"> Mailing list discussion </a> </td> </tr> </tbody> <tr> <th scope="row"></th> <th scope="row"></th> <td class="edit"></td> <td> <a class="btn btn-sm btn-warning mb-3" target="_blank" href="https://github.com/ietf-tools/datatracker/issues/new/choose"> Report a bug <i class="bi bi-bug"></i> </a> </td> </tr> </table> </div> </div> </nav> <div class="row g-0"> <div class="col-md-9 d-flex justify-content-center lh-sm" data-bs-spy="scroll" data-bs-target="#toc-nav" data-bs-smooth-scroll="true" tabindex="0" id="content"> <div class="rfcmarkup"> <br class="noprint">  <div class="rfcmarkup"><pre>Network Working Group R. Arends Request for Comments: 4034 Telematica Instituut Obsoletes: <a href="/doc/html/rfc2535">2535</a>, <a href="/doc/html/rfc3008">3008</a>, <a href="/doc/html/rfc3090">3090</a>, <a href="/doc/html/rfc3445">3445</a>, <a href="/doc/html/rfc3655">3655</a>, <a href="/doc/html/rfc3658">3658</a>, R. Austein <a href="/doc/html/rfc3755">3755</a>, <a href="/doc/html/rfc3757">3757</a>, <a href="/doc/html/rfc3845">3845</a> ISC Updates: <a href="/doc/html/rfc1034">1034</a>, <a href="/doc/html/rfc1035">1035</a>, <a href="/doc/html/rfc2136">2136</a>, <a href="/doc/html/rfc2181">2181</a>, <a href="/doc/html/rfc2308">2308</a>, <a href="/doc/html/rfc3225">3225</a>, M. Larson <a href="/doc/html/rfc3007">3007</a>, <a href="/doc/html/rfc3597">3597</a>, <a href="/doc/html/rfc3226">3226</a> VeriSign Category: Standards Track D. Massey Colorado State University S. Rose NIST March 2005 <span class="h1">Resource Records for the DNS Security Extensions</span> Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes <a href="/doc/html/rfc2535">RFC 2535</a> and incorporates changes from all updates to <a href="/doc/html/rfc2535">RFC 2535</a>. <span class="grey">Arends, et al. Standards Track [Page 1]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-2" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> Table of Contents <a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a> <a href="#section-1.1">1.1</a>. Background and Related Documents . . . . . . . . . . . <a href="#page-3">3</a> <a href="#section-1.2">1.2</a>. Reserved Words . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a> <a href="#section-2">2</a>. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . <a href="#page-4">4</a> <a href="#section-2.1">2.1</a>. DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . <a href="#page-4">4</a> <a href="#section-2.1.1">2.1.1</a>. The Flags Field. . . . . . . . . . . . . . . . <a href="#page-4">4</a> <a href="#section-2.1.2">2.1.2</a>. The Protocol Field . . . . . . . . . . . . . . <a href="#page-5">5</a> <a href="#section-2.1.3">2.1.3</a>. The Algorithm Field. . . . . . . . . . . . . . <a href="#page-5">5</a> <a href="#section-2.1.4">2.1.4</a>. The Public Key Field . . . . . . . . . . . . . <a href="#page-5">5</a> <a href="#section-2.1.5">2.1.5</a>. Notes on DNSKEY RDATA Design . . . . . . . . . <a href="#page-5">5</a> <a href="#section-2.2">2.2</a>. The DNSKEY RR Presentation Format. . . . . . . . . . . <a href="#page-5">5</a> <a href="#section-2.3">2.3</a>. DNSKEY RR Example . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a> <a href="#section-3">3</a>. The RRSIG Resource Record . . . . . . . . . . . . . . . . . <a href="#page-6">6</a> <a href="#section-3.1">3.1</a>. RRSIG RDATA Wire Format. . . . . . . . . . . . . . . . <a href="#page-7">7</a> <a href="#section-3.1.1">3.1.1</a>. The Type Covered Field . . . . . . . . . . . . <a href="#page-7">7</a> <a href="#section-3.1.2">3.1.2</a>. The Algorithm Number Field . . . . . . . . . . <a href="#page-8">8</a> <a href="#section-3.1.3">3.1.3</a>. The Labels Field . . . . . . . . . . . . . . . <a href="#page-8">8</a> <a href="#section-3.1.4">3.1.4</a>. Original TTL Field . . . . . . . . . . . . . . <a href="#page-8">8</a> <a href="#section-3.1.5">3.1.5</a>. Signature Expiration and Inception Fields. . . <a href="#page-9">9</a> <a href="#section-3.1.6">3.1.6</a>. The Key Tag Field. . . . . . . . . . . . . . . <a href="#page-9">9</a> <a href="#section-3.1.7">3.1.7</a>. The Signer's Name Field. . . . . . . . . . . . <a href="#page-9">9</a> <a href="#section-3.1.8">3.1.8</a>. The Signature Field. . . . . . . . . . . . . . <a href="#page-9">9</a> <a href="#section-3.2">3.2</a>. The RRSIG RR Presentation Format . . . . . . . . . . . <a href="#page-10">10</a> <a href="#section-3.3">3.3</a>. RRSIG RR Example . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a> <a href="#section-4">4</a>. The NSEC Resource Record . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a> <a href="#section-4.1">4.1</a>. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . <a href="#page-13">13</a> <a href="#section-4.1.1">4.1.1</a>. The Next Domain Name Field . . . . . . . . . . <a href="#page-13">13</a> <a href="#section-4.1.2">4.1.2</a>. The Type Bit Maps Field. . . . . . . . . . . . <a href="#page-13">13</a> <a href="#section-4.1.3">4.1.3</a>. Inclusion of Wildcard Names in NSEC RDATA. . . <a href="#page-14">14</a> <a href="#section-4.2">4.2</a>. The NSEC RR Presentation Format. . . . . . . . . . . . <a href="#page-14">14</a> <a href="#section-4.3">4.3</a>. NSEC RR Example. . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a> <a href="#section-5">5</a>. The DS Resource Record . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a> <a href="#section-5.1">5.1</a>. DS RDATA Wire Format . . . . . . . . . . . . . . . . . <a href="#page-16">16</a> <a href="#section-5.1.1">5.1.1</a>. The Key Tag Field. . . . . . . . . . . . . . . <a href="#page-16">16</a> <a href="#section-5.1.2">5.1.2</a>. The Algorithm Field. . . . . . . . . . . . . . <a href="#page-16">16</a> <a href="#section-5.1.3">5.1.3</a>. The Digest Type Field. . . . . . . . . . . . . <a href="#page-17">17</a> <a href="#section-5.1.4">5.1.4</a>. The Digest Field . . . . . . . . . . . . . . . <a href="#page-17">17</a> <a href="#section-5.2">5.2</a>. Processing of DS RRs When Validating Responses . . . . <a href="#page-17">17</a> <a href="#section-5.3">5.3</a>. The DS RR Presentation Format. . . . . . . . . . . . . <a href="#page-17">17</a> <a href="#section-5.4">5.4</a>. DS RR Example. . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a> <a href="#section-6">6</a>. Canonical Form and Order of Resource Records . . . . . . . . <a href="#page-18">18</a> <a href="#section-6.1">6.1</a>. Canonical DNS Name Order . . . . . . . . . . . . . . . <a href="#page-18">18</a> <a href="#section-6.2">6.2</a>. Canonical RR Form. . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a> <a href="#section-6.3">6.3</a>. Canonical RR Ordering within an RRset. . . . . . . . . <a href="#page-20">20</a> <a href="#section-7">7</a>. IANA Considerations. . . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a> <a href="#section-8">8</a>. Security Considerations. . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a> <span class="grey">Arends, et al. Standards Track [Page 2]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-3" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> <a href="#section-9">9</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a> <a href="#section-10">10</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a> <a href="#section-10.1">10.1</a>. Normative References . . . . . . . . . . . . . . . . . <a href="#page-22">22</a> <a href="#section-10.2">10.2</a>. Informative References . . . . . . . . . . . . . . . . <a href="#page-23">23</a> <a href="#appendix-A">A</a>. DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . <a href="#page-24">24</a> <a href="#appendix-A.1">A.1</a>. DNSSEC Algorithm Types . . . . . . . . . . . . . . . . <a href="#page-24">24</a> <a href="#appendix-A.1.1">A.1.1</a>. Private Algorithm Types. . . . . . . . . . . . <a href="#page-25">25</a> <a href="#appendix-A.2">A.2</a>. DNSSEC Digest Types. . . . . . . . . . . . . . . . . . <a href="#page-25">25</a> <a href="#appendix-B">B</a>. Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . <a href="#page-25">25</a> <a href="#appendix-B.1">B.1</a>. Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . <a href="#page-27">27</a> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a> Full Copyright Statement . . . . . . . . . . . . . . . . . . . . <a href="#page-29">29</a> <span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span> The DNS Security Extensions (DNSSEC) introduce four new DNS resource record types: DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), Next Secure (NSEC), and Delegation Signer (DS). This document defines the purpose of each resource record (RR), the RR's RDATA format, and its presentation format (ASCII representation). <span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Background and Related Documents</span> This document is part of a family of documents defining DNSSEC, which should be read together as a set. [<a id="ref-RFC4033">RFC4033</a>] contains an introduction to DNSSEC and definition of common terms; the reader is assumed to be familiar with this document. [<a href="/doc/html/rfc4033" title=""DNS Security Introduction and Requirements"">RFC4033</a>] also contains a list of other documents updated by and obsoleted by this document set. [<a id="ref-RFC4035">RFC4035</a>] defines the DNSSEC protocol operations. The reader is also assumed to be familiar with the basic DNS concepts described in [<a href="/doc/html/rfc1034" title=""Domain names - concepts and facilities"">RFC1034</a>], [<a href="/doc/html/rfc1035" title=""Domain names - implementation and specification"">RFC1035</a>], and the subsequent documents that update them, particularly [<a href="/doc/html/rfc2181" title=""Clarifications to the DNS Specification"">RFC2181</a>] and [<a href="/doc/html/rfc2308" title=""Negative Caching of DNS Queries (DNS NCACHE)"">RFC2308</a>]. This document defines the DNSSEC resource records. All numeric DNS type codes given in this document are decimal integers. <span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Reserved Words</span> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [<a href="/doc/html/rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>]. <span class="grey">Arends, et al. Standards Track [Page 3]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-4" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> <span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. The DNSKEY Resource Record</span> DNSSEC uses public key cryptography to sign and authenticate DNS resource record sets (RRsets). The public keys are stored in DNSKEY resource records and are used in the DNSSEC authentication process described in [<a href="/doc/html/rfc4035" title=""Protocol Modifications for the DNS Security Extensions"">RFC4035</a>]: A zone signs its authoritative RRsets by using a private key and stores the corresponding public key in a DNSKEY RR. A resolver can then use the public key to validate signatures covering the RRsets in the zone, and thus to authenticate them. The DNSKEY RR is not intended as a record for storing arbitrary public keys and MUST NOT be used to store certificates or public keys that do not directly relate to the DNS infrastructure. The Type value for the DNSKEY RR type is 48. The DNSKEY RR is class independent. The DNSKEY RR has no special TTL requirements. <span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. DNSKEY RDATA Wire Format</span> The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 octet Protocol Field, a 1 octet Algorithm Field, and the Public Key Field. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Protocol | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Public Key / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>. The Flags Field</span> Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's owner name MUST be the name of a zone. If bit 7 has value 0, then the DNSKEY record holds some other type of DNS public key and MUST NOT be used to verify RRSIGs that cover RRsets. Bit 15 of the Flags field is the Secure Entry Point flag, described in [<a href="/doc/html/rfc3757" title=""Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag"">RFC3757</a>]. If bit 15 has value 1, then the DNSKEY record holds a key intended for use as a secure entry point. This flag is only <span class="grey">Arends, et al. Standards Track [Page 4]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-5" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> intended to be a hint to zone signing or debugging software as to the intended use of this DNSKEY record; validators MUST NOT alter their behavior during the signature validation process in any way based on the setting of this bit. This also means that a DNSKEY RR with the SEP bit set would also need the Zone Key flag set in order to be able to generate signatures legally. A DNSKEY RR with the SEP set and the Zone Key flag not set MUST NOT be used to verify RRSIGs that cover RRsets. Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon creation of the DNSKEY RR and MUST be ignored upon receipt. <span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a>. The Protocol Field</span> The Protocol Field MUST have value 3, and the DNSKEY RR MUST be treated as invalid during signature verification if it is found to be some value other than 3. <span class="h4"><a class="selflink" id="section-2.1.3" href="#section-2.1.3">2.1.3</a>. The Algorithm Field</span> The Algorithm field identifies the public key's cryptographic algorithm and determines the format of the Public Key field. A list of DNSSEC algorithm types can be found in <a href="#appendix-A.1">Appendix A.1</a> <span class="h4"><a class="selflink" id="section-2.1.4" href="#section-2.1.4">2.1.4</a>. The Public Key Field</span> The Public Key Field holds the public key material. The format depends on the algorithm of the key being stored and is described in separate documents. <span class="h4"><a class="selflink" id="section-2.1.5" href="#section-2.1.5">2.1.5</a>. Notes on DNSKEY RDATA Design</span> Although the Protocol Field always has value 3, it is retained for backward compatibility with early versions of the KEY record. <span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. The DNSKEY RR Presentation Format</span> The presentation format of the RDATA portion is as follows: The Flag field MUST be represented as an unsigned decimal integer. Given the currently defined flags, the possible values are: 0, 256, and 257. The Protocol Field MUST be represented as an unsigned decimal integer with a value of 3. The Algorithm field MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic as specified in <a href="#appendix-A.1">Appendix A.1</a>. <span class="grey">Arends, et al. Standards Track [Page 5]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-6" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> The Public Key field MUST be represented as a Base64 encoding of the Public Key. Whitespace is allowed within the Base64 text. For a definition of Base64 encoding, see [<a href="/doc/html/rfc3548" title=""The Base16, Base32, and Base64 Data Encodings"">RFC3548</a>]. <span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. DNSKEY RR Example</span> The following DNSKEY RR stores a DNS zone key for example.com. example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 Cbl+BBZH4b/0PY1kxkmvHjcZc8no kfzj31GajIQKY+5CptLr3buXA10h WqTkF7H6RfoRqXQeogmMHfpftf6z Mv1LyBUgia7za6ZEzOJBOztyvhjL 742iU/TpPSEDhm2SNKLijfUppn1U aNvv4w== ) The first four text fields specify the owner name, TTL, Class, and RR type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in the Flags field has value 1. Value 3 is the fixed Protocol value. Value 5 indicates the public key algorithm. <a href="#appendix-A.1">Appendix A.1</a> identifies algorithm type 5 as RSA/SHA1 and indicates that the format of the RSA/SHA1 public key field is defined in [<a href="/doc/html/rfc3110" title=""RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)"">RFC3110</a>]. The remaining text is a Base64 encoding of the public key. <span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. The RRSIG Resource Record</span> DNSSEC uses public key cryptography to sign and authenticate DNS resource record sets (RRsets). Digital signatures are stored in RRSIG resource records and are used in the DNSSEC authentication process described in [<a href="/doc/html/rfc4035" title=""Protocol Modifications for the DNS Security Extensions"">RFC4035</a>]. A validator can use these RRSIG RRs to authenticate RRsets from the zone. The RRSIG RR MUST only be used to carry verification material (digital signatures) used to secure DNS operations. An RRSIG record contains the signature for an RRset with a particular name, class, and type. The RRSIG RR specifies a validity interval for the signature and uses the Algorithm, the Signer's Name, and the Key Tag to identify the DNSKEY RR containing the public key that a validator can use to verify the signature. Because every authoritative RRset in a zone must be protected by a digital signature, RRSIG RRs must be present for names containing a CNAME RR. This is a change to the traditional DNS specification [<a href="/doc/html/rfc1034" title=""Domain names - concepts and facilities"">RFC1034</a>], which stated that if a CNAME is present for a name, it is the only type allowed at that name. A RRSIG and NSEC (see <a href="#section-4">Section 4</a>) MUST exist for the same name as a CNAME resource record in a signed zone. <span class="grey">Arends, et al. Standards Track [Page 6]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-7" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> The Type value for the RRSIG RR type is 46. The RRSIG RR is class independent. An RRSIG RR MUST have the same class as the RRset it covers. The TTL value of an RRSIG RR MUST match the TTL value of the RRset it covers. This is an exception to the [<a href="/doc/html/rfc2181" title=""Clarifications to the DNS Specification"">RFC2181</a>] rules for TTL values of individual RRs within a RRset: individual RRSIG RRs with the same owner name will have different TTL values if the RRsets they cover have different TTL values. <span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. RRSIG RDATA Wire Format</span> The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original TTL field, a 4 octet Signature Expiration field, a 4 octet Signature Inception field, a 2 octet Key tag, the Signer's Name field, and the Signature field. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type Covered | Algorithm | Labels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature Expiration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature Inception | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Signature / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. The Type Covered Field</span> The Type Covered field identifies the type of the RRset that is covered by this RRSIG record. <span class="grey">Arends, et al. Standards Track [Page 7]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-8" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> <span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>. The Algorithm Number Field</span> The Algorithm Number field identifies the cryptographic algorithm used to create the signature. A list of DNSSEC algorithm types can be found in <a href="#appendix-A.1">Appendix A.1</a> <span class="h4"><a class="selflink" id="section-3.1.3" href="#section-3.1.3">3.1.3</a>. The Labels Field</span> The Labels field specifies the number of labels in the original RRSIG RR owner name. The significance of this field is that a validator uses it to determine whether the answer was synthesized from a wildcard. If so, it can be used to determine what owner name was used in generating the signature. To validate a signature, the validator needs the original owner name that was used to create the signature. If the original owner name contains a wildcard label ("*"), the owner name may have been expanded by the server during the response process, in which case the validator will have to reconstruct the original owner name in order to validate the signature. [<a href="/doc/html/rfc4035" title=""Protocol Modifications for the DNS Security Extensions"">RFC4035</a>] describes how to use the Labels field to reconstruct the original owner name. The value of the Labels field MUST NOT count either the null (root) label that terminates the owner name or the wildcard label (if present). The value of the Labels field MUST be less than or equal to the number of labels in the RRSIG owner name. For example, "www.example.com." has a Labels field value of 3, and "*.example.com." has a Labels field value of 2. Root (".") has a Labels field value of 0. Although the wildcard label is not included in the count stored in the Labels field of the RRSIG RR, the wildcard label is part of the RRset's owner name when the signature is generated or verified. <span class="h4"><a class="selflink" id="section-3.1.4" href="#section-3.1.4">3.1.4</a>. Original TTL Field</span> The Original TTL field specifies the TTL of the covered RRset as it appears in the authoritative zone. The Original TTL field is necessary because a caching resolver decrements the TTL value of a cached RRset. In order to validate a signature, a validator requires the original TTL. [<a href="/doc/html/rfc4035" title=""Protocol Modifications for the DNS Security Extensions"">RFC4035</a>] describes how to use the Original TTL field value to reconstruct the original TTL. <span class="grey">Arends, et al. Standards Track [Page 8]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-9" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> <span class="h4"><a class="selflink" id="section-3.1.5" href="#section-3.1.5">3.1.5</a>. Signature Expiration and Inception Fields</span> The Signature Expiration and Inception fields specify a validity period for the signature. The RRSIG record MUST NOT be used for authentication prior to the inception date and MUST NOT be used for authentication after the expiration date. The Signature Expiration and Inception field values specify a date and time in the form of a 32-bit unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The longest interval that can be expressed by this format without wrapping is approximately 136 years. An RRSIG RR can have an Expiration field value that is numerically smaller than the Inception field value if the expiration field value is near the 32-bit wrap-around point or if the signature is long lived. Because of this, all comparisons involving these fields MUST use "Serial number arithmetic", as defined in [<a href="/doc/html/rfc1982" title=""Serial Number Arithmetic"">RFC1982</a>]. As a direct consequence, the values contained in these fields cannot refer to dates more than 68 years in either the past or the future. <span class="h4"><a class="selflink" id="section-3.1.6" href="#section-3.1.6">3.1.6</a>. The Key Tag Field</span> The Key Tag field contains the key tag value of the DNSKEY RR that validates this signature, in network byte order. <a href="#appendix-B">Appendix B</a> explains how to calculate Key Tag values. <span class="h4"><a class="selflink" id="section-3.1.7" href="#section-3.1.7">3.1.7</a>. The Signer's Name Field</span> The Signer's Name field value identifies the owner name of the DNSKEY RR that a validator is supposed to use to validate this signature. The Signer's Name field MUST contain the name of the zone of the covered RRset. A sender MUST NOT use DNS name compression on the Signer's Name field when transmitting a RRSIG RR. <span class="h4"><a class="selflink" id="section-3.1.8" href="#section-3.1.8">3.1.8</a>. The Signature Field</span> The Signature field contains the cryptographic signature that covers the RRSIG RDATA (excluding the Signature field) and the RRset specified by the RRSIG owner name, RRSIG class, and RRSIG Type Covered field. The format of this field depends on the algorithm in use, and these formats are described in separate companion documents. <span class="h5"><a class="selflink" id="section-3.1.8.1" href="#section-3.1.8.1">3.1.8.1</a>. Signature Calculation</span> A signature covers the RRSIG RDATA (excluding the Signature Field) and covers the data RRset specified by the RRSIG owner name, RRSIG class, and RRSIG Type Covered fields. The RRset is in canonical form (see <a href="#section-6">Section 6</a>), and the set RR(1),...RR(n) is signed as follows: <span class="grey">Arends, et al. Standards Track [Page 9]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-10" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where "|" denotes concatenation; RRSIG_RDATA is the wire format of the RRSIG RDATA fields with the Signer's Name field in canonical form and the Signature field excluded; RR(i) = owner | type | class | TTL | RDATA length | RDATA "owner" is the fully qualified owner name of the RRset in canonical form (for RRs with wildcard owner names, the wildcard label is included in the owner name); Each RR MUST have the same owner name as the RRSIG RR; Each RR MUST have the same class as the RRSIG RR; Each RR in the RRset MUST have the RR type listed in the RRSIG RR's Type Covered field; Each RR in the RRset MUST have the TTL listed in the RRSIG Original TTL Field; Any DNS names in the RDATA field of each RR MUST be in canonical form; and The RRset MUST be sorted in canonical order. See Sections <a href="#section-6.2">6.2</a> and <a href="#section-6.3">6.3</a> for details on canonical form and ordering of RRsets. <span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. The RRSIG RR Presentation Format</span> The presentation format of the RDATA portion is as follows: The Type Covered field is represented as an RR type mnemonic. When the mnemonic is not known, the TYPE representation as described in <a href="/doc/html/rfc3597#section-5">[RFC3597], Section 5</a>, MUST be used. The Algorithm field value MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic, as specified in <a href="#appendix-A.1">Appendix</a> <a href="#appendix-A.1">A.1</a>. The Labels field value MUST be represented as an unsigned decimal integer. <span class="grey">Arends, et al. Standards Track [Page 10]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-11" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> The Original TTL field value MUST be represented as an unsigned decimal integer. The Signature Expiration Time and Inception Time field values MUST be represented either as an unsigned decimal integer indicating seconds since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in UTC, where: YYYY is the year (0001-9999, but see <a href="#section-3.1.5">Section 3.1.5</a>); MM is the month number (01-12); DD is the day of the month (01-31); HH is the hour, in 24 hour notation (00-23); mm is the minute (00-59); and SS is the second (00-59). Note that it is always possible to distinguish between these two formats because the YYYYMMDDHHmmSS format will always be exactly 14 digits, while the decimal representation of a 32-bit unsigned integer can never be longer than 10 digits. The Key Tag field MUST be represented as an unsigned decimal integer. The Signer's Name field value MUST be represented as a domain name. The Signature field is represented as a Base64 encoding of the signature. Whitespace is allowed within the Base64 text. See <a href="#section-2.2">Section 2.2</a>. <span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. RRSIG RR Example</span> The following RRSIG RR stores the signature for the A RRset of host.example.com: host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( 20030220173103 2642 example.com. oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) The first four fields specify the owner name, TTL, Class, and RR type (RRSIG). The "A" represents the Type Covered field. The value 5 identifies the algorithm used (RSA/SHA1) to create the signature. The value 3 is the number of Labels in the original owner name. The value 86400 in the RRSIG RDATA is the Original TTL for the covered A RRset. 20030322173103 and 20030220173103 are the expiration and <span class="grey">Arends, et al. Standards Track [Page 11]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-12" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> inception dates, respectively. 2642 is the Key Tag, and example.com. is the Signer's Name. The remaining text is a Base64 encoding of the signature. Note that combination of RRSIG RR owner name, class, and Type Covered indicates that this RRSIG covers the "host.example.com" A RRset. The Label value of 3 indicates that no wildcard expansion was used. The Algorithm, Signer's Name, and Key Tag indicate that this signature can be authenticated using an example.com zone DNSKEY RR whose algorithm is 5 and whose key tag is 2642. <span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. The NSEC Resource Record</span> The NSEC resource record lists two separate things: the next owner name (in the canonical ordering of the zone) that contains authoritative data or a delegation point NS RRset, and the set of RR types present at the NSEC RR's owner name [<a href="/doc/html/rfc3845" title=""DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format"">RFC3845</a>]. The complete set of NSEC RRs in a zone indicates which authoritative RRsets exist in a zone and also form a chain of authoritative owner names in the zone. This information is used to provide authenticated denial of existence for DNS data, as described in [<a href="/doc/html/rfc4035" title=""Protocol Modifications for the DNS Security Extensions"">RFC4035</a>]. Because every authoritative name in a zone must be part of the NSEC chain, NSEC RRs must be present for names containing a CNAME RR. This is a change to the traditional DNS specification [<a href="/doc/html/rfc1034" title=""Domain names - concepts and facilities"">RFC1034</a>], which stated that if a CNAME is present for a name, it is the only type allowed at that name. An RRSIG (see <a href="#section-3">Section 3</a>) and NSEC MUST exist for the same name as does a CNAME resource record in a signed zone. See [<a href="/doc/html/rfc4035" title=""Protocol Modifications for the DNS Security Extensions"">RFC4035</a>] for discussion of how a zone signer determines precisely which NSEC RRs it has to include in a zone. The type value for the NSEC RR is 47. The NSEC RR is class independent. The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching ([<a href="/doc/html/rfc2308" title=""Negative Caching of DNS Queries (DNS NCACHE)"">RFC2308</a>]). <span class="grey">Arends, et al. Standards Track [Page 12]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-13" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> <span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. NSEC RDATA Wire Format</span> The RDATA of the NSEC RR is as shown below: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Next Domain Name / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Type Bit Maps / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. The Next Domain Name Field</span> The Next Domain field contains the next owner name (in the canonical ordering of the zone) that has authoritative data or contains a delegation point NS RRset; see <a href="#section-6.1">Section 6.1</a> for an explanation of canonical ordering. The value of the Next Domain Name field in the last NSEC record in the zone is the name of the zone apex (the owner name of the zone's SOA RR). This indicates that the owner name of the NSEC RR is the last name in the canonical ordering of the zone. A sender MUST NOT use DNS name compression on the Next Domain Name field when transmitting an NSEC RR. Owner names of RRsets for which the given zone is not authoritative (such as glue records) MUST NOT be listed in the Next Domain Name unless at least one authoritative RRset exists at the same owner name. <span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>. The Type Bit Maps Field</span> The Type Bit Maps field identifies the RRset types that exist at the NSEC RR's owner name. The RR type space is split into 256 window blocks, each representing the low-order 8 bits of the 16-bit RR type space. Each block that has at least one active RR type is encoded using a single octet window number (from 0 to 255), a single octet bitmap length (from 1 to 32) indicating the number of octets used for the window block's bitmap, and up to 32 octets (256 bits) of bitmap. Blocks are present in the NSEC RR RDATA in increasing numerical order. Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ where "|" denotes concatenation. <span class="grey">Arends, et al. Standards Track [Page 13]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-14" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> Each bitmap encodes the low-order 8 bits of RR types within the window block, in network bit order. The first bit is bit 0. For window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS), and so forth. For window block 1, bit 1 corresponds to RR type 257, and bit 2 to RR type 258. If a bit is set, it indicates that an RRset of that type is present for the NSEC RR's owner name. If a bit is clear, it indicates that no RRset of that type is present for the NSEC RR's owner name. Bits representing pseudo-types MUST be clear, as they do not appear in zone data. If encountered, they MUST be ignored upon being read. Blocks with no types present MUST NOT be included. Trailing zero octets in the bitmap MUST be omitted. The length of each block's bitmap is determined by the type code with the largest numerical value, within that block, among the set of RR types present at the NSEC RR's owner name. Trailing zero octets not specified MUST be interpreted as zero octets. The bitmap for the NSEC RR at a delegation point requires special attention. Bits corresponding to the delegation NS RRset and the RR types for which the parent zone has authoritative data MUST be set; bits corresponding to any non-NS RRset for which the parent is not authoritative MUST be clear. A zone MUST NOT include an NSEC RR for any domain name that only holds glue records. <span class="h4"><a class="selflink" id="section-4.1.3" href="#section-4.1.3">4.1.3</a>. Inclusion of Wildcard Names in NSEC RDATA</span> If a wildcard owner name appears in a zone, the wildcard label ("*") is treated as a literal symbol and is treated the same as any other owner name for the purposes of generating NSEC RRs. Wildcard owner names appear in the Next Domain Name field without any wildcard expansion. [<a href="/doc/html/rfc4035" title=""Protocol Modifications for the DNS Security Extensions"">RFC4035</a>] describes the impact of wildcards on authenticated denial of existence. <span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. The NSEC RR Presentation Format</span> The presentation format of the RDATA portion is as follows: The Next Domain Name field is represented as a domain name. The Type Bit Maps field is represented as a sequence of RR type mnemonics. When the mnemonic is not known, the TYPE representation described in <a href="/doc/html/rfc3597#section-5">[RFC3597], Section 5</a>, MUST be used. <span class="grey">Arends, et al. Standards Track [Page 14]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-15" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> <span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. NSEC RR Example</span> The following NSEC RR identifies the RRsets associated with alfa.example.com. and identifies the next authoritative name after alfa.example.com. alfa.example.com. 86400 IN NSEC host.example.com. ( A MX RRSIG NSEC TYPE1234 ) The first four text fields specify the name, TTL, Class, and RR type (NSEC). The entry host.example.com. is the next authoritative name after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, and TYPE1234 mnemonics indicate that there are A, MX, RRSIG, NSEC, and TYPE1234 RRsets associated with the name alfa.example.com. The RDATA section of the NSEC RR above would be encoded as: 0x04 'h' 'o' 's' 't' 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' 0x03 'c' 'o' 'm' 0x00 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x20 Assuming that the validator can authenticate this NSEC record, it could be used to prove that beta.example.com does not exist, or to prove that there is no AAAA record associated with alfa.example.com. Authenticated denial of existence is discussed in [<a href="/doc/html/rfc4035" title=""Protocol Modifications for the DNS Security Extensions"">RFC4035</a>]. <span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. The DS Resource Record</span> The DS Resource Record refers to a DNSKEY RR and is used in the DNS DNSKEY authentication process. A DS RR refers to a DNSKEY RR by storing the key tag, algorithm number, and a digest of the DNSKEY RR. Note that while the digest should be sufficient to identify the public key, storing the key tag and key algorithm helps make the identification process more efficient. By authenticating the DS record, a resolver can authenticate the DNSKEY RR to which the DS record points. The key authentication process is described in [<a href="/doc/html/rfc4035" title=""Protocol Modifications for the DNS Security Extensions"">RFC4035</a>]. The DS RR and its corresponding DNSKEY RR have the same owner name, but they are stored in different locations. The DS RR appears only on the upper (parental) side of a delegation, and is authoritative data in the parent zone. For example, the DS RR for "example.com" is stored in the "com" zone (the parent zone) rather than in the <span class="grey">Arends, et al. Standards Track [Page 15]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-16" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> "example.com" zone (the child zone). The corresponding DNSKEY RR is stored in the "example.com" zone (the child zone). This simplifies DNS zone management and zone signing but introduces special response processing requirements for the DS RR; these are described in [<a href="/doc/html/rfc4035" title=""Protocol Modifications for the DNS Security Extensions"">RFC4035</a>]. The type number for the DS record is 43. The DS resource record is class independent. The DS RR has no special TTL requirements. <span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. DS RDATA Wire Format</span> The RDATA for a DS RR consists of a 2 octet Key Tag field, a 1 octet Algorithm field, a 1 octet Digest Type field, and a Digest field. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | Algorithm | Digest Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Digest / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>. The Key Tag Field</span> The Key Tag field lists the key tag of the DNSKEY RR referred to by the DS record, in network byte order. The Key Tag used by the DS RR is identical to the Key Tag used by RRSIG RRs. <a href="#appendix-B">Appendix B</a> describes how to compute a Key Tag. <span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>. The Algorithm Field</span> The Algorithm field lists the algorithm number of the DNSKEY RR referred to by the DS record. The algorithm number used by the DS RR is identical to the algorithm number used by RRSIG and DNSKEY RRs. <a href="#appendix-A.1">Appendix A.1</a> lists the algorithm number types. <span class="grey">Arends, et al. Standards Track [Page 16]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-17" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> <span class="h4"><a class="selflink" id="section-5.1.3" href="#section-5.1.3">5.1.3</a>. The Digest Type Field</span> The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY RR. The Digest Type field identifies the algorithm used to construct the digest. <a href="#appendix-A.2">Appendix A.2</a> lists the possible digest algorithm types. <span class="h4"><a class="selflink" id="section-5.1.4" href="#section-5.1.4">5.1.4</a>. The Digest Field</span> The DS record refers to a DNSKEY RR by including a digest of that DNSKEY RR. The digest is calculated by concatenating the canonical form of the fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, and then applying the digest algorithm. digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); "|" denotes concatenation DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. The size of the digest may vary depending on the digest algorithm and DNSKEY RR size. As of the time of this writing, the only defined digest algorithm is SHA-1, which produces a 20 octet digest. <span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Processing of DS RRs When Validating Responses</span> The DS RR links the authentication chain across zone boundaries, so the DS RR requires extra care in processing. The DNSKEY RR referred to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be used in the validation process. <span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. The DS RR Presentation Format</span> The presentation format of the RDATA portion is as follows: The Key Tag field MUST be represented as an unsigned decimal integer. The Algorithm field MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic specified in <a href="#appendix-A.1">Appendix A.1</a>. The Digest Type field MUST be represented as an unsigned decimal integer. <span class="grey">Arends, et al. Standards Track [Page 17]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-18" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> The Digest MUST be represented as a sequence of case-insensitive hexadecimal digits. Whitespace is allowed within the hexadecimal text. <span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. DS RR Example</span> The following example shows a DNSKEY RR and its corresponding DS RR. dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz fwJr1AYtsmx3TGkJaNXVbfi/ 2pHm822aJ5iI9BMzNXxeYCmZ DRD99WYwYqUSdjMmmAphXdvx egXd/M5+X7OrzKBaMbCVdFLU Uh6DhweJBjEVv5f2wwjM9Xzc nOf+EPbtG9DMBmADjFDc2w/r ljwvFw== ) ; key id = 60485 dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A 98631FAD1A292118 ) The first four text fields specify the name, TTL, Class, and RR type (DS). Value 60485 is the key tag for the corresponding "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm used by this "dskey.example.com." DNSKEY RR. The value 1 is the algorithm used to construct the digest, and the rest of the RDATA text is the digest in hexadecimal. <span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Canonical Form and Order of Resource Records</span> This section defines a canonical form for resource records, a canonical ordering of DNS names, and a canonical ordering of resource records within an RRset. A canonical name order is required to construct the NSEC name chain. A canonical RR form and ordering within an RRset are required in order to construct and verify RRSIG RRs. <span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Canonical DNS Name Order</span> For the purposes of DNS security, owner names are ordered by treating individual labels as unsigned left-justified octet strings. The absence of a octet sorts before a zero value octet, and uppercase US-ASCII letters are treated as if they were lowercase US-ASCII letters. <span class="grey">Arends, et al. Standards Track [Page 18]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-19" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> To compute the canonical ordering of a set of DNS names, start by sorting the names according to their most significant (rightmost) labels. For names in which the most significant label is identical, continue sorting according to their next most significant label, and so forth. For example, the following names are sorted in canonical DNS name order. The most significant label is "example". At this level, "example" sorts first, followed by names ending in "a.example", then by names ending "z.example". The names within each level are sorted in the same way. example a.example yljkjljk.a.example Z.a.example zABC.a.EXAMPLE z.example \001.z.example *.z.example \200.z.example <span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Canonical RR Form</span> For the purposes of DNS security, the canonical form of an RR is the wire format of the RR where: 1. every domain name in the RR is fully expanded (no DNS name compression) and fully qualified; 2. all uppercase US-ASCII letters in the owner name of the RR are replaced by the corresponding lowercase US-ASCII letters; 3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in the DNS names contained within the RDATA are replaced by the corresponding lowercase US-ASCII letters; 4. if the owner name of the RR is a wildcard name, the owner name is in its original unexpanded form, including the "*" label (no wildcard substitution); and 5. the RR's TTL is set to its original value as it appears in the originating authoritative zone or the Original TTL field of the covering RRSIG RR. <span class="grey">Arends, et al. Standards Track [Page 19]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-20" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> <span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Canonical RR Ordering within an RRset</span> For the purposes of DNS security, RRs with the same owner name, class, and type are sorted by treating the RDATA portion of the canonical form of each RR as a left-justified unsigned octet sequence in which the absence of an octet sorts before a zero octet. [<a id="ref-RFC2181">RFC2181</a>] specifies that an RRset is not allowed to contain duplicate records (multiple RRs with the same owner name, class, type, and RDATA). Therefore, if an implementation detects duplicate RRs when putting the RRset in canonical form, it MUST treat this as a protocol error. If the implementation chooses to handle this protocol error in the spirit of the robustness principle (being liberal in what it accepts), it MUST remove all but one of the duplicate RR(s) for the purposes of calculating the canonical form of the RRset. <span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span> This document introduces no new IANA considerations, as all of the protocol parameters used in this document have already been assigned by previous specifications. However, since the evolution of DNSSEC has been long and somewhat convoluted, this section attempts to describe the current state of the IANA registries and other protocol parameters that are (or once were) related to DNSSEC. Please refer to [<a href="/doc/html/rfc4035" title=""Protocol Modifications for the DNS Security Extensions"">RFC4035</a>] for additional IANA considerations. DNS Resource Record Types: [<a href="/doc/html/rfc2535" title=""Domain Name System Security Extensions"">RFC2535</a>] assigned types 24, 25, and 30 to the SIG, KEY, and NXT RRs, respectively. [<a href="/doc/html/rfc3658" title=""Delegation Signer (DS) Resource Record (RR)"">RFC3658</a>] assigned DNS Resource Record Type 43 to DS. [<a href="/doc/html/rfc3755" title=""Legacy Resolver Compatibility for Delegation Signer (DS)"">RFC3755</a>] assigned types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. [<a href="/doc/html/rfc3755" title=""Legacy Resolver Compatibility for Delegation Signer (DS)"">RFC3755</a>] also marked type 30 (NXT) as Obsolete and restricted use of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction security protocol described in [<a href="/doc/html/rfc2931" title=""DNS Request and Transaction Signatures ( SIG(0)s )"">RFC2931</a>] and to the transaction KEY Resource Record described in [<a href="/doc/html/rfc2930" title=""Secret Key Establishment for DNS (TKEY RR)"">RFC2930</a>]. DNS Security Algorithm Numbers: [<a href="/doc/html/rfc2535" title=""Domain Name System Security Extensions"">RFC2535</a>] created an IANA registry for DNSSEC Resource Record Algorithm field numbers and assigned values 1-4 and 252-255. [<a href="/doc/html/rfc3110" title=""RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)"">RFC3110</a>] assigned value 5. [<a href="/doc/html/rfc3755" title=""Legacy Resolver Compatibility for Delegation Signer (DS)"">RFC3755</a>] altered this registry to include flags for each entry regarding its use with the DNS security extensions. Each algorithm entry could refer to an algorithm that can be used for zone signing, transaction security (see [<a href="/doc/html/rfc2931" title=""DNS Request and Transaction Signatures ( SIG(0)s )"">RFC2931</a>]), or both. Values 6-251 are available for assignment by IETF standards action ([<a href="/doc/html/rfc3755" title=""Legacy Resolver Compatibility for Delegation Signer (DS)"">RFC3755</a>]). See <a href="#appendix-A">Appendix A</a> for a full listing of the DNS Security Algorithm Numbers entries at the time of this writing and their status for use in DNSSEC. <span class="grey">Arends, et al. Standards Track [Page 20]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-21" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> [<a id="ref-RFC3658">RFC3658</a>] created an IANA registry for DNSSEC DS Digest Types and assigned value 0 to reserved and value 1 to SHA-1. KEY Protocol Values: [<a href="/doc/html/rfc2535" title=""Domain Name System Security Extensions"">RFC2535</a>] created an IANA Registry for KEY Protocol Values, but [<a href="/doc/html/rfc3445" title=""Limiting the Scope of the KEY Resource Record (RR)"">RFC3445</a>] reassigned all values other than 3 to reserved and closed this IANA registry. The registry remains closed, and all KEY and DNSKEY records are required to have a Protocol Octet value of 3. Flag bits in the KEY and DNSKEY RRs: [<a href="/doc/html/rfc3755" title=""Legacy Resolver Compatibility for Delegation Signer (DS)"">RFC3755</a>] created an IANA registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, this registry only contains assignments for bit 7 (the ZONE bit) and bit 15 (the Secure Entry Point flag (SEP) bit; see [<a href="/doc/html/rfc3757" title=""Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag"">RFC3757</a>]). As stated in [<a href="/doc/html/rfc3755" title=""Legacy Resolver Compatibility for Delegation Signer (DS)"">RFC3755</a>], bits 0-6 and 8-14 are available for assignment by IETF Standards Action. <span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span> This document describes the format of four DNS resource records used by the DNS security extensions and presents an algorithm for calculating a key tag for a public key. Other than the items described below, the resource records themselves introduce no security considerations. Please see [<a href="/doc/html/rfc4033" title=""DNS Security Introduction and Requirements"">RFC4033</a>] and [<a href="/doc/html/rfc4035" title=""Protocol Modifications for the DNS Security Extensions"">RFC4035</a>] for additional security considerations related to the use of these records. The DS record points to a DNSKEY RR by using a cryptographic digest, the key algorithm type, and a key tag. The DS record is intended to identify an existing DNSKEY RR, but it is theoretically possible for an attacker to generate a DNSKEY that matches all the DS fields. The probability of constructing a matching DNSKEY depends on the type of digest algorithm in use. The only currently defined digest algorithm is SHA-1, and the working group believes that constructing a public key that would match the algorithm, key tag, and SHA-1 digest given in a DS record would be a sufficiently difficult problem that such an attack is not a serious threat at this time. The key tag is used to help select DNSKEY resource records efficiently, but it does not uniquely identify a single DNSKEY resource record. It is possible for two distinct DNSKEY RRs to have the same owner name, the same algorithm type, and the same key tag. An implementation that uses only the key tag to select a DNSKEY RR might select the wrong public key in some circumstances. Please see <a href="#appendix-B">Appendix B</a> for further details. <span class="grey">Arends, et al. Standards Track [Page 21]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-22" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> The table of algorithms in <a href="#appendix-A">Appendix A</a> and the key tag calculation algorithms in <a href="#appendix-B">Appendix B</a> include the RSA/MD5 algorithm for completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as explained in [<a href="/doc/html/rfc3110" title=""RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)"">RFC3110</a>]. <span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgements</span> This document was created from the input and ideas of the members of the DNS Extensions Working Group and working group mailing list. The editors would like to express their thanks for the comments and suggestions received during the revision of these security extension specifications. Although explicitly listing everyone who has contributed during the decade in which DNSSEC has been under development would be impossible, [<a href="/doc/html/rfc4033" title=""DNS Security Introduction and Requirements"">RFC4033</a>] includes a list of some of the participants who were kind enough to comment on these documents. <span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span> <span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span> [<a id="ref-RFC1034">RFC1034</a>] Mockapetris, P., "Domain names - concepts and facilities", STD 13, <a href="/doc/html/rfc1034">RFC 1034</a>, November 1987. [<a id="ref-RFC1035">RFC1035</a>] Mockapetris, P., "Domain names - implementation and specification", STD 13, <a href="/doc/html/rfc1035">RFC 1035</a>, November 1987. [<a id="ref-RFC1982">RFC1982</a>] Elz, R. and R. Bush, "Serial Number Arithmetic", <a href="/doc/html/rfc1982">RFC 1982</a>, August 1996. [<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", <a href="/doc/html/bcp14">BCP 14</a>, <a href="/doc/html/rfc2119">RFC 2119</a>, March 1997. [<a id="ref-RFC2181">RFC2181</a>] Elz, R. and R. Bush, "Clarifications to the DNS Specification", <a href="/doc/html/rfc2181">RFC 2181</a>, July 1997. [<a id="ref-RFC2308">RFC2308</a>] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", <a href="/doc/html/rfc2308">RFC 2308</a>, March 1998. [<a id="ref-RFC2536">RFC2536</a>] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", <a href="/doc/html/rfc2536">RFC 2536</a>, March 1999. [<a id="ref-RFC2931">RFC2931</a>] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", <a href="/doc/html/rfc2931">RFC 2931</a>, September 2000. [<a id="ref-RFC3110">RFC3110</a>] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", <a href="/doc/html/rfc3110">RFC 3110</a>, May 2001. <span class="grey">Arends, et al. Standards Track [Page 22]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-23" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> [<a id="ref-RFC3445">RFC3445</a>] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", <a href="/doc/html/rfc3445">RFC 3445</a>, December 2002. [<a id="ref-RFC3548">RFC3548</a>] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", <a href="/doc/html/rfc3548">RFC 3548</a>, July 2003. [<a id="ref-RFC3597">RFC3597</a>] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", <a href="/doc/html/rfc3597">RFC 3597</a>, September 2003. [<a id="ref-RFC3658">RFC3658</a>] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", <a href="/doc/html/rfc3658">RFC 3658</a>, December 2003. [<a id="ref-RFC3755">RFC3755</a>] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", <a href="/doc/html/rfc3755">RFC 3755</a>, May 2004. [<a id="ref-RFC3757">RFC3757</a>] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", <a href="/doc/html/rfc3757">RFC 3757</a>, April 2004. [<a id="ref-RFC4033">RFC4033</a>] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", <a href="/doc/html/rfc4033">RFC</a> <a href="/doc/html/rfc4033">4033</a>, March 2005. [<a id="ref-RFC4035">RFC4035</a>] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", <a href="/doc/html/rfc4035">RFC 4035</a>, March 2005. <span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span> [<a id="ref-RFC2535">RFC2535</a>] Eastlake 3rd, D., "Domain Name System Security Extensions", <a href="/doc/html/rfc2535">RFC 2535</a>, March 1999. [<a id="ref-RFC2537">RFC2537</a>] Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)", <a href="/doc/html/rfc2537">RFC 2537</a>, March 1999. [<a id="ref-RFC2539">RFC2539</a>] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", <a href="/doc/html/rfc2539">RFC 2539</a>, March 1999. [<a id="ref-RFC2930">RFC2930</a>] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", <a href="/doc/html/rfc2930">RFC 2930</a>, September 2000. [<a id="ref-RFC3845">RFC3845</a>] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format", <a href="/doc/html/rfc3845">RFC 3845</a>, August 2004. <span class="grey">Arends, et al. Standards Track [Page 23]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-24" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> <span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. DNSSEC Algorithm and Digest Types</span> The DNS security extensions are designed to be independent of the underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS resource records all use a DNSSEC Algorithm Number to identify the cryptographic algorithm in use by the resource record. The DS resource record also specifies a Digest Algorithm Number to identify the digest algorithm used to construct the DS record. The currently defined Algorithm and Digest Types are listed below. Additional Algorithm or Digest Types could be added as advances in cryptography warrant them. A DNSSEC aware resolver or name server MUST implement all MANDATORY algorithms. <span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. DNSSEC Algorithm Types</span> The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the security algorithm being used. These values are stored in the "Algorithm number" field in the resource record RDATA. Some algorithms are usable only for zone signing (DNSSEC), some only for transaction security mechanisms (SIG(0) and TSIG), and some for both. Those usable for zone signing may appear in DNSKEY, RRSIG, and DS RRs. Those usable for transaction security would be present in SIG(0) and KEY RRs, as described in [<a href="/doc/html/rfc2931" title=""DNS Request and Transaction Signatures ( SIG(0)s )"">RFC2931</a>]. Zone Value Algorithm [Mnemonic] Signing References Status ----- -------------------- --------- ---------- --------- 0 reserved 1 RSA/MD5 [RSAMD5] n [<a href="/doc/html/rfc2537" title=""RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)"">RFC2537</a>] NOT RECOMMENDED 2 Diffie-Hellman [DH] n [<a href="/doc/html/rfc2539" title=""Storage of Diffie-Hellman Keys in the Domain Name System (DNS)"">RFC2539</a>] - 3 DSA/SHA-1 [DSA] y [<a href="/doc/html/rfc2536" title=""DSA KEYs and SIGs in the Domain Name System (DNS)"">RFC2536</a>] OPTIONAL 4 Elliptic Curve [ECC] TBA - 5 RSA/SHA-1 [RSASHA1] y [<a href="/doc/html/rfc3110" title=""RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)"">RFC3110</a>] MANDATORY 252 Indirect [INDIRECT] n - 253 Private [PRIVATEDNS] y see below OPTIONAL 254 Private [PRIVATEOID] y see below OPTIONAL 255 reserved 6 - 251 Available for assignment by IETF Standards Action. <span class="grey">Arends, et al. Standards Track [Page 24]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-25" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> <span class="h4"><a class="selflink" id="appendix-A.1.1" href="#appendix-A.1.1">A.1.1</a>. Private Algorithm Types</span> Algorithm number 253 is reserved for private use and will never be assigned to a specific algorithm. The public key area in the DNSKEY RR and the signature area in the RRSIG RR begin with a wire encoded domain name, which MUST NOT be compressed. The domain name indicates the private algorithm to use, and the remainder of the public key area is determined by that algorithm. Entities should only use domain names they control to designate their private algorithms. Algorithm number 254 is reserved for private use and will never be assigned to a specific algorithm. The public key area in the DNSKEY RR and the signature area in the RRSIG RR begin with an unsigned length byte followed by a BER encoded Object Identifier (ISO OID) of that length. The OID indicates the private algorithm in use, and the remainder of the area is whatever is required by that algorithm. Entities should only use OIDs they control to designate their private algorithms. <span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>. DNSSEC Digest Types</span> A "Digest Type" field in the DS resource record types identifies the cryptographic digest algorithm used by the resource record. The following table lists the currently defined digest algorithm types. VALUE Algorithm STATUS 0 Reserved - 1 SHA-1 MANDATORY 2-255 Unassigned - <span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>. Key Tag Calculation</span> The Key Tag field in the RRSIG and DS resource record types provides a mechanism for selecting a public key efficiently. In most cases, a combination of owner name, algorithm, and key tag can efficiently identify a DNSKEY record. Both the RRSIG and DS resource records have corresponding DNSKEY records. The Key Tag field in the RRSIG and DS records can be used to help select the corresponding DNSKEY RR efficiently when more than one candidate DNSKEY RR is available. However, it is essential to note that the key tag is not a unique identifier. It is theoretically possible for two distinct DNSKEY RRs to have the same owner name, the same algorithm, and the same key tag. The key tag is used to limit the possible candidate keys, but it does not uniquely identify a DNSKEY record. Implementations MUST NOT assume that the key tag uniquely identifies a DNSKEY RR. <span class="grey">Arends, et al. Standards Track [Page 25]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-26" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> The key tag is the same for all DNSKEY algorithm types except algorithm 1 (please see <a href="#appendix-B.1">Appendix B.1</a> for the definition of the key tag for algorithm 1). The key tag algorithm is the sum of the wire format of the DNSKEY RDATA broken into 2 octet groups. First, the RDATA (in wire format) is treated as a series of 2 octet groups. These groups are then added together, ignoring any carry bits. A reference implementation of the key tag algorithm is as an ANSI C function is given below, with the RDATA portion of the DNSKEY RR is used as input. It is not necessary to use the following reference code verbatim, but the numerical value of the Key Tag MUST be identical to what the reference implementation would generate for the same input. Please note that the algorithm for calculating the Key Tag is almost but not completely identical to the familiar ones-complement checksum used in many other Internet protocols. Key Tags MUST be calculated using the algorithm described here rather than the ones complement checksum. The following ANSI C reference implementation calculates the value of a Key Tag. This reference implementation applies to all algorithm types except algorithm 1 (see <a href="#appendix-B.1">Appendix B.1</a>). The input is the wire format of the RDATA portion of the DNSKEY RR. The code is written for clarity, not efficiency. /* * Assumes that int is at least 16 bits. * First octet of the key tag is the most significant 8 bits of the * return value; * Second octet of the key tag is the least significant 8 bits of the * return value. */ unsigned int keytag ( unsigned char key[], /* the RDATA part of the DNSKEY RR */ unsigned int keysize /* the RDLENGTH */ ) { unsigned long ac; /* assumed to be 32 bits or larger */ int i; /* loop index */ for ( ac = 0, i = 0; i < keysize; ++i ) ac += (i & 1) ? key[i] : key[i] << 8; ac += (ac >> 16) & 0xFFFF; return ac & 0xFFFF; } <span class="grey">Arends, et al. Standards Track [Page 26]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-27" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> <span class="h3"><a class="selflink" id="appendix-B.1" href="#appendix-B.1">B.1</a>. Key Tag for Algorithm 1 (RSA/MD5)</span> The key tag for algorithm 1 (RSA/MD5) is defined differently from the key tag for all other algorithms, for historical reasons. For a DNSKEY RR with algorithm 1, the key tag is defined to be the most significant 16 bits of the least significant 24 bits in the public key modulus (in other words, the 4th to last and 3rd to last octets of the public key modulus). Please note that Algorithm 1 is NOT RECOMMENDED. <span class="grey">Arends, et al. Standards Track [Page 27]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-28" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> Authors' Addresses Roy Arends Telematica Instituut Brouwerijstraat 1 7523 XC Enschede NL EMail: roy.arends@telin.nl Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA EMail: sra@isc.org Matt Larson VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA EMail: mlarson@verisign.com Dan Massey Colorado State University Department of Computer Science Fort Collins, CO 80523-1873 EMail: massey@cs.colostate.edu Scott Rose National Institute for Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899-8920 USA EMail: scott.rose@nist.gov <span class="grey">Arends, et al. Standards Track [Page 28]</span></pre> <hr class='noprint'/><pre class='newpage'><span id="page-29" ></span> <span class="grey"><a href="/doc/html/rfc4034">RFC 4034</a> DNSSEC Resource Records March 2005</span> Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in <a href="/doc/html/bcp78">BCP 78</a>, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in <a href="/doc/html/bcp78">BCP 78</a> and <a href="/doc/html/bcp79">BCP 79</a>. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Arends, et al. Standards Track [Page 29] </pre></div> </div> </div> <div class="d-print-none col-md-3 bg-light-subtle collapse show" id="sidebar"> <div class="position-fixed border-start sidebar overflow-scroll overscroll-none no-scrollbar"> <div class="d-flex flex-column vh-100 pt-2 pt-lg-3 ps-3 pl-md-2 pl-lg-3"> <div> <a class="btn btn-primary btn-sm" href="/doc/rfc4034/">Datatracker</a> <p class="fw-bold pt-2"> RFC 4034 <br> <span class="text-success">RFC - Proposed Standard </span> </p> </div> <ul class="nav nav-tabs nav-fill small me-2" role="tablist"> <li class="nav-item" role="presentation" title="Document information"> <button class="nav-link px-2" id="docinfo-tab" data-bs-toggle="tab" data-bs-target="#docinfo-tab-pane" type="button" role="tab" aria-controls="docinfo-tab-pane" aria-selected="true"> <i class="bi bi-info-circle"></i><span class="d-none d-md-block d-xl-inline ms-xl-1">Info</span> </button> </li> <li class="nav-item" role="presentation" title="Table of contents"> <button class="nav-link px-2" id="toc-tab" data-bs-toggle="tab" data-bs-target="#toc-tab-pane" type="button" role="tab" aria-controls="toc-tab-pane" aria-selected="false"> <i class="bi bi-list-ol"></i><span class="d-none d-md-block d-xl-inline ms-xl-1">Contents</span> </button> </li> <li class="nav-item" role="presentation" title="Preferences"> <button class="nav-link px-2" id="pref-tab" data-bs-toggle="tab" data-bs-target="#pref-tab-pane" type="button" role="tab" aria-controls="pref-tab-pane" aria-selected="false"> <i class="bi bi-gear"></i><span class="d-none d-md-block d-xl-inline ms-xl-1">Prefs</span> </button> </li> </ul> <div class="overflow-auto tab-content pt-2 me-2"> <div class="tab-pane" id="docinfo-tab-pane" role="tabpanel" aria-labelledby="docinfo-tab" tabindex="0"> <table class="table table-sm table-borderless"> <tbody class="meta align-top "> <tr> <th scope="row">Document</th> <th scope="row">Document type</th> <td class="edit"></td> <td> <span class="text-success">RFC - Proposed Standard </span> <br>March 2005 <br> <a class="btn btn-primary btn-sm my-1" href="https://www.rfc-editor.org/errata_search.php?rfc=4034" title="Click to view errata." rel="nofollow"> View errata </a> <a class="btn btn-sm btn-warning" title="Click to report an error in the document." href="https://www.rfc-editor.org/errata.php#reportnew" target="_blank"> Report errata </a> <a title="Click to view IPR declarations." class="btn btn-warning btn-sm my-1" href="/ipr/search/?submit=draft&id=rfc4034">IPR</a> <div>Updated by <a href="/doc/html/rfc9077" title="NSEC and NSEC3: TTLs and Aggressive Use">RFC 9077</a>, <a href="/doc/html/rfc4470" title="Minimally Covering NSEC Records and DNSSEC On-line Signing">RFC 4470</a>, <a href="/doc/html/rfc6014" title="Cryptographic Algorithm Identifier Allocation for DNSSEC">RFC 6014</a>, <a href="/doc/html/rfc6840" title="Clarifications and Implementation Notes for DNS Security (DNSSEC)">RFC 6840</a>, <a href="/doc/html/rfc6944" title="Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status">RFC 6944</a></div> <div>Obsoletes <a href="/doc/html/rfc3090" title="DNS Security Extension Clarification on Zone Status">RFC 3090</a>, <a href="/doc/html/rfc3008" title="Domain Name System Security (DNSSEC) Signing Authority">RFC 3008</a>, <a href="/doc/html/rfc3445" title="Limiting the Scope of the KEY Resource Record (RR)">RFC 3445</a>, <a href="/doc/html/rfc2535" title="Domain Name System Security Extensions">RFC 2535</a>, <a href="/doc/html/rfc3655" title="Redefinition of DNS Authenticated Data (AD) bit">RFC 3655</a>, <a href="/doc/html/rfc3658" title="Delegation Signer (DS) Resource Record (RR)">RFC 3658</a>, <a href="/doc/html/rfc3755" title="Legacy Resolver Compatibility for Delegation Signer (DS)">RFC 3755</a>, <a href="/doc/html/rfc3845" title="DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format">RFC 3845</a>, <a href="/doc/html/rfc3757" title="Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag">RFC 3757</a></div> <div>Updates <a href="/doc/html/rfc3226" title="DNSSEC and IPv6 A6 aware server/resolver message size requirements">RFC 3226</a>, <a href="/doc/html/rfc3225" title="Indicating Resolver Support of DNSSEC">RFC 3225</a>, <a href="/doc/html/rfc2136" title="Dynamic Updates in the Domain Name System (DNS UPDATE)">RFC 2136</a>, <a href="/doc/html/rfc1035" title="Domain names - implementation and specification">RFC 1035</a>, <a href="/doc/html/rfc3597" title="Handling of Unknown DNS Resource Record (RR) Types">RFC 3597</a>, <a href="/doc/html/rfc2308" title="Negative Caching of DNS Queries (DNS NCACHE)">RFC 2308</a>, <a href="/doc/html/rfc1034" title="Domain names - concepts and facilities">RFC 1034</a>, <a href="/doc/html/rfc2181" title="Clarifications to the DNS Specification">RFC 2181</a>, <a href="/doc/html/rfc3007" title="Secure Domain Name System (DNS) Dynamic Update">RFC 3007</a></div> <div> Was <a href="/doc/draft-ietf-dnsext-dnssec-records/11/">draft-ietf-dnsext-dnssec-records</a> (<a href="/wg/dnsext/about/">dnsext WG</a>) </div> </td> </tr> <tr> <td></td> <th scope="row">Select version</th> <td class="edit"></td> <td> <ul class="revision-list pagination pagination-sm text-center flex-wrap my-0"> <li class="page-item"> <a class="page-link" href="/doc/html/draft-ietf-dnsext-dnssec-records-11" rel="nofollow"> 11 </a> </li> <li class="page-item rfc active"> <a class="page-link" href="/doc/html/rfc4034"> RFC 4034 </a> </li> </ul> </td> </tr> <tr> <td></td> <th scope="row">Compare versions</th> <td class="edit"></td> <td> <form class="form-horizontal diff-form" action="https://author-tools.ietf.org/iddiff" method="get" target="_blank"> <select class="form-select form-select-sm mb-1 select2-field" data-max-entries="1" data-width="resolve" data-allow-clear="false" data-minimum-input-length="0" aria-label="From revision" name="url1"> <option value="rfc4034"> RFC 4034 </option> <option value="draft-ietf-dnsext-dnssec-records-11" selected> draft-ietf-dnsext-dnssec-records-11 </option> <option value="draft-ietf-dnsext-dnssec-records-10"> draft-ietf-dnsext-dnssec-records-10 </option> <option value="draft-ietf-dnsext-dnssec-records-09"> draft-ietf-dnsext-dnssec-records-09 </option> <option value="draft-ietf-dnsext-dnssec-records-08"> draft-ietf-dnsext-dnssec-records-08 </option> <option value="draft-ietf-dnsext-dnssec-records-07"> draft-ietf-dnsext-dnssec-records-07 </option> <option value="draft-ietf-dnsext-dnssec-records-06"> draft-ietf-dnsext-dnssec-records-06 </option> <option value="draft-ietf-dnsext-dnssec-records-05"> draft-ietf-dnsext-dnssec-records-05 </option> <option value="draft-ietf-dnsext-dnssec-records-04"> draft-ietf-dnsext-dnssec-records-04 </option> <option value="draft-ietf-dnsext-dnssec-records-03"> draft-ietf-dnsext-dnssec-records-03 </option> <option value="draft-ietf-dnsext-dnssec-records-02"> draft-ietf-dnsext-dnssec-records-02 </option> <option value="draft-ietf-dnsext-dnssec-records-01"> draft-ietf-dnsext-dnssec-records-01 </option> <option value="draft-ietf-dnsext-dnssec-records-00"> draft-ietf-dnsext-dnssec-records-00 </option> </select> <select class="form-select form-select-sm mb-1 select2-field" data-max-entries="1" data-width="resolve" data-allow-clear="false" data-minimum-input-length="0" aria-label="To revision" name="url2"> <option value="rfc4034" selected> RFC 4034 </option> <option value="draft-ietf-dnsext-dnssec-records-11"> draft-ietf-dnsext-dnssec-records-11 </option> <option value="draft-ietf-dnsext-dnssec-records-10"> draft-ietf-dnsext-dnssec-records-10 </option> <option value="draft-ietf-dnsext-dnssec-records-09"> draft-ietf-dnsext-dnssec-records-09 </option> <option value="draft-ietf-dnsext-dnssec-records-08"> draft-ietf-dnsext-dnssec-records-08 </option> <option value="draft-ietf-dnsext-dnssec-records-07"> draft-ietf-dnsext-dnssec-records-07 </option> <option value="draft-ietf-dnsext-dnssec-records-06"> draft-ietf-dnsext-dnssec-records-06 </option> <option value="draft-ietf-dnsext-dnssec-records-05"> draft-ietf-dnsext-dnssec-records-05 </option> <option value="draft-ietf-dnsext-dnssec-records-04"> draft-ietf-dnsext-dnssec-records-04 </option> <option value="draft-ietf-dnsext-dnssec-records-03"> draft-ietf-dnsext-dnssec-records-03 </option> <option value="draft-ietf-dnsext-dnssec-records-02"> draft-ietf-dnsext-dnssec-records-02 </option> <option value="draft-ietf-dnsext-dnssec-records-01"> draft-ietf-dnsext-dnssec-records-01 </option> <option value="draft-ietf-dnsext-dnssec-records-00"> draft-ietf-dnsext-dnssec-records-00 </option> </select> <button type="submit" class="btn btn-primary btn-sm" value="--html" name="difftype"> Side-by-side </button> <button type="submit" class="btn btn-primary btn-sm" value="--hwdiff" name="difftype"> Inline </button> </form> </td> </tr> <tr> <td></td> <th scope="row">Authors</th> <td class="edit"> </td> <td> <span ><a title="Datatracker profile of Scott Rose" href="/person/scott.rose@nist.gov" >Scott Rose</a> <a href="mailto:scott.rose%40nist.gov" aria-label="Compose email to scott.rose@nist.gov" title="Compose email to scott.rose@nist.gov"> <i class="bi bi-envelope"></i></a></span>, <span ><a title="Datatracker profile of Matt Larson" href="/person/matt.larson@icann.org" >Matt Larson</a> <a href="mailto:matt.larson%40icann.org" aria-label="Compose email to matt.larson@icann.org" title="Compose email to matt.larson@icann.org"> <i class="bi bi-envelope"></i></a></span>, <span ><a title="Datatracker profile of Dan Massey" href="/person/masseyd@isi.edu" >Dan Massey</a> <a href="mailto:masseyd%40isi.edu" aria-label="Compose email to masseyd@isi.edu" title="Compose email to masseyd@isi.edu"> <i class="bi bi-envelope"></i></a></span>, <span ><a title="Datatracker profile of Rob Austein" href="/person/sra@hactrn.net" >Rob Austein</a> <a href="mailto:sra%40hactrn.net" aria-label="Compose email to sra@hactrn.net" title="Compose email to sra@hactrn.net"> <i class="bi bi-envelope"></i></a></span>, <span ><a title="Datatracker profile of Roy Arends" href="/person/roy.arends@icann.org" >Roy Arends</a> <a href="mailto:roy.arends%40icann.org" aria-label="Compose email to roy.arends@icann.org" title="Compose email to roy.arends@icann.org"> <i class="bi bi-envelope"></i></a></span> <br> <a class="btn btn-primary btn-sm mt-1" href="mailto:rfc4034@ietf.org?subject=rfc4034" title="Send email to the document authors">Email authors</a> </td> </tr> <tr> <td></td> <th scope="row"> RFC stream </th> <td class="edit"> </td> <td > <img alt="IETF Logo" class="d-lm-none w-25 mt-1" src="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor-white.svg" > <img alt="IETF Logo" class="d-dm-none w-25 mt-1" src="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor.svg" > </td> </tr> <tr> <td></td> <th scope="row"> Other formats </th> <td class="edit"> </td> <td> <div class="buttonlist"> <a class="btn btn-primary btn-sm" target="_blank" href="https://www.rfc-editor.org/rfc/rfc4034.txt"> <i class="bi bi-file-text"></i> txt </a> <a class="btn btn-primary btn-sm" target="_blank" href="https://www.rfc-editor.org/rfc/rfc4034.html"> <i class="bi bi-file-code"></i> html </a> <a class="btn btn-primary btn-sm" download="rfc4034.pdf" target="_blank" href="https://www.rfc-editor.org/rfc/pdfrfc/rfc4034.txt.pdf"> <i class="bi bi-file-pdf"></i> pdf </a> <a class="btn btn-primary btn-sm" target="_blank" href="https://www.rfc-editor.org/rfc/inline-errata/rfc4034.html"> <i class="bi bi-file-diff"></i> w/errata </a> <a class="btn btn-primary btn-sm" target="_blank" href="/doc/rfc4034/bibtex/"> <i class="bi bi-file-ruled"></i> bibtex </a> </div> </td> </tr> <tr> <td> </td> <th scope="row"> Additional resources </th> <td class="edit"> </td> <td> <a href="https://mailarchive.ietf.org/arch/browse/dnsext?q=rfc4034 OR %22draft-ietf-dnsext-dnssec-records%22"> Mailing list discussion </a> </td> </tr> </tbody> </table> <a class="btn btn-sm btn-warning mb-3" target="_blank" href="https://github.com/ietf-tools/datatracker/issues/new/choose"> Report a datatracker bug <i class="bi bi-bug"></i> </a> </div> <div class="tab-pane mb-5" id="toc-tab-pane" role="tabpanel" aria-labelledby="toc-tab" tabindex="0"> <nav class="nav nav-pills flex-column small" id="toc-nav"> </nav> </div> <div class="tab-pane mb-5 small" id="pref-tab-pane" role="tabpanel" aria-labelledby="pref-tab" tabindex="0"> <label class="form-label fw-bold mb-2">Show sidebar by default</label> <div class="btn-group-vertical btn-group-sm d-flex" role="group"> <input type="radio" class="btn-check" name="sidebar" id="on-radio"> <label class="btn btn-outline-primary" for="on-radio">Yes</label> <input type="radio" class="btn-check" name="sidebar" id="off-radio"> <label class="btn btn-outline-primary" for="off-radio">No</label> </div> <label class="form-label fw-bold mt-4 mb-2">Tab to show by default</label> <div class="btn-group-vertical btn-group-sm d-flex" role="group"> <input type="radio" class="btn-check" name="deftab" id="docinfo-radio"> <label class="btn btn-outline-primary" for="docinfo-radio"> <i class="bi bi-info-circle me-1"></i>Info </label> <input type="radio" class="btn-check" name="deftab" id="toc-radio"> <label class="btn btn-outline-primary" for="toc-radio"> <i class="bi bi-list-ol me-1"></i>Contents </label> </div> <label class="form-label fw-bold mt-4 mb-2">HTMLization configuration</label> <div class="btn-group-vertical btn-group-sm d-flex" role="group"> <input type="radio" class="btn-check" name="htmlconf" id="txt-radio"> <label class="btn btn-outline-primary" for="txt-radio" title="This is the traditional HTMLization method."> <i class="bi bi-badge-sd me-1"></i>HTMLize the plaintext </label> <input type="radio" class="btn-check" name="htmlconf" id="html-radio"> <label class="btn btn-outline-primary" for="html-radio" title="This is the modern HTMLization method."> <i class="bi bi-badge-hd me-1"></i>Plaintextify the HTML </label> </div> <label class="form-label fw-bold mt-4 mb-2" for="ptsize">Maximum font size</label> <input type="range" class="form-range" min="7" max="16" id="ptsize" oninput="ptdemo.value = ptsize.value"> <label class="form-label fw-bold mt-4 mb-2">Page dependencies</label> <div class="btn-group-vertical btn-group-sm d-flex" role="group"> <input type="radio" class="btn-check" name="pagedeps" id="inline-radio"> <label class="btn btn-outline-primary" for="inline-radio" title="Generate larger, standalone web pages that do not require network access to render."> <i class="bi bi-box me-1"></i>Inline </label> <input type="radio" class="btn-check" name="pagedeps" id="reference-radio"> <label class="btn btn-outline-primary" for="reference-radio" title="Generate regular web pages that require network access to render."> <i class="bi bi-link-45deg me-1"></i>Reference </label> </div> <label class="form-label fw-bold mt-4 mb-2">Citation links</label> <div class="btn-group-vertical btn-group-sm d-flex" role="group"> <input type="radio" class="btn-check" name="reflinks" id="refsection-radio"> <label class="btn btn-outline-primary" for="refsection-radio" title="Citation links go to the reference section."> <i class="bi bi-arrow-clockwise"></i> Go to reference section </label> <input type="radio" class="btn-check" name="reflinks" id="citation-radio"> <label class="btn btn-outline-primary" for="citation-radio" title="Citation links go directly to the cited document."> <i class="bi bi-link-45deg me-1"></i>Go to linked document </label> </div> </div> </div> </div> </div> </div> </div> <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:'8e7af1c2bf013def',t:'MTczMjQ2NzUxMy4wMDAwMDA='};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>

CINXE.COM

RFC 4034 - Resource Records for the DNS Security Extensions