< draft-ietf-dnsop-terminology-bis-09.txt		draft-ietf-dnsop-terminology-bis-10.txt >
	Network Working Group P. Hoffman		Network Working Group P. Hoffman
	Internet-Draft ICANN		Internet-Draft ICANN
	Obsoletes: 7719 (if approved) A. Sullivan		Obsoletes: 7719 (if approved) A. Sullivan
	Updates: 2308 (if approved) Oracle		Updates: 2308 (if approved) Oracle
	Intended status: Best Current Practice K. Fujiwara		Intended status: Best Current Practice K. Fujiwara
	Expires: September 6, 2018 JPRS		Expires: October 29, 2018 JPRS
	March 5, 2018		April 27, 2018
	DNS Terminology		DNS Terminology
	draft-ietf-dnsop-terminology-bis-09		draft-ietf-dnsop-terminology-bis-10
	Abstract		Abstract
	The DNS is defined in literally dozens of different RFCs. The		The domain name system (DNS) is defined in literally dozens of
	terminology used by implementers and developers of DNS protocols, and		different RFCs. The terminology used by implementers and developers
	by operators of DNS systems, has sometimes changed in the decades		of DNS protocols, and by operators of DNS systems, has sometimes
	since the DNS was first defined. This document gives current		changed in the decades since the DNS was first defined. This
	definitions for many of the terms used in the DNS in a single		document gives current definitions for many of the terms used in the
	document.		DNS in a single document.
	This document will be the successor to RFC 7719, and thus will		This document will be the successor to RFC 7719, and thus will
	obsolete RFC 7719. It will also update RFC 2308.		obsolete RFC 7719. It will also update RFC 2308.
	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 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 September 6, 2018.		This Internet-Draft will expire on October 29, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. DNS Response Codes . . . . . . . . . . . . . . . . . . . . . 8		3. DNS Response Codes . . . . . . . . . . . . . . . . . . . . . 9
	4. DNS Transactions . . . . . . . . . . . . . . . . . . . . . . 9		4. DNS Transactions . . . . . . . . . . . . . . . . . . . . . . 10
	5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 12		5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 12
	6. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 14		6. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 14
	7. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20		7. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 24		8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	9. Registration Model . . . . . . . . . . . . . . . . . . . . . 25		9. Registration Model . . . . . . . . . . . . . . . . . . . . . 26
	10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 27		10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 28
	11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 31		11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 32
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 33		12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 33		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
	14.1. Normative References . . . . . . . . . . . . . . . . . . 33		14.1. Normative References . . . . . . . . . . . . . . . . . . 34
	14.2. Informative References . . . . . . . . . . . . . . . . . 36		14.2. Informative References . . . . . . . . . . . . . . . . . 37
	Appendix A. Definitions Updated by this Document . . . . . . . . 40		Appendix A. Definitions Updated by this Document . . . . . . . . 41
	Appendix B. Definitions First Defined in this Document . . . . . 40		Appendix B. Definitions First Defined in this Document . . . . . 41
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
	1. Introduction		1. Introduction
	The Domain Name System (DNS) is a simple query-response protocol		The Domain Name System (DNS) is a simple query-response protocol
	whose messages in both directions have the same format. (Section 2		whose messages in both directions have the same format. (Section 2
	gives a definition of "public DNS", which is often what people mean		gives a definition of "public DNS", which is often what people mean
	when they say "the DNS".) The protocol and message format are		when they say "the DNS".) The protocol and message format are
	defined in [RFC1034] and [RFC1035]. These RFCs defined some terms,		defined in [RFC1034] and [RFC1035]. These RFCs defined some terms,
	but later documents defined others. Some of the terms from [RFC1034]		but later documents defined others. Some of the terms from [RFC1034]
	and [RFC1035] now have somewhat different meanings than they did in		and [RFC1035] now have somewhat different meanings than they did in
	skipping to change at page 3, line 27 ¶		skipping to change at page 3, line 27 ¶
	are defined in early DNS RFCs now have definitions that are generally		are defined in early DNS RFCs now have definitions that are generally
	agreed to, but that are different from the original definitions.		agreed to, but that are different from the original definitions.
	Therefore, this document is a substantial revision to [RFC7719].		Therefore, this document is a substantial revision to [RFC7719].
	The terms are organized loosely by topic. Some definitions are for		The terms are organized loosely by topic. Some definitions are for
	new terms for things that are commonly talked about in the DNS		new terms for things that are commonly talked about in the DNS
	community but that never had terms defined for them.		community but that never had terms defined for them.
	Other organizations sometimes define DNS-related terms their own way.		Other organizations sometimes define DNS-related terms their own way.
	For example, the W3C defines "domain" at		For example, the W3C defines "domain" at
	https://specs.webplatform.org/url/webspecs/develop/. The Root Server		<https://url.spec.whatwg.org/>. The Root Server System Advisory
	System Advisory Committee (RSSAC) has a good lexicon [RSSAC026].		Committee (RSSAC) has a good lexicon [RSSAC026].
	Note that there is no single consistent definition of "the DNS". It		Note that there is no single consistent definition of "the DNS". It
	can be considered to be some combination of the following: a commonly		can be considered to be some combination of the following: a commonly
	used naming scheme for objects on the Internet; a distributed		used naming scheme for objects on the Internet; a distributed
	database representing the names and certain properties of these		database representing the names and certain properties of these
	objects; an architecture providing distributed maintenance,		objects; an architecture providing distributed maintenance,
	resilience, and loose coherency for this database; and a simple		resilience, and loose coherency for this database; and a simple
	query-response protocol (as mentioned below) implementing this		query-response protocol (as mentioned below) implementing this
	architecture. Section 2 defines "global DNS" and "private DNS" as a		architecture. Section 2 defines "global DNS" and "private DNS" as a
	way to deal with these differing definitions.		way to deal with these differing definitions.
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 14 ¶
	come from [RFC1034] and [RFC1035], although the term "global DNS"		come from [RFC1034] and [RFC1035], although the term "global DNS"
	has not been defined before now.		has not been defined before now.
	Composition of names -- A name in the global DNS has one or more		Composition of names -- A name in the global DNS has one or more
	labels. The length of each label is between 0 and 63 octets		labels. The length of each label is between 0 and 63 octets
	inclusive. In a fully-qualified domain name, the first label in		inclusive. In a fully-qualified domain name, the first label in
	the ordered list is 0 octets long; it is the only label whose		the ordered list is 0 octets long; it is the only label whose
	length may be 0 octets, and it is called the "root" or "root		length may be 0 octets, and it is called the "root" or "root
	label". A domain name in the global DNS has a maximum total		label". A domain name in the global DNS has a maximum total
	length of 255 octets in the wire format; the root represents one		length of 255 octets in the wire format; the root represents one
	octet for this calculation.		octet for this calculation. (Multicast DNS [RFC6762] allows names
			up to 255 bytes plus a terminating zero byte based on a different
			interpretation of RFC 1035 and what is included in the 255
			octets.)
	Format of names -- Names in the global DNS are domain names.		Format of names -- Names in the global DNS are domain names.
	There are three formats: wire format, presentation format, and		There are three formats: wire format, presentation format, and
	common display.		common display.
	The basic wire format for names in the global DNS is a list of		The basic wire format for names in the global DNS is a list of
	labels ordered by decreasing distance from the root, with the root		labels ordered by decreasing distance from the root, with the root
	label last. Each label is preceded by a length octet. [RFC1035]		label last. Each label is preceded by a length octet. [RFC1035]
	also defines a compression scheme that modifies this format.		also defines a compression scheme that modifies this format.
	skipping to change at page 5, line 43 ¶		skipping to change at page 5, line 46 ¶
	in ASCII.		in ASCII.
	The common display format is used in applications and free text.		The common display format is used in applications and free text.
	It is the same as the presentation format, but showing the root		It is the same as the presentation format, but showing the root
	label and the "." before it is optional and is rarely done. For		label and the "." before it is optional and is rarely done. For
	example, in common display format, a fully-qualified domain name		example, in common display format, a fully-qualified domain name
	with two non-root labels is usually shown as "example.tld" instead		with two non-root labels is usually shown as "example.tld" instead
	of "example.tld.". Names in the common display format are		of "example.tld.". Names in the common display format are
	normally written such that the directionality of the writing		normally written such that the directionality of the writing
	system presents labels by decreasing distance from the root (so,		system presents labels by decreasing distance from the root (so,
	in both English and C the first label in the ordered list is		in both English and C the root or TLD label in the ordered list is
	right-most; but in Arabic it may be left-most, depending on local		right-most; but in Arabic it may be left-most, depending on local
	conventions).		conventions).
	Administration of names -- Administration is specified by		Administration of names -- Administration is specified by
	delegation (see the definition of "delegation" in Section 7).		delegation (see the definition of "delegation" in Section 7).
	Policies for administration of the root zone in the global DNS are		Policies for administration of the root zone in the global DNS are
	determined by the names operational community, which convenes		determined by the names operational community, which convenes
	itself in the Internet Corporation for Assigned Names and Numbers		itself in the Internet Corporation for Assigned Names and Numbers
	(ICANN). The names operational community selects the IANA		(ICANN). The names operational community selects the IANA
	Functions Operator for the global DNS root zone. At the time this		Functions Operator for the global DNS root zone. At the time this
	document is published, that operator is Public Technical		document is published, that operator is Public Technical
	Identifiers (PTI). The name servers that serve the root zone are		Identifiers (PTI). The name servers that serve the root zone are
	provided by independent root operators. Other zones in the global		provided by independent root operators. Other zones in the global
	DNS have their own policies for administration.		DNS have their own policies for administration.
	skipping to change at page 6, line 22 ¶		skipping to change at page 6, line 26 ¶
	zero or more resource records associated with it. There are		zero or more resource records associated with it. There are
	numerous types of resource records with unique data structures		numerous types of resource records with unique data structures
	defined in many different RFCs and in the IANA registry at		defined in many different RFCs and in the IANA registry at
	[IANA_Resource_Registry].		[IANA_Resource_Registry].
	Types of metadata for names -- Any name that is published in the		Types of metadata for names -- Any name that is published in the
	DNS appears as a set of resource records (see the definition of		DNS appears as a set of resource records (see the definition of
	"RRset" in Section 5). Some names do not themselves have data		"RRset" in Section 5). Some names do not themselves have data
	associated with them in the DNS, but "appear" in the DNS anyway		associated with them in the DNS, but "appear" in the DNS anyway
	because they form part of a longer name that does have data		because they form part of a longer name that does have data
	associated with it (see the defintion of "empty non-terminals" in		associated with it (see the definition of "empty non-terminals" in
	Section 7).		Section 7).
	Protocol for getting data from a name -- The protocol described in		Protocol for getting data from a name -- The protocol described in
	[RFC1035].		[RFC1035].
	Context for resolving a name -- The global DNS root zone		Context for resolving a name -- The global DNS root zone
	distributed by PTI.		distributed by PTI.
	Private DNS: Names that use the protocol described in [RFC1035] but		Private DNS: Names that use the protocol described in [RFC1035] but
	that do not rely on the global DNS root zone, or names that are		that do not rely on the global DNS root zone, or names that are
	otherwise not generally available on the Internet but are using		otherwise not generally available on the Internet but are using
	the protocol described in [RFC1035]. A system can use both the		the protocol described in [RFC1035]. A system can use both the
	global DNS and one or more private DNS systems; for example, see		global DNS and one or more private DNS systems; for example, see
	"Split DNS" in Section 6.		"Split DNS" in Section 6.
	Note that domain names that do not appear in the DNS, and that are		Note that domain names that do not appear in the DNS, and that are
	intended never to be looked up using the DNS protocol, are not		intended never to be looked up using the DNS protocol, are not
	part of the global DNS or a private DNS even though they are		part of the global DNS or a private DNS even though they are
	domain names.		domain names.
			Multicast DNS: "Multicast DNS (mDNS) provides the ability to perform
			DNS-like operations on the local link in the absence of any
			conventional Unicast DNS server. In addition, Multicast DNS
			designates a portion of the DNS namespace to be free for local
			use, without the need to pay any annual fee, and without the need
			to set up delegations or otherwise configure a conventional DNS
			server to answer for those names." Quoted from [RFC6762],
			Abstract) Although it uses a compatible wire format, mDNS is
			strictly speaking a different protocol than DNS. Also, where the
			above quote says "a portion of the DNS namespace", it would be
			clearer to say "a portion of the domain name space" The names in
			mDNS are not intended to be looked up in the DNS.
	Locally served DNS zone: A locally served DNS zone is a special case		Locally served DNS zone: A locally served DNS zone is a special case
	of private DNS. Names are resolved using the DNS protocol in a		of private DNS. Names are resolved using the DNS protocol in a
	local context. [RFC6303] defines subdomains of IN-ADDR.ARPA that		local context. [RFC6303] defines subdomains of IN-ADDR.ARPA that
	are locally served zones. Resolution of names through locally		are locally served zones. Resolution of names through locally
	served zones may result in ambiguous results. For example, the		served zones may result in ambiguous results. For example, the
	same name may resolve to different results in different locally		same name may resolve to different results in different locally
	served DNS zone contexts. The context through which a locally		served DNS zone contexts. The context through which a locally
	served zone may be explicit, for example, as defined in [RFC6303],		served zone may be explicit, for example, as defined in [RFC6303],
	or implicit, as defined by local DNS administration and not known		or implicit, as defined by local DNS administration and not known
	to the resolution client.		to the resolution client.
	skipping to change at page 7, line 32 ¶		skipping to change at page 7, line 47 ¶
	"www.example.net"). Such relative names are understood only by		"www.example.net"). Such relative names are understood only by
	context.		context.
	Host name: This term and its equivalent, "hostname", have been		Host name: This term and its equivalent, "hostname", have been
	widely used but are not defined in [RFC1034], [RFC1035],		widely used but are not defined in [RFC1034], [RFC1035],
	[RFC1123], or [RFC2181]. The DNS was originally deployed into the		[RFC1123], or [RFC2181]. The DNS was originally deployed into the
	Host Tables environment as outlined in [RFC0952], and it is likely		Host Tables environment as outlined in [RFC0952], and it is likely
	that the term followed informally from the definition there. Over		that the term followed informally from the definition there. Over
	time, the definition seems to have shifted. "Host name" is often		time, the definition seems to have shifted. "Host name" is often
	meant to be a domain name that follows the rules in Section 3.5 of		meant to be a domain name that follows the rules in Section 3.5 of
	[RFC1034], the "preferred name syntax". Note that any label in a		[RFC1034], the "preferred name syntax" (that is, every character
	domain name can contain any octet value; hostnames are generally		in each label are a letter, a digit, or a hyphen). Note that any
	considered to be domain names where every label follows the rules		label in a domain name can contain any octet value; hostnames are
	in the "preferred name syntax", with the amendment that labels can		generally considered to be domain names where every label follows
	start with ASCII digits (this amendment comes from Section 2.1 of		the rules in the "preferred name syntax", with the amendment that
	[RFC1123]).		labels can start with ASCII digits (this amendment comes from
			Section 2.1 of [RFC1123]).
	People also sometimes use the term hostname to refer to just the		People also sometimes use the term hostname to refer to just the
	first label of an FQDN, such as "printer" in		first label of an FQDN, such as "printer" in
	"printer.admin.example.com". (Sometimes this is formalized in		"printer.admin.example.com". (Sometimes this is formalized in
	configuration in operating systems.) In addition, people		configuration in operating systems.) In addition, people
	sometimes use this term to describe any name that refers to a		sometimes use this term to describe any name that refers to a
	machine, and those might include labels that do not conform to the		machine, and those might include labels that do not conform to the
	"preferred name syntax".		"preferred name syntax".
	TLD: A Top-Level Domain, meaning a zone that is one layer below the		TLD: A Top-Level Domain, meaning a zone that is one layer below the
	skipping to change at page 9, line 15 ¶		skipping to change at page 9, line 32 ¶
	FORMERR: "Format error - The name server was unable to interpret the		FORMERR: "Format error - The name server was unable to interpret the
	query." (Quoted from [RFC1035], Section 4.1.1.)		query." (Quoted from [RFC1035], Section 4.1.1.)
	SERVFAIL: "Server failure - The name server was unable to process		SERVFAIL: "Server failure - The name server was unable to process
	this query due to a problem with the name server." (Quoted from		this query due to a problem with the name server." (Quoted from
	[RFC1035], Section 4.1.1.)		[RFC1035], Section 4.1.1.)
	NXDOMAIN: "Name Error - Meaningful only for responses from an		NXDOMAIN: "Name Error - Meaningful only for responses from an
	authoritative name server, this code signifies that the domain		authoritative name server, this code signifies that the domain
	name referenced in the query does not exist." (Quoted from		name referenced in the query does not exist." (Quoted from
	[RFC1035], Section 4.1.1.)		[RFC1035], Section 4.1.1.) [RFC2308] established NXDOMAIN as a
			synonym for Name Error.
	NOTIMP: "Not Implemented - The name server does not support the		NOTIMP: "Not Implemented - The name server does not support the
	requested kind of query." (Quoted from [RFC1035], Section 4.1.1.)		requested kind of query." (Quoted from [RFC1035], Section 4.1.1.)
	REFUSED: "Refused - The name server refuses to perform the specified		REFUSED: "Refused - The name server refuses to perform the specified
	operation for policy reasons. For example, a name server may not		operation for policy reasons. For example, a name server may not
	wish to provide the information to the particular requester, or a		wish to provide the information to the particular requester, or a
	name server may not wish to perform a particular operation (e.g.,		name server may not wish to perform a particular operation (e.g.,
	zone transfer) for particular data." (Quoted from [RFC1035],		zone transfer) for particular data." (Quoted from [RFC1035],
	Section 4.1.1.)		Section 4.1.1.)
	skipping to change at page 11, line 6 ¶		skipping to change at page 11, line 24 ¶
	Question Section one QNAME (the name in the original query), and a		Question Section one QNAME (the name in the original query), and a
	second QNAME that is in the data field of the last CNAME. The		second QNAME that is in the data field of the last CNAME. The
	confusion comes from the iterative/recursive mode of resolution,		confusion comes from the iterative/recursive mode of resolution,
	which finally returns an answer that need not actually have the		which finally returns an answer that need not actually have the
	same owner name as the QNAME contained in the original query.		same owner name as the QNAME contained in the original query.
	To address this potential confusion, it is helpful to distinguish		To address this potential confusion, it is helpful to distinguish
	between three meanings:		between three meanings:
	* QNAME (original): The name actually sent in the Question		* QNAME (original): The name actually sent in the Question
	Section in the orignal query, which is always echoed in the		Section in the original query, which is always echoed in the
	(final) reply in the Question Section when the QR bit is set to		(final) reply in the Question Section when the QR bit is set to
	1.		1.
	* QNAME (effective): A name actually resolved, which is either		* QNAME (effective): A name actually resolved, which is either
	the name originally queried, or a name received in a CNAME		the name originally queried, or a name received in a CNAME
	chain response.		chain response.
	* QNAME (final): The name actually resolved, which is either the		* QNAME (final): The name actually resolved, which is either the
	name actually queried or else the last name in a CNAME chain		name actually queried or else the last name in a CNAME chain
	response.		response.
	Note that, because the definition in [RFC2308] is actually for a		Note that, because the definition in [RFC2308] is actually for a
	different concept than what was in [RFC1034], it would have be		different concept than what was in [RFC1034], it would have be
	better if [RFC2308] had used a different name for that concept.		better if [RFC2308] had used a different name for that concept.
	In general use today, QNAME almost always means what is defined		In general use today, QNAME almost always means what is defined
	above as "QNAME (original)".		above as "QNAME (original)".
	Referrals: A type of response in which a server, signalling that it		Referrals: A type of response in which a server, signaling that it
	is not (completely) authoritative for an answer, provides the		is not (completely) authoritative for an answer, provides the
	querying resolver with an alternative place to send its query.		querying resolver with an alternative place to send its query.
	Referrals can be partial.		Referrals can be partial.
	A referral arises when a server is not performing recursive		A referral arises when a server is not performing recursive
	service while answering a query. It appears in step 3(b) of the		service while answering a query. It appears in step 3(b) of the
	algorithm in [RFC1034], Section 4.3.2.		algorithm in [RFC1034], Section 4.3.2.
	There are two types of referral response. The first is a downward		There are two types of referral response. The first is a downward
	referral (sometimes described as "delegation response"), where the		referral (sometimes described as "delegation response"), where the
	skipping to change at page 12, line 31 ¶		skipping to change at page 12, line 52 ¶
	5. Resource Records		5. Resource Records
	RR: An acronym for resource record. ([RFC1034], Section 3.6.)		RR: An acronym for resource record. ([RFC1034], Section 3.6.)
	RRset: A set of resource records with the same label, class and		RRset: A set of resource records with the same label, class and
	type, but with different data. (Definition from [RFC2181]) Also		type, but with different data. (Definition from [RFC2181]) Also
	spelled RRSet in some documents. As a clarification, "same label"		spelled RRSet in some documents. As a clarification, "same label"
	in this definition means "same owner name". In addition,		in this definition means "same owner name". In addition,
	[RFC2181] states that "the TTLs of all RRs in an RRSet must be the		[RFC2181] states that "the TTLs of all RRs in an RRSet must be the
	same". (This definition is definitely not the same as "the		same".
	response one gets to a query for QTYPE=ANY", which is an
	unfortunate misunderstanding.)		Note that RRSIG resource records do not match this definition.
			[RFC4035] says: "An RRset MAY have multiple RRSIG RRs associated
			with it. Note that as RRSIG RRs are closely tied to the RRsets
			whose signatures they contain, RRSIG RRs, unlike all other DNS RR
			types, do not form RRsets. In particular, the TTL values among
			RRSIG RRs with a common owner name do not follow the RRset rules
			described in [RFC2181]."
	Master file: "Master files are text files that contain RRs in text		Master file: "Master files are text files that contain RRs in text
	form. Since the contents of a zone can be expressed in the form		form. Since the contents of a zone can be expressed in the form
	of a list of RRs a master file is most often used to define a		of a list of RRs a master file is most often used to define a
	zone, though it can be used to list a cache's contents."		zone, though it can be used to list a cache's contents."
	([RFC1035], Section 5.) Master files are sometimes called "zone		([RFC1035], Section 5.) Master files are sometimes called "zone
	files".		files".
	Presentation format: The text format used in master files. This		Presentation format: The text format used in master files. This
	format is shown but not formally defined in [RFC1034] and		format is shown but not formally defined in [RFC1034] and
	skipping to change at page 14, line 14 ¶		skipping to change at page 14, line 39 ¶
	There is also the concept of a "default TTL" for a zone, which can		There is also the concept of a "default TTL" for a zone, which can
	be a configuration parameter in the server software. This is		be a configuration parameter in the server software. This is
	often expressed by a default for the entire server, and a default		often expressed by a default for the entire server, and a default
	for a zone using the $TTL directive in a zone file. The $TTL		for a zone using the $TTL directive in a zone file. The $TTL
	directive was added to the master file format by [RFC2308].		directive was added to the master file format by [RFC2308].
	Class independent: A resource record type whose syntax and semantics		Class independent: A resource record type whose syntax and semantics
	are the same for every DNS class. A resource record type that is		are the same for every DNS class. A resource record type that is
	not class independent has different meanings depending on the DNS		not class independent has different meanings depending on the DNS
	class of the record, or the meaning is undefined for classes other		class of the record, or the meaning is undefined for some class.
	than IN (class 1, the Internet).		Most resorece record types are defined for class 1 (IN, the
			Internet), but many are undefined for other classes.
	Address records: Records whose type is A or AAAA. [RFC2181]		Address records: Records whose type is A or AAAA. [RFC2181]
	informally defines these as "(A, AAAA, etc)". Note that new types		informally defines these as "(A, AAAA, etc)". Note that new types
	of address records could be defined in the future.		of address records could be defined in the future.
	6. DNS Servers and Clients		6. DNS Servers and Clients
	This section defines the terms used for the systems that act as DNS		This section defines the terms used for the systems that act as DNS
	clients, DNS servers, or both. In the RFCs, DNS servers are		clients, DNS servers, or both. In the RFCs, DNS servers are
	sometimes called "name servers", "nameservers", or just "servers".		sometimes called "name servers", "nameservers", or just "servers".
	skipping to change at page 14, line 26 ¶		skipping to change at page 15, line 4 ¶
	Address records: Records whose type is A or AAAA. [RFC2181]		Address records: Records whose type is A or AAAA. [RFC2181]
	informally defines these as "(A, AAAA, etc)". Note that new types		informally defines these as "(A, AAAA, etc)". Note that new types
	of address records could be defined in the future.		of address records could be defined in the future.
	6. DNS Servers and Clients		6. DNS Servers and Clients
	This section defines the terms used for the systems that act as DNS		This section defines the terms used for the systems that act as DNS
	clients, DNS servers, or both. In the RFCs, DNS servers are		clients, DNS servers, or both. In the RFCs, DNS servers are
	sometimes called "name servers", "nameservers", or just "servers".		sometimes called "name servers", "nameservers", or just "servers".
	There is no formal definition of DNS server, but the RFCs generally		There is no formal definition of DNS server, but the RFCs generally
	assume that it is an Internet server that listens for queries and		assume that it is an Internet server that listens for queries and
	sends responses using the DNS protocol defined in [RFC1035] and its		sends responses using the DNS protocol defined in [RFC1035] and its
	successors.		successors.
			It is important to note that the terms "DNS server" and "name server"
			require context in order to understand the services being provided.
			Both authoritative servers and recursive resolvers are often called
			"DNS servers" and "name servers" even though they serve different
			roles (and may be part of the same software package).
	For terminology specific to the public DNS root server system, see		For terminology specific to the public DNS root server system, see
	[RSSAC026]. That document defines terms such as "root server", "root		[RSSAC026]. That document defines terms such as "root server", "root
	server operator", and terms that are specific to the way that the		server operator", and terms that are specific to the way that the
	root zone of the public DNS is served.		root zone of the public DNS is served.
	Resolver: A program "that extract[s] information from name servers		Resolver: A program "that extract[s] information from name servers
	in response to client requests." (Quoted from [RFC1034],		in response to client requests." (Quoted from [RFC1034],
	Section 2.4) "The resolver is located on the same machine as the		Section 2.4) "The resolver is located on the same machine as the
	program that requests the resolver's services, but it may need to		program that requests the resolver's services, but it may need to
	consult name servers on other hosts." (Quoted from [RFC1034],		consult name servers on other hosts." (Quoted from [RFC1034],
	skipping to change at page 15, line 24 ¶		skipping to change at page 16, line 10 ¶
	client to another server and lets the client pursue the query". A		client to another server and lets the client pursue the query". A
	resolver that works in iterative mode is sometimes called an		resolver that works in iterative mode is sometimes called an
	"iterative resolver". See also "iterative resolution" later in		"iterative resolver". See also "iterative resolution" later in
	this section.		this section.
	Recursive mode: A resolution mode of a server that receives DNS		Recursive mode: A resolution mode of a server that receives DNS
	queries and either responds to those queries from a local cache or		queries and either responds to those queries from a local cache or
	sends queries to other servers in order to get the final answers		sends queries to other servers in order to get the final answers
	to the original queries. Section 2.3 of [RFC1034] describes this		to the original queries. Section 2.3 of [RFC1034] describes this
	as "The first server pursues the query for the client at another		as "The first server pursues the query for the client at another
	server". A server operating in recursive mode may be thought of		server". Section 4.3.1 of of [RFC1034] says "in \[recursive\]
	as having a name server side (which is what answers the query) and		mode the name server acts in the role of a resolver and returns
	a resolver side (which performs the resolution function). Systems		either an error or the answer, but never referrals." That same
	operating in this mode are commonly called "recursive servers".		section also says "The recursive mode occurs when a query with RD
	Sometimes they are called "recursive resolvers". While strictly		set arrives at a server which is willing to provide recursive
	the difference between these is that one of them sends queries to		service; the client can verify that recursive mode was used by
			checking that both RA and RD are set in the reply."
			A server operating in recursive mode may be thought of as having a
			name server side (which is what answers the query) and a resolver
			side (which performs the resolution function). Systems operating
			in this mode are commonly called "recursive servers". Sometimes
			they are called "recursive resolvers". While strictly the
			difference between these is that one of them sends queries to
	another recursive server and the other does not, in practice it is		another recursive server and the other does not, in practice it is
	not possible to know in advance whether the server that one is		not possible to know in advance whether the server that one is
	querying will also perform recursion; both terms can be observed		querying will also perform recursion; both terms can be observed
	in use interchangeably.		in use interchangeably.
	Full resolver: This term is used in [RFC1035], but it is not defined
	there. RFC 1123 defines a "full-service resolver" that may or may
	not be what was intended by "full resolver" in [RFC1035]. This
	term is not properly defined in any RFC.
	Full-service resolver: Section 6.1.3.1 of [RFC1123] defines this
	term to mean a resolver that acts in recursive mode with a cache
	(and meets other requirements).
	Recursive resolver: A resolver that acts in recursive mode. In		Recursive resolver: A resolver that acts in recursive mode. In
	general, a recursive resolver is expected to cache the answers it		general, a recursive resolver is expected to cache the answers it
	receives (which would make it a full-service resolver), but some		receives (which would make it a full-service resolver), but some
	recursive resolvers might not cache.		recursive resolvers might not cache.
			[RFC4697] tried to differentiate between a recursive resolver and
			an iterative resolver.
	Recursive query: A query with the Recursion Desired (RD) bit set to		Recursive query: A query with the Recursion Desired (RD) bit set to
	1 in the header.(See Section 4.1.1 of [RFC1035].) If recursive		1 in the header. (See Section 4.1.1 of [RFC1035].) If recursive
	service is available and is requested by the RD bit in the query,		service is available and is requested by the RD bit in the query,
	the server uses its resolver to answer the query. (See		the server uses its resolver to answer the query. (See
	Section 4.3.2 of [RFC1035].)		Section 4.3.2 of [RFC1035].)
	Non-recursive query: A query with the Recursion Desired (RD) bit set		Non-recursive query: A query with the Recursion Desired (RD) bit set
	to 0 in the header. A server can answer non-recursive queries		to 0 in the header. A server can answer non-recursive queries
	using only local information: the response contains either an		using only local information: the response contains either an
	error, the answer, or a referral to some other server "closer" to		error, the answer, or a referral to some other server "closer" to
	the answer. (See Section 4.3.1 of [RFC1035].)		the answer. (See Section 4.3.1 of [RFC1035].)
	Iterative query: Synonym for non-recursive query that happens to be
	a query in a series of recursive queries, but that is itself not a
	recursive query. This term is used in a number of RFCs though
	never explicitly defined.
	Iterative resolution: A name server may be presented with a query		Iterative resolution: A name server may be presented with a query
	that can only be answered by some other server. The two general		that can only be answered by some other server. The two general
	approaches to dealing with this problem are "recursive", in which		approaches to dealing with this problem are "recursive", in which
	the first server pursues the query for the client at another		the first server pursues the query on behalf of the client at
	server, and "iterative", in which the server refers the client to		another server, and "iterative", in which the server refers the
	another server and lets the client pursue the query there. (See		client to another server and lets the client pursue the query
	Section 2.3 of [RFC1034].)		there. (See Section 2.3 of [RFC1034].)
	In iterative resolution, the client repeatedly makes non-recursive		In iterative resolution, the client repeatedly makes non-recursive
	queries and follows referrals and/or aliases. The iterative		queries and follows referrals and/or aliases. The iterative
	resolution algorithm is described in Section 5.3.3 of [RFC1034].		resolution algorithm is described in Section 5.3.3 of [RFC1034].
			Full resolver: This term is used in [RFC1035], but it is not defined
			there. RFC 1123 defines a "full-service resolver" that may or may
			not be what was intended by "full resolver" in [RFC1035]. This
			term is not properly defined in any RFC.
			Full-service resolver: Section 6.1.3.1 of [RFC1123] defines this
			term to mean a resolver that acts in recursive mode with a cache
			(and meets other requirements).
	Priming: "The act of finding the list of root servers from a		Priming: "The act of finding the list of root servers from a
	configuration that lists some or all of the purported IP addresses		configuration that lists some or all of the purported IP addresses
	of some or all of those root servers." (Quoted from [RFC8109],		of some or all of those root servers." (Quoted from [RFC8109],
	Section 2.) In order to operate in recursive mode, a resolver		Section 2.) In order to operate in recursive mode, a resolver
	needs to know the address of at least one root server. Priming is		needs to know the address of at least one root server. Priming is
	most often done from a configuration setting that contains a list		most often done from a configuration setting that contains a list
	of authoritative servers for the root zone.		of authoritative servers for the root zone.
	Root hints: "Operators who manage a DNS recursive resolver typically		Root hints: "Operators who manage a DNS recursive resolver typically
	need to configure a 'root hints file'. This file contains the		need to configure a 'root hints file'. This file contains the
	skipping to change at page 18, line 30 ¶		skipping to change at page 19, line 21 ¶
	Stealth server: This is "like a slave server except not listed in an		Stealth server: This is "like a slave server except not listed in an
	NS RR for the zone." (Quoted from [RFC1996], Section 2.1)		NS RR for the zone." (Quoted from [RFC1996], Section 2.1)
	Hidden master: A stealth server that is a primary server for zone		Hidden master: A stealth server that is a primary server for zone
	transfers. "In this arrangement, the master name server that		transfers. "In this arrangement, the master name server that
	processes the updates is unavailable to general hosts on the		processes the updates is unavailable to general hosts on the
	Internet; it is not listed in the NS RRset." (Quoted from		Internet; it is not listed in the NS RRset." (Quoted from
	[RFC6781], Section 3.4.3). An earlier RFC, [RFC4641], said that		[RFC6781], Section 3.4.3). An earlier RFC, [RFC4641], said that
	the hidden master's name "appears in the SOA RRs MNAME field",		the hidden master's name "appears in the SOA RRs MNAME field",
	although in some setups, the name does not appear at all in the		although in some setups, the name does not appear at all in the
	public DNS. A hidden master can also be a secondary server		public DNS. A hidden master can also be a secondary server for
	itself.		the zone itself.
	Forwarding: The process of one server sending a DNS query with the		Forwarding: The process of one server sending a DNS query with the
	RD bit set to 1 to another server to resolve that query.		RD bit set to 1 to another server to resolve that query.
	Forwarding is a function of a DNS resolver; it is different than		Forwarding is a function of a DNS resolver; it is different than
	simply blindly relaying queries.		simply blindly relaying queries.
	[RFC5625] does not give a specific definition for forwarding, but		[RFC5625] does not give a specific definition for forwarding, but
	describes in detail what features a system that forwards needs to		describes in detail what features a system that forwards needs to
	support. Systems that forward are sometimes called "DNS proxies",		support. Systems that forward are sometimes called "DNS proxies",
	but that term has not yet been defined (even in [RFC5625]).		but that term has not yet been defined (even in [RFC5625]).
	skipping to change at page 19, line 24 ¶		skipping to change at page 20, line 15 ¶
	of the stub resolver being informed.		of the stub resolver being informed.
	Open resolver: A full-service resolver that accepts and processes		Open resolver: A full-service resolver that accepts and processes
	queries from any (or nearly any) stub resolver. This is sometimes		queries from any (or nearly any) stub resolver. This is sometimes
	also called a "public resolver", although the term "public		also called a "public resolver", although the term "public
	resolver" is used more with open resolvers that are meant to be		resolver" is used more with open resolvers that are meant to be
	open, as compared to the vast majority of open resolvers that are		open, as compared to the vast majority of open resolvers that are
	probably misconfigured to be open. Open resolvers are discussed		probably misconfigured to be open. Open resolvers are discussed
	in [RFC5358]		in [RFC5358]
			Split DNS: The terms "split DNS" and "split-horizon DNS" have long
			been used in the DNS community without formal definition. In
			general, they refer to situations in which DNS servers that are
			authoritative for a particular set of domains provide partly or
			completely different answers in those domains depending on the
			source of the query. The effect of this is that a domain name
			that is notionally globally unique nevertheless has different
			meanings for different network users. This can sometimes be the
			result of a "view" configuration, described below.
			[RFC2775], Section 3.8 gives a related definition that is too
			specific to be generally useful.
	View: A configuration for a DNS server that allows it to provide		View: A configuration for a DNS server that allows it to provide
	different answers depending on attributes of the query.		different answers depending on attributes of the query, such as
	Typically, views differ by the source IP address of a query, but		for "split DNS". Typically, views differ by the source IP address
	can also be based on the destination IP address, the type of query		of a query, but can also be based on the destination IP address,
	(such as AXFR), whether it is recursive, and so on. Views are		the type of query (such as AXFR), whether it is recursive, and so
	often used to provide more names or different addresses to queries		on. Views are often used to provide more names or different
	from "inside" a protected network than to those "outside" that		addresses to queries from "inside" a protected network than to
	network. Views are not a standardized part of the DNS, but they		those "outside" that network. Views are not a standardized part
	are widely implemented in server software.		of the DNS, but they are widely implemented in server software.
	Passive DNS: A mechanism to collect DNS data by storing DNS		Passive DNS: A mechanism to collect DNS data by storing DNS
	responses from name servers. Some of these systems also collect		responses from name servers. Some of these systems also collect
	the DNS queries associated with the responses, although doing so		the DNS queries associated with the responses, although doing so
	raises some privacy concerns. Passive DNS databases can be used		raises some privacy concerns. Passive DNS databases can be used
	to answer historical questions about DNS zones such as which		to answer historical questions about DNS zones such as which
	values were present at a given time in the past, or when a name		values were present at a given time in the past, or when a name
	was spotted first. Passive DNS databases allow searching of the		was spotted first. Passive DNS databases allow searching of the
	stored records on keys other than just the name and type, such as		stored records on keys other than just the name and type, such as
	"find all names which have A records of a particular value".		"find all names which have A records of a particular value".
	Anycast: "The practice of making a particular service address		Anycast: "The practice of making a particular service address
	available in multiple, discrete, autonomous locations, such that		available in multiple, discrete, autonomous locations, such that
	datagrams sent are routed to one of several available locations."		datagrams sent are routed to one of several available locations."
	(Quoted from [RFC4786], Section 2)		(Quoted from [RFC4786], Section 2) See [RFC4786] for more detail
			on Anycast and other terms that are specific to its use.
	Instance: "When anycast routing is used to allow more than one		Instance: "When anycast routing is used to allow more than one
	server to have the same IP address, each one of those servers is		server to have the same IP address, each one of those servers is
	commonly referred to as an 'instance'." "An instance of a server,		commonly referred to as an 'instance'." "An instance of a server,
	such as a root server, is often referred to as an 'Anycast		such as a root server, is often referred to as an 'Anycast
	instance'." (Quoted from [RSSAC026])		instance'." (Quoted from [RSSAC026])
	Split DNS: "Where a corporate network serves up partly or completely		Privacy-enabling DNS server: "A DNS server that implements DNS over
	different DNS inside and outside its firewall. There are many		TLS [RFC7858] and may optionally implement DNS over DTLS
	possible variants on this; the basic point is that the		[RFC8094]." (Quoted from [RFC8310], Section 2)
	correspondence between a given FQDN (fully qualified domain name)
	and a given IPv4 address is no longer universal and stable over
	long periods." (Quoted from [RFC2775], Section 3.8)
	7. Zones		7. Zones
	This section defines terms that are used when discussing zones that		This section defines terms that are used when discussing zones that
	are being served or retrieved.		are being served or retrieved.
	Zone: "Authoritative information is organized into units called		Zone: "Authoritative information is organized into units called
	'zones', and these zones can be automatically distributed to the		'zones', and these zones can be automatically distributed to the
	name servers which provide redundant service for the data in a		name servers which provide redundant service for the data in a
	zone." (Quoted from [RFC1034], Section 2.4)		zone." (Quoted from [RFC1034], Section 2.4)
	skipping to change at page 21, line 21 ¶		skipping to change at page 22, line 23 ¶
	distinction is not always maintained in use, however, and one can		distinction is not always maintained in use, however, and one can
	find uses that conflict subtly with this definition. [RFC1034]		find uses that conflict subtly with this definition. [RFC1034]
	uses the term "top node of the zone" as a synonym of "apex", but		uses the term "top node of the zone" as a synonym of "apex", but
	that term is not widely used. These days, the first sense of		that term is not widely used. These days, the first sense of
	"origin" (above) and "apex" are often used interchangeably.		"origin" (above) and "apex" are often used interchangeably.
	Zone cut: The delimitation point between two zones where the origin		Zone cut: The delimitation point between two zones where the origin
	of one of the zones is the child of the other zone.		of one of the zones is the child of the other zone.
	"Zones are delimited by 'zone cuts'. Each zone cut separates a		"Zones are delimited by 'zone cuts'. Each zone cut separates a
	'child' zone (below the cut) from a 'parent' zone (above the cut).		'child' zone (below the cut) from a 'parent' zone (above the
	(Quoted from [RFC2181], Section 6; note that this is barely an		cut)." (Quoted from [RFC2181], Section 6; note that this is
	ostensive definition.) Section 4.2 of [RFC1034] uses "cuts" as		barely an ostensive definition.) Section 4.2 of [RFC1034] uses
	'zone cut'."		"cuts" instead of "zone cut".
	Delegation: The process by which a separate zone is created in the		Delegation: The process by which a separate zone is created in the
	name space beneath the apex of a given domain. Delegation happens		name space beneath the apex of a given domain. Delegation happens
	when an NS RRset is added in the parent zone for the child origin.		when an NS RRset is added in the parent zone for the child origin.
	Delegation inherently happens at a zone cut. The term is also		Delegation inherently happens at a zone cut. The term is also
	commonly a noun: the new zone that is created by the act of		commonly a noun: the new zone that is created by the act of
	delegating.		delegating.
	Authoritative data: "All of the RRs attached to all of the nodes		Authoritative data: "All of the RRs attached to all of the nodes
	from the top node of the zone down to leaf nodes or nodes above		from the top node of the zone down to leaf nodes or nodes above
	cuts around the bottom edge of the zone." (Quoted from [RFC1034],		cuts around the bottom edge of the zone." (Quoted from [RFC1034],
	Section 4.2.1) It is noted that this definition might		Section 4.2.1) Note that this definition might inadvertently also
	inadvertently also include any NS records that appear in the zone,		cause any NS records that appear in the zone to be included, even
	even those that might not truly be authoritative because there are		those that might not truly be authoritative because there are
	identical NS RRs below the zone cut. This reveals the ambiguity		identical NS RRs below the zone cut. This reveals the ambiguity
	in the notion of authoritative data, because the parent-side NS		in the notion of authoritative data, because the parent-side NS
	records authoritatively indicate the delegation, even though they		records authoritatively indicate the delegation, even though they
	are not themselves authoritative data.		are not themselves authoritative data.
	Lame delegation: "A lame delegations exists when a nameserver is		Lame delegation: "A lame delegations exists when a nameserver is
	delegated responsibility for providing nameservice for a zone (via		delegated responsibility for providing nameservice for a zone (via
	NS records) but is not performing nameservice for that zone		NS records) but is not performing nameservice for that zone
	(usually because it is not set up as a primary or secondary for		(usually because it is not set up as a primary or secondary for
	the zone)." (Definition from [RFC1912], Section 2.8)		the zone)." (Definition from [RFC1912], Section 2.8)
	skipping to change at page 22, line 22 ¶		skipping to change at page 23, line 26 ¶
	file that is not properly part of that zone, including nameserver		file that is not properly part of that zone, including nameserver
	records of delegated sub-zones (NS records), address records that		records of delegated sub-zones (NS records), address records that
	accompany those NS records (A, AAAA, etc), and any other stray		accompany those NS records (A, AAAA, etc), and any other stray
	data that might appear" ([RFC2181], Section 5.4.1). Although glue		data that might appear" ([RFC2181], Section 5.4.1). Although glue
	is sometimes used today with this wider definition in mind, the		is sometimes used today with this wider definition in mind, the
	context surrounding the [RFC2181] definition suggests it is		context surrounding the [RFC2181] definition suggests it is
	intended to apply to the use of glue within the document itself		intended to apply to the use of glue within the document itself
	and not necessarily beyond.		and not necessarily beyond.
	Bailiwick: "In-bailiwick" is an adjective to describe a name server		Bailiwick: "In-bailiwick" is an adjective to describe a name server
	whose name is either subordinate to or (rarely) the same as the		whose name is either a subdomain of or (rarely) the same as the
	origin of the zone that contains the delegation to the name		origin of the zone that contains the delegation to the name
	server. In-bailiwick name servers may have glue records in their		server. In-bailiwick name servers may have glue records in their
	parent zone (using the first of the definitions of "glue records"		parent zone (using the first of the definitions of "glue records"
	in the definition above). (The term "bailiwick" means the		in the definition above). (The term "bailiwick" means the
	district or territory where a bailiff or policeman has		district or territory where a bailiff or policeman has
	jusrisdiction.)		jurisdiction.)
	"In-bailiwick" names are divided into two type of name server		"In-bailiwick" names are divided into two type of name server
	names: "in-domain" names and "sibling domain" names.		names: "in-domain" names and "sibling domain" names.
	* In-domain: an adjective to describe a name server whose name is		* In-domain: an adjective to describe a name server whose name is
	either subordinate to or (rarely) the same as the owner name of		either subordinate to or (rarely) the same as the owner name of
	the NS resource records. An in-domain name server name MUST		the NS resource records. An in-domain name server name MUST
	have glue records or name resolution fails. For example, a		have glue records or name resolution fails. For example, a
	delegation for "child.example.com" may have "in-domain" name		delegation for "child.example.com" may have "in-domain" name
	server name "ns.child.example.com".		server name "ns.child.example.com".
	skipping to change at page 23, line 46 ¶		skipping to change at page 24, line 50 ¶
	still part of the zone, but not available to the lookup process.		still part of the zone, but not available to the lookup process.
	The addition of a DNAME resource record has the same impact. The		The addition of a DNAME resource record has the same impact. The
	subordinate names are said to be 'occluded'." (Quoted from		subordinate names are said to be 'occluded'." (Quoted from
	[RFC5936], Section 3.5)		[RFC5936], Section 3.5)
	Fast flux DNS: This "occurs when a domain is found in DNS using A		Fast flux DNS: This "occurs when a domain is found in DNS using A
	records to multiple IP addresses, each of which has a very short		records to multiple IP addresses, each of which has a very short
	Time-to-Live (TTL) value associated with it. This means that the		Time-to-Live (TTL) value associated with it. This means that the
	domain resolves to varying IP addresses over a short period of		domain resolves to varying IP addresses over a short period of
	time." (Quoted from [RFC6561], Section 1.1.5, with typo		time." (Quoted from [RFC6561], Section 1.1.5, with typo
	corrected) It is often used to deliver malware. Because the		corrected) In addition to having legitimate uses, fast flux DNS
	addresses change so rapidly, it is difficult to ascertain all the		can used to deliver malware. Because the addresses change so
	hosts. It should be noted that the technique also works with AAAA		rapidly, it is difficult to ascertain all the hosts. It should be
	records, but such use is not frequently observed on the Internet		noted that the technique also works with AAAA records, but such
	as of this writing.		use is not frequently observed on the Internet as of this writing.
	Reverse DNS, reverse lookup: "The process of mapping an address to a		Reverse DNS, reverse lookup: "The process of mapping an address to a
	name is generally known as a 'reverse lookup', and the IN-		name is generally known as a 'reverse lookup', and the IN-
	ADDR.ARPA and IP6.ARPA zones are said to support the 'reverse		ADDR.ARPA and IP6.ARPA zones are said to support the 'reverse
	DNS'." (Quoted from [RFC5855], Section 1)		DNS'." (Quoted from [RFC5855], Section 1)
	Forward lookup: "Hostname-to-address translation". (Quoted from		Forward lookup: "Hostname-to-address translation". (Quoted from
	[RFC2133], Section 6)		[RFC2133], Section 6)
	arpa: Address and Routing Parameter Area Domain: "The 'arpa' domain		arpa: Address and Routing Parameter Area Domain: "The 'arpa' domain
	was originally established as part of the initial deployment of		was originally established as part of the initial deployment of
	the DNS, to provide a transition mechanism from the Host Tables		the DNS, to provide a transition mechanism from the Host Tables
	that were common in the ARPANET, as well as a home for the IPv4		that were common in the ARPANET, as well as a home for the IPv4
	reverse mapping domain. During 2000, the abbreviation was		reverse mapping domain. During 2000, the abbreviation was
	redesignated to 'Address and Routing Parameter Area' in the hope		redesignated to 'Address and Routing Parameter Area' in the hope
	of reducing confusion with the earlier network name." (Quoted		of reducing confusion with the earlier network name." (Quoted
	from [RFC3172], Section 2.) .arpa is an "infrastructure domain", a		from [RFC3172], Section 2.) .arpa is an "infrastructure domain", a
	domain whose "role is to support the operating infrastructure of		domain whose "role is to support the operating infrastructure of
	the Internet". (Quoted from [RFC3172], Section 2.)		the Internet". (Quoted from [RFC3172], Section 2.) See [RFC3172]
			for more history of this name.
	Service name: "Service names are the unique key in the Service Name		Service name: "Service names are the unique key in the Service Name
	and Transport Protocol Port Number registry. This unique symbolic		and Transport Protocol Port Number registry. This unique symbolic
	name for a service may also be used for other purposes, such as in		name for a service may also be used for other purposes, such as in
	DNS SRV records." (Quoted from [RFC6335], Section 5.)		DNS SRV records." (Quoted from [RFC6335], Section 5.)
	8. Wildcards		8. Wildcards
	Wildcard: [RFC1034] defined "wildcard", but in a way that turned out		Wildcard: [RFC1034] defined "wildcard", but in a way that turned out
	to be confusing to implementers. For an extended discussion of		to be confusing to implementers. For an extended discussion of
	skipping to change at page 26, line 27 ¶		skipping to change at page 27, line 31 ¶
	DNS operator: An entity responsible for running DNS servers. For a		DNS operator: An entity responsible for running DNS servers. For a
	zone's authoritative servers, the registrant may act as their own		zone's authoritative servers, the registrant may act as their own
	DNS operator, or their registrar may do it on their behalf, or		DNS operator, or their registrar may do it on their behalf, or
	they may use a third-party operator. For some zones, the registry		they may use a third-party operator. For some zones, the registry
	function is performed by the DNS operator plus other entities who		function is performed by the DNS operator plus other entities who
	decide about the allowed contents of the zone.		decide about the allowed contents of the zone.
	Public suffix: "A domain that is controlled by a public registry."		Public suffix: "A domain that is controlled by a public registry."
	(Quoted from [RFC6265], Section 5.3) A common definition for this		(Quoted from [RFC6265], Section 5.3) A common definition for this
	term is a domain under which subdomains can be registered, and on		term is a domain under which subdomains can be registered by third
	which HTTP cookies (which are described in detail in [RFC6265])		parties, and on which HTTP cookies (which are described in detail
	should not be set. There is no indication in a domain name		in [RFC6265]) should not be set. There is no indication in a
	whether it is a public suffix; that can only be determined by		domain name whether it is a public suffix; that can only be
	outside means. In fact, both a domain and a subdomain of that		determined by outside means. In fact, both a domain and a
	domain can be public suffixes.		subdomain of that domain can be public suffixes.
	There is nothing inherent in a domain name to indicate whether it		There is nothing inherent in a domain name to indicate whether it
	is a public suffix. One resource for identifying public suffixes		is a public suffix. One resource for identifying public suffixes
	is the Public Suffix List (PSL) maintained by Mozilla		is the Public Suffix List (PSL) maintained by Mozilla
	(http://publicsuffix.org/).		(http://publicsuffix.org/).
	For example, at the time this document is published, the "com.au"		For example, at the time this document is published, the "com.au"
	domain is listed as a public suffix in the PSL. (Note that this		domain is listed as a public suffix in the PSL. (Note that this
	example might change in the future.)		example might change in the future.)
	skipping to change at page 30, line 46 ¶		skipping to change at page 31, line 48 ¶
	configured as a trust anchor. Therefore, it is suggested that the		configured as a trust anchor. Therefore, it is suggested that the
	SEP flag be set on keys that are used as KSKs and not on keys that		SEP flag be set on keys that are used as KSKs and not on keys that
	are used as ZSKs, while in those cases where a distinction between		are used as ZSKs, while in those cases where a distinction between
	a KSK and ZSK is not made (i.e., for a Single-Type Signing		a KSK and ZSK is not made (i.e., for a Single-Type Signing
	Scheme), it is suggested that the SEP flag be set on all keys."		Scheme), it is suggested that the SEP flag be set on all keys."
	(Quoted from [RFC6781], Section 3.2.3.) Note that the SEP flag is		(Quoted from [RFC6781], Section 3.2.3.) Note that the SEP flag is
	only a hint, and its presence or absence may not be used to		only a hint, and its presence or absence may not be used to
	disqualify a given DNSKEY RR from use as a KSK or ZSK during		disqualify a given DNSKEY RR from use as a KSK or ZSK during
	validation.		validation.
	The original defintion of SEPs was in [RFC3757]. That definition		The original definition of SEPs was in [RFC3757]. That definition
	clearly indicated that the SEP was a key, not just a bit in the		clearly indicated that the SEP was a key, not just a bit in the
	key. The abstract of [RFC3757] says: "With the Delegation Signer		key. The abstract of [RFC3757] says: "With the Delegation Signer
	(DS) resource record (RR), the concept of a public key acting as a		(DS) resource record (RR), the concept of a public key acting as a
	secure entry point (SEP) has been introduced. During exchanges of		secure entry point (SEP) has been introduced. During exchanges of
	public keys with the parent there is a need to differentiate SEP		public keys with the parent there is a need to differentiate SEP
	keys from other public keys in the Domain Name System KEY (DNSKEY)		keys from other public keys in the Domain Name System KEY (DNSKEY)
	resource record set. A flag bit in the DNSKEY RR is defined to		resource record set. A flag bit in the DNSKEY RR is defined to
	indicate that DNSKEY is to be used as a SEP." That definition of		indicate that DNSKEY is to be used as a SEP." That definition of
	the SEP as a key was made obsolete by [RFC4034], and the		the SEP as a key was made obsolete by [RFC4034], and the
	definition from [RFC6781] is consistent with [RFC4034].		definition from [RFC6781] is consistent with [RFC4034].
	Trust anchor: "A configured DNSKEY RR or DS RR hash of a DNSKEY RR.		Trust anchor: "A configured DNSKEY RR or DS RR hash of a DNSKEY RR.
	A validating security-aware resolver uses this public key or hash		A validating security-aware resolver uses this public key or hash
	as a starting point for building the authentication chain to a		as a starting point for building the authentication chain to a
	signed DNS response." (Quoted from [RFC4033], Section 2)		signed DNS response. In general, a validating resolver will have
			to obtain the initial values of its trust anchors via some secure
			or trusted means outside the DNS protocol." (Quoted from
			[RFC4033], Section 2)
	DNSSEC Policy (DP): A statement that "sets forth the security		DNSSEC Policy (DP): A statement that "sets forth the security
	requirements and standards to be implemented for a DNSSEC-signed		requirements and standards to be implemented for a DNSSEC-signed
	zone." (Quoted from [RFC6841], Section 2)		zone." (Quoted from [RFC6841], Section 2)
	DNSSEC Practice Statement (DPS): "A practices disclosure document		DNSSEC Practice Statement (DPS): "A practices disclosure document
	that may support and be a supplemental document to the DNSSEC		that may support and be a supplemental document to the DNSSEC
	Policy (if such exists), and it states how the management of a		Policy (if such exists), and it states how the management of a
	given zone implements procedures and controls at a high level."		given zone implements procedures and controls at a high level."
	(Quoted from [RFC6841], Section 2)		(Quoted from [RFC6841], Section 2)
	skipping to change at page 36, line 34 ¶		skipping to change at page 37, line 34 ¶
	[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating		[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
	DNSSEC Delegation Trust Maintenance", RFC 7344,		DNSSEC Delegation Trust Maintenance", RFC 7344,
	DOI 10.17487/RFC7344, September 2014,		DOI 10.17487/RFC7344, September 2014,
	<https://www.rfc-editor.org/info/rfc7344>.		<https://www.rfc-editor.org/info/rfc7344>.
	[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS		[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", RFC 7719, DOI 10.17487/RFC7719, December		Terminology", RFC 7719, DOI 10.17487/RFC7719, December
	2015, <https://www.rfc-editor.org/info/rfc7719>.		2015, <https://www.rfc-editor.org/info/rfc7719>.
			[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
			for DNS over TLS and DNS over DTLS", RFC 8310,
			DOI 10.17487/RFC8310, March 2018,
			<https://www.rfc-editor.org/info/rfc8310>.
	14.2. Informative References		14.2. Informative References
	[IANA_Resource_Registry]		[IANA_Resource_Registry]
	Internet Assigned Numbers Authority, "Resource Record (RR)		Internet Assigned Numbers Authority, "Resource Record (RR)
	TYPEs", 2017,		TYPEs", 2017,
	<http://www.iana.org/assignments/dns-parameters/>.		<http://www.iana.org/assignments/dns-parameters/>.
	[RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for		[RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for
	Internet User Applications", RFC 819,		Internet User Applications", RFC 819,
	DOI 10.17487/RFC0819, August 1982,		DOI 10.17487/RFC0819, August 1982,
	skipping to change at page 39, line 10 ¶		skipping to change at page 40, line 17 ¶
	Procedures for the Management of the Service Name and		Procedures for the Management of the Service Name and
	Transport Protocol Port Number Registry", BCP 165,		Transport Protocol Port Number Registry", BCP 165,
	RFC 6335, DOI 10.17487/RFC6335, August 2011,		RFC 6335, DOI 10.17487/RFC6335, August 2011,
	<https://www.rfc-editor.org/info/rfc6335>.		<https://www.rfc-editor.org/info/rfc6335>.
	[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in		[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
	Internationalization in the IETF", BCP 166, RFC 6365,		Internationalization in the IETF", BCP 166, RFC 6365,
	DOI 10.17487/RFC6365, September 2011,		DOI 10.17487/RFC6365, September 2011,
	<https://www.rfc-editor.org/info/rfc6365>.		<https://www.rfc-editor.org/info/rfc6365>.
			[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
			DOI 10.17487/RFC6762, February 2013,
			<https://www.rfc-editor.org/info/rfc6762>.
	[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of		[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
	Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,		Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
	February 2014, <https://www.rfc-editor.org/info/rfc7129>.		February 2014, <https://www.rfc-editor.org/info/rfc7129>.
	[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the		[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
	Registration Data Access Protocol (RDAP)", RFC 7480,		Registration Data Access Protocol (RDAP)", RFC 7480,
	DOI 10.17487/RFC7480, March 2015,		DOI 10.17487/RFC7480, March 2015,
	<https://www.rfc-editor.org/info/rfc7480>.		<https://www.rfc-editor.org/info/rfc7480>.
	[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the		[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
	skipping to change at page 39, line 43 ¶		skipping to change at page 41, line 5 ¶
	[RFC7484] Blanchet, M., "Finding the Authoritative Registration Data		[RFC7484] Blanchet, M., "Finding the Authoritative Registration Data
	(RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March		(RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March
	2015, <https://www.rfc-editor.org/info/rfc7484>.		2015, <https://www.rfc-editor.org/info/rfc7484>.
	[RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin,		[RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin,
	"Inventory and Analysis of WHOIS Registration Objects",		"Inventory and Analysis of WHOIS Registration Objects",
	RFC 7485, DOI 10.17487/RFC7485, March 2015,		RFC 7485, DOI 10.17487/RFC7485, March 2015,
	<https://www.rfc-editor.org/info/rfc7485>.		<https://www.rfc-editor.org/info/rfc7485>.
			[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
			and P. Hoffman, "Specification for DNS over Transport
			Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
			2016, <https://www.rfc-editor.org/info/rfc7858>.
			[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
			Transport Layer Security (DTLS)", RFC 8094,
			DOI 10.17487/RFC8094, February 2017,
			<https://www.rfc-editor.org/info/rfc8094>.
	[RFC8109] Koch, P., Larson, M., and P. Hoffman, "Initializing a DNS		[RFC8109] Koch, P., Larson, M., and P. Hoffman, "Initializing a DNS
	Resolver with Priming Queries", BCP 209, RFC 8109,		Resolver with Priming Queries", BCP 209, RFC 8109,
	DOI 10.17487/RFC8109, March 2017,		DOI 10.17487/RFC8109, March 2017,
	<https://www.rfc-editor.org/info/rfc8109>.		<https://www.rfc-editor.org/info/rfc8109>.
	[RSSAC026]		[RSSAC026]
	Root Server System Advisory Committee (RSSAC), "RSSAC		Root Server System Advisory Committee (RSSAC), "RSSAC
	Lexicon", 2017,		Lexicon", 2017,
	<https://www.icann.org/en/system/files/files/		<https://www.icann.org/en/system/files/files/
	rssac-026-14mar17-en.pdf>.		rssac-026-14mar17-en.pdf>.
	skipping to change at page 42, line 10 ¶		skipping to change at page 43, line 31 ¶
	o "View" in Section 6		o "View" in Section 6
	o "Zone transfer" in Section 6		o "Zone transfer" in Section 6
	Index		Index
	A		A
	Address records 14		Address records 14
	Alias 8		Alias 8
	Anycast 19		Anycast 20
	Apex 21		Apex 22
	Asterisk label 24		Asterisk label 25
	Authoritative data 21		Authoritative data 22
	Authoritative server 16		Authoritative server 17
	Authoritative-only server 17		Authoritative-only server 18
	arpa: Address and Routing Parameter Area Domain 24		arpa: Address and Routing Parameter Area Domain 25
	C		C
	CNAME 8		CNAME 9
	Canonical name 8		Canonical name 8
	Child 20		Child 21
	Class independent 14		Class independent 14
	Closest encloser 24		Closest encloser 26
	Closest provable encloser 25		Closest provable encloser 26
	Combined signing key (CSK) 30		Combined signing key (CSK) 31
	D		D
	DNS operator 26		DNS operator 27
	DNSSEC Policy (DP) 31		DNSSEC Policy (DP) 32
	DNSSEC Practice Statement (DPS) 31		DNSSEC Practice Statement (DPS) 32
	DNSSEC-aware and DNSSEC-unaware 27		DNSSEC-aware and DNSSEC-unaware 28
	Delegation 21		Delegation 22
	Delegation-centric zone 23		Delegation-centric zone 24
	Domain name 4		Domain name 4
	E		E
	EDNS 12		EDNS 13
	EPP 25		EPP 27
	Empty non-terminals (ENT) 23		Empty non-terminals (ENT) 24
	F		F
	FORMERR 9		FORMERR 9
	Fast flux DNS 23		Fast flux DNS 24
	Forward lookup 24		Forward lookup 25
	Forwarder 18		Forwarder 19
	Forwarding 18		Forwarding 19
	Full resolver 15		Full resolver 17
	Full-service resolver 15		Full-service resolver 17
	Fully qualified domain name (FQDN) 7		Fully qualified domain name (FQDN) 7
	G		G
	Global DNS 4		Global DNS 4
	Glue records 21		Glue records 23
	H		H
	Hardware security module (HSM) 31		Hardware security module (HSM) 32
	Hidden master 18		Hidden master 19
	Host name 7		Host name 7
	I		I
	IDN 8		IDN 8
	In-bailiwick 22		In-bailiwick 23
	Insecure delegation 28		Insecure delegation 29
	Instance 19		Instance 21
	Iterative mode 15		Iterative mode 15
	Iterative query 16
	Iterative resolution 16		Iterative resolution 16
	K		K
	Key signing key (KSK) 30		Key signing key (KSK) 31
	L		L
	Label 4		Label 4
	Lame delegation 21		Lame delegation 22
	Locally served DNS zone 6		Locally served DNS zone 7
	M		M
	Master file 12		Master file 13
	Master server 17		Master server 18
			Multicast DNS 6
	N		N
	NODATA 9		NODATA 9
	NOERROR 8		NOERROR 9
	NOTIMP 9		NOTIMP 9
	NSEC 28		NSEC 29
	NSEC3 28		NSEC3 29
	NXDOMAIN 9		NXDOMAIN 9
	Naming system 3		Naming system 3
	Negative caching 16		Negative caching 17
	Negative response 9		Negative response 10
	Next closer name 25		Next closer name 26
	Non-recursive query 16		Non-recursive query 16
	O		O
	OPT 13		OPT 13
	Occluded name 23		Occluded name 24
	Open resolver 19		Open resolver 20
	Opt-out 28		Opt-out 29
	Origin 20		Origin 21
	Out-of-bailiwick 22		Out-of-bailiwick 23
	Owner 13		Owner 13
	P		P
	Parent 20		Parent 21
	Passive DNS 19		Passive DNS 20
	Policy-implementing resolver 19		Policy-implementing resolver 19
	Presentation format 12		Presentation format 13
	Primary master 18		Primary master 18
	Primary server 17		Primary server 18
	Priming 16		Priming 17
			Privacy-enabling DNS server 21
	Private DNS 6		Private DNS 6
	Public suffix 26		Public suffix 27
	Q		Q
	QNAME 10		QNAME 10
	R		R
	RDAP 26		RDAP 27
	REFUSED 9		REFUSED 9
	RR 12		RR 12
	RRset 12		RRset 12
	Recursive mode 15		Recursive mode 16
	Recursive query 15		Recursive query 16
	Recursive resolver 15		Recursive resolver 16
	Referrals 11		Referrals 11
	Registrant 25		Registrant 26
	Registrar 25		Registrar 26
	Registry 25		Registry 26
	Resolver 14		Resolver 15
	Reverse DNS, reverse lookup 24		Reverse DNS, reverse lookup 25
	Root hints 16		Root hints 17
	Root zone 23		Root zone 24
	S		S
	SERVFAIL 9		SERVFAIL 9
	SOA field names 13		SOA field names 13
	Secondary server 17		Secondary server 18
	Secure Entry Point (SEP) 30		Secure Entry Point (SEP) 31
	Service name 24		Service name 25
	Signed zone 27		Signed zone 28
	Signing software 31		Signing software 32
	Slave server 17		Slave server 18
	Source of Synthesis 25		Source of Synthesis 26
	Split DNS 20		Split DNS 20
	Stealth server 18		Split-horizon DNS 20
			Stealth server 19
	Stub resolver 15		Stub resolver 15
	Subdomain 8		Subdomain 8
	Subordinate 26		Subordinate 28
	Superordinate 26		Superordinate 28
	T		T
	TLD 7		TLD 8
	TTL 13		TTL 13
	Trust anchor 31		Trust anchor 32
	U		U
	Unsigned zone 27		Unsigned zone 28
	V		V
	Validating resolver 30		Validating resolver 31
	Validation 29		Validation 30
	View 19		View 20
	W		W
	WHOIS 26		WHOIS 27
	Wildcard 24		Wildcard 25
	Wildcard domain name 24		Wildcard domain name 25
	Z		Z
	Zone 20		Zone 21
	Zone cut 21		Zone cut 22
	Zone enumeration 28		Zone enumeration 30
	Zone signing key (ZSK) 30		Zone signing key (ZSK) 31
	Zone transfer 17		Zone transfer 18
	Acknowledgements		Acknowledgements
	The following is the Acknowledgements for RFC 7719. Additional		The following is the Acknowledgements for RFC 7719. Additional
	acknowledgements may be added as this draft is worked on.		acknowledgements may be added as this draft is worked on.
	The authors gratefully acknowledge all of the authors of DNS-related		The authors gratefully acknowledge all of the authors of DNS-related
	RFCs that proceed this one. Comments from Tony Finch, Stephane		RFCs that proceed this one. Comments from Tony Finch, Stephane
	Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John		Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John
	Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman,		Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman,
	David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, Ed Lewis,		David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, Ed Lewis,
	John Klensin, David Black, and many others in the DNSOP Working Group		John Klensin, David Black, and many others in the DNSOP Working Group
	helped shape RFC 7719.		helped shape RFC 7719.
	Additional people contributed to this document, including: Bob		Additional people contributed to this document, including: Bob
	Harold, Dick Franks, Evan Hunt, John Dickinson, Mark Andrews, Martin		Harold, Dick Franks, Evan Hunt, John Dickinson, Mark Andrews, Martin
	Hoffmann, Paul Vixie, Peter Koch, [[ MORE NAMES WILL APPEAR HERE AS		Hoffmann, Paul Vixie, Peter Koch, Duane Wessels [[ MORE NAMES WILL
	FOLKS CONTRIBUTE]].		APPEAR HERE AS FOLKS CONTRIBUTE]].
	Authors' Addresses		Authors' Addresses
	Paul Hoffman		Paul Hoffman
	ICANN		ICANN
	Email: paul.hoffman@icann.org		Email: paul.hoffman@icann.org
	Andrew Sullivan		Andrew Sullivan
	Oracle		Oracle
End of changes. 79 change blocks.
	204 lines changed or deleted		279 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/