<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.36 -->

<!DOCTYPE rfc SYSTEM "../Tools/rfc2629xslt/rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<rfc ipr="trust200902" docName="draft-wicinski-dns-roadmap-00" category="info">

  <front>
    <title abbrev="DNS Roadmap">A Document Roadmap for the Doman Name System (DNS) Specifications</title>

    <author initials="T." surname="Wicinski" fullname="Tim Wicinski">
      <organization>Salesforce</organization>
      <address>
        <email>tjw.ietf@gmail.com</email>
      </address>
    </author>

    <date year="2016"/>

    <area>General</area>
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document contains a roadmap to the Requests for Comments (RFC) documents relating to the Domain Name System (DNS).  This roadmap provides a brief summary of the documents defining DNS and the various extensions. This serves as a guide and quick reference for DNS Implementers, as well as others.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The Domain Name System (DNS) is a critical piece of communication for Internet hosts.  As DNS has evolved over the years, many distinct documents have become part of the standard, updating older documents either partially or completely.</t>

<t>This document is intended as an introduction to DNS, and also an attempt to organize the work from over the years.  It provides a brief summary of the RFC documents that define DNS. This should be useful to implementers and others on the relevance and significance of the work that relate to DNS.</t>

<t>This roadmap includes a brief description of the contents of each DNS-related RFC.  In addition, a letter code after each RFC indicates its category in the RFC document process. The explanations of these codes are described in 
<xref target="RFC2026"/>.</t>

<t>S - Standards Truck (either Proposed Standard, Draft Standard or Internet Standard)</t>

<t>E - Experimental</t>

<t>I - Informational</t>

<t>H - Historic</t>

<t>B - Best Current Practice</t>

<t>U - Unknown (or not formally defined)</t>

<t>The DNS consists of multiple portions which could be implemented. These parts are (but are not restricted to): an Authorative Server (which includes managing the storage of zone data) and a Caching Server.</t>

<t>The roadmap is broken up into several sections. 
Section 2 decribes the core functionality. 
Section 3 lists the RFCs which are required to implement a DNS Server
Section 3.1 lists the DNS Resource Record (RR) Types nees
Section 4 discusses managing DNS zone data and updating DNS Zones
Section 5 covers DNS Security (DNSSEC), how to implmenet it.</t>

<t>Experimental extensions which are not yet standard track, as well as documents which help to document behavior of the DNS but are not required are in Section 6. Current Best Practices are described in Section 7.</t>

<t>For the definition  of DNS terms or phrases, please refer to the DNS Terminology document <xref target="RFC7719"/></t>

<section anchor="notational-conventions" title="Notational Conventions">

<t>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 <xref target="RFC2119"/>.</t>

</section>
<section anchor="dns-terminology" title="DNS Terminology">

<t><xref target="RFC7719"/> I: “DNS Terminology”</t>

<t>Since the DNS has been defined in dozens of different RFC over several 
decades, the terminology used by developers, implementors and operators 
of the DNS protocol sometimes changed over time. This document captured 
how terms were defined in the original standards, and if they have 
different meanings today.</t>

</section>
</section>
<section anchor="core-functionality-and-specifications" title="Core Functionality and Specifications">

<t><xref target="RFC1034"/> U: “Domain Names - Concepts and Facilities”</t>

<t><xref target="RFC1035"/> S: “Domain Names - Implementation and Specification”</t>

<t><xref target="RFC2181"/> S: “Clarifications to the DNS Specification”</t>

</section>
<section anchor="implementation" title="Implementation">

<t><xref target="RFC2308"/> S: “Negative Caching of DNS Queries (DNS NCACHE)”</t>

<t><xref target="RFC5001"/> S: “DNS Name Server Identifier (NSID) Option”</t>

<t><xref target="RFC4343"/> S: “Domain Name System (DNS) Case Insensitivity Clarification”</t>

<t><xref target="RFC6604"/> S: “xNAME RCODE and Status Bits Clarification”</t>

<t><xref target="RFC3597"/> S: “Handling of Unknown DNS Resource Record (RR) Types”</t>

<t><xref target="RFC4592"/> S: “The Role of Wildcards in the Domain Name System”</t>

<t><xref target="RFC1536"/> I: “Common DNS Implementation Errors and Suggested Fixes”</t>

<t><xref target="RFC7766"/> S: “DNS Transport over TCP - Implementation Requirements”</t>

