--- 1/draft-ietf-dnssd-srp-09.txt 2021-07-12 15:13:30.699141161 -0700 +++ 2/draft-ietf-dnssd-srp-10.txt 2021-07-12 15:13:30.763142781 -0700 @@ -1,18 +1,18 @@ Internet Engineering Task Force T. Lemon Internet-Draft S. Cheshire Intended status: Standards Track Apple Inc. -Expires: 15 July 2021 11 January 2021 +Expires: 13 January 2022 12 July 2021 Service Registration Protocol for DNS-Based Service Discovery - draft-ietf-dnssd-srp-09 + draft-ietf-dnssd-srp-10 Abstract The Service Registration Protocol for DNS-Based Service Discovery uses the standard DNS Update mechanism to enable DNS-Based Service Discovery using only unicast packets. This makes it possible to deploy DNS Service Discovery without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly 802.11 (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 15 July 2021. + This Internet-Draft will expire on 13 January 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -256,21 +256,21 @@ that typically use Constrained-Node Networks may have very limited battery power. The series of DNS lookups required to discover an SRP server and then communicate with it will increase the power required to advertise a service; for low-power devices, the additional flexibility this provides does not justify the additional use of power. It is also fairly typical of such networks that some network service information is obtained as part of the process of joining the network, and so this can be relied upon to provide nodes with the information they need. - Networks that are not constrained networks can more complicated + Networks that are not constrained networks can have more complicated topologies at the Internet layer. Nodes connected to such networks can be assumed to be able to do DNSSD service registration domain discovery. Such networks are generally able to provide registration domain discovery and routing. By requiring the use of TCP, the possibility of off-network spoofing is eliminated. 2.2. Protocol Details We will discuss several parts to this process: how to know what to publish, how to know where to publish it (under what name), how to @@ -631,27 +631,30 @@ sign the message, * there is a Service Instance Name Instruction in the SRP update for which the SRV RR that is added points to the hostname being updated by this update. * Host Description updates do not modify any other records. 2.3.2. Valid SRP Update Requirements An SRP Update MUST include zero or more Service Discovery instructions. For each Service Discovery instruction, there MUST be - at least one Service Description instruction. For each Service - Description instruction there MUST be at least one Service Discovery - instruction with its service instance name as the target of its PTR - record. There MUST be exactly one Host Description Instruction. - Every Service Description instruction must have that Host Description - instruction as the target of its SRV record. A DNS Update that does - not meet these constraints is not an SRP update. + at least one Service Description instruction. Note that in the case + of SRP subtypes Section 7.1 of [RFC6763], it's quite possible that + two Service Discovery instructions might reference the same Service + Description instruction. For each Service Description instruction + there MUST be at least one Service Discovery instruction with its + service instance name as the target of its PTR record. There MUST be + exactly one Host Description Instruction. Every Service Description + instruction must have that Host Description instruction as the target + of its SRV record. A DNS Update that does not meet these constraints + is not an SRP update. A DNS Update that contains any additional adds or deletes that cannot be identified as Service Discovery, Service Description or Host Description instructions is not an SRP update. A DNS update that contains any prerequisites is not an SRP update. Such messages should either be processed as regular RFC2136 updates, including access control checks and constraint checks, if supported, or else rejected with RCODE=REFUSED. In addition, in order for an update to be a valid SRP update, the @@ -1109,22 +1112,22 @@ 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] Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases", Work in Progress, Internet-Draft, draft-sekar-dns-ul-02, 2 - August 2018, - . + August 2018, . [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, . [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, . @@ -1224,35 +1227,36 @@ RFC 8415, DOI 10.17487/RFC8415, November 2018, . [RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June 2020, . [I-D.cheshire-dnssd-roadmap] Cheshire, S., "Service Discovery Road Map", Work in Progress, Internet-Draft, draft-cheshire-dnssd-roadmap-03, - 23 October 2018, . + 23 October 2018, . [I-D.cheshire-edns0-owner-option] Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", Work in Progress, Internet-Draft, draft-cheshire-edns0-owner- - option-01, 3 July 2017, . + option-01, 3 July 2017, + . [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, . + Internet-Draft, draft-sctl-advertising-proxy-01, 22 + February 2021, . [ZC] Cheshire, S. and D.H. Steinberg, "Zero Configuration Networking: The Definitive Guide", O'Reilly Media, Inc. , ISBN 0-596-10100-7, December 2005. Appendix A. Testing using standard RFC2136-compliant servers 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 on the anycast address, or advertising it in the