< draft-ietf-dnsop-nsec-ttl-00.txt		draft-ietf-dnsop-nsec-ttl-01.txt >
	dnsop P. van Dijk		dnsop P. van Dijk
	Internet-Draft PowerDNS		Internet-Draft PowerDNS
	Updates: 4034, 4035, 5155 (if approved) 13 January 2021		Updates: 4034, 4035, 5155 (if approved) 24 January 2021
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 17 July 2021		Expires: 28 July 2021
	NSEC(3) TTLs and NSEC Aggressive Use		NSEC(3) TTLs and NSEC Aggressive Use
	draft-ietf-dnsop-nsec-ttl-00		draft-ietf-dnsop-nsec-ttl-01
	Abstract		Abstract
	Due to a combination of unfortunate wording in earlier documents,		Due to a combination of unfortunate wording in earlier documents,
	aggressive use of NSEC(3) records may deny names far beyond the		aggressive use of NSEC(3) records may deny names far beyond the
	intended lifetime of a denial. This document changes the definition		intended lifetime of a denial. This document changes the definition
	of the NSEC(3) TTL to correct that situation. This document updates		of the NSEC(3) TTL to correct that situation. This document updates
	RFC 4034, RFC 4035, and RFC 5155.		RFC 4034, RFC 4035, and RFC 5155.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 17 July 2021.		This Internet-Draft will expire on 28 July 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	3.3. Updates to RFC5155 . . . . . . . . . . . . . . . . . . . 4		3.3. Updates to RFC5155 . . . . . . . . . . . . . . . . . . . 4
	3.4. No updates to RFC8198 . . . . . . . . . . . . . . . . . . 5		3.4. No updates to RFC8198 . . . . . . . . . . . . . . . . . . 5
	4. Zone Operator Considerations . . . . . . . . . . . . . . . . 5		4. Zone Operator Considerations . . . . . . . . . . . . . . . . 5
	4.1. A Note On Wildcards . . . . . . . . . . . . . . . . . . . 5		4.1. A Note On Wildcards . . . . . . . . . . . . . . . . . . . 5
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 5		5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	7. Normative References . . . . . . . . . . . . . . . . . . . . 6		7. Normative References . . . . . . . . . . . . . . . . . . . . 6
	8. Informative References . . . . . . . . . . . . . . . . . . . 6		8. Informative References . . . . . . . . . . . . . . . . . . . 6
	Appendix A. Implementation Status . . . . . . . . . . . . . . . 6		Appendix A. Implementation Status . . . . . . . . . . . . . . . 6
	Appendix B. Document history . . . . . . . . . . . . . . . . . . 7		Appendix B. Document history . . . . . . . . . . . . . . . . . . 7
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	[RFC editor: please remove this block before publication.		[RFC editor: please remove this block before publication.
	Earlier notes on this:		Earlier notes on this:
	* https://indico.dns-oarc.net/event/29/sessions/98/#20181013		* https://indico.dns-oarc.net/event/29/sessions/98/#20181013
	(https://indico.dns-oarc.net/event/29/sessions/98/#20181013)		(https://indico.dns-oarc.net/event/29/sessions/98/#20181013)
	skipping to change at page 2, line 50 ¶		skipping to change at page 2, line 50 ¶
	oarc.net/pipermail/dns-operations/2018-March/017416.html)		oarc.net/pipermail/dns-operations/2018-March/017416.html)
	This document lives on GitHub (https://github.com/PowerDNS/draft-		This document lives on GitHub (https://github.com/PowerDNS/draft-
	dnsop-nsec-ttl); proposed text and editorial changes are very much		dnsop-nsec-ttl); proposed text and editorial changes are very much
	welcomed there, but any functional changes should always first be		welcomed there, but any functional changes should always first be
	discussed on the IETF DNSOP WG mailing list.		discussed on the IETF DNSOP WG mailing list.
	]		]
	[RFC2308] defines that the SOA TTL to be used in negative answers		[RFC2308] defines that the SOA TTL to be used in negative answers
	(NXDOMAIN, NoData NOERROR) is		(NXDOMAIN or NODATA) is
	| the minimum of the MINIMUM field of the SOA record and the TTL of		| the minimum of the MINIMUM field of the SOA record and the TTL of
	| the SOA itself		| the SOA itself
	Thus, if the TTL of the SOA in the zone is lower than the SOA MINIMUM		Thus, if the TTL of the SOA in the zone is lower than the SOA MINIMUM
	value (the last number in a SOA record), the negative TTL for that		value (the last number in a SOA record), the negative TTL for that
	zone is lower than the SOA MINIMUM value.		zone is lower than the SOA MINIMUM value.
	However, [RFC4034] section 4 has this unfortunate text:		However, [RFC4034] section 4 has this unfortunate text:
	| The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL		| The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
	skipping to change at page 3, line 37 ¶		skipping to change at page 3, line 37 ¶
	|		|
	| A resolver that supports aggressive use of NSEC and NSEC3 SHOULD		| A resolver that supports aggressive use of NSEC and NSEC3 SHOULD
	| reduce the TTL of NSEC and NSEC3 records to match the SOA.MINIMUM		| reduce the TTL of NSEC and NSEC3 records to match the SOA.MINIMUM
	| field in the authority section of a negative response, if		| field in the authority section of a negative response, if
	| SOA.MINIMUM is smaller.		| SOA.MINIMUM is smaller.
	But the NSEC(3) RRs should, per RFC4034, already be at the MINIMUM		But the NSEC(3) RRs should, per RFC4034, already be at the MINIMUM
	TTL, which means this advice would never actually change the TTL used		TTL, which means this advice would never actually change the TTL used
	for the NSEC(3) RRs.		for the NSEC(3) RRs.
	As a theoretical exercise, consider a TLD ".example" with a SOA like		As a theoretical exercise, consider a TLD named ".example" with a SOA
	this:		record like this:
	"example. 900 IN SOA primary.example. hostmaster.example. 1 1800 900		"example. 900 IN SOA primary.example. hostmaster.example. 1 1800 900
	604800 86400"		604800 86400"
	The SOA record has a 900 second TTL, and a 86400 MINIMUM TTL.		The SOA record has a 900 second TTL, and a 86400 MINIMUM TTL.
	Negative responses from this zone have a 900 second TTL, but the		Negative responses from this zone have a 900 second TTL, but the
	NSEC(3) records in those negative responses have a 86400 TTL. If a		NSEC(3) records in those negative responses have a 86400 TTL. If a
	resolver were to use those NSEC3s aggressively, they would be		resolver were to use those NSEC(3)s aggressively, they would be
	considered valid for a day, instead of the intended 15 minutes.		considered valid for a day, instead of the intended 15 minutes.
	2. Conventions and Definitions		2. Conventions and Definitions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	skipping to change at page 4, line 24 ¶		skipping to change at page 4, line 24 ¶
	3.1. Updates to RFC4034		3.1. Updates to RFC4034
	Where [RFC4034] says:		Where [RFC4034] says:
	| The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL		| The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
	| field. This is in the spirit of negative caching ([RFC2308]).		| field. This is in the spirit of negative caching ([RFC2308]).
	This is updated to say:		This is updated to say:
	| The NSEC RR MUST have the same TTL value as the minimum of the		| The NSEC RR SHOULD have the same TTL value as the lesser of the
	| MINIMUM field of the SOA record and the TTL of the SOA itself.		| MINIMUM field of the SOA record and the TTL of the SOA itself.
	| This matches the definition of the TTL for negative responses in		| This matches the definition of the TTL for negative responses in
	| [RFC2308].		| [RFC2308].
	3.2. Updates to RFC4035		3.2. Updates to RFC4035
	Where [RFC4035] says:		Where [RFC4035] says:
	| The TTL value for any NSEC RR SHOULD be the same as the minimum		| The TTL value for any NSEC RR SHOULD be the same as the minimum
	| TTL value field in the zone SOA RR.		| TTL value field in the zone SOA RR.
	This is updated to say:		This is updated to say:
	| The TTL value for any NSEC RR MUST be the same TTL value as the		| The TTL value for any NSEC RR SHOULD be the same TTL value as the
	| minimum of the MINIMUM field of the SOA record and the TTL of the		| lesser of the MINIMUM field of the SOA record and the TTL of the
	| SOA itself. This matches the definition of the TTL for negative		| SOA itself. This matches the definition of the TTL for negative
	| responses in [RFC2308].		| responses in [RFC2308].
	3.3. Updates to RFC5155		3.3. Updates to RFC5155
	Where [RFC5155] says:		Where [RFC5155] says:
	| The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL		| The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
	| field. This is in the spirit of negative caching [RFC2308].		| field. This is in the spirit of negative caching [RFC2308].
	This is updated to say:		This is updated to say:
	| The NSEC3 RR MUST have the same TTL value as the minimum of the		| The NSEC3 RR SHOULD have the same TTL value as the lesser of the
	| MINIMUM field of the SOA record and the TTL of the SOA itself.		| MINIMUM field of the SOA record and the TTL of the SOA itself.
	| This matches the definition of the TTL for negative responses in		| This matches the definition of the TTL for negative responses in
	| [RFC2308].		| [RFC2308].
	3.4. No updates to RFC8198		3.4. No updates to RFC8198
	Instead of updating four documents, it would have been preferable to		Instead of updating three documents, it would have been preferable to
	update it in one. [RFC8198] says:		update one. [RFC8198] says:
	| With DNSSEC and aggressive use of DNSSEC-validated cache, the TTL		| With DNSSEC and aggressive use of DNSSEC-validated cache, the TTL
	| of the NSEC/NSEC3 record and the SOA.MINIMUM field are the		| of the NSEC/NSEC3 record and the SOA.MINIMUM field are the
	| authoritative statement of how quickly a name can start working		| authoritative statement of how quickly a name can start working
	| within a zone.		| within a zone.
	Here, the SOA.MINIMUM field cannot be changed to "the minimum of the		Here, the SOA.MINIMUM field cannot be changed to "the minimum/lesser
	SOA.MINIMUM field and the SOA TTL" because the resolver may not have		of the SOA.MINIMUM field and the SOA TTL" because the resolver may
	the SOA RRset in cache. Because of that, this document cannot get		not have the SOA RRset in cache. Because of that, this document
	away with updating just [RFC8198]. However, if authoritative servers		cannot get away with updating just [RFC8198]. However, if
	follow the updates from this document, this should not make a		authoritative servers follow the updates from this document, this
	difference, as the TTL of the NSEC/NSEC3 record is already set to the		should not make a difference, as the TTL of the NSEC/NSEC3 record is
	minimum value.		already set to the minimum value.
	4. Zone Operator Considerations		4. Zone Operator Considerations
	If signers & DNS servers for a zone cannot immediately be updated to		If signers & DNS servers for a zone cannot immediately be updated to
	conform to this document, zone operators are encouraged to consider		conform to this document, zone operators are encouraged to consider
	setting their SOA record TTL and the SOA MINIMUM field to the same		setting their SOA record TTL and the SOA MINIMUM field to the same
	value. That way, the TTL used for aggressive NSEC use matches the		value. That way, the TTL used for aggressive NSEC use matches the
	SOA TTL for negative responses.		SOA TTL for negative responses.
	4.1. A Note On Wildcards		4.1. A Note On Wildcards
	skipping to change at page 6, line 13 ¶		skipping to change at page 6, line 13 ¶
	the zone operator intended.		the zone operator intended.
	6. IANA Considerations		6. IANA Considerations
	IANA is requested to add a reference to this document in the		IANA is requested to add a reference to this document in the
	"Resource Record (RR) TYPEs" subregistry of the "Domain Name System		"Resource Record (RR) TYPEs" subregistry of the "Domain Name System
	(DNS) Parameters" registry, for the NSEC and NSEC3 types.		(DNS) Parameters" registry, for the NSEC and NSEC3 types.
	7. Normative References		7. Normative References
	[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
	Security (DNSSEC) Hashed Authenticated Denial of
	Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
	<https://www.rfc-editor.org/info/rfc5155>.
	[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, DOI 10.17487/RFC4035, March 2005,		Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
	<https://www.rfc-editor.org/info/rfc4035>.		<https://www.rfc-editor.org/info/rfc4035>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS		[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
	NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,		NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
	<https://www.rfc-editor.org/info/rfc2308>.		<https://www.rfc-editor.org/info/rfc2308>.
	[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, DOI 10.17487/RFC4034, March 2005,		RFC 4034, DOI 10.17487/RFC4034, March 2005,
	<https://www.rfc-editor.org/info/rfc4034>.		<https://www.rfc-editor.org/info/rfc4034>.
			[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
			Security (DNSSEC) Hashed Authenticated Denial of
			Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
			<https://www.rfc-editor.org/info/rfc5155>.
	8. Informative References		8. Informative References
	[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of		[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
	DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,		DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
	July 2017, <https://www.rfc-editor.org/info/rfc8198>.		July 2017, <https://www.rfc-editor.org/info/rfc8198>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	skipping to change at page 7, line 13 ¶		skipping to change at page 7, line 13 ¶
	[RFC Editor: please remove this section before publication]		[RFC Editor: please remove this section before publication]
	Implemented in PowerDNS Authoritative Server 4.3.0		Implemented in PowerDNS Authoritative Server 4.3.0
	https://doc.powerdns.com/authoritative/dnssec/		https://doc.powerdns.com/authoritative/dnssec/
	operational.html?highlight=ttl#some-notes-on-ttl-usage		operational.html?highlight=ttl#some-notes-on-ttl-usage
	(https://doc.powerdns.com/authoritative/dnssec/		(https://doc.powerdns.com/authoritative/dnssec/
	operational.html?highlight=ttl#some-notes-on-ttl-usage) .		operational.html?highlight=ttl#some-notes-on-ttl-usage) .
	Implemented in BIND 9.16 and up, to be released early 2021		Implemented in BIND 9.16 and up, to be released early 2021
	https://mailarchive.ietf.org/arch/msg/dnsop/ga41J2PPUbmc21--		https://mailarchive.ietf.org/arch/msg/dnsop/ga41J2PPUbmc21--
	dqf3i7_IY6M (https://mailarchive.ietf.org/arch/msg/dnsop/		dqf3i7_IY6M (https://mailarchive.ietf.org/arch/msg/dnsop/
	ga41J2PPUbmc21--dqf3i7_IY6M) .		ga41J2PPUbmc21--dqf3i7_IY6M) https://gitlab.isc.org/isc-projects/
			bind9/-/merge_requests/4506 (https://gitlab.isc.org/isc-projects/
			bind9/-/merge_requests/4506) .
			Implemented in Knot DNS 3.1, to be released in 2021
			https://gitlab.nic.cz/knot/knot-dns/-/merge_requests/1219
			(https://gitlab.nic.cz/knot/knot-dns/-/merge_requests/1219) .
	Appendix B. Document history		Appendix B. Document history
	[RFC editor: please remove this section before publication.]		[RFC editor: please remove this section before publication.]
	From draft-vandijk-dnsop-nsec-ttl-00 to draft-ietf-dnsop-nsec-ttl-00:		From draft-vandijk-dnsop-nsec-ttl-00 to draft-ietf-dnsop-nsec-ttl-00:
	* document was adopted		* document was adopted
	* various minor editorial changes		* various minor editorial changes
	* now also updates 4035		* now also updates 4035
	* use .example instead of .com for the example		* use .example instead of .com for the example
	* more words on 8198		* more words on 8198
	* a note on wildcards		* a note on wildcards
			From draft-ietf-dnsop-nsec-ttl-00 to draft-ietf-dnsop-nsec-ttl-01:
			* various wording improvements
			* added Implementation note from Knot, expanded the BIND one with
			the GitLab MR URL
			* reduced requirement level from MUST to SHOULD, like the original
			texts
	Acknowledgements		Acknowledgements
	Ralph Dolmans helpfully pointed out that fixing this in RFC8198 is		Ralph Dolmans helpfully pointed out that fixing this in RFC8198 is
	only possible for negative (NXDOMAIN/NoData NOERROR) responses, and		only possible for negative (NXDOMAIN/NODATA) responses, and not for
	not for wildcard responses. Warren Kumari gracefully acknowledged		wildcard responses. Warren Kumari gracefully acknowledged that the
	that the current behaviour of RFC8198, in context of the NSEC TTL		current behaviour of RFC8198, in context of the NSEC TTL defined in
	defined in RFC4034, is not the intended behaviour. Matthijs Mekking		RFC4034, is not the intended behaviour. Matthijs Mekking provided
	provided additional text explaining why this document cannot simply		additional text explaining why this document cannot simply update
	update RFC8198. Vladimir Cunat pointed out that the effect wildcards		RFC8198. Vladimir Cunat pointed out that the effect on wildcards
	should be made explicit.		should be made explicit. Paul Hoffman, Matt Nordhoff, and Josh Soref
			provided helpful corrections as native speakers.
	Author's Address		Author's Address
	Peter van Dijk		Peter van Dijk
	PowerDNS		PowerDNS
	Den Haag		Den Haag
	Netherlands		Netherlands
	Email: peter.van.dijk@powerdns.com		Email: peter.van.dijk@powerdns.com
End of changes. 18 change blocks.
	36 lines changed or deleted		53 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/