draft-ietf-dnssd-srp-07.txt		draft-ietf-dnssd-srp-08.txt
	Internet Engineering Task Force T. Lemon		Internet Engineering Task Force T. Lemon
	Internet-Draft S. Cheshire		Internet-Draft S. Cheshire
	Intended status: Standards Track Apple Inc.		Intended status: Standards Track Apple Inc.
	Expires: 21 June 2021 18 December 2020		Expires: 11 July 2021 7 January 2021
	Service Registration Protocol for DNS-Based Service Discovery		Service Registration Protocol for DNS-Based Service Discovery
	draft-ietf-dnssd-srp-07		draft-ietf-dnssd-srp-08
	Abstract		Abstract
	The Service Registration Protocol for DNS-Based Service Discovery		The Service Registration Protocol for DNS-Based Service Discovery
	uses the standard DNS Update mechanism to enable DNS-Based Service		uses the standard DNS Update mechanism to enable DNS-Based Service
	Discovery using only unicast packets. This makes it possible to		Discovery using only unicast packets. This makes it possible to
	deploy DNS Service Discovery without multicast, which greatly		deploy DNS Service Discovery without multicast, which greatly
	improves scalability and improves performance on networks where		improves scalability and improves performance on networks where
	multicast service is not an optimal choice, particularly 802.11		multicast service is not an optimal choice, particularly 802.11
	(Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration		(Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 21 June 2021.		This Internet-Draft will expire on 11 July 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	2.1.1. Full-featured Hosts . . . . . . . . . . . . . . . . . 5		2.1.1. Full-featured Hosts . . . . . . . . . . . . . . . . . 5
	2.1.2. Constrained Hosts . . . . . . . . . . . . . . . . . . 6		2.1.2. Constrained Hosts . . . . . . . . . . . . . . . . . . 6
	2.1.3. Why two variants? . . . . . . . . . . . . . . . . . . 6		2.1.3. Why two variants? . . . . . . . . . . . . . . . . . . 6
	2.2. Protocol Details . . . . . . . . . . . . . . . . . . . . 6		2.2. Protocol Details . . . . . . . . . . . . . . . . . . . . 6
	2.2.1. What to publish . . . . . . . . . . . . . . . . . . . 7		2.2.1. What to publish . . . . . . . . . . . . . . . . . . . 7
	2.2.2. Where to publish it . . . . . . . . . . . . . . . . . 7		2.2.2. Where to publish it . . . . . . . . . . . . . . . . . 7
	2.2.3. How to publish it . . . . . . . . . . . . . . . . . . 8		2.2.3. How to publish it . . . . . . . . . . . . . . . . . . 8
	2.2.4. How to secure it . . . . . . . . . . . . . . . . . . 9		2.2.4. How to secure it . . . . . . . . . . . . . . . . . . 9
	2.2.5. Service Behavior . . . . . . . . . . . . . . . . . . 9		2.2.5. Service Behavior . . . . . . . . . . . . . . . . . . 9
	2.3. SRP Server Behavior . . . . . . . . . . . . . . . . . . . 12		2.3. SRP Server Behavior . . . . . . . . . . . . . . . . . . . 12
	2.3.1. Validation of Adds . . . . . . . . . . . . . . . . . 12		2.3.1. Validation of Adds and Deletes . . . . . . . . . . . 12
	2.3.2. Valid SRP Update Requirements . . . . . . . . . . . . 14		2.3.2. Valid SRP Update Requirements . . . . . . . . . . . . 14
	2.3.3. FCFS Name And Signature Validation . . . . . . . . . 14		2.3.3. FCFS Name And Signature Validation . . . . . . . . . 15
	2.3.4. SRP Update response . . . . . . . . . . . . . . . . . 15		2.3.4. SRP Update response . . . . . . . . . . . . . . . . . 15
	2.3.5. Optional Behavior . . . . . . . . . . . . . . . . . . 15		2.3.5. Optional Behavior . . . . . . . . . . . . . . . . . . 16
	3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 16		3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 16
	4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 17		4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 17
	4.1. Cleaning up stale data . . . . . . . . . . . . . . . . . 17		4.1. Cleaning up stale data . . . . . . . . . . . . . . . . . 17
	5. Sleep Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 18		5. Sleep Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 19
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 19		6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	6.1. Source Validation . . . . . . . . . . . . . . . . . . . . 20		6.1. Source Validation . . . . . . . . . . . . . . . . . . . . 20
	6.2. SRP Server Authentication . . . . . . . . . . . . . . . . 20		6.2. SRP Server Authentication . . . . . . . . . . . . . . . . 21
	6.3. Required Signature Algorithm . . . . . . . . . . . . . . 21		6.3. Required Signature Algorithm . . . . . . . . . . . . . . 21
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
	8. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 21		8. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 21
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	9.1. Registration and Delegation of 'service.arpa' as a		9.1. Registration and Delegation of 'service.arpa' as a
	Special-Use Domain Name . . . . . . . . . . . . . . . . . 21		Special-Use Domain Name . . . . . . . . . . . . . . . . . 22
	9.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 22		9.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 22
	9.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 22		9.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 22
	9.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 22		9.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 23
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23		10. Implementation Status . . . . . . . . . . . . . . . . . . . . 23
	11. Normative References . . . . . . . . . . . . . . . . . . . . 23		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
	12. Informative References . . . . . . . . . . . . . . . . . . . 25		12. Normative References . . . . . . . . . . . . . . . . . . . . 24
	Appendix A. Testing using standard RFC2136-compliant servers . . 26		13. Informative References . . . . . . . . . . . . . . . . . . . 26
			Appendix A. Testing using standard RFC2136-compliant servers . . 27
	Appendix B. How to allow services to update standard		Appendix B. How to allow services to update standard
	RFC2136-compliant servers . . . . . . . . . . . . . . . . 27		RFC2136-compliant servers . . . . . . . . . . . . . . . . 28
	Appendix C. Sample BIND9 configuration for
	default.service.arpa. . . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28		Appendix C. Sample BIND9 configuration for
			default.service.arpa. . . . . . . . . . . . . . . . . . . 28
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
	1. Introduction		1. Introduction
	DNS-Based Service Discovery [RFC6763] is a component of Zero		DNS-Based Service Discovery [RFC6763] is a component of Zero
	Configuration Networking [RFC6760] [ZC] [I-D.cheshire-dnssd-roadmap].		Configuration Networking [RFC6760] [ZC] [I-D.cheshire-dnssd-roadmap].
	This document describes an enhancement to DNS-Based Service Discovery		This document describes an enhancement to DNS-Based Service Discovery
	[RFC6763] that allows services to register their services using the		[RFC6763] that allows services to register their services using the
	DNS protocol rather than using Multicast DNS [RFC6762] (mDNS). There		DNS protocol rather than using Multicast DNS [RFC6762] (mDNS). There
	is already a large installed base of DNS-SD clients that can discover		is already a large installed base of DNS-SD clients that can discover
	skipping to change at page 11, line 48 ¶		skipping to change at page 11, line 48 ¶
	To support this, when removing services based on the lease time being		To support this, when removing services based on the lease time being
	zero, an SRP server MUST remove all service instances pointing to a		zero, an SRP server MUST remove all service instances pointing to a
	host when a host is removed, even if the SRP client doesn't list them		host when a host is removed, even if the SRP client doesn't list them
	explicitly. If the key lease time is nonzero, the SRP server MUST		explicitly. If the key lease time is nonzero, the SRP server MUST
	NOT delete the KEY records for these SRP clients.		NOT delete the KEY records for these SRP clients.
	2.2.5.5.2. Removing some published services		2.2.5.5.2. Removing some published services
	In some use cases a client may need to remove some specific service,		In some use cases a client may need to remove some specific service,
	without removing its other services. This can be accomplished in one		without removing its other services. This can be accomplished in one
	of two ways. The first alternative is to send a valid SRP update		of two ways. To simply remove a specific service, the client sends a
	where the only Service Discovery instruction is a remove-only		valid SRP update where the Service Discovery instruction
	instruction, and the only Service Description instruction is a		(Section 2.3.1.1) contains a single Delete an RR from an RRset
	remove-only instruction. In this case, the host lease will be		([RFC2136], Section 2.5.4) update that deletes the PTR record whose
	updated with the lease time provided in the SRP update.		target is the service instance name. The Service Description
			instruction (Section 2.3.1.2) in this case contains a single Delete
			all RRsets from a Name ([RFC2136], Section 2.5.3) update to the
			service instance name.
	The second alternative is to send a normal SRP update, but as in the		The second alternative is used when some service is being replaced by
	first alternative, including a Service Discovery Instruction and a		a different service with a different service instance name. In this
	Service Description that delete the service being removed. This can		case, the old service is deleted as in the first alternative. The
	be particularly useful when one service is being replaced with		new service is added, just as it would be in an update that wasn't
	another, since this can be done in a single SRP Update.		deleting the old service. Because both the removal of the old
			service and the add of the new service consist of a valid Service
			Discovery instruction and 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 the new one added, or, to put it
			differently, in the old service being replaced by the new service.
	In neither of these cases is it permissible to delete the host. All		It is perhaps worth noting that if a service is being updated without
	services must point to a host. If a host is to be deleted, this must		the service instance name changing, that will look very much like the
	be done using the zero-lease deletion method.		second alternative above. The difference is that because the target
			for the PTR record in the Service Discovery instruction is the same
			for both the Delete An RR From An RRset update and the Add To An
			RRSet update, these will be seen as a single Service Description
			instruction, not as two instructions. The same would be true of the
			Service Description instruction.
			Whichever of these two alternatives is used, the host lease will be
			updated with the lease time provided in the SRP update. In neither
			of these cases is it permissible to delete the host. All services
			must point to a host. If a host is to be deleted, this must be done
			using the method described in Section 2.2.5.5.1, which deletes the
			host and all services that have that host as their target.
	2.3. SRP Server Behavior		2.3. SRP Server Behavior
	2.3.1. Validation of Adds		2.3.1. Validation of Adds and Deletes
	The SRP server first validates that the DNS Update is a syntactically		The SRP server first validates that the DNS Update is a syntactically
	and semantically valid DNS Update according to the rules specified in		and semantically valid DNS Update according to the rules specified in
	RFC2136.		RFC2136.
	SRP Updates consist of a set of _instructions_ that together add or		SRP Updates consist of a set of _instructions_ that together add or
	remove one or more services. Each instruction consists either of a		remove one or more services. Each instruction consists some
	single add, a single delete, or a delete optionally followed by an		combination of delete updates and add updates. When an instruction
	add. When an instruction contains a delete and an add, the delete		contains a delete and an add, the delete MUST precede the add.
	MUST precede the add.
	The SRP server checks each instruction in the SRP update to see that		The SRP server checks each instruction in the SRP update to see that
	it is either a Service Discovery update, a Service Description		it is either a Service Discovery update, a Service Description
	update, or a Host Description update. Order matters in DNS updates.		update, or a Host Description update. Order matters in DNS updates.
	Specifically, deletes must precede adds for records that the deletes		Specifically, deletes must precede adds for records that the deletes
	would affect; otherwise the add will have no effect. This is the		would affect; otherwise the add will have no effect. This is the
	only ordering constraint; aside from this constraint, updates may		only ordering constraint; aside from this constraint, updates may
	appear in whatever order is convenient when constructing the update.		appear in whatever order is convenient when constructing the update.
	Because the SRP update is a DNS update, it MUST contain a single		Because the SRP update is a DNS update, it MUST contain a single
	question that indicates the zone to be updated. Every delete and		question that indicates the zone to be updated. Every delete and
	update in an SRP update MUST be within the zone that is specified for		update in an SRP update MUST be within the zone that is specified for
	the SRP Update.		the SRP Update.
	2.3.1.1. Service Discovery Instruction		2.3.1.1. Service Discovery Instruction
	An instruction is a Service Discovery Instruction if it contains		An instruction is a Service Discovery Instruction if it contains
	* exactly one "Add to an RRSet" or one "Delete an RR from an RRSet"		* exactly one "Add to an RRSet" or exactly one "Delete an RR from an
	([RFC2136], Section 2.5.1) RR update,		RRSet" ([RFC2136], Section 2.5.1) RR update,
	* which updates a PTR RR,		* which updates a PTR RR,
	* which points to a Service Instance Name		* which points to a Service Instance Name
	* for which a Service Description Instruction is present in the SRP		* for which a Service Description Instruction is present in the SRP
	Update		Update
	* if the Service Discovery update is an "Add to an RRSet"		* if the Service Discovery update is an "Add to an RRSet"
	instruction, the Service Description Instruction does not match if		instruction, the Service Description Instruction does not match if
	it does not contain an "Add to an RRset" update for the SRV RR		it does not contain an "Add to an RRset" update for the SRV RR
	describing that service.		describing that service.
	* if the Service Discovery Instruction is an "Delete an RR from an		* if the Service Discovery Instruction is an "Delete an RR from an
	RRSet" update, the Service Description Instruction does not match		RRSet" update, the Service Description Instruction does not match
	if it contains an "Add to an RRset" update.		if it contains an "Add to an RRset" update.
	* Service Discovery Instructions do not contain any other add or		* Service Discovery Instructions do not contain any other add or
	delete updates.		delete updates.
	skipping to change at page 13, line 33 ¶		skipping to change at page 13, line 51 ¶
	* zero or one "Add to an RRset" KEY RR that, if present, contains		* zero or one "Add to an RRset" KEY RR that, if present, contains
	the public key corresponding to the private key that was used to		the public key corresponding to the private key that was used to
	sign the message (if present, the KEY MUST match the KEY RR given		sign the message (if present, the KEY MUST match the KEY RR given
	in the Host Description),		in the Host Description),
	* zero or more "Add to an RRset" TXT RRs,		* zero or more "Add to an RRset" TXT RRs,
	* If there is one "Add to an RRset" SRV update, there MUST be at		* If there is one "Add to an RRset" SRV update, there MUST be at
	least one "Add to an RRset" TXT update.		least one "Add to an RRset" TXT update.
	* the target of the SRV RR Add, if present points to a hostname for		* the target of the SRV RR Add, if present points to a hostname for
	which there is a Host Description Instruction in the SRP Update,		which there is a Host Description Instruction in the SRP Update,
	or		or
	* if there is no "Add to an RRset" SRV RR, then there is an existing		* if there is no "Add to an RRset" SRV RR, then either
	SRV RR on the name specified in the "Delete all RRsets from a		- the name to which the "Delete all RRsets from a name" applies
	name" update that to a hostname for which there is a Host		does not exist, or
	Description Instruction in the SRP Update, and there is a KEY RR
	on that name which matches the key with which the SRP Update was		- there is an existing KEY RR on that name, which matches the key
	signed.		with which the SRP Update was signed.
	* Service Descriptions Instructions do not modify any other RRs.		* Service Descriptions Instructions do not modify any other RRs.
	An SRP server MUST correctly handle compressed names in the SRV		An SRP server MUST correctly handle compressed names in the SRV
	target.		target.
	2.3.1.3. Host Description Instruction		2.3.1.3. Host Description Instruction
	An instruction is a Host Description Instruction if, for the		An instruction is a Host Description Instruction if, for the
	appropriate hostname, it contains		appropriate hostname, it contains
	skipping to change at page 23, line 32 ¶		skipping to change at page 23, line 40 ¶
	+----------------------+-----------------------------+		+----------------------+-----------------------------+
	| Forwardable | True |		| Forwardable | True |
	+----------------------+-----------------------------+		+----------------------+-----------------------------+
	| Global | True |		| Global | True |
	+----------------------+-----------------------------+		+----------------------+-----------------------------+
	| Reserved-by-protocol | False |		| Reserved-by-protocol | False |
	+----------------------+-----------------------------+		+----------------------+-----------------------------+
	Table 1		Table 1
	10. Acknowledgments		10. Implementation Status
	Thanks to Toke Høiland-Jørgensen, Jonathan Hui and Esko Dijk for		[Note to the RFC Editor: please remove this section prior to
	their thorough technical reviews, to Tamara Kemper for doing a nice		publication.]
	developmental edit, Tim Wattenberg for doing a service implementation
	at the Montreal Hackathon at IETF 102, and Tom Pusateri for reviewing
	during the hackathon and afterwards.
	11. Normative References		This section records the status of known implementations of the
			protocol defined by this specification at the time of posting of this
			Internet-Draft, and is based on a proposal described in RFC 7942.
			The description of implementations in this section is intended to
			assist the IETF in its decision processes in progressing drafts to
			RFCs. Please note that the listing of any individual implementation
			here does not imply endorsement by the IETF. Furthermore, no effort
			has been spent to verify the information presented here that was
			supplied by IETF contributors. This is not intended as, and must not
			be construed to be, a catalog of available implementations or their
			features. Readers are advised to note that other implementations may
			exist.
			According to RFC 7942, "this will allow reviewers and working groups
			to assign due consideration to documents that have the benefit of
			running code, which may serve as evidence of valuable experimentation
			and feedback that have made the implemented protocols more mature.
			It is up to the individual working groups to use this information as
			they see fit".
			There are two known independent implementations of SRP clients:
			* SRP Client for OpenThread:
			https://github.com/openthread/openthread/pull/6038
			* mDNSResponder open source project: https://github.com/Abhayakara/
			mdnsresponder
			There are two related implementations of an SRP server. One acts as
			a DNS Update proxy, taking an SRP update and applying it to the
			specified DNS zone using DNS update. The other acts as an
			Advertising Proxy [I-D.sctl-advertising-proxy]. Both are included in
			the mDNSResponder open source project mentioned above.
			11. Acknowledgments
			Thanks to Toke Høiland-Jørgensen, Jonathan Hui, Esko Dijk, Kangping
			Dong and Abtin Keshavarzian for their thorough technical reviews.
			Thanks to Kangping and Abtin as well for testing the document by
			doing an independent implementation. Thanks to Tamara Kemper for
			doing a nice developmental edit, Tim Wattenberg for doing a SRP
			client proof-of-concept implementation at the Montreal Hackathon at
			IETF 102, and Tom Pusateri for reviewing during the hackathon and
			afterwards.
			12. Normative References
	[I-D.sekar-dns-ul]		[I-D.sekar-dns-ul]
	Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases",		Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases",
	Work in Progress, Internet-Draft, draft-sekar-dns-ul-02, 2		Work in Progress, Internet-Draft, draft-sekar-dns-ul-02, 2
	August 2018,		August 2018,
	<https://tools.ietf.org/html/draft-sekar-dns-ul-02>.		<https://tools.ietf.org/html/draft-sekar-dns-ul-02>.
	[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor		[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
	Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,		Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
	<https://www.rfc-editor.org/info/rfc2132>.		<https://www.rfc-editor.org/info/rfc2132>.
	skipping to change at page 25, line 5 ¶		skipping to change at page 26, line 5 ¶
	<https://www.rfc-editor.org/info/rfc8765>.		<https://www.rfc-editor.org/info/rfc8765>.
	[SUDN] "Special-Use Domain Names Registry", July 2012,		[SUDN] "Special-Use Domain Names Registry", July 2012,
	<https://www.iana.org/assignments/special-use-domain-		<https://www.iana.org/assignments/special-use-domain-
	names/special-use-domain-names.xhtml>.		names/special-use-domain-names.xhtml>.
	[LSDZ] "Locally-Served DNS Zones Registry", July 2011,		[LSDZ] "Locally-Served DNS Zones Registry", July 2011,
	<https://www.iana.org/assignments/locally-served-dns-		<https://www.iana.org/assignments/locally-served-dns-
	zones/locally-served-dns-zones.xhtml>.		zones/locally-served-dns-zones.xhtml>.
	12. Informative References		13. Informative References
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <https://www.rfc-editor.org/info/rfc1035>.		November 1987, <https://www.rfc-editor.org/info/rfc1035>.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
	RFC 2131, DOI 10.17487/RFC2131, March 1997,		RFC 2131, DOI 10.17487/RFC2131, March 1997,
	<https://www.rfc-editor.org/info/rfc2131>.		<https://www.rfc-editor.org/info/rfc2131>.
	[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS		[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
	skipping to change at page 26, line 27 ¶		skipping to change at page 27, line 27 ¶
	Progress, Internet-Draft, draft-cheshire-dnssd-roadmap-03,		Progress, Internet-Draft, draft-cheshire-dnssd-roadmap-03,
	23 October 2018, <https://tools.ietf.org/html/draft-		23 October 2018, <https://tools.ietf.org/html/draft-
	cheshire-dnssd-roadmap-03>.		cheshire-dnssd-roadmap-03>.
	[I-D.cheshire-edns0-owner-option]		[I-D.cheshire-edns0-owner-option]
	Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", Work		Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", Work
	in Progress, Internet-Draft, draft-cheshire-edns0-owner-		in Progress, Internet-Draft, draft-cheshire-edns0-owner-
	option-01, 3 July 2017, <https://tools.ietf.org/html/		option-01, 3 July 2017, <https://tools.ietf.org/html/
	draft-cheshire-edns0-owner-option-01>.		draft-cheshire-edns0-owner-option-01>.
			[I-D.sctl-advertising-proxy]
			Cheshire, S. and T. Lemon, "Advertising Proxy for DNS-SD
			Service Registration Protocol", Work in Progress,
			Internet-Draft, draft-sctl-advertising-proxy-00, 13 July
			2020, <https://tools.ietf.org/html/draft-sctl-advertising-
			proxy-00>.
	[ZC] Cheshire, S. and D.H. Steinberg, "Zero Configuration		[ZC] Cheshire, S. and D.H. Steinberg, "Zero Configuration
	Networking: The Definitive Guide", O'Reilly Media, Inc. ,		Networking: The Definitive Guide", O'Reilly Media, Inc. ,
	ISBN 0-596-10100-7, December 2005.		ISBN 0-596-10100-7, December 2005.
	Appendix A. Testing using standard RFC2136-compliant servers		Appendix A. Testing using standard RFC2136-compliant servers
	It may be useful to set up a DNS server for testing that does not		It may be useful to set up a DNS server for testing that does not
	implement SRP. This can be done by configuring the server to listen		implement SRP. This can be done by configuring the server to listen
	on the anycast address, or advertising it in the		on the anycast address, or advertising it in the
	_dnssd-srp._tcp.<zone> SRV and _dnssd-srp-tls._tcp.<zone> record. It		_dnssd-srp._tcp.<zone> SRV and _dnssd-srp-tls._tcp.<zone> record. It
End of changes. 26 change blocks.
	55 lines changed or deleted		123 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/