draft-ietf-dnssd-srp-10.txt   draft-ietf-dnssd-srp-11.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: 13 January 2022 12 July 2021 Expires: 25 April 2022 22 October 2021
Service Registration Protocol for DNS-Based Service Discovery Service Registration Protocol for DNS-Based Service Discovery
draft-ietf-dnssd-srp-10 draft-ietf-dnssd-srp-11
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 13 January 2022. This Internet-Draft will expire on 25 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Service Registration Protocol . . . . . . . . . . . . . . . . 5 2. Service Registration Protocol . . . . . . . . . . . . . . . . 5
2.1. Protocol Variants . . . . . . . . . . . . . . . . . . . . 5 2.1. Protocol Variants . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . 7
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.3.1. How DNS-SD Service Registration differs from
standard RFC2136 DNS Update . . . . . . . . . . . . 8
2.2.4. How to secure it . . . . . . . . . . . . . . . . . . 9 2.2.4. How to secure it . . . . . . . . . . . . . . . . . . 9
2.2.4.1. First-Come First-Served Naming . . . . . . . . . 9
2.2.5. Service Behavior . . . . . . . . . . . . . . . . . . 9 2.2.5. Service Behavior . . . . . . . . . . . . . . . . . . 9
2.2.5.1. Public/Private key pair generation and storage . 9
2.2.5.2. Name Conflict Handling . . . . . . . . . . . . . 10
2.2.5.3. Record Lifetimes . . . . . . . . . . . . . . . . 10
2.2.5.4. Compression in SRV records . . . . . . . . . . . 11
2.2.5.5. Removing published services . . . . . . . . . . . 11
2.3. SRP Server Behavior . . . . . . . . . . . . . . . . . . . 12 2.3. SRP Server Behavior . . . . . . . . . . . . . . . . . . . 12
2.3.1. Validation of Adds and Deletes . . . . . . . . . . . 12 2.3.1. Validation of Adds and Deletes . . . . . . . . . . . 12
2.3.1.1. Service Discovery Instruction . . . . . . . . . . 13
2.3.1.2. Service Description Instruction . . . . . . . . . 13
2.3.1.3. Host Description Instruction . . . . . . . . . . 14
2.3.2. Valid SRP Update Requirements . . . . . . . . . . . . 14 2.3.2. Valid SRP Update Requirements . . . . . . . . . . . . 14
2.3.3. FCFS Name And Signature Validation . . . . . . . . . 15 2.3.3. FCFS Name And Signature Validation . . . . . . . . . 15
2.3.4. SRP Update response . . . . . . . . . . . . . . . . . 16 2.3.4. Handling of Service Subtypes . . . . . . . . . . . . 16
2.3.5. Optional Behavior . . . . . . . . . . . . . . . . . . 16 2.3.5. SRP Update response . . . . . . . . . . . . . . . . . 16
2.3.6. Optional Behavior . . . . . . . . . . . . . . . . . . 16
3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 17 3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 17
4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Cleaning up stale data . . . . . . . . . . . . . . . . . 17 4.1. Cleaning up stale data . . . . . . . . . . . . . . . . . 18
5. Sleep Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5.1. Source Validation . . . . . . . . . . . . . . . . . . . . 20
6.1. Source Validation . . . . . . . . . . . . . . . . . . . . 20 5.2. SRP Server Authentication . . . . . . . . . . . . . . . . 20
6.2. SRP Server Authentication . . . . . . . . . . . . . . . . 21 5.3. Required Signature Algorithm . . . . . . . . . . . . . . 21
6.3. Required Signature Algorithm . . . . . . . . . . . . . . 21 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 7. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 21
8. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8.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 8.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 22
9.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 22 8.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 22
9.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 23 8.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 22
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
12. Normative References . . . . . . . . . . . . . . . . . . . . 24 11. Normative References . . . . . . . . . . . . . . . . . . . . 24
13. Informative References . . . . . . . . . . . . . . . . . . . 26 12. Informative References . . . . . . . . . . . . . . . . . . . 25
Appendix A. Testing using standard RFC2136-compliant servers . . 27 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 . . . . . . . . . . . . . . . . 28 RFC2136-compliant servers . . . . . . . . . . . . . . . . 28
Appendix C. Sample BIND9 configuration for Appendix C. Sample BIND9 configuration for
default.service.arpa. . . . . . . . . . . . . . . . . . . 28 default.service.arpa. . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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
skipping to change at page 13, line 20 skipping to change at page 13, line 20
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 exactly one "Delete an RR from an * exactly one "Add to an RRSet" or exactly one "Delete an RR from an
RRSet" ([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 * the target of which is a Service Instance Name
* for which a Service Description Instruction is present in the SRP * for which name a Service Description Instruction is present in the
Update SRP Update
* if the Service Discovery update is an "Add to an RRSet" * if the Service Discovery Instruction 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 a "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.
2.3.1.2. Service Description Instruction 2.3.1.2. Service Description Instruction
An instruction is a Service Description Instruction if, for the An instruction is a Service Description Instruction if, for the
appropriate Service Instance Name, it contains appropriate Service Instance Name, it contains
skipping to change at page 14, line 39 skipping to change at page 14, line 39
* there is a Service Instance Name Instruction in the SRP update for * there is a Service Instance Name Instruction in the SRP update for
which the SRV RR that is added points to the hostname being which the SRV RR that is added points to the hostname being
updated by this update. updated by this update.
* Host Description updates do not modify any other records. * Host Description updates do not modify any other records.
2.3.2. Valid SRP Update Requirements 2.3.2. Valid SRP Update Requirements
An SRP Update MUST include zero or more Service Discovery An SRP Update MUST include zero or more Service Discovery
instructions. For each Service Discovery instruction, there MUST be instructions. For each Service Discovery instruction, there MUST be
at least one Service Description instruction. Note that in the case at least one Service Description instruction. Note that in the case
of SRP subtypes Section 7.1 of [RFC6763], it's quite possible that of SRP subtypes (Section 7.1 of [RFC6763]), it's quite possible that
two Service Discovery instructions might reference the same Service two Service Discovery instructions might reference the same Service
Description instruction. For each Service Description instruction Description instruction. For each Service Description instruction
there MUST be at least one Service Discovery instruction with its there MUST be at least one Service Discovery instruction with its
service instance name as the target of its PTR record. There MUST be service instance name as the target of its PTR record. There MUST be
exactly one Host Description Instruction. Every Service Description exactly one Host Description Instruction. Every Service Description
instruction must have that Host Description instruction as the target instruction must have that Host Description instruction as the target
of its SRV record. A DNS Update that does not meet these constraints of its SRV record. A DNS Update that does not meet these constraints
is not an SRP update. is not an SRP update.
A DNS Update that contains any additional adds or deletes that cannot A DNS Update that contains any additional adds or deletes that cannot
skipping to change at page 16, line 11 skipping to change at page 16, line 11
REFUSED RCODE. Otherwise, the SRP update is considered valid and REFUSED RCODE. Otherwise, the SRP update is considered valid and
authentic, and is processed according to the method described in authentic, and is processed according to the method described in
RFC2136. RFC2136.
KEY record updates omitted from Service Description update are KEY record updates omitted from Service Description update are
processed as if they had been explicitly present: every Service processed as if they had been explicitly present: every Service
Description that is updated MUST, after the update, have a KEY RR, Description that is updated MUST, after the update, have a KEY RR,
and it must be the same KEY RR that is present in the Host and it must be the same KEY RR that is present in the Host
Description to which the Service Description refers. Description to which the Service Description refers.
2.3.4. SRP Update response 2.3.4. Handling of Service Subtypes
SRP servers MUST treat the update instructions for a service type and
all its subtypes as atomic. That is, when a service and its subtypes
are being updated, whatever information appears in the SRP update is
the entirety of information about that service and its subtypes. If
any subtype appeared in a previous update but does not appear in the
current update, then the DNS server MUST remove that subtype.
Similarly, there is no mechanism for deleting subtypes. A delete of
a service deletes all of its subtypes. To delete an individual
subtype, an SRP update must be constructed that contains the service
type and all subtypes for that service.
2.3.5. SRP Update response
The status that is returned depends on the result of processing the The status that is returned depends on the result of processing the
update, and can be either SUCCESS or SERVFAIL: all other possible update, and can be either SUCCESS or SERVFAIL: all other possible
outcomes should already have been accounted for when applying the outcomes should already have been accounted for when applying the
constraints that qualify the update as an SRP Update. constraints that qualify the update as an SRP Update.
2.3.5. Optional Behavior 2.3.6. Optional Behavior
The server MAY add a Reverse Mapping that corresponds to the Host The server MAY add a Reverse Mapping that corresponds to the Host
Description. This is not required because the Reverse Mapping serves Description. This is not required because the Reverse Mapping serves
no protocol function, but it may be useful for debugging, e.g. in no protocol function, but it may be useful for debugging, e.g. in
annotating network packet traces or logs. In order for the server to annotating network packet traces or logs. In order for the server to
add a reverse mapping update, it must be authoritative for the zone add a reverse mapping update, it must be authoritative for the zone
or have credentials to do the update. The SRP client MAY also do a or have credentials to do the update. The SRP client MAY also do a
reverse mapping update if it has credentials to do so. reverse mapping update if it has credentials to do so.
The server MAY apply additional criteria when accepting updates. In The server MAY apply additional criteria when accepting updates. In
skipping to change at page 19, line 19 skipping to change at page 19, line 46
if they do not include leases. if they do not include leases.
Lease times have a completely different function than TTLs. On an Lease times have a completely different function than TTLs. On an
authoritative DNS server, the TTL on a resource record is a constant: authoritative DNS server, the TTL on a resource record is a constant:
whenever that RR is served in a DNS response, the TTL value sent in whenever that RR is served in a DNS response, the TTL value sent in
the answer is the same. The lease time is never sent as a TTL; its the answer is the same. The lease time is never sent as a TTL; its
sole purpose is to determine when the authoritative DNS server will sole purpose is to determine when the authoritative DNS server will
delete stale records. It is not an error to send a DNS response with delete stale records. It is not an error to send a DNS response with
a TTL of 'n' when the remaining time on the lease is less than 'n'. a TTL of 'n' when the remaining time on the lease is less than 'n'.
5. Sleep Proxy 5. Security Considerations
5.1. Source Validation
Another use of SRP is for devices that sleep to reduce power
consumption.
In this case, in addition to the DNS Update Lease option
[I-D.sekar-dns-ul] described above, the device includes an EDNS(0)
OWNER Option [I-D.cheshire-edns0-owner-option].
The EDNS(0) Update Lease option constitutes a promise by the device
that it will wake up before this time elapses, to renew its
registration and thereby demonstrate that it is still attached to the
network. If it fails to renew the registration by this time, that
indicates that it is no longer attached to the network, and its
registration (except for the KEY in the Host Description) should be
deleted.
The EDNS(0) OWNER Option indicates that the device will be asleep,
and will not be receptive to normal network traffic. When a DNS
server receives a DNS Update with an EDNS(0) OWNER Option, that
signifies that the SRP server should set up a proxy for any IPv4 or
IPv6 address records in the DNS Update message. This proxy should
send ARP or ND messages claiming ownership of the IPv4 and/or IPv6
addresses in the records in question. In addition, the proxy should
answer future ARP or ND requests for those IPv4 and/or IPv6
addresses, claiming ownership of them. When the DNS server receives
a TCP SYN or UDP packet addressed to one of the IPv4 or IPv6
addresses for which it proxying, it should then wake up the sleeping
device using the information in the EDNS(0) OWNER Option. At present
version 0 of the OWNER Option specifies the "Wake-on-LAN Magic
Packet" that needs to be sent; future versions could be extended to
specify other wakeup mechanisms.
Note that although the authoritative DNS server that implements the
SRP function need not be on the same link as the sleeping host, the
Sleep Proxy must be on the same link.
It is not required that sleepy nodes on a Constrained-Node Network
support sleep proxy. Such devices may have different mechanisms for
dealing with sleep and wakeup. An SRP registration for such a device
will be useful regardless of the mechanism whereby messages are
delivered to the sleepy end device. For example, the message might
be held in a buffer for an extended period of time by an intermediate
device on a mesh network, and then delivered to the device when it
wakes up. The exact details of such behaviors are out of scope for
this document.
6. Security Considerations
6.1. Source Validation
SRP updates have no authorization semantics other than first-come, SRP updates have no authorization semantics other than first-come,
first-served. This means that if an attacker from outside of the first-served. This means that if an attacker from outside of the
administrative domain of the server knows the server's IP address, it administrative domain of the server knows the server's IP address, it
can in principle send updates to the server that will be processed can in principle send updates to the server that will be processed
successfully. Servers should therefore be configured to reject successfully. Servers should therefore be configured to reject
updates from source addresses outside of the administrative domain of updates from source addresses outside of the administrative domain of
the server. the server.
For updates sent to an anycast IP address of an SRP server, this For updates sent to an anycast IP address of an SRP server, this
skipping to change at page 21, line 10 skipping to change at page 20, line 42
For example, a normal, authenticated DNS update to any RR that was For example, a normal, authenticated DNS update to any RR that was
added using SRP, but that is authenticated using a different key, added using SRP, but that is authenticated using a different key,
could be used to override a promise made by the registration could be used to override a promise made by the registration
protocol, by replacing all or part of the service registration protocol, by replacing all or part of the service registration
information with information provided by an SRP client. An information with information provided by an SRP client. An
implementation that allows both kinds of updates should not allow DNS implementation that allows both kinds of updates should not allow DNS
Update clients that are using different authentication and Update clients that are using different authentication and
authorization credentialsto to update records added by SRP clients. authorization credentialsto to update records added by SRP clients.
6.2. SRP Server Authentication 5.2. SRP Server Authentication
This specification does not provide a mechanism for validating This specification does not provide a mechanism for validating
responses from DNS servers to SRP clients. In the case of responses from DNS servers to SRP clients. In the case of
Constrained Network/Constrained Node clients, such validation isn't Constrained Network/Constrained Node clients, such validation isn't
practical because there's no way to establish trust. In principle, a practical because there's no way to establish trust. In principle, a
KEY RR could be used by a non-constrained SRP client to validate KEY RR could be used by a non-constrained SRP client to validate
responses from the server, but this is not required, nor do we responses from the server, but this is not required, nor do we
specify a mechanism for determining which key to use. specify a mechanism for determining which key to use.
6.3. Required Signature Algorithm 5.3. Required Signature Algorithm
For validation, SRP servers MUST implement the ECDSAP256SHA256 For validation, SRP servers MUST implement the ECDSAP256SHA256
signature algorithm. SRP servers SHOULD implement the algorithms signature algorithm. SRP servers SHOULD implement the algorithms
specified in [RFC8624], Section 3.1, in the validation column of the specified in [RFC8624], Section 3.1, in the validation column of the
table, that are numbered 13 or higher and have a "MUST", table, that are numbered 13 or higher and have a "MUST",
"RECOMMENDED", or "MAY" designation in the validation column of the "RECOMMENDED", or "MAY" designation in the validation column of the
table. SRP clients MUST NOT assume that any algorithm numbered lower table. SRP clients MUST NOT assume that any algorithm numbered lower
than 13 is available for use in validating SIG(0) signatures. than 13 is available for use in validating SIG(0) signatures.
7. Privacy Considerations 6. Privacy Considerations
Because DNSSD SRP updates can be sent off-link, the privacy Because DNSSD SRP updates can be sent off-link, the privacy
implications of SRP are different than for multicast DNS responses. implications of SRP are different than for multicast DNS responses.
Host implementations that are using TCP SHOULD also use TLS if Host implementations that are using TCP SHOULD also use TLS if
available. Server implementations MUST offer TLS support. The use available. Server implementations MUST offer TLS support. The use
of TLS with DNS is described in [RFC7858] and [RFC8310]. of TLS with DNS is described in [RFC7858] and [RFC8310].
Hosts that implement TLS support SHOULD NOT fall back to TCP; since Hosts that implement TLS support SHOULD NOT fall back to TCP; since
servers are required to support TLS, it is entirely up to the host servers are required to support TLS, it is entirely up to the host
implementation whether to use it. implementation whether to use it.
Public keys can be used as identifiers to track hosts. SRP servers Public keys can be used as identifiers to track hosts. SRP servers
MAY elect not to return KEY records for queries for SRP MAY elect not to return KEY records for queries for SRP
registrations. registrations.
8. Delegation of 'service.arpa.' 7. Delegation of 'service.arpa.'
In order to be fully functional, the owner of the 'arpa.' zone must In order to be fully functional, the owner of the 'arpa.' zone must
add a delegation of 'service.arpa.' in the '.arpa.' zone [RFC3172]. add a delegation of 'service.arpa.' in the '.arpa.' zone [RFC3172].
This delegation should be set up as was done for 'home.arpa', as a This delegation should be set up as was done for 'home.arpa', as a
result of the specification in Section 7 of [RFC8375]. result of the specification in Section 7 of [RFC8375].
9. IANA Considerations 8. IANA Considerations
9.1. Registration and Delegation of 'service.arpa' as a Special-Use 8.1. Registration and Delegation of 'service.arpa' as a Special-Use
Domain Name Domain Name
IANA is requested to record the domain name 'service.arpa.' in the IANA is requested to record the domain name 'service.arpa.' in the
Special-Use Domain Names registry [SUDN]. IANA is requested, with Special-Use Domain Names registry [SUDN]. IANA is requested, with
the approval of IAB, to implement the delegation requested in the approval of IAB, to implement the delegation requested in
Section 8. Section 7.
IANA is further requested to add a new entry to the "Transport- IANA is further requested to add a new entry to the "Transport-
Independent Locally-Served Zones" subregistry of the the "Locally- Independent Locally-Served Zones" subregistry of the the "Locally-
Served DNS Zones" registry [LSDZ]. The entry will be for the domain Served DNS Zones" registry [LSDZ]. The entry will be for the domain
'service.arpa.' with the description "DNS-SD Registration Protocol 'service.arpa.' with the description "DNS-SD Registration Protocol
Special-Use Domain", listing this document as the reference. Special-Use Domain", listing this document as the reference.
9.2. 'dnssd-srp' Service Name 8.2. 'dnssd-srp' Service Name
IANA is also requested to add a new entry to the Service Names and IANA is also requested to add a new entry to the Service Names and
Port Numbers registry for dnssd-srp with a transport type of tcp. No Port Numbers registry for dnssd-srp with a transport type of tcp. No
port number is to be assigned. The reference should be to this port number is to be assigned. The reference should be to this
document, and the Assignee and Contact information should reference document, and the Assignee and Contact information should reference
the authors of this document. The Description should be as follows: the authors of this document. The Description should be as follows:
Availability of DNS Service Discovery Service Registration Protocol Availability of DNS Service Discovery Service Registration Protocol
Service for a given domain is advertised using the Service for a given domain is advertised using the
"_dnssd-srp._tcp.<domain>." SRV record gives the target host and "_dnssd-srp._tcp.<domain>." SRV record gives the target host and
port where DNSSD Service Registration Service is provided for the port where DNSSD Service Registration Service is provided for the
named domain. named domain.
9.3. 'dnssd-srp-tls' Service Name 8.3. 'dnssd-srp-tls' Service Name
IANA is also requested to add a new entry to the Service Names and IANA is also requested to add a new entry to the Service Names and
Port Numbers registry for dnssd-srp with a transport type of tcp. No Port Numbers registry for dnssd-srp with a transport type of tcp. No
port number is to be assigned. The reference should be to this port number is to be assigned. The reference should be to this
document, and the Assignee and Contact information should reference document, and the Assignee and Contact information should reference
the authors of this document. The Description should be as follows: the authors of this document. The Description should be as follows:
Availability of DNS Service Discovery Service Registration Protocol Availability of DNS Service Discovery Service Registration Protocol
Service for a given domain over TLS is advertised using the Service for a given domain over TLS is advertised using the
"_dnssd-srp-tls._tcp.<domain>." SRV record gives the target host and "_dnssd-srp-tls._tcp.<domain>." SRV record gives the target host and
port where DNSSD Service Registration Service is provided for the port where DNSSD Service Registration Service is provided for the
named domain. named domain.
9.4. Anycast Address 8.4. Anycast Address
IANA is requested to allocate an IPv6 Anycast address from the IPv6 IANA is requested to allocate an IPv6 Anycast address from the IPv6
Special-Purpose Address Registry, similar to the Port Control Special-Purpose Address Registry, similar to the Port Control
Protocol anycast address, 2001:1::1. The value TBD should be Protocol anycast address, 2001:1::1. The value TBD should be
replaced with the actual allocation in the table that follows. The replaced with the actual allocation in the table that follows. The
values for the registry are: values for the registry are:
+----------------------+-----------------------------+ +----------------------+-----------------------------+
| Attribute | value | | Attribute | value |
+----------------------+-----------------------------+ +----------------------+-----------------------------+
skipping to change at page 23, line 40 skipping to change at page 23, line 32
+----------------------+-----------------------------+ +----------------------+-----------------------------+
| Forwardable | True | | Forwardable | True |
+----------------------+-----------------------------+ +----------------------+-----------------------------+
| Global | True | | Global | True |
+----------------------+-----------------------------+ +----------------------+-----------------------------+
| Reserved-by-protocol | False | | Reserved-by-protocol | False |
+----------------------+-----------------------------+ +----------------------+-----------------------------+
Table 1 Table 1
10. Implementation Status 9. Implementation Status
[Note to the RFC Editor: please remove this section prior to [Note to the RFC Editor: please remove this section prior to
publication.] publication.]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC 7942. Internet-Draft, and is based on a proposal described in RFC 7942.
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
skipping to change at page 24, line 30 skipping to change at page 24, line 22
* mDNSResponder open source project: https://github.com/Abhayakara/ * mDNSResponder open source project: https://github.com/Abhayakara/
mdnsresponder mdnsresponder
There are two related implementations of an SRP server. One acts as 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 a DNS Update proxy, taking an SRP update and applying it to the
specified DNS zone using DNS update. The other acts as an specified DNS zone using DNS update. The other acts as an
Advertising Proxy [I-D.sctl-advertising-proxy]. Both are included in Advertising Proxy [I-D.sctl-advertising-proxy]. Both are included in
the mDNSResponder open source project mentioned above. the mDNSResponder open source project mentioned above.
11. Acknowledgments 10. Acknowledgments
Thanks to Toke Høiland-Jørgensen, Jonathan Hui, Esko Dijk, Kangping Thanks to Toke Høiland-Jørgensen, Jonathan Hui, Esko Dijk, Kangping
Dong and Abtin Keshavarzian for their thorough technical reviews. Dong and Abtin Keshavarzian for their thorough technical reviews.
Thanks to Kangping and Abtin as well for testing the document by Thanks to Kangping and Abtin as well for testing the document by
doing an independent implementation. Thanks to Tamara Kemper for doing an independent implementation. Thanks to Tamara Kemper for
doing a nice developmental edit, Tim Wattenberg for doing a SRP doing a nice developmental edit, Tim Wattenberg for doing a SRP
client proof-of-concept implementation at the Montreal Hackathon at client proof-of-concept implementation at the Montreal Hackathon at
IETF 102, and Tom Pusateri for reviewing during the hackathon and IETF 102, and Tom Pusateri for reviewing during the hackathon and
afterwards. afterwards.
12. Normative References 11. 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, "An EDNS0 option to negotiate
Work in Progress, Internet-Draft, draft-sekar-dns-ul-02, 2 Leases on DNS Updates", Work in Progress, Internet-Draft,
August 2018, <https://datatracker.ietf.org/doc/html/draft- draft-sekar-dns-ul-03, 27 July 2021,
sekar-dns-ul-02>. <https://datatracker.ietf.org/doc/html/draft-sekar-dns-ul-
03>.
[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>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997, RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>. <https://www.rfc-editor.org/info/rfc2136>.
skipping to change at page 26, line 5 skipping to change at page 25, line 49
<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>.
13. Informative References 12. 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 27, line 31 skipping to change at page 27, line 31
[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, option-01, 3 July 2017,
<https://datatracker.ietf.org/doc/html/draft-cheshire- <https://datatracker.ietf.org/doc/html/draft-cheshire-
edns0-owner-option-01>. edns0-owner-option-01>.
[I-D.sctl-advertising-proxy] [I-D.sctl-advertising-proxy]
Cheshire, S. and T. Lemon, "Advertising Proxy for DNS-SD Cheshire, S. and T. Lemon, "Advertising Proxy for DNS-SD
Service Registration Protocol", Work in Progress, Service Registration Protocol", Work in Progress,
Internet-Draft, draft-sctl-advertising-proxy-01, 22 Internet-Draft, draft-sctl-advertising-proxy-02, 12 July
February 2021, <https://datatracker.ietf.org/doc/html/ 2021, <https://datatracker.ietf.org/doc/html/draft-sctl-
draft-sctl-advertising-proxy-01>. advertising-proxy-02>.
[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
 End of changes. 33 change blocks. 
105 lines changed or deleted 83 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/