<section anchor="dns-resource-record-rr-types" title="DNS Resource Record (RR) Types">

</section>
</section>
<section anchor="dns-zones" title="DNS Zones">

<section anchor="managing-dns-zone-data" title="Managing DNS Zone Data">

</section>
<section anchor="updating-dns-zones" title="Updating DNS Zones">

</section>
<section anchor="name-server-management" title="Name Server Management">

</section>
</section>
<section anchor="dns-security-dnssec" title="DNS Security (DNSSEC)">

<t><xref target="RFC4033"/> S: “DNS Security Introduction and Requirements”</t>

<t><xref target="RFC4034"/> S: “Resource Records for the DNS Security Extensions”</t>

<t><xref target="RFC4035"/> S: “Protocol Modifications for the DNS Security Extensions”</t>

<t><xref target="RFC3225"/> S: “Indicating Resolver Support of DNSSEC”</t>

<t><xref target="RFC3226"/> S: “DNSSEC and IPv6 A6 aware server/resolver message size requirements”</t>

<t><xref target="RFC4470"/> S: “Minimally Covering NSEC Records and DNSSEC On-line Signing”</t>

<t><xref target="RFC4955"/> S: “DNS Security (DNSSEC) Experiments”</t>

<t><xref target="RFC5155"/> S: “DNS Security (DNSSEC) Hashed Authenticated Denial of Existence”</t>

<t><xref target="RFC6840"/> S: “Clarifications and Implementation Notes for DNS Security (DNSSEC)”</t>

<t><xref target="RFC4956"/> E: “DNS Security (DNSSEC) Opt-In”</t>

<t><xref target="RFC6841"/> I: “A Framework for DNSSEC Policies and DNSSEC Practice Statements”</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

</section>
<section anchor="security-considerations" title="Security Considerations">

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor='RFC1034' target='http://www.rfc-editor.org/info/rfc1034'>
<front>
<title>Domain names - concepts and facilities</title>
<author initials='P.V.' surname='Mockapetris' fullname='P.V. Mockapetris'><organization /></author>
<date year='1987' month='November' />
<abstract><t>This RFC is the revised basic definition of The Domain Name System.  It obsoletes RFC-882.  This memo describes the domain style names and their used for host address look up and electronic mail forwarding.  It discusses the clients and servers in the domain name system and the protocol used between them.</t></abstract>
</front>
<seriesInfo name='STD' value='13'/>
<seriesInfo name='RFC' value='1034'/>
<seriesInfo name='DOI' value='10.17487/RFC1034'/>
</reference>



<reference  anchor='RFC1035' target='http://www.rfc-editor.org/info/rfc1035'>
<front>
<title>Domain names - implementation and specification</title>
<author initials='P.V.' surname='Mockapetris' fullname='P.V. Mockapetris'><organization /></author>
<date year='1987' month='November' />
<abstract><t>This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System.  It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t></abstract>
</front>
<seriesInfo name='STD' value='13'/>
<seriesInfo name='RFC' value='1035'/>
<seriesInfo name='DOI' value='10.17487/RFC1035'/>
</reference>



<reference  anchor='RFC2181' target='http://www.rfc-editor.org/info/rfc2181'>
<front>
<title>Clarifications to the DNS Specification</title>
<author initials='R.' surname='Elz' fullname='R. Elz'><organization /></author>
<author initials='R.' surname='Bush' fullname='R. Bush'><organization /></author>
<date year='1997' month='July' />
<abstract><t>This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2181'/>
<seriesInfo name='DOI' value='10.17487/RFC2181'/>
</reference>



<reference  anchor='RFC2308' target='http://www.rfc-editor.org/info/rfc2308'>
<front>
<title>Negative Caching of DNS Queries (DNS NCACHE)</title>
<author initials='M.' surname='Andrews' fullname='M. Andrews'><organization /></author>
<date year='1998' month='March' />
<abstract><t>RFC1034 provided a description of how to cache negative responses.  It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching.  This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2308'/>
<seriesInfo name='DOI' value='10.17487/RFC2308'/>
</reference>



<reference  anchor='RFC5001' target='http://www.rfc-editor.org/info/rfc5001'>
<front>
<title>DNS Name Server Identifier (NSID) Option</title>
<author initials='R.' surname='Austein' fullname='R. Austein'><organization /></author>
<date year='2007' month='August' />
<abstract><t>With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query.  While existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server that responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5001'/>
<seriesInfo name='DOI' value='10.17487/RFC5001'/>
</reference>



