< draft-livingood-negative-trust-anchors-06.txt		draft-livingood-negative-trust-anchors-07.txt >
	Domain Name System Operations J. Livingood		Domain Name System Operations J. Livingood
	Internet-Draft C. Griffiths		Internet-Draft Comcast
	Intended status: Informational Comcast		Intended status: Informational C. Griffiths
	Expires: August 26, 2013 February 22, 2013		Expires: March 28, 2015 Dyn
			September 24, 2014
	Definition and Use of DNSSEC Negative Trust Anchors		Definition and Use of DNSSEC Negative Trust Anchors
	draft-livingood-negative-trust-anchors-06		draft-livingood-negative-trust-anchors-07
	Abstract		Abstract
	DNS Security Extensions (DNSSEC) is now entering widespread		DNS Security Extensions (DNSSEC) is now entering widespread
	deployment. However, domain signing tools and processes are not yet		deployment. However, domain signing tools and processes are not yet
	as mature and reliable as is the case for non-DNSSEC-related domain		as mature and reliable as is the case for non-DNSSEC-related domain
	administration tools and processes. One potential technique to		administration tools and processes. One potential technique to
	mitigate this is to use a Negative Trust Anchor, which is defined in		mitigate this is to use a Negative Trust Anchor, which is defined in
	this document.		this document.
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 35 ¶
	resolver and can shield end users of such a resolver from the DNSSEC-		resolver and can shield end users of such a resolver from the DNSSEC-
	related authoritative name server operational errors that appear to		related authoritative name server operational errors that appear to
	be somewhat typical during the transition to ubiquitous DNSSEC		be somewhat typical during the transition to ubiquitous DNSSEC
	deployment. Negative Trust Anchors are intended to be temporary, and		deployment. Negative Trust Anchors are intended to be temporary, and
	should not be distributed by IANA or any other organization outside		should not be distributed by IANA or any other organization outside
	of the administrative boundary of the organization locally		of the administrative boundary of the organization locally
	implementing a Negative Trust Anchor. Finally, Negative Trust		implementing a Negative Trust Anchor. Finally, Negative Trust
	Anchors pertain only to DNSSEC and not to Public Key Infrastructures		Anchors pertain only to DNSSEC and not to Public Key Infrastructures
	(PKI) such ad X.509.		(PKI) such ad X.509.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
			This Internet-Draft will expire on March 28, 2015.
	This Internet-Draft will expire on August 26, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Definition of a Negative Trust Anchor . . . . . . . . . . . . 4		2. Definition of a Negative Trust Anchor . . . . . . . . . . . . 4
	3. Limited Time and Scope of Use . . . . . . . . . . . . . . . . 4		3. Limited Time and Scope of Use . . . . . . . . . . . . . . . . 4
	4. Domain Validation Failures . . . . . . . . . . . . . . . . . . 5		4. Domain Validation Failures . . . . . . . . . . . . . . . . . 5
	5. End User Reaction . . . . . . . . . . . . . . . . . . . . . . 5		5. End User Reaction . . . . . . . . . . . . . . . . . . . . . . 5
	6. Switching to a Non-Validating Resolver is Not Recommended . . 6		6. Switching to a Non-Validating Resolver is Not Recommended . . 6
	7. Responsibility for Failures . . . . . . . . . . . . . . . . . 6		7. Responsibility for Failures . . . . . . . . . . . . . . . . . 6
	8. Use of a Negative Trust Anchor . . . . . . . . . . . . . . . . 7		8. Use of a Negative Trust Anchor . . . . . . . . . . . . . . . 7
	9. Managing Negative Trust Anchors . . . . . . . . . . . . . . . 9		9. Managing Negative Trust Anchors . . . . . . . . . . . . . . . 8
	10. Removal of a Negative Trust Anchor . . . . . . . . . . . . . . 9		10. Removal of a Negative Trust Anchor . . . . . . . . . . . . . 9
	11. Comparison to Other DNS Misconfigurations . . . . . . . . . . 10		11. Comparison to Other DNS Misconfigurations . . . . . . . . . . 9
	12. Intentionally Broken Domains . . . . . . . . . . . . . . . . . 10		12. Intentionally Broken Domains . . . . . . . . . . . . . . . . 10
	13. Other Considerations . . . . . . . . . . . . . . . . . . . . . 10		13. Other Considerations . . . . . . . . . . . . . . . . . . . . 10
	13.1. Security Considerations . . . . . . . . . . . . . . . . . 10		13.1. Security Considerations . . . . . . . . . . . . . . . . 10
	13.2. Privacy Considerations . . . . . . . . . . . . . . . . . 11		13.2. Privacy Considerations . . . . . . . . . . . . . . . . . 11
	13.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 11		13.3. IANA Considerations . . . . . . . . . . . . . . . . . . 11
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	15.1. Normative References . . . . . . . . . . . . . . . . . . 12		15.1. Normative References . . . . . . . . . . . . . . . . . . 12
	15.2. Informative References . . . . . . . . . . . . . . . . . 13		15.2. Informative References . . . . . . . . . . . . . . . . . 13
	Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 13		Appendix A. Document Change Log . . . . . . . . . . . . . . . . 13
	Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 14		Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	The Domain Name System (DNS), DNS Security Extensions (DNSSEC), and		The Domain Name System (DNS), DNS Security Extensions (DNSSEC), and
	related operational practices are defined extensively [RFC1034]		related operational practices are defined extensively [RFC1034]
	[RFC1035] [RFC4033] [RFC4034] [RFC4035] [RFC4398] [RFC4509] [RFC6781]		[RFC1035] [RFC4033] [RFC4034] [RFC4035] [RFC4398] [RFC4509] [RFC6781]
	[RFC5155].		[RFC5155].
	This document discusses Trust Anchors for DNSSEC and defines a		This document discusses Trust Anchors for DNSSEC and defines a
	Negative Trust Anchor, which is potentially useful during the		Negative Trust Anchor, which is potentially useful during the
	transition to ubiquitous DNSSEC deployment. These are configured		transition to ubiquitous DNSSEC deployment. These are configured
	locally on a particular instance of a validating DNS recursive		locally on a particular instance of a validating DNS recursive
	resolver and can shield end users of such a resolver from the DNSSEC-		resolver and can shield end users of such a resolver from the DNSSEC-
	related authoritative name server operational errors that appear to		related authoritative name server operational errors that appear to
	be somewhat typical during the transition to ubiquitous DNSSEC		be somewhat typical during the transition to ubiquitous DNSSEC
	skipping to change at page 5, line 13 ¶		skipping to change at page 5, line 13 ¶
	technical personnel trained in the operation of DNS servers.		technical personnel trained in the operation of DNS servers.
	4. Domain Validation Failures		4. Domain Validation Failures
	A domain name can fail validation for two general reasons, a		A domain name can fail validation for two general reasons, a
	legitimate security failure such as due to an attack or compromise of		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		some sort, or as a result of misconfiguration on the part of an
	domain administrator. As domains transition to DNSSEC the most		domain administrator. As domains transition to DNSSEC the most
	likely reason for a validation failure will be due to		likely reason for a validation failure will be due to
	misconfiguration. Thus, domain administrators should be sure to read		misconfiguration. Thus, domain administrators should be sure to read
	[RFC6781] in full. They should also pay special attention to Section		[RFC6781] in full. They should also pay special attention to
	4.2, pertaining to key rollovers, which appears to be the cause of		Section 4.2, pertaining to key rollovers, which appears to be the
	many recent validation failures.		cause of many recent validation failures.
	In one recent example [DNSSEC Validation Failure Analysis], a		In one recent example [DNSSEC-Validation-Failure-Analysis], a
	specific domain name failed to validate. An investigation revealed		specific domain name failed to validate. An investigation revealed
	that the domain's administrators performed a Key Signing Key (KSK)		that the domain's administrators performed a Key Signing Key (KSK)
	rollover by (1) generating a new key and (2) signing the domain with		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		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		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		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		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,		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		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		used for signing the zone but the old key was not. As a result, the
	skipping to change at page 9, line 29 ¶		skipping to change at page 9, line 21 ¶
	Most current implementations of DNS validating resolvers currently		Most current implementations of DNS validating resolvers currently
	follow [RFC4033] on defining the implementation of Trust Anchor as		follow [RFC4033] on defining the implementation of Trust Anchor as
	either using Delegation Signer (DS), Key Signing Key (KSK), or Zone		either using Delegation Signer (DS), Key Signing Key (KSK), or Zone
	Signing Key (ZSK). A Negative Trust Anchor should use domain name		Signing Key (ZSK). A Negative Trust Anchor should use domain name
	formatting that signifies where in a delegation a validation process		formatting that signifies where in a delegation a validation process
	should be stopped.		should be stopped.
	Different DNS recursive resolvers may have different configuration		Different DNS recursive resolvers may have different configuration
	names for a Negative Trust Anchor. For example, Unbound calls their		names for a Negative Trust Anchor. For example, Unbound calls their
	configuration "domain-insecure" [Unbound Configuration]		configuration "domain-insecure" [Unbound-Configuration]
	10. Removal of a Negative Trust Anchor		10. Removal of a Negative Trust Anchor
	As explored in Section 13.1, if a Negative Trust Anchor is still in		As explored in Section 13.1, if a Negative Trust Anchor is still in
	place after the point in time when the DNS misconfiguration that		place after the point in time when the DNS misconfiguration that
	caused validation to break has been fixed, this could be problematic.		caused validation to break has been fixed, this could be problematic.
	It is therefore recommended that implementors should periodically or		It is therefore recommended that implementors should periodically or
	even continuously attempt to validate the domain in question, for the		even continuously attempt to validate the domain in question, for the
	period of time that the Negative Trust Anchor is in place, until such		period of time that the Negative Trust Anchor is in place, until such
	validation is again successful. (Obviously a Negative Trust Anchor		validation is again successful. (Obviously a Negative Trust Anchor
	skipping to change at page 10, line 21 ¶		skipping to change at page 10, line 10 ¶
	resource records of domains for which they are not authoritative.		resource records of domains for which they are not authoritative.
	Expecting non-authoritative entities to protect domain administrators		Expecting non-authoritative entities to protect domain administrators
	from any misconfiguration of resource records is therefore		from any misconfiguration of resource records is therefore
	unrealistic and unreasonable, and in the long-term is harmful to the		unrealistic and unreasonable, and in the long-term is harmful to the
	delegated design of the DNS and could lead to extensive operational		delegated design of the DNS and could lead to extensive operational
	instability and/or variation.		instability and/or variation.
	12. Intentionally Broken Domains		12. Intentionally Broken Domains
	Some domains, such as dnssec-failed.org, have been intentionally		Some domains, such as dnssec-failed.org, have been intentionally
	broken for testing purposes [Measuring DNSSEC Validation of Website		broken for testing purposes
	Visitors] [Netalyzr]. For example, dnssec-failed.org is a DNSSEC-		[Measuring-DNSSEC-Validation-of-Website-Visitors] [Netalyzr]. For
	signed domain that is broken. If an end user is querying a		example, dnssec-failed.org is a DNSSEC-signed domain that is broken.
	validating DNS recursive resolver, then this or other similarly		If an end user is querying a validating DNS recursive resolver, then
	intentionally broken domains should fail to resolve and should result		this or other similarly intentionally broken domains should fail to
	in a SERVFAIL error. If such a domain resolved successfully, then it		resolve and should result in a SERVFAIL error. If such a domain
	is a sign that the DNS recursive resolver is not fully validating.		resolved successfully, then it is a sign that the DNS recursive
			resolver is not fully validating.
	Organizations that utilize Negative Trust Anchors should not add a		Organizations that utilize Negative Trust Anchors should not add a
	Negative Trust Anchor for any intentionally broken domain.		Negative Trust Anchor for any intentionally broken domain.
	Organizations operating an intentionally broken domain may wish to		Organizations operating an intentionally broken domain may wish to
	consider adding a TXT record for the domain to the effect of "This		consider adding a TXT record for the domain to the effect of "This
	domain is purposely DNSSEC broken for testing purposes".		domain is purposely DNSSEC broken for testing purposes".
	13. Other Considerations		13. Other Considerations
	skipping to change at page 11, line 8 ¶		skipping to change at page 10, line 45 ¶
	secured and when a Negative Trust Anchor is removed. In addition, a		secured and when a Negative Trust Anchor is removed. In addition, a
	Negative Trust Anchor may be put in place by DNS recursive resolver		Negative Trust Anchor may be put in place by DNS recursive resolver
	operators without the knowledge of the authoritative domain		operators without the knowledge of the authoritative domain
	administrator for a given domain name.		administrator for a given domain name.
	End users of a DNS recursive resolver or other people may wonder why		End users of a DNS recursive resolver or other people may wonder why
	a domain that fails DNSSEC validation resolves with a supposedly		a domain that fails DNSSEC validation resolves with a supposedly
	validating resolver. As a result, implementors should consider		validating resolver. As a result, implementors should consider
	transparently disclosing those Negative Trust Anchors which are		transparently disclosing those Negative Trust Anchors which are
	currently in place or were in place in the past, such as on a website		currently in place or were in place in the past, such as on a website
	[Disclosure Example]. This is particularly important since there is		[Disclosure-Example]. This is particularly important since there is
	currently no special DNS query response code that could indicate to		currently no special DNS query response code that could indicate to
	end users or applications that a Negative Trust Anchor is in place.		end users or applications that a Negative Trust Anchor is in place.
	Such disclosures should optimally include both the data and time that		Such disclosures should optimally include both the data and time that
	the Negative Trust Anchor was put in place and when it was removed.		the Negative Trust Anchor was put in place and when it was removed.
	13.2. Privacy Considerations		13.2. Privacy Considerations
	There are no privacy considerations in this document.		There are no privacy considerations in this document.
	13.3. IANA Considerations		13.3. IANA Considerations
	skipping to change at page 11, line 40 ¶		skipping to change at page 11, line 31 ¶
	the following individuals merit acknowledgement:		the following individuals merit acknowledgement:
	- Joe Abley		- Joe Abley
	- John Barnitz		- John Barnitz
	- Tom Creighton		- Tom Creighton
	- Marco Davids		- Marco Davids
			- Brian Dickson
	- Patrik Falstrom		- Patrik Falstrom
	- Tony Finch		- Tony Finch
	- Chris Ganster		- Chris Ganster
	- Olafur Gudmundsson		- Olafur Gudmundsson
			- Peter Hagopian
	- Wes Hardaker		- Wes Hardaker
	- Paul Hoffman		- Paul Hoffman
	- Shane Kerr		- Shane Kerr
	- Murray Kucherawy		- Murray Kucherawy
			- Warren Kumari
			- Rick Lamb
	- Marc Lampo		- Marc Lampo
	- Ted Lemon		- Ted Lemon
			- Ed Lewis
	- Antoin Verschuren		- Antoin Verschuren
	- Paul Vixie		- Paul Vixie
	- Patrik Wallstrom		- Patrik Wallstrom
	- Nick Weaver		- Nick Weaver
	- Ralf Weber		- Ralf Weber
	skipping to change at page 12, line 33 ¶		skipping to change at page 12, line 33 ¶
	15.1. Normative References		15.1. Normative References
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, November 1987.		STD 13, RFC 1034, November 1987.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, November 1987.
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements",		Rose, "DNS Security Introduction and Requirements", RFC
	RFC 4033, March 2005.		4033, March 2005.
	[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Resource Records for the DNS Security Extensions",		Rose, "Resource Records for the DNS Security Extensions",
	RFC 4034, March 2005.		RFC 4034, March 2005.
	[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Protocol Modifications for the DNS Security		Rose, "Protocol Modifications for the DNS Security
	Extensions", RFC 4035, March 2005.		Extensions", RFC 4035, March 2005.
	[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name		[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name
	skipping to change at page 13, line 11 ¶		skipping to change at page 13, line 13 ¶
	(DS) Resource Records (RRs)", RFC 4509, May 2006.		(DS) Resource Records (RRs)", RFC 4509, May 2006.
	[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS		[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
	Security (DNSSEC) Hashed Authenticated Denial of		Security (DNSSEC) Hashed Authenticated Denial of
	Existence", RFC 5155, March 2008.		Existence", RFC 5155, March 2008.
	[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor		[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
	Format", RFC 5914, June 2010.		Format", RFC 5914, June 2010.
	[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC		[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
	Operational Practices, Version 2", RFC 6781,		Operational Practices, Version 2", RFC 6781, December
	December 2012.		2012.
	15.2. Informative References		15.2. Informative References
	[DNSSEC Validation Failure Analysis]		[DNSSEC-Validation-Failure-Analysis]
	Barnitz, J., Creighton, T., Ganster, C., Griffiths, C.,		Barnitz, J., Creighton, T., Ganster, C., Griffiths, C.,
	and J. Livingood, "Analysis of DNSSEC Validation Failure -		and J. Livingood, "Analysis of DNSSEC Validation Failure -
	NASA.GOV", Comcast , January 2012, <http://		NASA.GOV", Comcast , January 2012,
	www.dnssec.comcast.net/		<http://www.dnssec.comcast.net/
	DNSSEC_Validation_Failure_NASAGOV_20120118_FINAL.pdf>.		DNSSEC_Validation_Failure_NASAGOV_20120118_FINAL.pdf>.
	[Disclosure Example]		[Disclosure-Example]
	Comcast, "faa.gov Failing DNSSEC Validation (Fixed)",		Comcast, "faa.gov Failing DNSSEC Validation (Fixed)",
	Comcast , February 2013, <http://dns.comcast.net/		Comcast , February 2013,
	index.php/entry/faa-gov-failing-dnssec-validation-fixed>.		<http://dns.comcast.net/index.php/entry/
			faa-gov-failing-dnssec-validation-fixed>.
	[Measuring DNSSEC Validation of Website Visitors]		[Measuring-DNSSEC-Validation-of-Website-Visitors]
	Mens, J., "Is my Web site being used via a DNSSEC-		Mens, J., "Is my Web site being used via a DNSSEC-
	validator?", July 2012, <http://jpmens.net/2012/07/30/		validator?", July 2012, <http://jpmens.net/2012/07/30/
	is-my-web-site-being-used-via-dnssec-validator/>.		is-my-web-site-being-used-via-dnssec-validator/>.
	[Netalyzr]		[Netalyzr]
	Weaver, N., Kreibich, C., Nechaev, B., and V. Paxson,		Weaver, N., Kreibich, C., Nechaev, B., and V. Paxson,
	"Implications of Netalyzr's DNS Measurements", Securing		"Implications of Netalyzr's DNS Measurements", Securing
	and Trusting Internet Names, SATIN 2011 SATIN 2011,		and Trusting Internet Names, SATIN 2011 SATIN 2011, April
	April 2011, <http://conferences.npl.co.uk/satin/		2011, <http://conferences.npl.co.uk/satin/presentations/
	presentations/satin2011slides-Weaver.pdf>.		satin2011slides-Weaver.pdf>.
	[Unbound Configuration]		[Unbound-Configuration]
	Wijngaards, W., "Unbound: How to Turn Off DNSSEC",		Wijngaards, W., "Unbound: How to Turn Off DNSSEC", June
	June 2010, <http://unbound.net/documentation/		2010, <http://unbound.net/documentation/
	howto_turnoff_dnssec.html>.		howto_turnoff_dnssec.html>.
	Appendix A. Document Change Log		Appendix A. Document Change Log
	[RFC Editor: This section is to be removed before publication]		[RFC Editor: This section is to be removed before publication]
	-00: First version published as an individual draft.		-00: First version published as an individual draft.
	-01: Fixed minor typos and grammatical nits. Closed all open		-01: Fixed minor typos and grammatical nits. Closed all open
	editorial items.		editorial items.
	skipping to change at page 14, line 32 ¶		skipping to change at page 14, line 32 ¶
	the Abstract and Introduction per feedback from Paul Hoffman.		the Abstract and Introduction per feedback from Paul Hoffman.
	-05: Incorporated feedback from the DNSOP WG list received on 2/17/13		-05: Incorporated feedback from the DNSOP WG list received on 2/17/13
	and 2/18/13. This is likely the final version before the IETF 86		and 2/18/13. This is likely the final version before the IETF 86
	draft cutoff date. Updated references to RFC6781 to RFC6781, per		draft cutoff date. Updated references to RFC6781 to RFC6781, per
	March Davids.		March Davids.
	-06: Added more OPEN issues to continue tracking WG discussion. No		-06: Added more OPEN issues to continue tracking WG discussion. No
	changes in the main document - just expanded issue tracking.		changes in the main document - just expanded issue tracking.
			-07: Refresh document - needs revision and rework before IETF-91.
			Planning to add more contributors.
	Appendix B. Open Issues		Appendix B. Open Issues
	[RFC Editor: This section is to be removed before publication]		[RFC Editor: This section is to be removed before publication]
	Determine whether RFC 2119 language should be used or not when		Determine whether RFC 2119 language should be used or not when
	describing things like the duration of a NTA.		describing things like the duration of a NTA.
	Determine whether this is an individual I-D or a DNSOP WG I-D.
	Determine whether this is Informational or a BCP.
	The DNSOP WG should discuss whether a 1 day limit is reasonable,		The DNSOP WG should discuss whether a 1 day limit is reasonable,
	whether a different time (more or less than 1 day, such as 1 hour or		whether a different time (more or less than 1 day, such as 1 hour or
	1 week) should be specified, or whether no time should be specified		1 week) should be specified, or whether no time should be specified
	(just a recommendation that it SHOULD generally be limited to X).		(just a recommendation that it SHOULD generally be limited to X).
	The DNSOP WG should discuss how to assess when critical DNSSEC
	deployment mass has been achieved so that this is no longer a common
	practice.
	Olafur Gudmundsson has suggested that we may want to consider whether		Olafur Gudmundsson has suggested that we may want to consider whether
	a non validatable RRSIG should be returned or not when a NTA is in		a non validatable RRSIG should be returned or not when a NTA is in
	place. This was raised in the context of NLnet Labs' DNSSEC-Trigger,		place. This was raised in the context of NLnet Labs' DNSSEC-Trigger,
	which apparently acts like forwarding stub-validator. He said, "The		which apparently acts like forwarding stub-validator. He said, "The
	reason for this is if NTA strips signatures the stub-validator thinks		reason for this is if NTA strips signatures the stub-validator thinks
	it is under attack and may a) go into recursive mode to try to		it is under attack and may a) go into recursive mode to try to
	resolve the domain, getting to the right answer the long way. b) Give		resolve the domain, getting to the right answer the long way. b) Give
	the wrong error "Missing signatures" instead of the real error. If		the wrong error "Missing signatures" instead of the real error. If
	all the validator does is not to set the AD bit for RRsets at and		all the validator does is not to set the AD bit for RRsets at and
	below the NTA, stub-resolvers (and cascading resolvers) should be		below the NTA, stub-resolvers (and cascading resolvers) should be
	happy."		happy."
	Determine whether an informative reference to X.509 in the		Determine whether an informative reference to X.509 in the
	Introduction is necessary.		Introduction is necessary.
	Is it desirable to say that NTAs should not be distributed across		Is it desirable to say that NTAs should not be distributed across
	organizational boundaries?		organizational boundaries?
	Per Warren Kumari on 2/19/2013, add examples to appendix. "it would		Per Warren Kumari on 2/19/2013, add examples to appendix. "it would
	be very helpful to actually show how this is used, with e.g and		be very helpful to actually show how this is used, with e.g and
	example in an Appendix, for -insert favorite resolver here-. The		example in an Appendix, for -insert favorite resolver here-. The
	document contains a lot of really useful content about why you might		document contains a lot of really useful content about why you might
	use one, how to minimize damage, etc but (IMO) does't do a great job		use one, how to minimize damage, etc but (IMO) does't do a great job
	of explaining how to actually do so". Rick Lamb and Joe Abley also		of explaining how to actually do so". Rick Lamb and Joe Abley also
	agreed on the need for this.		agreed on the need for this.
	Per Rick Lamb on 2/20/2013, "it might be useful to have section 2		Per Rick Lamb on 2/20/2013, "it might be useful to have section 2
	"Definition .." make that clear for slow people like me - that the		"Definition .." make that clear for slow people like me - that the
	NTA is not an RR and is more of a configuration. Maybe simply		NTA is not an RR and is more of a configuration. Maybe simply
	replacing "placed" with "implemented" in section 2? "This NTA can		replacing "placed" with "implemented" in section 2? "This NTA can
	potentially be -placed/implemented- at any level within the chain of		potentially be -placed/implemented- at any level within the chain of
	skipping to change at page 16, line 9 ¶		skipping to change at page 16, line 4 ¶
	by a key not in the DNSKEY RRset, thus it is possible that either		by a key not in the DNSKEY RRset, thus it is possible that either
	human or automated checks may assume there is no problem when there		human or automated checks may assume there is no problem when there
	actually is one. What this is bringing to my mind is maybe you want		actually is one. What this is bringing to my mind is maybe you want
	a new section with guidelines on how to test for failures and in what		a new section with guidelines on how to test for failures and in what
	cases failure justifies NTA and what tests MUST pass before		cases failure justifies NTA and what tests MUST pass before
	preemttive removal of an NTA."		preemttive removal of an NTA."
	Per Olafur Gudmundsson on 2/18/2013, "Also should there be guidance		Per Olafur Gudmundsson on 2/18/2013, "Also should there be guidance
	that removal of NTA should include cleaning the caches of all RRsets		that removal of NTA should include cleaning the caches of all RRsets
	below the name?"		below the name?"
			Reference and text per Ed Lewis: One thing that seems to need
			repeating from time to time is this passage in RFC 4033. ... In the
			final analysis, however, authenticating both DNS keys and data is a
			matter of local policy, which may extend or even override the
			protocol extensions defined in this document set. See Section 5 for
			further discussion. A responsibility (one of many) of a caching
			server operator is to "protect the integrity of the cache." DNSSEC
			is just a tool to help accomplish that. It carries ancillary data
			that a local cache administrator may use to filter out undesired
			responses. DNSSEC is not an enforcement mechanism, it's a resource.
			When I see folks voice opinions that DNSSEC's recommended operation
			has to strictly followed, my gut reaction is that these folks have
			forgotten the purpose of all of our efforts. We don't secure
			protocols to make things work better. We don't operate the DNS
			because we like to run a well run machine. We don't run the Internet
			for the fun of it. (Some might enjoy running it, that's job
			satisfaction to some extent.) At the end of the day all that matters
			is that what is being done benefits society. We run the Internet to
			enrich society. We prefer a well run DNS because it saps less
			resources than a poorly run DNS. We prefer secure protocols so that
			people don't become victims (in some sense of the word). Make it
			work. Do what it takes to make it work. "Local policy" rules.
			Per David Conrad: I'd suggest that in the BCP/RFC/whatever, in
			addition to recommending that NTAs be time capped and not written to
			permanent storage, it should also recommend NTAs be written as
			specifically as possible. (Should be obvious, but doesn't hurt to
			reiterate I suppose).
			Per Ralf Weber: Informing the domain owner on the validation failure.
			There should be a section in the document that the operator deploying
			an NTA has to inform the domain owner of the problem. (JL note:
			would prefer to say operator SHOULD take reasonable steps to notify
			the domain owner, etc.)
	Authors' Addresses		Authors' Addresses
	Jason Livingood		Jason Livingood
	Comcast Cable Communications		Comcast Cable Communications
	One Comcast Center		One Comcast Center
	1701 John F. Kennedy Boulevard		1701 John F. Kennedy Boulevard
	Philadelphia, PA 19103		Philadelphia, PA 19103
	US		US
	skipping to change at page 16, line 21 ¶		skipping to change at page 17, line 4 ¶
	Jason Livingood		Jason Livingood
	Comcast Cable Communications		Comcast Cable Communications
	One Comcast Center		One Comcast Center
	1701 John F. Kennedy Boulevard		1701 John F. Kennedy Boulevard
	Philadelphia, PA 19103		Philadelphia, PA 19103
	US		US
	Email: jason_livingood@cable.comcast.com		Email: jason_livingood@cable.comcast.com
	URI: http://www.comcast.com		URI: http://www.comcast.com
	Chris Griffiths		Chris Griffiths
	Comcast Cable Communications		Dyn
	One Comcast Center
	1701 John F. Kennedy Boulevard
	Philadelphia, PA 19103
	US
	Email: chris_griffiths@cable.comcast.com
	URI: http://www.comcast.com
End of changes. 33 change blocks.
	71 lines changed or deleted		112 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/