rfc9199v2.txt		rfc9199.txt
	Independent Submission G. Moura		Independent Submission G. Moura
	Request for Comments: 9199 SIDN Labs/TU Delft		Request for Comments: 9199 SIDN Labs/TU Delft
	Category: Informational W. Hardaker		Category: Informational W. Hardaker
	ISSN: 2070-1721 J. Heidemann		ISSN: 2070-1721 J. Heidemann
	USC/Information Sciences Institute		USC/Information Sciences Institute
	M. Davids		M. Davids
	SIDN Labs		SIDN Labs
	February 2022		March 2022
	Considerations for Large Authoritative DNS Server Operators		Considerations for Large Authoritative DNS Server Operators
	Abstract		Abstract
	Recent research work has explored the deployment characteristics and		Recent research work has explored the deployment characteristics and
	configuration of the Domain Name System (DNS). This document		configuration of the Domain Name System (DNS). This document
	summarizes the conclusions from these research efforts and offers		summarizes the conclusions from these research efforts and offers
	specific, tangible considerations or advice to authoritative DNS		specific, tangible considerations or advice to authoritative DNS
	server operators. Authoritative server operators may wish to follow		server operators. Authoritative server operators may wish to follow
	skipping to change at line 593 ¶		skipping to change at line 593 ¶
	that most resolvers will use the TTL values provided by the child		that most resolvers will use the TTL values provided by the child
	delegations while some others will choose the TTL provided by the		delegations while some others will choose the TTL provided by the
	parent's copy of the record. As such, [Moura19b] recommends		parent's copy of the record. As such, [Moura19b] recommends
	longer TTLs (at least an hour or more) for registry operators as		longer TTLs (at least an hour or more) for registry operators as
	well for child NS and other records.		well for child NS and other records.
	* Users of DNS-based load balancing or DDoS-prevention services may		* Users of DNS-based load balancing or DDoS-prevention services may
	require shorter TTLs: TTLs may even need to be as short as 5		require shorter TTLs: TTLs may even need to be as short as 5
	minutes, although 15 minutes may provide sufficient agility for		minutes, although 15 minutes may provide sufficient agility for
	many operators. There is always a tussle between using shorter		many operators. There is always a tussle between using shorter
	TTLs that provide more agility and using longer TTls that include		TTLs that provide more agility and using longer TTLs that include
	all the benefits listed above.		all the benefits listed above.
	* Regarding the use of A/AAAA and NS records, the TTLs for A/AAAA		* Regarding the use of A/AAAA and NS records, the TTLs for A/AAAA
	records should be shorter than or equal to the TTL for the		records should be shorter than or equal to the TTL for the
	corresponding NS records for in-bailiwick authoritative DNS		corresponding NS records for in-bailiwick authoritative DNS
	servers, since [Moura19b] finds that once an NS record expires,		servers, since [Moura19b] finds that once an NS record expires,
	their associated A/AAAA will also be requeried when glue is		their associated A/AAAA will also be requeried when glue is
	required to be sent by the parents. For out-of-bailiwick servers,		required to be sent by the parents. For out-of-bailiwick servers,
	A, AAAA, and NS records are usually all cached independently, so		A, AAAA, and NS records are usually all cached independently, so
	different TTLs can be used effectively if desired. In either		different TTLs can be used effectively if desired. In either
End of changes. 2 change blocks.
	2 lines changed or deleted		2 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/