<reference  anchor='RFC4343' target='http://www.rfc-editor.org/info/rfc4343'>
<front>
<title>Domain Name System (DNS) Case Insensitivity Clarification</title>
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organization /></author>
<date year='2006' month='January' />
<abstract><t>Domain Name System (DNS) names are &quot;case insensitive&quot;.  This document explains exactly what that means and provides a clear specification of the rules.  This clarification updates RFCs 1034, 1035, and 2181.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4343'/>
<seriesInfo name='DOI' value='10.17487/RFC4343'/>
</reference>



<reference  anchor='RFC6604' target='http://www.rfc-editor.org/info/rfc6604'>
<front>
<title>xNAME RCODE and Status Bits Clarification</title>
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organization /></author>
<date year='2012' month='April' />
<abstract><t>The Domain Name System (DNS) has long provided means, such as the CNAME (Canonical Name), whereby a DNS query can be redirected to a different name.  A DNS response header has an RCODE (Response Code) field, used for indicating errors, and response status bits.  This document clarifies, in the case of such redirected queries, how the RCODE and status bits correspond to the initial query cycle (where the CNAME or the like was detected) and subsequent or final query cycles.   [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6604'/>
<seriesInfo name='DOI' value='10.17487/RFC6604'/>
</reference>



<reference  anchor='RFC3597' target='http://www.rfc-editor.org/info/rfc3597'>
<front>
<title>Handling of Unknown DNS Resource Record (RR) Types</title>
<author initials='A.' surname='Gustafsson' fullname='A. Gustafsson'><organization /></author>
<date year='2003' month='September' />
<abstract><t>Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software.  This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3597'/>
<seriesInfo name='DOI' value='10.17487/RFC3597'/>
</reference>



<reference  anchor='RFC4592' target='http://www.rfc-editor.org/info/rfc4592'>
<front>
<title>The Role of Wildcards in the Domain Name System</title>
<author initials='E.' surname='Lewis' fullname='E. Lewis'><organization /></author>
<date year='2006' month='July' />
<abstract><t>This is an update to the wildcard definition of RFC 1034.  The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed.  The overall goal is not to change wildcards, but to refine the definition of RFC 1034.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4592'/>
<seriesInfo name='DOI' value='10.17487/RFC4592'/>
</reference>



<reference  anchor='RFC1536' target='http://www.rfc-editor.org/info/rfc1536'>
<front>
<title>Common DNS Implementation Errors and Suggested Fixes</title>
<author initials='A.' surname='Kumar' fullname='A. Kumar'><organization /></author>
<author initials='J.' surname='Postel' fullname='J. Postel'><organization /></author>
<author initials='C.' surname='Neuman' fullname='C. Neuman'><organization /></author>
<author initials='P.' surname='Danzig' fullname='P. Danzig'><organization /></author>
<author initials='S.' surname='Miller' fullname='S. Miller'><organization /></author>
<date year='1993' month='October' />
<abstract><t>This memo describes common errors seen in DNS implementations and suggests some fixes.  This memo provides information for the Internet community.  It does not specify an Internet standard.</t></abstract>
</front>
<seriesInfo name='RFC' value='1536'/>
<seriesInfo name='DOI' value='10.17487/RFC1536'/>
</reference>



<reference  anchor='RFC7766' target='http://www.rfc-editor.org/info/rfc7766'>
<front>
<title>DNS Transport over TCP - Implementation Requirements</title>
<author initials='J.' surname='Dickinson' fullname='J. Dickinson'><organization /></author>
<author initials='S.' surname='Dickinson' fullname='S. Dickinson'><organization /></author>
<author initials='R.' surname='Bellis' fullname='R. Bellis'><organization /></author>
<author initials='A.' surname='Mankin' fullname='A. Mankin'><organization /></author>
<author initials='D.' surname='Wessels' fullname='D. Wessels'><organization /></author>
<date year='2016' month='March' />
<abstract><t>This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123.</t></abstract>
</front>
<seriesInfo name='RFC' value='7766'/>
<seriesInfo name='DOI' value='10.17487/RFC7766'/>
</reference>



<reference  anchor='RFC4033' target='http://www.rfc-editor.org/info/rfc4033'>
<front>
<title>DNS Security Introduction and Requirements</title>
<author initials='R.' surname='Arends' fullname='R. Arends'><organization /></author>
<author initials='R.' surname='Austein' fullname='R. Austein'><organization /></author>
<author initials='M.' surname='Larson' fullname='M. Larson'><organization /></author>
<author initials='D.' surname='Massey' fullname='D. Massey'><organization /></author>
<author initials='S.' surname='Rose' fullname='S. Rose'><organization /></author>
<date year='2005' month='March' />
<abstract><t>The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System.  This document introduces these extensions and describes their capabilities and limitations.  This document also discusses the services that the DNS security extensions do and do not provide.  Last, this document describes the interrelationships between the documents that collectively describe DNSSEC.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4033'/>
<seriesInfo name='DOI' value='10.17487/RFC4033'/>
</reference>



<reference  anchor='RFC4034' target='http://www.rfc-editor.org/info/rfc4034'>
<front>
<title>Resource Records for the DNS Security Extensions</title>
<author initials='R.' surname='Arends' fullname='R. Arends'><organization /></author>
<author initials='R.' surname='Austein' fullname='R. Austein'><organization /></author>
<author initials='M.' surname='Larson' fullname='M. Larson'><organization /></author>
<author initials='D.' surname='Massey' fullname='D. Massey'><organization /></author>
<author initials='S.' surname='Rose' fullname='S. Rose'><organization /></author>
<date year='2005' month='March' />
<abstract><t>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. </t><t> This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4034'/>
<seriesInfo name='DOI' value='10.17487/RFC4034'/>
</reference>



<reference  anchor='RFC4035' target='http://www.rfc-editor.org/info/rfc4035'>
<front>
<title>Protocol Modifications for the DNS Security Extensions</title>
<author initials='R.' surname='Arends' fullname='R. Arends'><organization /></author>
<author initials='R.' surname='Austein' fullname='R. Austein'><organization /></author>
<author initials='M.' surname='Larson' fullname='M. Larson'><organization /></author>
<author initials='D.' surname='Massey' fullname='D. Massey'><organization /></author>
<author initials='S.' surname='Rose' fullname='S. Rose'><organization /></author>
<date year='2005' month='March' />
<abstract><t>This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC).  The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS.  This document describes the DNSSEC protocol modifications.  This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC.  These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. </t><t> This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4035'/>
<seriesInfo name='DOI' value='10.17487/RFC4035'/>
</reference>



