One document matched: draft-livingood-negative-trust-anchors-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 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 RFC4641 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4641.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">
]>
<?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-negative-trust-anchors-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='DNSSEC Negative Trust Anchors'>
Definition and Use of DNSSEC Negative Trust Anchors
</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>
<author initials='C.' surname='Griffiths' fullname='Chris Griffiths'>
<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>chris_griffiths@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
<!-- author role='editor' is an optional value here -->
</author>
<date day='26' month='March' year='2012'/>
<!-- 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. One potential technique to mitigate this is to use a Negative Trust Anchor, which is defined in this document.</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='RFC4641'/> <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 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>In the short-term, one potential way to address this is for DNS operators to use a Negative Trust Anchor to temporarily disable DNSSEC validation for a specific misconfigured domain name. This immediately restore access for end users while that domain's administrators fix their misconfiguration. While DNS operators likely prefer not to use this tool, during the global transition to DNSSEC it seems some tool is needed to reduce the negative impact on such operators.</t>
<t>A Negative Trust Anchor should be considered a transitional and temporary tactic which is not particularly scalable and should not be used in the long-term. Over time, however, the use of Negative Trust Anchors will become less necessary as DNSSEC-related domain administration becomes more resilient.</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="RFC4641"/> 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="NASA.GOV Validation Failure Analysis"/>, the NASA.GOV domain name failed to validate. An investigation revealed that the NASA.GOV domain administrators performed a Key Signing Key (KSK) rollover by (1) generating a new key and (2) signing the NASA.GOV 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 NASA.GOV 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 .GOV and NASA.GOV.)</t>
</section>
<section title='End User Reaction' anchor='End User Reaction' toc='include'>
<t>End users generally do not know what DNSSEC is, nor should they be expected to at the current time (and absent widespread integration of DNSSEC indicators in end user software such as web browsers). As a result, end users may incorrectly the failure to reach a domain due to DNSSEC-related misconfiguration as their ISP purposely blocking access to the domain or as a performance failure on the part of their ISP (especially of the ISP's DNS servers). End users may feel less satisfied with their ISP's service, which may make them more likely to switch to a competing ISP. They may also contact their ISP to complain, which of course will incur cost for their ISP. In addition, they may use online tools and sites to complain of this problem, such as via a blog, web forum, or social media site, which may lead to dissatisfaction on the part of other end users or general criticism of an ISP or operator of a DNS recursive resolver.</t>
<t>As end users publicize these failures, others may recommend they switch from security-aware DNS resolvers to resolvers not performing DNSSEC validation. This is a shame since the ISP or other DNS recursive resolver operator is actually doing exactly what they are supposed to do in failing to resolve a domain name, as this is the expected result when a domain can no longer be validated, protecting end users from a potential security threat.</t>
</section>
<section title='Switching to a Non-Validating Resolver is Not Recommended' anchor='Switching to a Non-Validating Resolver is Not Recommended' toc='include'>
<t>As noted in <xref target="End User Reaction"/> some people may consider switching to an alternative, non-validating resolver themselves, or may recommend that others do so. But if a domain fails DNSSEC validation and is inaccessible, this could very well be due to a security-related issue. In order to be as safe and secure as possible, end users should not change to DNS servers that do not perform DNSSEC validation as a workaround, and people should not recommend that others do so either. Even if a website in a domain seems to look "normal" and valid, including any applicable SSL [REFERENCE NEEDED - RFC 5246 CORRECT?] certificates, according to the DNSSEC protocol, that domain is not secure. Domains that fail DNSSEC for legitimate reasons may be in control of hackers or there could be other significant security issues with the domain.</t>
<t>Thus, switching to a non-validating resolver to restore access to a domain that fails DNSSEC validation is not a recommended practice, is bad advice to others, is potentially harmful to end user security, and is potentially harmful to DNSSEC adoption.</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 DNS authoritative 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>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='Negative Trust Anchor Defined' anchor='Negative Trust Anchor Defined' toc='include'>
<t>Trust Anchors are defined in <xref target='RFC5914'/> [editorial note: details or what to say about reference is undefined in the -00 version, so this needs work for the -01]. A trust anchor should be used by a validating caching resolver as a starting point for building the authentication chain for a signed DNS response. The inverse of this is a Negative Trust Anchor, which would create a stopping point for a caching resolver to end validation of the authentication chain. This Negative Trust Anchor can potentially be placed at any level within the chain of trust and would stop validation at that point in the chain.</t>
</section>
<section title='Negative Trust Anchor Use' anchor='Negative Trust Anchor Use' toc='include'>
<t>When a domain has been confirmed to be failing DNSSEC validation due to a DNSSEC-related misconfiguration, an ISP or other DNS recursive resolver operator may in some cases use a Negative Trust Anchor for a domain or sub-domain. This instructs a DNS recursive resolver to temporarily NOT perform DNSSEC validation for a specific domain name. This immediately restores access to the domain for end users while the domain's administrator corrects the misconfiguration(s).</t>
<t>In the case of a validation failure due to misconfiguration of a TLD or popular domain name (such as a top 100 website), this could make content or services in the affected TLD or domain to be inaccessible for a large number of users. A Negative Trust Anchor can therefore be useful in the short-term when used on a targeted and time-limited basis. It does not [editorial question: must not? should not?] involve turning off validation more broadly, and helps during the transition to DNSSEC as organizations that are new to signing their domains are still maturing their DNSSEC operational practices, alleviating end user issues <xref target="End User Reaction"/> and restoring end user access. However, use of a Negative Trust Anchor should not be automatic in any way, and must involve investigation by technical personnel trained in the operation of DNS servers. Such an investigation must confirm that a failure is due to misconfiguration, as a similar breakage could have occurred if an attacker gained access to a domain's authoritative servers and modified those records or had the domain pointed to their own rogue authoritative servers. Furthermore, a Negative Trust Anchor should be used only for a short duration, perhaps for a day or less.</t>
<t>Finally, a Negative Trust Anchor is used only in a specific domain or sub-domain and would not affect validation at other names up the authentication chain. For example, a Negative Trust Anchor for zone1.example.com would affect only names within zone1.example.com, and validation would still be performed on example.com, .com, and the root ("."). In another example, a Negative Trust Anchor for example.com would affect only names within example.com, and validation would still be performed on .com, and the root (".")</t>
<t>[Editorial note: diagram helpful here?]</t>
</section>
<section title='Managing Negative Trust Anchors' anchor='Managing Negative Trust Anchors' toc='include'>
<t>This tool is unlikely to be [editorial note: should not be?] used over the long-term since DNSSEC-related domain administration practices will naturally improve over time. In addition, however, continued and frequent use of Negative Trust Anchors is not scalable since it requires investigation by technical personnel and may involve manual processes, resulting in increased operational overhead (and therefore cost).</t>
<t>While Negative Trust Anchors have proven useful during the early stages of DNSSEC adoption, domain owners are ultimately responsible for managing and ensuring their DNS records are configured correctly <xref target="Responsibility for Failures"/>.</t>
<t>Most current implementations of DNS validating resolvers currently follow <xref target='RFC4033'/> on defining the implementation of Trust Anchor as either using Delegation Signer (DS), Key Signing Key (KSK), or Zone Signing Key (ZSK). A Negative Trust Anchor should use domain name formatting that signifies where in a delegation that validation should be stopped [editorial note: research if domain names should be used, or if alternatives formatting needs to be clear in the case of RFC 5914].</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>[Editorial note: to be completed in -01]</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='Contributors' toc='include'>
<t>The following people made significant textual contributions to this document and/or played an important role in the development and evolution of this document:</t>
<t>- John Barnitz</t>
<t>- Tom Creighton</t>
<t>- Chris Ganster</t>
</section>
<section title='Acknowledgements' toc='include'>
<t>The authors and contributors also wish to acknowledge the assistance of the following individuals or groups. Some of these people provided helpful and important guidance in the development of this document and/or in the development of the concepts covered in this document. Other people assisted by performing a detailed review of this document, and then providing feedback and constructive criticism for revisions to this document, or engaged in a healthy debate over the subject of the document. All of this was helpful and therefore the following individuals merit acknowledgement:</t>
<t>- Your Name Here!</t>
</section>
</middle>
<!-- END MIDDLE SECTION -->
<!-- BACK SECTION -->
<back>
<references title='Normative References'>
&RFC1034;
&RFC1035;
&RFC4033;
&RFC4034;
&RFC4035;
&RFC4398;
&RFC4509;
&RFC4641;
&RFC5155;
&RFC5914;
</references>
<references title='Informative References'>
<reference anchor="NASA.GOV 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>
<t>Check references to ensure all of them are still necessary</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 04:29:33 |