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/