<reference  anchor='RFC3225' target='http://www.rfc-editor.org/info/rfc3225'>
<front>
<title>Indicating Resolver Support of DNSSEC</title>
<author initials='D.' surname='Conrad' fullname='D. Conrad'><organization /></author>
<date year='2001' month='December' />
<abstract><t>In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs.  This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3225'/>
<seriesInfo name='DOI' value='10.17487/RFC3225'/>
</reference>



<reference  anchor='RFC3226' target='http://www.rfc-editor.org/info/rfc3226'>
<front>
<title>DNSSEC and IPv6 A6 aware server/resolver message size requirements</title>
<author initials='O.' surname='Gudmundsson' fullname='O. Gudmundsson'><organization /></author>
<date year='2001' month='December' />
<abstract><t>This document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support either DNS Security Extensions or A6 records.  This requirement is necessary because these new features increase the size of DNS messages.  If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load.  This document updates RFC 2535 and RFC 2874, by adding new requirements.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3226'/>
<seriesInfo name='DOI' value='10.17487/RFC3226'/>
</reference>



<reference  anchor='RFC4470' target='http://www.rfc-editor.org/info/rfc4470'>
<front>
<title>Minimally Covering NSEC Records and DNSSEC On-line Signing</title>
<author initials='S.' surname='Weiler' fullname='S. Weiler'><organization /></author>
<author initials='J.' surname='Ihren' fullname='J. Ihren'><organization /></author>
<date year='2006' month='April' />
<abstract><t>This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC 4034.  By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4470'/>
<seriesInfo name='DOI' value='10.17487/RFC4470'/>
</reference>



<reference  anchor='RFC4955' target='http://www.rfc-editor.org/info/rfc4955'>
<front>
<title>DNS Security (DNSSEC) Experiments</title>
<author initials='D.' surname='Blacka' fullname='D. Blacka'><organization /></author>
<date year='2007' month='July' />
<abstract><t>This document describes a methodology for deploying alternate, non-backwards-compatible, DNS Security (DNSSEC) methodologies in an experimental fashion without disrupting the deployment of standard DNSSEC.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4955'/>
<seriesInfo name='DOI' value='10.17487/RFC4955'/>
</reference>



