One document matched: draft-livingood-auth-dnssec-mistakes-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- References are listed here so that they can be called via Entity attributes later -->
<!ENTITY RFC1034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY RFC4035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY RFC4398 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4398.xml">
<!ENTITY RFC4509 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4509.xml">
<!ENTITY RFC5155 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5155.xml">
<!ENTITY RFC5914 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5914.xml">
<!ENTITY RFC6781 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6781.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- PROCESSING INSTRUCTIONS - GENERAL -->
<!-- EACH ONE STARTS WITH '?' BELOW -->
<!-- give errors on I-D nits and perform DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc strict='yes' ?>
<?rfc toc='yes'?>
<!-- generate a ToC -->
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth='4'?>
<!-- END GENERAL PROCESSING -->
<!-- PROCESSING INSTRUCTIONS - CONTROL OF REFERENCES -->
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs='yes'?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space -->
<?rfc sortrefs='yes' ?>
<!-- do not start each main section on a new page -->
<?rfc compact='yes' ?>
<!-- keep one blank line between list items -->
<?rfc subcompact='no' ?>
<!-- END REFERENCE PROCESSING -->
<rfc ipr='trust200902' docName='draft-livingood-auth-dnssec-mistakes-00' category='info'>
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3978, noModification3978, noDerivatives3978
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- FRONT SECTION -->
<front>
<title abbrev='Responsibility for DNSSEC Mistakes'>
Responsibility for Authoritative DNSSEC Mistakes
</title>
<!-- add role='editor' attribute to author tag below for the editors if appropriate -->
<author initials='J.' surname='Livingood' fullname='Jason Livingood'>
<organization abbrev='Comcast'>
Comcast Cable Communications
</organization>
<address>
<postal>
<street>One Comcast Center</street>
<street>1701 John F. Kennedy Boulevard</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>US</country>
</postal>
<email>jason_livingood@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
<!-- author role='editor' is an optional value here -->
</author>
<date day='4' month='September' year='2013'/>
<!-- META-DATA DECLARATIONS -->
<area>Operations and Management Area</area>
<!-- WG name at the upperleft corner of the doc; 'Internet Engineering Task Force' is fine for individual submissions. -->
<workgroup>Domain Name System Operations</workgroup>
<!-- Keywords will be incorporated into HTML output files in a meta tag but they have no effect on text or nroff output. If you submit your draft to the RFC Editor, the keywords will be used for the search engine. -->
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Comcast</keyword>
<keyword>ISP</keyword>
<keyword>Internet Service Provider</keyword>
<keyword>DNS</keyword>
<keyword>DNSSEC</keyword>
<keyword>Negative Trust Anchors</keyword>
<abstract>
<t>DNS Security Extensions (DNSSEC) is now entering widespread deployment. However, domain signing tools and processes are not yet as mature and reliable as is the case for non-DNSSEC-related domain administration tools and processes. Authoritative DNS operators should focus on improving these processes and establishing a high level of quality in their work.</t>
</abstract>
<!-- END META-DATA DECLARATIONS -->
</front>
<!-- END FRONT SECTION -->
<!-- MIDDLE SECTION -->
<middle>
<section anchor='intro' title='Introduction' toc='include'>
<t>The Domain Name System (DNS), DNS Security Extensions (DNSSEC), and related operational practices are defined extensively <xref target='RFC1034'/> <xref target='RFC1035'/> <xref target='RFC4033'/> <xref target='RFC4034'/> <xref target='RFC4035'/> <xref target='RFC4398'/> <xref target='RFC4509'/> <xref target='RFC6781'/> <xref target='RFC5155'/>.</t>
<t>DNSSEC has now entered widespread deployment. However, domain signing tools and processes are not yet as mature and reliable as is the case for non-DNSSEC-related domain administration tools and processes. As a result, operators of DNS recursive resolvers, such as Internet Service Providers (ISPs), occasionally observe domains incorrectly managing DNSSEC-related resource records. This mismanagement triggers DNSSEC validation failures, and then causes large numbers of end users to be unable to reach a domain. Many end users tend interpret this as a failure of their DNS servers, and may switch to a non-validating resolver (reducing their security) or contact their ISP to complain, rather than seeing this as a failure on the part of the domain they wanted to reach.</t>
<t>This document makes clear, however, that responsibility for these failures rests squarely with authoritative domain name operators, as noted in <xref target='Responsibility for Failures'/>.</t>
</section>
<section title='Domain Validation Failures' anchor='Domain Validation Failures' toc='include'>
<t>A domain name can fail validation for two general reasons, a legitimate security failure such as due to an attack or compromise of some sort, or as a result of misconfiguration on the part of an domain administrator. As domains transition to DNSSEC the most likely reason for a validation failure will be due to misconfiguration. Thus, domain administrators should be sure to read <xref target="RFC6781"/> in full. They should also pay special attention to Section 4.2, pertaining to key rollovers, which appears to be the cause of many recent validation failures.</t>
<t>In one recent example <xref target="DNSSEC Validation Failure Analysis"/>, a specific domain name failed to validate. An investigation revealed that the domain's administrators performed a Key Signing Key (KSK) rollover by (1) generating a new key and (2) signing the domain with the new key. However, they did not use a double-signing procedure for the KSK and a pre-publish procedure for the ZSK. Double-signing refers to signing a zone with two KSKs and then updating the parent zone with the new DS record so that both keys are valid at the same time. This meant that the domain name was signed with the new KSK, but it was not double-signed with the old KSK. So, the new key was used for signing the zone but the old key was not. As a result, the domain could not be trusted and returned an error when trying to reach the domain. Thus, the domain was in a situation where the DNSSEC chain of trust was broken because the Delegation Signer (DS) record pointed to the old KSK, which was no longer used for signing the zone. (A DS record provides a link in the chain of trust for DNSSEC from the parent zone to the child zone - in this case between TLD and domain name.)</t>
</section>
<section title='Responsibility for Failures' anchor='Responsibility for Failures' toc='include'>
<t>A domain administrator is solely and completely responsible for managing their domain name(s) and DNS resource records. This includes complete responsibility for the correctness of those resource records, the proper functioning of their authoritative DNS servers, and the correctness of DNS records linking their domain to a top-level domain (TLD) or other higher level domain. Even in cases where some error may be introduced by a third party, whether that is due to an authoritative server software vendor, software tools vendor, domain name registrar, or other organization, these are all parties that the domain administrator has selected and is responsible for managing successfully.</t>
<t>There are some cases where the domain administrator is different than the domain owner. In those cases, a domain owner has delegated operational responsibility to the domain administrator. So no matter whether a domain owner is also the domain administrator or not, the domain administrator is nevertheless operationally responsible for the proper configuration operation of the domain.</t>
<t>So in the case of a domain name failing to successfully validate, when this is due to a misconfiguration of the domain, that is the sole responsibility of the domain administrator.</t>
<t>Any assistance or mitigation responses undertaken by other parties to mitigate the misconfiguration of a domain name by a domain administrator, especially operators of DNS recursive resolvers, are optional and at the pleasure of those parties.</t>
</section>
<section title='Comparison to Other DNS Misconfigurations' anchor='Comparison to Other DNS Misconfigurations' toc='include'>
<t>As noted in <xref target="Responsibility for Failures"/> domain administrators are ultimately responsible for managing and ensuring their DNS records are configured correctly. ISPs or other DNS recursive resolver operators cannot and should not correct misconfigured A, CNAME, MX, or other resource records of domains for which they are not authoritative. Expecting non-authoritative entities to protect domain administrators from any misconfiguration of resource records is therefore unrealistic and unreasonable, and in the long-term is harmful to the delegated design of the DNS and could lead to extensive operational instability and/or variation.</t>
</section>
<section title='Other Considerations' anchor='Other Considerations' toc='include'>
<section title='Security Considerations' anchor='Security Considerations' toc='include'>
<t>Authoritative domain name operators and domain name owners, in the case of DNSSEC-related mistakes that cause validation failures to occur, should focus on correcting the issue and then improving their processes and tools in the future. During the period of time that their domain cannot be resolved due to a DNSSEC-related mistake, they should not encourage end users to switch to non-validating resolvers, as the use of a non-validating DNS recursive resolver has comparatively less security capabilities than a non-validating resolvers, since one implements DNS Security Extensions and one does not. In addition, if an end user changes to a non-validating resolver they may subject themselves to increased security risks and threats against which DNS Security Extensions may have provided protection.</t>
</section>
<section title='Privacy Considerations' anchor='Privacy Considerations' toc='include'>
<t>There are no privacy considerations in this document.</t>
</section>
<section title='IANA Considerations' anchor='IANA Considerations' toc='include'>
<t>There are no IANA considerations in this document.</t>
</section>
</section>
<section title='Acknowledgements' toc='include'>
<t></t>
</section>
</middle>
<!-- END MIDDLE SECTION -->
<!-- BACK SECTION -->
<back>
<references title='Normative References'>
&RFC1034;
&RFC1035;
&RFC4033;
&RFC4034;
&RFC4035;
&RFC4398;
&RFC4509;
&RFC5155;
&RFC5914;
&RFC6781;
</references>
<references title='Informative References'>
<reference anchor="DNSSEC Validation Failure Analysis" target="http://www.dnssec.comcast.net/DNSSEC_Validation_Failure_NASAGOV_20120118_FINAL.pdf">
<front>
<title>Analysis of DNSSEC Validation Failure - NASA.GOV</title>
<author initials='J.' surname='Barnitz' fullname='John Barnitz'>
<organization abbrev='Comcast'>Comcast</organization>
</author>
<author initials='T.' surname='Creighton' fullname='Tom Creighton'>
<organization abbrev='Comcast'>Comcast</organization>
</author>
<author initials='C.' surname='Ganster' fullname='Chris Ganster'>
<organization abbrev='Comcast'>Comcast</organization>
</author>
<author initials='C.' surname='Griffiths' fullname='Chris Griffiths'>
<organization abbrev='Comcast'>Comcast</organization>
</author>
<author initials='J.' surname='Livingood' fullname='Jason Livingood'>
<organization abbrev='Comcast'>Comcast</organization>
</author>
<date month="January" day="24" year="2012"/>
</front>
<seriesInfo name="Comcast" value=""/>
</reference>
</references>
<section title='Document Change Log'>
<t>[RFC Editor: This section is to be removed before publication]</t>
<t>-00: First version published as an individual draft.</t>
</section>
<section title='Open Issues'>
<t>[RFC Editor: This section is to be removed before publication]</t>
</section>
</back>
<!-- END BACK SECTION -->
</rfc>
<!-- FOR REFERENCE -->
<!-- less than is < -->
<!-- ampersand is & -->
<!-- apostrophe is &apos -->
<!-- quotation is " -->
| PAFTECH AB 2003-2026 | 2026-04-24 13:59:08 |