--- 1/draft-ietf-dnssd-srp-08.txt 2021-01-11 06:16:08.608927727 -0800 +++ 2/draft-ietf-dnssd-srp-09.txt 2021-01-11 06:16:08.672929353 -0800 @@ -1,18 +1,18 @@ Internet Engineering Task Force T. Lemon Internet-Draft S. Cheshire Intended status: Standards Track Apple Inc. -Expires: 11 July 2021 7 January 2021 +Expires: 15 July 2021 11 January 2021 Service Registration Protocol for DNS-Based Service Discovery - draft-ietf-dnssd-srp-08 + draft-ietf-dnssd-srp-09 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 11 July 2021. + This Internet-Draft will expire on 15 July 2021. 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 @@ -61,33 +61,33 @@ 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 and Deletes . . . . . . . . . . . 12 2.3.2. Valid SRP Update Requirements . . . . . . . . . . . . 14 2.3.3. FCFS Name And Signature Validation . . . . . . . . . 15 - 2.3.4. SRP Update response . . . . . . . . . . . . . . . . . 15 + 2.3.4. SRP Update response . . . . . . . . . . . . . . . . . 16 2.3.5. Optional Behavior . . . . . . . . . . . . . . . . . . 16 - 3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 16 + 3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 17 4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Cleaning up stale data . . . . . . . . . . . . . . . . . 17 5. Sleep Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6.1. Source Validation . . . . . . . . . . . . . . . . . . . . 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9.1. Registration and Delegation of 'service.arpa' as a Special-Use Domain Name . . . . . . . . . . . . . . . . . 22 9.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 22 9.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 22 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 @@ -629,28 +629,37 @@ * exactly one "Add to an RRset" RR that adds a KEY RR that contains the public key corresponding to the private key that was used to 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 at zero or more Service Discovery - Instructions, the same number of Service Description Instructions, - and exactly one Host Description Instruction. A DNS Update that does - not is not an SRP update. A DNS Update that contains any other adds, - any other deletes, or 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. + 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. + + 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 target of every Service Discovery Instruction MUST be a Service Description Instruction that is present in the SRP Update. There MUST NOT be any Service Description Instruction to which no Service Discovery Instruction points. The target of the SRV record in every Service Description instruction MUST be the single Host Description Instruction. If the definitions of each of these instructions are followed