<reference  anchor='RFC5155' target='http://www.rfc-editor.org/info/rfc5155'>
<front>
<title>DNS Security (DNSSEC) Hashed Authenticated Denial of Existence</title>
<author initials='B.' surname='Laurie' fullname='B. Laurie'><organization /></author>
<author initials='G.' surname='Sisson' fullname='G. Sisson'><organization /></author>
<author initials='R.' surname='Arends' fullname='R. Arends'><organization /></author>
<author initials='D.' surname='Blacka' fullname='D. Blacka'><organization /></author>
<date year='2008' month='March' />
<abstract><t>The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence.  However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5155'/>
<seriesInfo name='DOI' value='10.17487/RFC5155'/>
</reference>



<reference  anchor='RFC6840' target='http://www.rfc-editor.org/info/rfc6840'>
<front>
<title>Clarifications and Implementation Notes for DNS Security (DNSSEC)</title>
<author initials='S.' surname='Weiler' fullname='S. Weiler' role='editor'><organization /></author>
<author initials='D.' surname='Blacka' fullname='D. Blacka' role='editor'><organization /></author>
<date year='2013' month='February' />
<abstract><t>This document is a collection of technical clarifications to the DNS Security (DNSSEC) document set.  It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing.</t><t>This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155).  It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification.</t></abstract>
</front>
<seriesInfo name='RFC' value='6840'/>
<seriesInfo name='DOI' value='10.17487/RFC6840'/>
</reference>



<reference  anchor='RFC4956' target='http://www.rfc-editor.org/info/rfc4956'>
<front>
<title>DNS Security (DNSSEC) Opt-In</title>
<author initials='R.' surname='Arends' fullname='R. Arends'><organization /></author>
<author initials='M.' surname='Kosters' fullname='M. Kosters'><organization /></author>
<author initials='D.' surname='Blacka' fullname='D. Blacka'><organization /></author>
<date year='2007' month='July' />
<abstract><t>In the DNS security (DNSSEC) extensions, delegations to unsigned subzones are cryptographically secured.  Maintaining this cryptography is not always practical or necessary.  This document describes an experimental &quot;Opt-In&quot; model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones.  This memo defines an Experimental Protocol for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='4956'/>
<seriesInfo name='DOI' value='10.17487/RFC4956'/>
</reference>



<reference  anchor='RFC6841' target='http://www.rfc-editor.org/info/rfc6841'>
<front>
<title>A Framework for DNSSEC Policies and DNSSEC Practice Statements</title>
<author initials='F.' surname='Ljunggren' fullname='F. Ljunggren'><organization /></author>
<author initials='AM.' surname='Eklund Lowinder' fullname='AM. Eklund Lowinder'><organization /></author>
<author initials='T.' surname='Okubo' fullname='T. Okubo'><organization /></author>
<date year='2013' month='January' />
<abstract><t>This document presents a framework to assist writers of DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone with Security Extensions implemented.</t><t>In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement.  This document is not an Internet Standards Track specification; it is published for informational  purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='6841'/>
<seriesInfo name='DOI' value='10.17487/RFC6841'/>
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor='RFC2026' target='http://www.rfc-editor.org/info/rfc2026'>
<front>
<title>The Internet Standards Process -- Revision 3</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1996' month='October' />
<abstract><t>This memo documents the process used by the Internet community for the standardization of protocols and procedures.  It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='9'/>
<seriesInfo name='RFC' value='2026'/>
<seriesInfo name='DOI' value='10.17487/RFC2026'/>
</reference>



<reference  anchor='RFC7719' target='http://www.rfc-editor.org/info/rfc7719'>
<front>
<title>DNS Terminology</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></author>
<author initials='A.' surname='Sullivan' fullname='A. Sullivan'><organization /></author>
<author initials='K.' surname='Fujiwara' fullname='K. Fujiwara'><organization /></author>
<date year='2015' month='December' />
<abstract><t>The DNS is defined in literally dozens of different RFCs.  The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined.  This document gives current definitions for many of the terms used in the DNS in a single document.</t></abstract>
</front>
<seriesInfo name='RFC' value='7719'/>
<seriesInfo name='DOI' value='10.17487/RFC7719'/>
</reference>




    </references>



  </back>
</rfc>

