--- 1/draft-ietf-dnssd-srp-07.txt 2021-01-07 09:13:15.696609090 -0800 +++ 2/draft-ietf-dnssd-srp-08.txt 2021-01-07 09:13:15.760610724 -0800 @@ -1,18 +1,18 @@ Internet Engineering Task Force T. Lemon Internet-Draft S. Cheshire 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 - draft-ietf-dnssd-srp-07 + draft-ietf-dnssd-srp-08 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,25 +27,25 @@ 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 21 June 2021. + This Internet-Draft will expire on 11 July 2021. 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. 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 and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. @@ -58,51 +58,52 @@ 2.1.1. Full-featured Hosts . . . . . . . . . . . . . . . . . 5 2.1.2. Constrained Hosts . . . . . . . . . . . . . . . . . . 6 2.1.3. Why two variants? . . . . . . . . . . . . . . . . . . 6 2.2. Protocol Details . . . . . . . . . . . . . . . . . . . . 6 2.2.1. What to publish . . . . . . . . . . . . . . . . . . . 7 2.2.2. Where to publish it . . . . . . . . . . . . . . . . . 7 2.2.3. How to publish it . . . . . . . . . . . . . . . . . . 8 2.2.4. How to secure it . . . . . . . . . . . . . . . . . . 9 2.2.5. Service Behavior . . . . . . . . . . . . . . . . . . 9 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.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.5. Optional Behavior . . . . . . . . . . . . . . . . . . 15 + 2.3.5. Optional Behavior . . . . . . . . . . . . . . . . . . 16 3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 16 4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Cleaning up stale data . . . . . . . . . . . . . . . . . 17 - 5. Sleep Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 5. Sleep Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6.1. Source Validation . . . . . . . . . . . . . . . . . . . . 20 - 6.2. SRP Server Authentication . . . . . . . . . . . . . . . . 20 + 6.2. SRP Server Authentication . . . . . . . . . . . . . . . . 21 6.3. Required Signature Algorithm . . . . . . . . . . . . . . 21 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 8. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 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.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 22 - 9.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 22 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 - 11. Normative References . . . . . . . . . . . . . . . . . . . . 23 - 12. Informative References . . . . . . . . . . . . . . . . . . . 25 - Appendix A. Testing using standard RFC2136-compliant servers . . 26 + 9.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 23 + 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 + 12. Normative References . . . . . . . . . . . . . . . . . . . . 24 + 13. Informative References . . . . . . . . . . . . . . . . . . . 26 + Appendix A. Testing using standard RFC2136-compliant servers . . 27 Appendix B. How to allow services to update standard - RFC2136-compliant servers . . . . . . . . . . . . . . . . 27 - Appendix C. Sample BIND9 configuration for - default.service.arpa. . . . . . . . . . . . . . . . . . . 27 + RFC2136-compliant servers . . . . . . . . . . . . . . . . 28 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 + Appendix C. Sample BIND9 configuration for + default.service.arpa. . . . . . . . . . . . . . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction DNS-Based Service Discovery [RFC6763] is a component of Zero Configuration Networking [RFC6760] [ZC] [I-D.cheshire-dnssd-roadmap]. This document describes an enhancement to DNS-Based Service Discovery [RFC6763] that allows services to register their services using the DNS protocol rather than using Multicast DNS [RFC6762] (mDNS). There is already a large installed base of DNS-SD clients that can discover @@ -495,74 +496,92 @@ To support this, when removing services based on the lease time being 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 explicitly. If the key lease time is nonzero, the SRP server MUST NOT delete the KEY records for these SRP clients. 2.2.5.5.2. Removing some published services In some use cases a client may need to remove some specific service, without removing its other services. This can be accomplished in one - of two ways. The first alternative is to send a valid SRP update - where the only Service Discovery instruction is a remove-only - instruction, and the only Service Description instruction is a - remove-only instruction. In this case, the host lease will be - updated with the lease time provided in the SRP update. + of two ways. To simply remove a specific service, the client sends a + valid SRP update where the Service Discovery instruction + (Section 2.3.1.1) contains a single Delete an RR from an RRset + ([RFC2136], Section 2.5.4) update that deletes the PTR record whose + 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 - first alternative, including a Service Discovery Instruction and a - Service Description that delete the service being removed. This can - be particularly useful when one service is being replaced with - another, since this can be done in a single SRP Update. + The second alternative is used when some service is being replaced by + a different service with a different service instance name. 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 update that wasn't + 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 - services must point to a host. If a host is to be deleted, this must - be done using the zero-lease deletion method. + It is perhaps worth noting that if a service is being updated without + the service instance name changing, that will look very much like the + 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.1. Validation of Adds +2.3.1. Validation of Adds and Deletes The SRP server first validates that the DNS Update is a syntactically and semantically valid DNS Update according to the rules specified in RFC2136. SRP Updates consist of a set of _instructions_ that together add or - remove one or more services. Each instruction consists either of a - single add, a single delete, or a delete optionally followed by an - add. When an instruction contains a delete and an add, the delete - MUST precede the add. + remove one or more services. Each instruction consists some + combination of delete updates and add updates. When an instruction + contains a delete and an add, the delete MUST precede the add. The SRP server checks each instruction in the SRP update to see that it is either a Service Discovery update, a Service Description update, or a Host Description update. Order matters in DNS updates. Specifically, deletes must precede adds for records that the deletes would affect; otherwise the add will have no effect. This is the only ordering constraint; aside from this constraint, updates may appear in whatever order is convenient when constructing the update. Because the SRP update is a DNS update, it MUST contain a single 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 the SRP Update. 2.3.1.1. Service Discovery Instruction An instruction is a Service Discovery Instruction if it contains - * exactly one "Add to an RRSet" or one "Delete an RR from an RRSet" - ([RFC2136], Section 2.5.1) RR update, + * exactly one "Add to an RRSet" or exactly one "Delete an RR from an + RRSet" ([RFC2136], Section 2.5.1) RR update, * which updates a PTR RR, * which points to a Service Instance Name * for which a Service Description Instruction is present in the SRP Update - * if the Service Discovery update is an "Add to an RRSet" instruction, the Service Description Instruction does not match if it does not contain an "Add to an RRset" update for the SRV RR describing that service. * if the Service Discovery Instruction is an "Delete an RR from an RRSet" update, the Service Description Instruction does not match if it contains an "Add to an RRset" update. * Service Discovery Instructions do not contain any other add or delete updates. @@ -577,26 +596,26 @@ * 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 sign the message (if present, the KEY MUST match the KEY RR given in the Host Description), * zero or more "Add to an RRset" TXT RRs, * If there is one "Add to an RRset" SRV update, there MUST be at least one "Add to an RRset" TXT update. * 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, or - * if there is no "Add to an RRset" SRV RR, then there is an existing - SRV RR on the name specified in the "Delete all RRsets from a - name" update that to a hostname for which there is a Host - 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 - signed. + * if there is no "Add to an RRset" SRV RR, then either + - the name to which the "Delete all RRsets from a name" applies + does not exist, or + + - there is an existing KEY RR on that name, which matches the key + with which the SRP Update was signed. * Service Descriptions Instructions do not modify any other RRs. An SRP server MUST correctly handle compressed names in the SRV target. 2.3.1.3. Host Description Instruction An instruction is a Host Description Instruction if, for the appropriate hostname, it contains @@ -1025,29 +1044,71 @@ +----------------------+-----------------------------+ | Forwardable | True | +----------------------+-----------------------------+ | Global | True | +----------------------+-----------------------------+ | Reserved-by-protocol | False | +----------------------+-----------------------------+ Table 1 -10. Acknowledgments +10. Implementation Status - Thanks to Toke Høiland-Jørgensen, Jonathan Hui and Esko Dijk for - their thorough technical reviews, to Tamara Kemper for doing a nice - 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. + [Note to the RFC Editor: please remove this section prior to + publication.] -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] Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases", Work in Progress, Internet-Draft, draft-sekar-dns-ul-02, 2 August 2018, . [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, . @@ -1094,21 +1155,21 @@ . [SUDN] "Special-Use Domain Names Registry", July 2012, . [LSDZ] "Locally-Served DNS Zones Registry", July 2011, . -12. Informative References +13. Informative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, . [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS @@ -1162,20 +1223,27 @@ Progress, Internet-Draft, draft-cheshire-dnssd-roadmap-03, 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, . + [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, . + [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 _dnssd-srp._tcp. SRV and _dnssd-srp-tls._tcp. record. It