rfc9665v2.txt		rfc9665.txt
	skipping to change at line 250 ¶		skipping to change at line 250 ¶
	information. Once published, these services can be readily		information. Once published, these services can be readily
	discovered by DNS-SD clients using standard DNS lookups.		discovered by DNS-SD clients using standard DNS lookups.
	Section 10 of the DNS-SD specification [RFC6763] briefly discusses		Section 10 of the DNS-SD specification [RFC6763] briefly discusses
	ways that servers can advertise the services they provide in the DNS		ways that servers can advertise the services they provide in the DNS
	namespace. In the case of mDNS, it allows servers to advertise their		namespace. In the case of mDNS, it allows servers to advertise their
	services on the local link, using names in the "local." namespace,		services on the local link, using names in the "local." namespace,
	which makes their services directly discoverable by peers attached to		which makes their services directly discoverable by peers attached to
	that same local link.		that same local link.
	DNS-SD [RFC6763] also allows clients to discover services using the		DNS-SD [RFC6763] also allows clients to discover services by using
	DNS protocol over traditional unicast [RFC1035]. This can be done by		the DNS protocol over traditional unicast [RFC1035]. This can be
	having a system administrator manually configure service information		done by having a system administrator manually configure service
	in the DNS; however, manually populating DNS authoritative server		information in the DNS; however, manually populating DNS
	databases is costly and potentially error-prone and requires a		authoritative server databases is costly and potentially error-prone
	knowledgeable network administrator. Consequently, although all		and requires a knowledgeable network administrator. Consequently,
	DNS-SD client implementations of which we are aware support DNS-SD		although all DNS-SD client implementations of which we are aware
	using DNS queries, in practice it is used much less frequently than		support DNS-SD using DNS queries, in practice it is used much less
	mDNS.		frequently than mDNS.
	The Discovery Proxy [RFC8766] provides one way to automatically		The Discovery Proxy [RFC8766] provides one way to automatically
	populate the DNS namespace but is only appropriate on networks where		populate the DNS namespace but is only appropriate on networks where
	services are easily advertised using mDNS. The present document		services are easily advertised using mDNS. The present document
	describes a solution more suitable for networks where multicast is		describes a solution more suitable for networks where multicast is
	inefficient, or where sleepy devices are common, by supporting the		inefficient, or where sleepy devices are common, by supporting the
	use of unicast for both the offering of and the discovery of		use of unicast for both the offering of and the discovery of
	services.		services.
	2. Conventions and Terminology Used in This Document		2. Conventions and Terminology Used in This Document
	skipping to change at line 410 ¶		skipping to change at line 410 ¶
	instructions. These instructions are made up of DNS Update Resource		instructions. These instructions are made up of DNS Update Resource
	Records (RRs) that are either adds or deletes. The types of records		Records (RRs) that are either adds or deletes. The types of records
	that are added, updated, and removed in each of these instructions,		that are added, updated, and removed in each of these instructions,
	as well as the constraints that apply to them, are described in		as well as the constraints that apply to them, are described in
	Section 3.3. An SRP Update is a DNS Update message [RFC2136] that is		Section 3.3. An SRP Update is a DNS Update message [RFC2136] that is
	constructed so as to meet the constraints described in that section.		constructed so as to meet the constraints described in that section.
	The following is a brief overview of what is included in a typical		The following is a brief overview of what is included in a typical
	SRP Update:		SRP Update:
	* Service Discovery PTR RR(s) for service(s), which map from a		* Service Discovery PTR RR(s) for service(s), which map from a
	generic service type (or subtype(s)) to a specific Service		generic service type (or subtype(s)) to a specific service
	Instance Name [RFC6763].		instance name [RFC6763].
	* For each Service Instance Name, an SRV RR, one or more TXT RRs,		* For each service instance name, an SRV RR, one or more TXT RRs,
	and a KEY RR. Although, in principle, DNS-SD Service Description		and a KEY RR. Although, in principle, DNS-SD Service Description
	records can include other record types with the same Service		records can include other record types with the same service
	Instance Name, in practice, they rarely do. Currently, SRP does		instance name, in practice, they rarely do. Currently, SRP does
	not permit other record types. The KEY RR is used to support FCFS		not permit other record types. The KEY RR is used to support FCFS
	Naming and has no specific meaning for DNS-SD lookups. SRV		Naming and has no specific meaning for DNS-SD lookups. SRV
	records for all services described in an SRP Update point to the		records for all services described in an SRP Update point to the
	same hostname.		same hostname.
	* There is always exactly one hostname in a single SRP Update. A		* There is always exactly one hostname in a single SRP Update. A
	DNS Update containing more than one hostname is not an SRP Update.		DNS Update containing more than one hostname is not an SRP Update.
	The hostname has one or more address RRs (AAAA or A) and a KEY RR		The hostname has one or more address RRs (AAAA or A) and a KEY RR
	(used for FCFS Naming). Depending on the use case, an SRP		(used for FCFS Naming). Depending on the use case, an SRP
	requester may be required to suppress some addresses that would		requester may be required to suppress some addresses that would
	skipping to change at line 442 ¶		skipping to change at line 442 ¶
	The DNS-Based Service Discovery specification [RFC6763] describes the		The DNS-Based Service Discovery specification [RFC6763] describes the
	details of what each of these RR types mean, with the exception of		details of what each of these RR types mean, with the exception of
	the KEY RR, which was defined in the specification for how to store		the KEY RR, which was defined in the specification for how to store
	Diffie-Hellman Keys in the DNS [RFC2539]. These specifications		Diffie-Hellman Keys in the DNS [RFC2539]. These specifications
	should be considered the definitive sources for information about		should be considered the definitive sources for information about
	what to publish; the reason for summarizing this here is to provide		what to publish; the reason for summarizing this here is to provide
	the reader with enough information about what will be published that		the reader with enough information about what will be published that
	the service registration process can be understood at a high level		the service registration process can be understood at a high level
	without first learning the full details of DNS-SD. Also, the		without first learning the full details of DNS-SD. Also, the
	"Service Instance Name" is an important aspect of FCFS Naming, which		"service instance name" is an important aspect of FCFS Naming, which
	we describe later on in this document.		we describe later on in this document.
	3.2.2. Where to Publish It		3.2.2. Where to Publish It
	Multicast DNS (mDNS) uses a single namespace, "local.". Subdomains		Multicast DNS (mDNS) uses a single namespace, "local.". Subdomains
	of "local." are specific to the local link on which they are		of "local." are specific to the local link on which they are
	advertised. This convenience is not available for DNS-SD using the		advertised. This convenience is not available for DNS-SD using the
	DNS protocol: Services must exist in some specific DNS namespace that		DNS protocol: Services must exist in some specific DNS namespace that
	is chosen either by the network operator or automatically.		is chosen either by the network operator or automatically.
	skipping to change at line 734 ¶		skipping to change at line 734 ¶
	In some use cases, a requester may need to remove a specific service		In some use cases, a requester may need to remove a specific service
	without removing its other services. For example, a device may shut		without removing its other services. For example, a device may shut
	down its remote screen access (_rfb._tcp) service while retaining its		down its remote screen access (_rfb._tcp) service while retaining its
	command-line login (_ssh._tcp) service. This can be accomplished in		command-line login (_ssh._tcp) service. This can be accomplished in
	one of two ways:		one of two ways:
	1. To simply remove a specific service, the requester sends a valid		1. To simply remove a specific service, the requester sends a valid
	SRP Update with a Service Description Instruction		SRP Update with a Service Description Instruction
	(Section 3.3.1.2) containing a single "Delete All RRsets From A		(Section 3.3.1.2) containing a single "Delete All RRsets From A
	Name" update to the Service Instance Name. The SRP Update SHOULD		Name" update to the service instance name. The SRP Update SHOULD
	include Service Discovery Instructions (Section 3.3.1.1)		include Service Discovery Instructions (Section 3.3.1.1)
	consisting of "Delete An RR From An RRset" updates [RFC2136] that		consisting of "Delete An RR From An RRset" updates [RFC2136] that
	delete any Service Discovery PTR records whose target is the		delete any Service Discovery PTR records whose target is the
	Service Instance Name. However, even in the absence of such		service instance name. However, even in the absence of such
	Service Discovery Instructions, the SRP registrar MUST delete any		Service Discovery Instructions, the SRP registrar MUST delete any
	Service Discovery PTR records that point to the deleted Service		Service Discovery PTR records that point to the deleted service
	Instance Name.		instance name.
	2. When deleting one service instance while simultaneously creating		2. When deleting one service instance while simultaneously creating
	a new service instance with a different service instance name, an		a new service instance with a different service instance name, an
	alternative is to perform both operations using a single SRP		alternative is to perform both operations using a single SRP
	Update. In this case, the old service is deleted as in the first		Update. In this case, the old service is deleted as in the first
	alternative. The new service is added, just as it would be in an		alternative. The new service is added, just as it would be in an
	update that wasn't deleting the old service. Because both the		update that wasn't deleting the old service. Because both the
	removal of the old service and the add of the new service		removal of the old service and the add of the new service
	consists of a valid Service Discovery Instruction and a valid		consists of a valid Service Discovery Instruction and a valid
	Service Description Instruction, the update as a whole is a valid		Service Description Instruction, the update as a whole is a valid
	SRP Update and will result in the old service being removed and		SRP Update and will result in the old service being removed and
	the new one added; or, to put it differently, the SRP Update will		the new one added; or, to put it differently, the SRP Update will
	result in the old service being replaced by the new service.		result in the old service being replaced by the new service.
	It is perhaps worth noting that if a service is being updated without		It is perhaps worth noting that if a service is being updated without
	the Service Instance Name changing (for example, when only the target		the service instance name changing (for example, when only the target
	port in the SRV record is being updated), then that SRP Update will		port in the SRV record is being updated), then that SRP Update will
	look very much like the second alternative above. The PTR record in		look very much like the second alternative above. The PTR record in
	the Service Discovery Instruction will be the same for both the		the Service Discovery Instruction will be the same for both the
	"Delete An RR From An RRset" update and the "Add To An RRset" update		"Delete An RR From An RRset" update and the "Add To An RRset" update
	[RFC2136]. Since the removal of the old service and the addition of		[RFC2136]. Since the removal of the old service and the addition of
	the new service are both valid SRP Update operations, the combined		the new service are both valid SRP Update operations, the combined
	operation is a valid SRP Update operation. The SRP registrar does		operation is a valid SRP Update operation. The SRP registrar does
	not need to include code to recognize this special case and does not		not need to include code to recognize this special case and does not
	need to take any special actions to handle it correctly.		need to take any special actions to handle it correctly.
	skipping to change at line 812 ¶		skipping to change at line 812 ¶
	is specified for the SRP Update.		is specified for the SRP Update.
	3.3.1.1. Service Discovery Instruction		3.3.1.1. Service Discovery Instruction
	An instruction is a Service Discovery Instruction if it:		An instruction is a Service Discovery Instruction if it:
	* consists of exactly one "Add To An RRSet" or exactly one "Delete		* consists of exactly one "Add To An RRSet" or exactly one "Delete
	An RR From An RRSet" RR update (Section 2.5 of the DNS Update		An RR From An RRSet" RR update (Section 2.5 of the DNS Update
	specification [RFC2136]),		specification [RFC2136]),
	* which updates a PTR RR,		* which updates a PTR RR,
	* the target of which is a Service Instance Name		* the target of which is a service instance name
	* for which name a Service Description Instruction is present in the		* for which name a Service Description Instruction is present in the
	SRP Update, and:		SRP Update, and:
	- if the Service Discovery Instruction is an "Add To An RRSet"		- if the Service Discovery Instruction is an "Add To An RRSet"
	instruction, that Service Description Instruction contains a		instruction, that Service Description Instruction contains a
	"Delete All RRsets From A Name" instruction for that Service		"Delete All RRsets From A Name" instruction for that service
	Instance Name followed by "Add To An RRset" instructions for		instance name followed by "Add To An RRset" instructions for
	the SRV and TXT records describing that service; or		the SRV and TXT records describing that service; or
	- if the Service Discovery Instruction is a "Delete An RR From An		- if the Service Discovery Instruction is a "Delete An RR From An
	RRSet" instruction, that Service Description Instruction		RRSet" instruction, that Service Description Instruction
	contains a "Delete All RRsets From A Name" instruction for that		contains a "Delete All RRsets From A Name" instruction for that
	Service Instance Name with no following "Add To An RRset"		service instance name with no following "Add To An RRset"
	instructions for the SRV and TXT records describing that		instructions for the SRV and TXT records describing that
	service.		service.
	Note that there can be more than one Service Discovery Instruction		Note that there can be more than one Service Discovery Instruction
	for the same service name (the owner name of the Service Discovery		for the same service name (the owner name of the Service Discovery
	PTR record) if the SRP requester is advertising more than one		PTR record) if the SRP requester is advertising more than one
	instance of the same service type or is changing the target of a PTR		instance of the same service type or is changing the target of a PTR
	RR. When subtypes are being used (Section 7.1 of the DNS-SD		RR. When subtypes are being used (Section 7.1 of the DNS-SD
	specification [RFC6763]), each subtype is a separate Service		specification [RFC6763]), each subtype is a separate Service
	Discovery Instruction. For each such PTR RR add or delete, the above		Discovery Instruction. For each such PTR RR add or delete, the above
	constraints must be met.		constraints must be met.
	3.3.1.2. Service Description Instruction		3.3.1.2. Service Description Instruction
	An instruction is a Service Description Instruction if, for the given		An instruction is a Service Description Instruction if, for the given
	Service Instance Name, all of the following are true:		service instance name, all of the following are true:
	* It contains exactly one "Delete All RRsets From A Name" update for		* It contains exactly one "Delete All RRsets From A Name" update for
	the Service Instance Name (Section 2.5.3 of the DNS Update		the service instance name (Section 2.5.3 of the DNS Update
	specification [RFC2136]).		specification [RFC2136]).
	* It contains zero or one "Add To An RRset" KEY RRs that, if		* It contains zero or one "Add To An RRset" KEY RRs that, if
	present, contains the public key corresponding to the private key		present, contains the public key corresponding to the private key
	that was used to sign the message (if present, the KEY RR MUST		that was used to sign the message (if present, the KEY RR MUST
	match the KEY RR given in the Host Description).		match the KEY RR given in the Host Description).
	* It contains zero or one "Add To An RRset" SRV RR.		* It contains zero or one "Add To An RRset" SRV RR.
	* If an "Add To An RRSet" update for an SRV RR is present, there		* If an "Add To An RRSet" update for an SRV RR is present, there
	MUST be at least one "Add To An RRset" update for the		MUST be at least one "Add To An RRset" update for the
	corresponding TXT RR, and the target of the SRV RR MUST be the		corresponding TXT RR, and the target of the SRV RR MUST be the
	hostname given in the Host Description Instruction in the SRP		hostname given in the Host Description Instruction in the SRP
	skipping to change at line 930 ¶		skipping to change at line 930 ¶
	SRP update, it MAY process the update as normal DNS Update [RFC2136],		SRP update, it MAY process the update as normal DNS Update [RFC2136],
	including access control checks and constraint checks, if supported.		including access control checks and constraint checks, if supported.
	Otherwise, the SRP registrar MUST reject the DNS Update with the		Otherwise, the SRP registrar MUST reject the DNS Update with the
	Refused RCODE.		Refused RCODE.
	If the definitions of each of these instructions are followed		If the definitions of each of these instructions are followed
	carefully and the update requirements are validated correctly, many		carefully and the update requirements are validated correctly, many
	DNS Update messages that look very much like SRP Updates nevertheless		DNS Update messages that look very much like SRP Updates nevertheless
	will fail to validate. For example, a DNS update that contains an		will fail to validate. For example, a DNS update that contains an
	"Add To An RRset" instruction for a Service Name and an "Add to an		"Add To An RRset" instruction for a Service Name and an "Add to an
	RRset" instruction for a Service Instance Name where the PTR record		RRset" instruction for a service instance name where the PTR record
	added to the Service Name does not reference the Service Instance		added to the Service Name does not reference the service instance
	Name is not a valid SRP Update but may be a valid DNS Update.		name is not a valid SRP Update but may be a valid DNS Update.
	3.3.3. FCFS Name and Signature Validation		3.3.3. FCFS Name and Signature Validation
	Assuming that the SRP registrar has confirmed that a DNS Update		Assuming that the SRP registrar has confirmed that a DNS Update
	message is a valid SRP Update (Section 3.3.2), it then checks that		message is a valid SRP Update (Section 3.3.2), it then checks that
	the name in the Host Description Instruction exists in the zone being		the name in the Host Description Instruction exists in the zone being
	updated. If so, then the registrar checks to see if the KEY record		updated. If so, then the registrar checks to see if the KEY record
	on that name is the same as the KEY record in the Host Description		on that name is the same as the KEY record in the Host Description
	Instruction. The registrar performs the same check for the KEY		Instruction. The registrar performs the same check for the KEY
	records in any Service Description Instructions. For KEY records		records in any Service Description Instructions. For KEY records
	skipping to change at line 1019 ¶		skipping to change at line 1019 ¶
	attempt to validate the RRs in the response, it might reject such a		attempt to validate the RRs in the response, it might reject such a
	response, since it would contain RRs but probably not a set of RRs		response, since it would contain RRs but probably not a set of RRs
	identical to what was sent in the SRP Update.		identical to what was sent in the SRP Update.
	3.3.6. Optional Behavior		3.3.6. Optional Behavior
	The SRP registrar MAY add a Reverse Mapping PTR record (described for		The SRP registrar MAY add a Reverse Mapping PTR record (described for
	IPv4 in Section 3.5 of [RFC1035] of the DNS specification [RFC1035]		IPv4 in Section 3.5 of [RFC1035] of the DNS specification [RFC1035]
	and for IPv6 in Section 2.5 of [RFC3596] of the later document		and for IPv6 in Section 2.5 of [RFC3596] of the later document
	updating DNS for IPv6 [RFC3596]) that corresponds to the Host		updating DNS for IPv6 [RFC3596]) that corresponds to the Host
	Description. This is optional because the reverse mapping PTR record		Description. This is optional: The reverse mapping PTR record serves
	serves no essential protocol function, but it may be useful for		no essential protocol function. One reason to provide reverse
	debugging, for example, in annotating network packet traces or logs.		mappings is that they can be used to annotate logs and network packet
	In order for the registrar to do a reverse mapping update, it must be		traces. In order for the registrar to do a reverse mapping update,
	authoritative for the zone that would need to be updated or have		it must be authoritative for the zone that would need to be updated
	credentials to do the update. The SRP requester MAY also do a		or have credentials to do the update. The SRP requester MAY also do
	reverse mapping update if it has credentials to do so.		a reverse mapping update if it has credentials to do so.
	The SRP registrar MAY apply additional criteria when accepting		The SRP registrar MAY apply additional criteria when accepting
	updates. In some networks, it may be possible to do out-of-band		updates. In some networks, it may be possible to do out-of-band
	registration of keys and only accept updates from preregistered keys.		registration of keys and only accept updates from preregistered keys.
	In this case, an update for a key that has not been registered SHOULD		In this case, an update for a key that has not been registered SHOULD
	be rejected with the Refused RCODE. When use of managed keys is		be rejected with the Refused RCODE. When use of managed keys is
	desired, there are at least two benefits to doing this in conjunction		desired, there are at least two benefits to doing this in conjunction
	with SRP rather than simply performing traditional DNS Updates using		with SRP rather than simply performing traditional DNS Updates using
	SIG(0) keys:		SIG(0) keys:
	skipping to change at line 1052 ¶		skipping to change at line 1052 ¶
	Note that the semantics of using SRP in this way are different from		Note that the semantics of using SRP in this way are different from
	the semantics of typical implementations of DNS Update. The KEY used		the semantics of typical implementations of DNS Update. The KEY used
	to sign the SRP Update only allows the SRP requester to update		to sign the SRP Update only allows the SRP requester to update
	records that refer to its Host Description. Implementations of a		records that refer to its Host Description. Implementations of a
	traditional DNS Update [RFC2136] do not normally provide a way to		traditional DNS Update [RFC2136] do not normally provide a way to
	enforce a constraint of this type.		enforce a constraint of this type.
	The SRP registrar could also have a dictionary of names or name		The SRP registrar could also have a dictionary of names or name
	patterns that are not permitted. If such a list is used, updates for		patterns that are not permitted. If such a list is used, updates for
	Service Instance Names that match entries in the dictionary are		service instance names that match entries in the dictionary are
	rejected with a Refused RCODE.		rejected with a Refused RCODE.
	4. TTL Consistency		4. TTL Consistency
	All RRs within an RRset are required to have the same TTL (required		All RRs within an RRset are required to have the same TTL (required
	by Section 5.2 of the DNS Clarifications document [RFC2181]). In		by Section 5.2 of the DNS Clarifications document [RFC2181]). In
	order to avoid inconsistencies, SRP places restrictions on TTLs sent		order to avoid inconsistencies, SRP places restrictions on TTLs sent
	by requesters and requires that SRP registrars enforce consistency.		by requesters and requires that SRP registrars enforce consistency.
	Requesters sending SRP Updates MUST use consistent TTLs in all RRs		Requesters sending SRP Updates MUST use consistent TTLs in all RRs
	skipping to change at line 1487 ¶		skipping to change at line 1487 ¶
	with the description "DNS-SD Service Registration Protocol Special-		with the description "DNS-SD Service Registration Protocol Special-
	Use Domain" and lists this document as the reference.		Use Domain" and lists this document as the reference.
	10.3. Subdomains of "service.arpa."		10.3. Subdomains of "service.arpa."
	This document only makes use of the "default.service.arpa." subdomain		This document only makes use of the "default.service.arpa." subdomain
	of "service.arpa." Other subdomains are reserved for future use by		of "service.arpa." Other subdomains are reserved for future use by
	DNS-SD or related work. IANA has created the "service.arpa.		DNS-SD or related work. IANA has created the "service.arpa.
	Subdomain" registry [SUB]. The IETF has change control for this		Subdomain" registry [SUB]. The IETF has change control for this
	registry. New entries may be added either as a result of Standards		registry. New entries may be added either as a result of Standards
	Action or with IESG Approval, provided that a specification exists		Action (Section 4.9 of [RFC8126]) or with IESG Approval (Section 4.10
	[RFC8126].		of [RFC8126]), provided that the values and their meanings are
			documented in a permanent and readily available public specification,
			in sufficient detail so that interoperability between independent
			implementations is possible.
	IANA has grouped the "service.arpa. Subdomain" registry with the		IANA has grouped the "service.arpa. Subdomain" registry with the
	"Locally-Served DNS Zones" group. The registry is a table with three		"Locally-Served DNS Zones" group. The registry is a table with three
	columns: the subdomain name (expressed as a fully qualified domain		columns: the subdomain name (expressed as a fully qualified domain
	name), a brief description of how it is used, and a reference to the		name), a brief description of how it is used, and a reference to the
	document that describes its use in detail.		document that describes its use in detail.
	This initial contents of this registry are as follows:		This initial contents of this registry are as follows:
	+=======================+=================+===========+		+=======================+=================+===========+
End of changes. 18 change blocks.
	39 lines changed or deleted		42 lines changed or added
This html diff was produced by rfcdiff 1.48.