draft-ietf-dnssd-srp-05.txt   draft-ietf-dnssd-srp-06.txt 
Internet Engineering Task Force T. Lemon Internet Engineering Task Force T. Lemon
Internet-Draft S. Cheshire Internet-Draft S. Cheshire
Intended status: Informational Apple Inc. Intended status: Standards Track Apple Inc.
Expires: April 29, 2021 October 26, 2020 Expires: 22 May 2021 18 November 2020
Service Registration Protocol for DNS-Based Service Discovery Service Registration Protocol for DNS-Based Service Discovery
draft-ietf-dnssd-srp-05 draft-ietf-dnssd-srp-06
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 April 29, 2021. This Internet-Draft will expire on 22 May 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Service Registration Protocol . . . . . . . . . . . . . . . . 4 2. Service Registration Protocol . . . . . . . . . . . . . . . . 5
2.1. What to publish . . . . . . . . . . . . . . . . . . . . . 6 2.1. Protocol Variants . . . . . . . . . . . . . . . . . . . . 5
2.2. Where to publish it . . . . . . . . . . . . . . . . . . . 7 2.1.1. Full-featured Hosts . . . . . . . . . . . . . . . . . 5
2.3. How to publish it . . . . . . . . . . . . . . . . . . . . 7 2.1.2. Constrained Hosts . . . . . . . . . . . . . . . . . . 6
2.3.1. How DNS-SD Service Registration differs from standard 2.1.3. Why two variants? . . . . . . . . . . . . . . . . . . 6
RFC2136 DNS Update . . . . . . . . . . . . . . . . . 8 2.2. Protocol Details . . . . . . . . . . . . . . . . . . . . 6
2.4. How to secure it . . . . . . . . . . . . . . . . . . . . 8 2.2.1. What to publish . . . . . . . . . . . . . . . . . . . 7
2.4.1. First-Come First-Served Naming . . . . . . . . . . . 8 2.2.2. Where to publish it . . . . . . . . . . . . . . . . . 7
2.4.2. Removing published services . . . . . . . . . . . . . 10 2.2.3. How to publish it . . . . . . . . . . . . . . . . . . 8
2.4.3. SRP Server Behavior . . . . . . . . . . . . . . . . . 10 2.2.4. How to secure it . . . . . . . . . . . . . . . . . . 9
2.5. TTL Consistency . . . . . . . . . . . . . . . . . . . . . 13 2.2.5. Service Behavior . . . . . . . . . . . . . . . . . . 9
2.6. Maintenance . . . . . . . . . . . . . . . . . . . . . . . 14 2.3. SRP Server Behavior . . . . . . . . . . . . . . . . . . . 11
2.6.1. Cleaning up stale data . . . . . . . . . . . . . . . 14 2.3.1. Validation of Adds . . . . . . . . . . . . . . . . . 11
2.6.2. Sleep Proxy . . . . . . . . . . . . . . . . . . . . . 15 2.3.2. Valid SRP Update Requirements . . . . . . . . . . . . 13
3. Security Considerations . . . . . . . . . . . . . . . . . . . 16 2.3.3. FCFS Name And Signature Validation . . . . . . . . . 14
3.1. Source Validation . . . . . . . . . . . . . . . . . . . . 16 2.3.4. SRP Update response . . . . . . . . . . . . . . . . . 14
3.2. SIG(0) signature validation . . . . . . . . . . . . . . . 17 2.3.5. Optional Behavior . . . . . . . . . . . . . . . . . . 14
3.3. Required Signature Algorithm . . . . . . . . . . . . . . 17 3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 15
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 17 4.1. Cleaning up stale data . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. Sleep Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Registration and Delegation of 'service.arpa' as a 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
Special-Use Domain Name . . . . . . . . . . . . . . . . . 18 6.1. Source Validation . . . . . . . . . . . . . . . . . . . . 18
6.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 18 6.2. SRP Server Authentication . . . . . . . . . . . . . . . . 19
6.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 18 6.3. Required Signature Algorithm . . . . . . . . . . . . . . 19
6.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 19 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 8. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.1. Registration and Delegation of 'service.arpa' as a
8.2. Informative References . . . . . . . . . . . . . . . . . 20 Special-Use Domain Name . . . . . . . . . . . . . . . . . 20
Appendix A. Testing using standard RFC2136-compliant servers . . 22 9.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 20
9.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 20
9.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
11. Normative References . . . . . . . . . . . . . . . . . . . . 22
12. Informative References . . . . . . . . . . . . . . . . . . . 23
Appendix A. Testing using standard RFC2136-compliant servers . . 24
Appendix B. How to allow services to update standard Appendix B. How to allow services to update standard
RFC2136-compliant servers . . . . . . . . . . . . . 22 RFC2136-compliant servers . . . . . . . . . . . . . . . . 25
Appendix C. Sample BIND9 configuration for default.service.arpa. 23 Appendix C. Sample BIND9 configuration for
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 default.service.arpa. . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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 3, line 26 skipping to change at page 3, line 28
This document is intended for three audiences: implementors of This document is intended for three audiences: implementors of
software that provides services that should be advertised using software that provides services that should be advertised using
DNS-SD, implementors of DNS servers that will be used in contexts DNS-SD, implementors of DNS servers that will be used in contexts
where DNS-SD registration is needed, and administrators of networks where DNS-SD registration is needed, and administrators of networks
where DNS-SD service is required. The document is intended to where DNS-SD service is required. The document is intended to
provide sufficient information to allow interoperable implementation provide sufficient information to allow interoperable implementation
of the registration protocol. of the registration protocol.
DNS-Based Service Discovery (DNS-SD) allows services to advertise the DNS-Based Service Discovery (DNS-SD) allows services to advertise the
fact that they provide service, and to provide the information fact that they provide service, and to provide the information
required to access that service. Clients can then discover the set required to access that service. DNS-SD clients can then discover
of services of a particular type that are available. They can then the set of services of a particular type that are available. They
select a service from among those that are available and obtain the can then select a service from among those that are available and
information required to use it. Although DNS-SD using the DNS obtain the information required to use it. Although DNS-SD using the
protocol (as opposed to mDNS) can be more efficient and versatile, it DNS protocol (as opposed to mDNS) can be more efficient and
is not common in practice, because of the difficulties associated versatile, it is not common in practice, because of the difficulties
with updating authoritative DNS services with service information. associated with updating authoritative DNS services with service
information.
Existing practice for updating DNS zones is to either manually enter Existing practice for updating DNS zones is to either manually enter
new data, or else use DNS Update [RFC2136]. Unfortunately DNS Update new data, or else use DNS Update [RFC2136]. Unfortunately DNS Update
requires either that the authoritative DNS server automatically trust requires either that the authoritative DNS server automatically trust
updates, or else that the DNS Update client have some kind of shared updates, or else that the DNS Update client have some kind of shared
secret or public key that is known to the DNS server and can be used secret or public key that is known to the DNS server and can be used
to authenticate the update. Furthermore, DNS Update can be a fairly to authenticate the update. Furthermore, DNS Update can be a fairly
chatty process, requiring multiple round trips with different chatty process, requiring multiple round trips with different
conditional predicates to complete the update process. conditional predicates to complete the update process.
skipping to change at page 4, line 21 skipping to change at page 4, line 25
Dynamic Host Configuration Protocol [RFC8415]. The SRP registration Dynamic Host Configuration Protocol [RFC8415]. The SRP registration
itself has a lease which may be on the order of an hour; if the itself has a lease which may be on the order of an hour; if the
registering service does not renew the lease before it has elapsed, registering service does not renew the lease before it has elapsed,
the registration is removed. The claim on the name can have a longer the registration is removed. The claim on the name can have a longer
lease, so that another service cannot claim the name, even though the lease, so that another service cannot claim the name, even though the
registration has expired. registration has expired.
The Service Registration Protocol for DNS-SD (SRP), described in this The Service Registration Protocol for DNS-SD (SRP), described in this
document, provides a reasonably secure mechanism for publishing this document, provides a reasonably secure mechanism for publishing this
information. Once published, these services can be readily information. Once published, these services can be readily
discovered by clients using standard DNS lookups. discovered by DNS-SD clients using standard DNS lookups.
The DNS-SD specification [RFC6763], Section 10 ("Populating the DNS The DNS-SD specification [RFC6763], Section 10 ("Populating the DNS
with Information"), briefly discusses ways that services can publish with Information"), briefly discusses ways that services can publish
their information in the DNS namespace. In the case of mDNS, it their information in the DNS namespace. In the case of mDNS, it
allows services to publish their information on the local link, using allows services to publish their information on the local link, using
names in the ".local" namespace, which makes their services directly names in the ".local" namespace, which makes their services directly
discoverable by peers attached to that same local link. discoverable by peers attached to that same local link.
RFC6763 also allows clients to discover services using the DNS RFC6763 also allows clients to discover services using the DNS
protocol [RFC1035]. This can be done by having a system protocol [RFC1035]. This can be done by having a system
skipping to change at page 4, line 51 skipping to change at page 5, line 10
services are easily advertised using mDNS. This document describes a services are easily advertised using mDNS. This document describes a
solution more suitable for networks where multicast is inefficient, solution more suitable for networks where multicast is inefficient,
or where sleepy devices are common, by supporting both offering of or where sleepy devices are common, by supporting both offering of
services, and discovery of services, using unicast. services, and discovery of services, using unicast.
2. Service Registration Protocol 2. Service Registration Protocol
Services that implement SRP use DNS Update [RFC2136] [RFC3007] to Services that implement SRP use DNS Update [RFC2136] [RFC3007] to
publish service information in the DNS. Two variants exist, one for publish service information in the DNS. Two variants exist, one for
full-featured hosts, and one for devices designed for "Constrained- full-featured hosts, and one for devices designed for "Constrained-
Node Networks" [RFC7228]. Node Networks" [RFC7228]. An SRP server is most likely an
authoritative DNS server, or else is updating an authoritative DNS
server. There is no requirement that the server that is receiving
SRP requests be the same server that is answering queries that return
records that have been registered.
2.1. Protocol Variants
2.1.1. Full-featured Hosts
Full-featured hosts are either configured manually with a Full-featured hosts are either configured manually with a
registration domain, or use the "dr._dns-sd._udp.<domain>" query registration domain, or use the "dr._dns-sd._udp.<domain>" query
([RFC6763] Section 11) to learn the default registration domain from ([RFC6763], Section 11) to learn the default registration domain from
the network. RFC6763 says to discover the registration domain using the network. RFC6763 says to discover the registration domain using
either ".local" or a network-supplied domain name for <domain>. either ".local" or a network-supplied domain name for <domain>.
Services using SRP MUST use the domain name received through the Services using SRP MUST use the domain name received through the
DHCPv4 Domain Name option ([RFC2132] section 3.17), if available, or DHCPv4 Domain Name option ([RFC2132], Section 3.17), if available, or
the Neighbor Discovery DNS Search List option [RFC8106]. If the DNS the Neighbor Discovery DNS Search List option [RFC8106]. If the DNS
Search List option contains more than one domain name, it MUST NOT be Search List option contains more than one domain name, it MUST NOT be
used. If neither option is available, the Service Registration used. If neither option is available, the Service Registration
protocol is not available on the local network. protocol is not available on the local network.
Manual configuration of the registration domain can be done either by Manual configuration of the registration domain can be done either by
querying the list of available registration zones ("r._dns-sd._udp") querying the list of available registration zones ("r._dns-sd._udp")
and allowing the user to select one from the UI, or by any other and allowing the user to select one from the UI, or by any other
means appropriate to the particular use case being addressed. Full- means appropriate to the particular use case being addressed. Full-
featured devices construct the names of the SRV, TXT, and PTR records featured devices construct the names of the SRV, TXT, and PTR records
describing their service(s) as subdomains of the chosen service describing their service(s) as subdomains of the chosen service
registration domain. For these names they then discover the zone registration domain. For these names they then discover the zone
apex of the closest enclosing DNS zone using SOA queries [RFC8765]. apex of the closest enclosing DNS zone using SOA queries [RFC8765].
Having discovered the enclosing DNS zone, they query for the Having discovered the enclosing DNS zone, they query for the
"_dnssd-srp._tcp<zone>" SRV record to discover the server to which "_dnssd-srp._tcp.<zone>" SRV record to discover the server to which
they should send DNS updates. Hosts that support SRP updates using they should send DNS updates. Hosts that support SRP updates using
TLS use the "_dnssd-srp-tls._tcp<zone>" SRV record instead. TLS use the "_dnssd-srp-tls._tcp.<zone>" SRV record instead.
2.1.2. Constrained Hosts
For devices designed for Constrained-Node Networks [RFC7228] some For devices designed for Constrained-Node Networks [RFC7228] some
simplifications are available. Instead of being configured with (or simplifications are available. Instead of being configured with (or
discovering) the service registration domain, the (proposed) special- discovering) the service registration domain, the (proposed) special-
use domain name (see [RFC6761]) "default.service.arpa" is used. The use domain name (see [RFC6761]) "default.service.arpa" is used. The
details of how SRP server(s) are discovered will be specific to the details of how SRP server(s) are discovered will be specific to the
constrained network, and therefore we do not suggest a specific constrained network, and therefore we do not suggest a specific
mechanism here. mechanism here.
SRP clients on constrained networks are expected to receive from the SRP clients on constrained networks are expected to receive from the
network a list of SRP servers with which to register. It is the network a list of SRP servers with which to register. It is the
responsibility of a Constrained-Node Network supporting SRP to responsibility of a Constrained-Node Network supporting SRP to
provide one or more SRP server addresses. It is the responsibility provide one or more SRP server addresses. It is the responsibility
of the SRP server supporting a Constrained-Node Network to handle the of the SRP server supporting a Constrained-Node Network to handle the
updates appropriately. In some network environments, updates may be updates appropriately. In some network environments, updates may be
accepted directly into a local "default.service.arpa" zone, which has accepted directly into a local "default.service.arpa" zone, which has
only local visibility. In other network environments, updates for only local visibility. In other network environments, updates for
names ending in "default.service.arpa" may be rewritten internally to names ending in "default.service.arpa" may be rewritten internally to
names with broader visibility. names with broader visibility.
2.1.3. Why two variants?
The reason for these different assumptions is that low-power devices The reason for these different assumptions is that low-power devices
that typically use Constrained-Node Networks may have very limited that typically use Constrained-Node Networks may have very limited
battery power. The series of DNS lookups required to discover an SRP battery power. The series of DNS lookups required to discover an SRP
server and then communicate with it will increase the power required server and then communicate with it will increase the power required
to advertise a service; for low-power devices, the additional to advertise a service; for low-power devices, the additional
flexibility this provides does not justify the additional use of flexibility this provides does not justify the additional use of
power. It is also fairly typical of such networks that some network power. It is also fairly typical of such networks that some network
service information is obtained as part of the process of joining the 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 network, and so this can be relied upon to provide nodes with the
information they need. information they need.
Networks that are not constrained networks can more complicated Networks that are not constrained networks can more complicated
topologies at the Internet layer. Nodes connected to such networks topologies at the Internet layer. Nodes connected to such networks
can be assumed to be able to do DNSSD service registration domain can be assumed to be able to do DNSSD service registration domain
discovery. Such networks are generally able to provide registration discovery. Such networks are generally able to provide registration
domain discovery and routing. By requiring the use of TCP, the domain discovery and routing. By requiring the use of TCP, the
possibility of off-network spoofing is eliminated. possibility of off-network spoofing is eliminated.
2.2. Protocol Details
We will discuss several parts to this process: how to know what to 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 publish, how to know where to publish it (under what name), how to
publish it, how to secure its publication, and how to maintain the publish it, how to secure its publication, and how to maintain the
information once published. information once published.
2.1. What to publish 2.2.1. What to publish
We refer to the DNS Update message sent by services using SRP as an We refer to the DNS Update message sent by services using SRP as an
SRP update. Three types of updates appear in an SRP update: Service SRP update. Three types of updates appear in an SRP update: Service
Discovery records, Service Description records, and Host Description Discovery records, Service Description records, and Host Description
records. records.
o Service Discovery records are one or more PTR RRs, mapping from * Service Discovery records are one or more PTR RRs, mapping from
the generic service type (or subtype) to the specific Service the generic service type (or subtype) to the specific Service
Instance Name. Instance Name.
* Service Description records are exactly one SRV RR, exactly one
o Service Description records are exactly one SRV RR, exactly one
KEY RR, and one or more TXT RRs, all with the same name, the KEY RR, and one or more TXT RRs, all with the same name, the
Service Instance Name ([RFC6763] section 4.1). In principle Service Instance Name ([RFC6763], Section 4.1). In principle
Service Description records can include other record types, with Service Description records can include other record types, with
the same Service Instance Name, though in practice they rarely do. the same Service Instance Name, though in practice they rarely do.
The Service Instance Name MUST be referenced by one or more The Service Instance Name MUST be referenced by one or more
Service Discovery PTR records, unless it is a placeholder service Service Discovery PTR records, unless it is a placeholder service
registration for an intentionally non-discoverable service name. registration for an intentionally non-discoverable service name.
* The Host Description records for a service are a KEY RR, used to
o The Host Description records for a service are a KEY RR, used to
claim exclusive ownership of the service registration, and one or claim exclusive ownership of the service registration, and one or
more RRs of type A or AAAA, giving the IPv4 or IPv6 address(es) of more RRs of type A or AAAA, giving the IPv4 or IPv6 address(es) of
the host where the service resides. the host where the service resides.
RFC 6763 describes the details of what each of these types of updates RFC 6763 describes the details of what each of these types of updates
contains and is the definitive source for information about what to contains and is the definitive source for information about what to
publish; the reason for summarizing this here is to provide the publish; the reason for summarizing this here is to provide the
reader with enough information about what will be published that the reader with enough information about what will be published that the
service registration process can be understood at a high level service registration process can be understood at a high level
without first learning the full details of DNS-SD. Also, the without first learning the full details of DNS-SD. Also, the
"Service Instance Name" is an important aspect of first-come, first- "Service Instance Name" is an important aspect of first-come, first-
serve naming, which we describe later on in this document. serve naming, which we describe later on in this document.
2.2. Where to publish it 2.2.2. Where to publish it
Multicast DNS uses a single namespace, ".local", which is valid on Multicast DNS uses a single namespace, ".local", which is valid on
the local link. This convenience is not available for DNS-SD using the local link. This convenience is not available for DNS-SD using
the DNS protocol: services must exist in some specific unicast the DNS protocol: services must exist in some specific unicast
namespace. namespace.
As described above, full-featured devices are responsible for knowing As described above, full-featured devices are responsible for knowing
in what domain they should register their services. Devices made for in what domain they should register their services. Devices made for
Constrained-Node Networks register in the (proposed) special use Constrained-Node Networks register in the (proposed) special use
domain name [RFC6761] "default.service.arpa", and let the SRP server domain name [RFC6761] "default.service.arpa", and let the SRP server
handle rewriting that to a different domain if necessary. handle rewriting that to a different domain if necessary.
2.3. How to publish it 2.2.3. How to publish it
It is possible to issue a DNS Update that does several things at It is possible to issue a DNS Update that does several things at
once; this means that it's possible to do all the work of adding a once; this means that it's possible to do all the work of adding a
PTR resource record to the PTR RRset on the Service Name, and PTR resource record to the PTR RRset on the Service Name, and
creating or updating the Service Instance Name and Host Description, creating or updating the Service Instance Name and Host Description,
in a single transaction. in a single transaction.
An SRP update takes advantage of this: it is implemented as a single An SRP update takes advantage of this: it is implemented as a single
DNS Update message that contains a service's Service Discovery DNS Update message that contains a service's Service Discovery
records, Service Description records, and Host Description records. records, Service Description records, and Host Description records.
skipping to change at page 7, line 44 skipping to change at page 8, line 27
Updates done according to this specification are somewhat different Updates done according to this specification are somewhat different
than regular DNS Updates as defined in RFC2136. The RFC2136 update than regular DNS Updates as defined in RFC2136. The RFC2136 update
process can involve many update attempts: you might first attempt to process can involve many update attempts: you might first attempt to
add a name if it doesn't exist; if that fails, then in a second add a name if it doesn't exist; if that fails, then in a second
message you might update the name if it does exist but matches message you might update the name if it does exist but matches
certain preconditions. Because the registration protocol uses a certain preconditions. Because the registration protocol uses a
single transaction, some of this adaptability is lost. single transaction, some of this adaptability is lost.
In order to allow updates to happen in a single transaction, SRP In order to allow updates to happen in a single transaction, SRP
updates do not include update prerequisites. The requirements updates do not include update prerequisites. The requirements
specified in Section 2.4.3 are implicit in the processing of SRP specified in Section 2.3 are implicit in the processing of SRP
updates, and so there is no need for the service sending the SRP updates, and so there is no need for the service sending the SRP
update to put in any explicit prerequisites. update to put in any explicit prerequisites.
2.3.1. How DNS-SD Service Registration differs from standard RFC2136 2.2.3.1. How DNS-SD Service Registration differs from standard RFC2136
DNS Update DNS Update
DNS-SD Service Registration is based on standard RFC2136 DNS Update, DNS-SD Service Registration is based on standard RFC2136 DNS Update,
with some differences: with some differences:
o It implements first-come first-served name allocation, protected * It implements first-come first-served name allocation, protected
using SIG(0) [RFC2931]. using SIG(0) [RFC2931].
* It enforces policy about what updates are allowed.
o It enforces policy about what updates are allowed. * It optionally performs rewriting of "default.service.arpa" to some
o It optionally performs rewriting of "default.service.arpa" to some
other domain. other domain.
* It optionally performs automatic population of the address-to-name
o It optionally performs automatic population of the address-to-name
reverse mapping domains. reverse mapping domains.
* An SRP server is not required to implement general DNS Update
o An SRP server is not required to implement general DNS Update
prerequisite processing. prerequisite processing.
* SRP clients are allowed to send updates to the generic domain
o Clients are allowed to send updates to the generic domain
"default.service.arpa" "default.service.arpa"
2.4. How to secure it 2.2.4. How to secure it
Traditional DNS update is secured using the TSIG protocol, which uses Traditional DNS update is secured using the TSIG protocol, which uses
a secret key shared between the client (which issues the update) and a secret key shared between the DNS Update client (which issues the
the server (which authenticates it). This model does not work for update) and the server (which authenticates it). This model does not
automatic service registration. work for automatic service registration.
The goal of securing the DNS-SD Registration Protocol is to provide The goal of securing the DNS-SD Registration Protocol is to provide
the best possible security given the constraint that service the best possible security given the constraint that service
registration has to be automatic. It is possible to layer more registration has to be automatic. It is possible to layer more
operational security on top of what we describe here, but what we operational security on top of what we describe here, but what we
describe here is an improvement over the security of mDNS. The goal describe here is an improvement over the security of mDNS. The goal
is not to provide the level of security of a network managed by a is not to provide the level of security of a network managed by a
skilled operator. skilled operator.
2.4.1. First-Come First-Served Naming 2.2.4.1. First-Come First-Served Naming
First-Come First-Serve naming provides a limited degree of security: First-Come First-Serve naming provides a limited degree of security:
a service that registers its service using DNS-SD Registration a service that registers its service using DNS-SD Registration
protocol is given ownership of a name for an extended period of time protocol is given ownership of a name for an extended period of time
based on the key used to authenticate the DNS Update. As long as the based on the key used to authenticate the DNS Update. As long as the
registration service remembers the name and the key used to register registration service remembers the name and the key used to register
that name, no other service can add or update the information that name, no other service can add or update the information
associated with that. FCFS naming is used to protect both the associated with that. FCFS naming is used to protect both the
Service Description and the Host Description. Service Description and the Host Description.
2.4.1.1. Service Behavior 2.2.5. Service Behavior
2.2.5.1. Public/Private key pair generation and storage
The service generates a public/private key pair. This key pair MUST The service generates a public/private key pair. This key pair MUST
be stored in stable storage; if there is no writable stable storage be stored in stable storage; if there is no writable stable storage
on the client, the client MUST be pre-configured with a public/ on the SRP client, the SRP client MUST be pre-configured with a
private key pair in read-only storage that can be used. This key public/private key pair in read-only storage that can be used. This
pair MUST be unique to the device. This key pair MUST be unique to key pair MUST be unique to the device. This key pair MUST be unique
the device. A device with rewritable storage + should retain this to the device. A device with rewritable storage should retain this
key indefinitely; the key MAY be overwritten as a result of + a full key indefinitely. When the device changes ownership, it may be
reset of the device (e.g., a "factory reset"). appropriate to erase the old key and install a new one. Therefore
the key MAY be overwritten as a result of a full reset of the device
(e.g., a "factory reset").
When sending DNS updates, the service includes a KEY record When sending DNS updates, the service includes a KEY record
containing the public portion of the key in each Host Description containing the public portion of the key in each Host Description
update and each Service Description update. Each KEY record MUST update and each Service Description update. Each KEY record MUST
contain the same public key. The update is signed using SIG(0), contain the same public key. The update is signed using SIG(0),
using the private key that corresponds to the public key in the KEY using the private key that corresponds to the public key in the KEY
record. The lifetimes of the records in the update is set using the record. The lifetimes of the records in the update is set using the
EDNS(0) Update Lease option [I-D.sekar-dns-ul]. EDNS(0) Update Lease option [I-D.sekar-dns-ul].
The KEY record in Service Description updates MAY be omitted for The KEY record in Service Description updates MAY be omitted for
brevity; if it is omitted, the SRP server MUST behave as if the same brevity; if it is omitted, the SRP server MUST behave as if the same
KEY record that is given for the Host Description is also given for KEY record that is given for the Host Description is also given for
each Service Description for which no KEY record is provided. each Service Description for which no KEY record is provided.
Omitted KEY records are not used when computing the SIG(0) signature. Omitted KEY records are not used when computing the SIG(0) signature.
2.2.5.2. Name Conflict Handling
Both Host Description records and Service Description Records can
have names that result in name conflicts. Service Discovery records
cannot have name conflicts. If any Host Description or Service
Description record is found by the server to have a conflict with an
existing name, the server will respond to the SRP Update with a
YXDOMAIN rcode. In this case, the Service MUST either abandon the
service registration attempt, or else choose a new name.
There is no specific requirement for how this is done; typically,
however, the service will append a number to the preferred name.
This number could be sequentially increasing, or could be chosen
randomly. One existing implementation attempts several sequential
numbers before choosing randomly. So for instance, it might try
host.service.arpa, then host-1.service.arpa, then host-
2.service.arpa, then host-31773.service.arpa.
2.2.5.3. Record Lifetimes
The lifetime of the DNS-SD PTR, SRV, A, AAAA and TXT records The lifetime of the DNS-SD PTR, SRV, A, AAAA and TXT records
[RFC6763] uses the LEASE field of the Update Lease option, and is [RFC6763] uses the LEASE field of the Update Lease option, and is
typically set to two hours. This means that if a device is typically set to two hours. This means that if a device is
disconnected from the network, it does not appear in the user disconnected from the network, it does not appear in the user
interfaces of devices looking for services of that type for too long. interfaces of devices looking for services of that type for too long.
The lifetime of the KEY records is set using the KEY-LEASE field of The lifetime of the KEY records is set using the KEY-LEASE field of
the Update Lease Option, and should be set to a much longer time, the Update Lease Option, and should be set to a much longer time,
typically 14 days. The result of this is that even though a device typically 14 days. The result of this is that even though a device
may be temporarily unplugged, disappearing from the network for a few may be temporarily unplugged, disappearing from the network for a few
days, it makes a claim on its name that lasts much longer. days, it makes a claim on its name that lasts much longer.
This means that even if a device is unplugged from the network for a This means that even if a device is unplugged from the network for a
few days, and its services are not available for that time, no other few days, and its services are not available for that time, no other
device can come along and claim its name the moment it disappears device can come along and claim its name the moment it disappears
from the network. In the event that a device is unplugged from the from the network. In the event that a device is unplugged from the
network and permanently discarded, then its name is eventually network and permanently discarded, then its name is eventually
cleaned up and made available for re-use. cleaned up and made available for re-use.
2.4.2. Removing published services 2.2.5.4. Compression in SRV records
To remove a service registration, the client retransmits its most Although [RFC2782] requires that the target name in the SRV record
not be compressed, an SRP client SHOULD compress the target in the
SRV record. The motivation for _not_ compressing in RFC2782 is not
stated, but is assumed to be because a caching resolver that does not
understand the format of the SRV record might store it as binary data
and thus return an invalid pointer in response to a query. This does
not apply in the case of SRP case: an SRP server needs to understand
SRV records in order to validate the SRP update. Compression of the
target potentially saves substantial space in the SRP update.
2.2.5.5. Removing published services
To remove a service registration, the SRP client retransmits its most
recent update with an Update Lease option that has a LEASE value of recent update with an Update Lease option that has a LEASE value of
zero. If the registration is to be permanently removed, KEY-LEASE zero. If the registration is to be permanently removed, KEY-LEASE
should also be zero. Otherwise, it should have the same value it had should also be zero. Otherwise, it should have the same value it had
previously; this holds the name in reserve for when the client is previously; this holds the name in reserve for when the SRP client is
once again able to provide the service. once again able to provide the service.
SRP clients are normally expected to remove all service instances SRP clients are normally expected to remove all service instances
when removing a host. However, in some cases a client may not have when removing a host. However, in some cases a SRP client may not
retained sufficient state to know that some service instance is have retained sufficient state to know that some service instance is
pointing to a host that it is removing. Nevertheless, removing the pointing to a host that it is removing. An SRP server can assume
host can be assumed to mean that all service instances pointing to it that all service instances pointing to a host entry that's being
are no longer valid. Therefore, SRP servers MAY remove all service removed are no longer valid. Therefore, SRP servers MAY remove all
instances pointing to a host when a host is removed, even if the service instances pointing to a host when a host is removed, even if
client doesn't remove them explicitly. the SRP client doesn't remove them explicitly.
2.4.3. SRP Server Behavior 2.3. SRP Server Behavior
2.4.3.1. Validation of Adds 2.3.1. Validation of Adds
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 one or SRP Updates consist of a set of _instructions_ that together add one
more services. Each instruction consists either of a single add, or or more services. Each instruction consists either of a single add,
a delete followed by an add. When an instruction contains a delete or a delete followed by an add. When an instruction contains a
and an add, the delete MUST precede the add. delete and an add, the delete 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
An Instruction is a Service Discovery Instruction if it contains An Instruction is a Service Discovery Instruction if it contains
o exactly one "Add to an RRSet" ([RFC2136] Section 2.5.1) RR, * exactly one "Add to an RRSet" ([RFC2136], Section 2.5.1) RR,
o which is a PTR RR, * which is a PTR RR,
o which points to a Service Instance Name * which points to a Service Instance Name
o for which a Service Description Instruction is present in the SRP * for which a Service Description Instruction is present in the SRP
Update. Update.
o Service Discovery Instructions do not contain any deletes, and do * Service Discovery Instructions do not contain any deletes, and do
not contain any other adds. not contain any other adds.
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
o exactly one "Delete all RRsets from a name" update for the service * exactly one "Delete all RRsets from a name" update for the service
instance name [RFC2136] Section 2.5.3, instance name ([RFC2136], Section 2.5.3),
o exactly one "Add to an RRset" SRV RR, * exactly one "Add to an RRset" SRV RR,
o zero or one "Add to an RRset" KEY RR that contains the public key * zero or one "Add to an RRset" KEY RR that contains the public key
corresponding to the private key that was used to sign the message 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 (if present, the KEY MUST match the KEY RR given in the Host
Description), Description),
o one or more "Add to an RRset" TXT RRs, * one or more "Add to an RRset" TXT RRs,
o and the target of the SRV RR Add points to a hostname for which * and the target of the SRV RR Add points to a hostname for which
there is a Host Description Instruction in the SRP Update. there is a Host Description Instruction in the SRP Update.
o 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
target.
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
o exactly one "Delete all RRsets from a name" RR, * exactly one "Delete all RRsets from a name" RR,
o one or more "Add to an RRset" RRs of type A and/or AAAA, * one or more "Add to an RRset" RRs of type A and/or AAAA,
o A and/or AAAA records must be of sufficient scope to be reachable * A and/or AAAA records must be of sufficient scope to be reachable
by all hosts that might query the DNS. If a link-scope address or by all hosts that might query the DNS. If a link-scope address or
IPv4 autoconfiguration address is provided by the SRP client, the IPv4 autoconfiguration address is provided by the SRP client, the
SRP server MUST treat this as if no address records were received; SRP server MUST treat this as if no address records were received;
that is, the Host Description is not valid. that is, the Host Description is not valid.
o exactly one "Add to an RRset" RR that adds a KEY RR that contains * 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 the public key corresponding to the private key that was used to
sign the message, sign the message,
o 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.
o Host Description updates do not modify any other records. * Host Description updates do not modify any other records.
An SRP Update MUST include at least one Service Discovery 2.3.2. Valid SRP Update Requirements
Instruction, at least one Service Description Instruction, and
exactly one Host Description Instruction. A DNS Update that does not An SRP Update MUST include at zero or more Service Discovery
is not an SRP update. A DNS Update that contains any other adds, any Instructions, the same number of Service Description Instructions,
other deletes, or any prerequisites, is not an SRP update. Such 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, messages should either be processed as regular RFC2136 updates,
including access control checks and constraint checks, if supported, including access control checks and constraint checks, if supported,
or else rejected with RCODE=REFUSED. or else rejected with RCODE=REFUSED.
Note that if the definitions of each of these update types are In addition, in order for an update to be a valid SRP update, the
followed carefully, this means that many things that look very much target of every Service Discovery Instruction MUST be a Service
like SRP updates nevertheless are not. For example, a DNS update Description Instruction that is present in the SRP Update. There
that contains an RRset Add to a Service Name and an RRset Add to a MUST NOT be any Service Description Instruction to which no Service
Service Instance Name, where the Service Name does not reference the Discovery Instruction points. The target of the SRV record in every
Service Instance Name, is not a valid SRP update message, but may be Service Description instruction MUST be the single Host Description
a valid RFC2136 update. Instruction.
If the definitions of each of these instructions are followed
carefully and the update requirements are validated correctly, many
DNS Updates that look very much like SRP updates nevertheless will
fail to validate. For example, a DNS update that contains an RRset
Add to a Service Name and an RRset Add to a Service Instance Name,
where the Service Name does not reference the Service Instance Name,
is not a valid SRP update message, but may be a valid RFC2136 update.
2.3.3. FCFS Name And Signature Validation
Assuming that a DNS Update message has been validated with these Assuming that a DNS Update message has been validated with these
conditions and is a valid SRP Update, the server checks that the name conditions and is a valid SRP Update, the server checks that the name
in the Host Description Instruction exists. If so, then the server in the Host Description Instruction exists. If so, then the server
checks to see if the KEY record on that name is the same as the KEY checks to see if the KEY record on that name is the same as the KEY
record in the Host Description Instruction. The server performs the record in the Host Description Instruction. The server performs the
same check for the KEY records in any Service Description same check for the KEY records in any Service Description
Instrructions. For KEY records that were omitted from Service Instructions. For KEY records that were omitted from Service
Description Instructions, the KEY from the Host Description Description Instructions, the KEY from the Host Description
Instruction is used. If any existing KEY record corresponding to a Instruction is used. If any existing KEY record corresponding to a
KEY record in the SRP Update does not match the KEY same record in KEY record in the SRP Update does not match the KEY same record in
the SRP Update (whether provided or taken from the Host Description the SRP Update (whether provided or taken from the Host Description
Instruction), then the server MUST reject the SRP Update with the Instruction), then the server MUST reject the SRP Update with the
YXDOMAIN RCODE. YXDOMAIN RCODE.
Otherwise, the server validates the SRP Update using SIG(0) on the Otherwise, the server validates the SRP Update using SIG(0) on the
public key in the KEY record of the Host Description update. If the public key in the KEY record of the Host Description update. If the
validation fails, the server MUST reject the SRP Update with the validation fails, the server MUST reject the SRP Update with the
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
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
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 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
some networks, it may be possible to do out-of-band registration of some networks, it may be possible to do out-of-band registration of
keys, and only accept updates from pre-registered keys. In this keys, and only accept updates from pre-registered keys. In this
case, an update for a key that has not been registered should be case, an update for a key that has not been registered should be
rejected with the REFUSED RCODE. rejected with the REFUSED RCODE.
There are at least two benefits to doing this rather than simply There are at least two benefits to doing this rather than simply
using normal SIG(0) DNS updates. First, the same registration using normal SIG(0) DNS updates. First, the same registration
protocol can be used in both cases, so both use cases can be protocol can be used in both cases, so both use cases can be
addressed by the same service implementation. Second, the addressed by the same service implementation. Second, the
registration protocol includes maintenance functionality not present registration protocol includes maintenance functionality not present
with normal DNS updates. with normal DNS updates.
Note that the semantics of using SRP in this way are different than Note that the semantics of using SRP in this way are different than
for typical RFC2136 implementations: the KEY used to sign the SRP for typical RFC2136 implementations: the KEY used to sign the SRP
update only allows the client to update records that refer to its update only allows the SRP client to update records that refer to its
Host Description. RFC2136 implementations do not normally provide a Host Description. RFC2136 implementations do not normally provide a
way to enforce a constraint of this type. way to enforce a constraint of this type.
The server may also have a dictionary of names or name patterns that The server may also have a dictionary of names or name patterns that
are not permitted. If such a list is used, updates for Service are not permitted. If such a list is used, updates for Service
Instance Names that match entries in the dictionary are rejected with Instance Names that match entries in the dictionary are rejected with
YXDOMAIN. YXDOMAIN.
2.5. TTL Consistency 3. TTL Consistency
All RRs within an RRset are required to have the same TTL All RRs within an RRset are required to have the same TTL
(Clarifications to the DNS Specification [RFC2181], Section 5.2). In (Clarifications to the DNS Specification [RFC2181], Section 5.2). In
order to avoid inconsistencies, SRP places restrictions on TTLs sent order to avoid inconsistencies, SRP places restrictions on TTLs sent
by services and requires that SRP Servers enforce consistency. by services and requires that SRP servers enforce consistency.
Services sending SRP updates MUST use consistent TTLs in all RRs Services sending SRP updates MUST use consistent TTLs in all RRs
within the SRP update. within the SRP update.
SRP update servers MUST check that the TTLs for all RRs within the SRP update servers MUST check that the TTLs for all RRs within the
SRP update are the same. If they are not, the SRP update MUST be SRP update are the same. If they are not, the SRP update MUST be
rejected with a REFUSED RCODE. rejected with a REFUSED RCODE.
Additionally, when adding RRs to an RRset, for example when Additionally, when adding RRs to an RRset, for example when
processing Service Discovery records, the server MUST use the same processing Service Discovery records, the server MUST use the same
TTL on all RRs in the RRset. How this consistency is enforced is up TTL on all RRs in the RRset. How this consistency is enforced is up
to the implementation. to the implementation.
TTLs sent in SRP updates are advisory: they indicate the client's TTLs sent in SRP updates are advisory: they indicate the SRP client's
guess as to what a good TTL would be. SRP servers may override these guess as to what a good TTL would be. SRP servers may override these
TTLs. SRP servers SHOULD ensure that TTLs are reasonable: neither TTLs. SRP servers SHOULD ensure that TTLs are reasonable: neither
too long nor too short. The TTL should never be longer than the too long nor too short. The TTL should never be longer than the
lease time Section 2.6.1. Shorter TTLs will result in more frequent lease time (Section 4.1). Shorter TTLs will result in more frequent
data refreshes; this increases latency on the client side, increases data refreshes; this increases latency on the DNS-SD client side,
load on any caching resolvers and on the authoritative server, and increases load on any caching resolvers and on the authoritative
also increases network load, which may be an + issue for constrained server, and also increases network load, which may be an issue for
networks. Longer TTLs will increase the likelihood that data in constrained networks. Longer TTLs will increase the likelihood that
caches will be stale. TTL minimums and maximums SHOULD be data in caches will be stale. TTL minimums and maximums SHOULD be
configurable by the operator of the SRP server. configurable by the operator of the SRP server.
2.6. Maintenance 4. Maintenance
2.6.1. Cleaning up stale data 4.1. Cleaning up stale data
Because the DNS-SD registration protocol is automatic, and not Because the DNS-SD registration protocol is automatic, and not
managed by humans, some additional bookkeeping is required. When an managed by humans, some additional bookkeeping is required. When an
update is constructed by the client, it MUST include an EDNS(0) update is constructed by the SRP client, it MUST include an EDNS(0)
Update Lease Option [I-D.sekar-dns-ul]. The Update Lease Option Update Lease Option [I-D.sekar-dns-ul]. The Update Lease Option
contains two lease times: the Lease Time and the Key Lease Time. contains two lease times: the Lease Time and the Key Lease Time.
These leases are promises, similar to DHCP leases [RFC2131], from the These leases are promises, similar to DHCP leases [RFC2131], from the
client that it will send a new update for the service registration SRP client that it will send a new update for the service
before the lease time expires. The Lease time is chosen to represent registration before the lease time expires. The Lease time is chosen
the time after the update during which the registered records other to represent the time after the update during which the registered
than the KEY record should be assumed to be valid. The Key Lease records other than the KEY record should be assumed to be valid. The
time represents the time after the update during which the KEY record Key Lease time represents the time after the update during which the
should be assumed to be valid. KEY record should be assumed to be valid.
The reasoning behind the different lease times is discussed in the The reasoning behind the different lease times is discussed in the
section on first-come, first-served naming Section 2.4.1. SRP section on first-come, first-served naming (Section 2.2.4.1). SRP
servers may be configured with limits for these values. A default servers may be configured with limits for these values. A default
limit of two hours for the Lease and 14 days for the SIG(0) KEY are limit of two hours for the Lease and 14 days for the SIG(0) KEY are
currently thought to be good choices. Clients that are going to currently thought to be good choices. Constrained devices with
continue to use names on which they hold leases should update well limited battery that wake infrequently are likely to negotiate longer
before the lease ends, in case the registration service is leases. SRP clients that are going to continue to use names on which
unavailable or under heavy load. they hold leases should update well before the lease ends, in case
the registration service is unavailable or under heavy load.
The SRP server MUST include an EDNS(0) Update Lease option in the The SRP server MUST include an EDNS(0) Update Lease option in the
response if the lease time proposed by the service has been shortened response if the lease time proposed by the service has been shortened
or lengthened. The service MUST check for the EDNS(0) Update Lease or lengthened. The service MUST check for the EDNS(0) Update Lease
option in the response and MUST use the lease times from that option option in the response and MUST use the lease times from that option
in place of the options that it sent to the server when deciding when in place of the options that it sent to the server when deciding when
to update its registration. The times may be shorter or longer than to update its registration. The times may be shorter or longer than
those specified in the SRP update; the client must honor them in those specified in the SRP update; the SRP client must honor them in
either case. either case.
Clients should assume that each lease ends N seconds after the update SRP clients should assume that each lease ends N seconds after the
was first transmitted, where N is the lease duration. Servers should update was first transmitted, where N is the lease duration. Servers
assume that each lease ends N seconds after the update that was should assume that each lease ends N seconds after the update that
successfully processed was received. Because the server will always was successfully processed was received. Because the server will
receive the update after the client sent it, this avoids the always receive the update after the SRP client sent it, this avoids
possibility of misunderstandings. the possibility of misunderstandings.
SRP servers MUST reject updates that do not include an EDNS(0) Update SRP servers MUST reject updates that do not include an EDNS(0) Update
Lease option. Dual-use servers MAY accept updates that don't include Lease option. Dual-use servers MAY accept updates that don't include
leases, but SHOULD differentiate between SRP updates and other leases, but SHOULD differentiate between SRP updates and other
updates, and MUST reject updates that would otherwise be SRP updates updates, and MUST reject updates that would otherwise be SRP updates
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'.
2.6.2. Sleep Proxy 5. Sleep Proxy
Another use of SRP is for devices that sleep to reduce power Another use of SRP is for devices that sleep to reduce power
consumption. consumption.
In this case, in addition to the DNS Update Lease option In this case, in addition to the DNS Update Lease option
[I-D.sekar-dns-ul] described above, the device includes an EDNS(0) [I-D.sekar-dns-ul] described above, the device includes an EDNS(0)
OWNER Option [I-D.cheshire-edns0-owner-option]. OWNER Option [I-D.cheshire-edns0-owner-option].
The EDNS(0) Update Lease option constitutes a promise by the device The EDNS(0) Update Lease option constitutes a promise by the device
that it will wake up before this time elapses, to renew its that it will wake up before this time elapses, to renew its
skipping to change at page 16, line 21 skipping to change at page 18, line 24
It is not required that sleepy nodes on a Constrained-Node Network It is not required that sleepy nodes on a Constrained-Node Network
support sleep proxy. Such devices may have different mechanisms for support sleep proxy. Such devices may have different mechanisms for
dealing with sleep and wakeup. An SRP registration for such a device dealing with sleep and wakeup. An SRP registration for such a device
will be useful regardless of the mechanism whereby messages are will be useful regardless of the mechanism whereby messages are
delivered to the sleepy end device. For example, the message might 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 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 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 wakes up. The exact details of such behaviors are out of scope for
this document. this document.
3. Security Considerations 6. Security Considerations
3.1. Source Validation 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 Anycast updates, this validation must be enforced by every router For updates sent to an anycast IP address of an SRP server, this
that connects the Constrained-Device Network to the unconstrained validation must be enforced by every router on the path from the
portion of the network. For TCP updates, the initial SYN-SYN+ACK Constrained-Device Network to the unconstrained portion of the
handshake prevents updates being forged by an off-network attacker. network. For TCP updates, the initial SYN-SYN+ACK handshake prevents
In order to ensure that this handshake happens, Service Discovery updates being forged by an off-network attacker. In order to ensure
Protocol servers MUST NOT accept TCP Fast Open payloads. that this handshake happens, Service Discovery Protocol servers
relying on three-way-handshake validation MUST NOT accept TCP Fast
Open payloads. If the network infrastructure allows it, an SRP
server MAY accept TCP Fast Open payloads if all such packets are
validated along the path, and the network is able to reject this type
of spoofing at all ingress points.
Note that these rules only apply to the validation of SRP updates. A Note that these rules only apply to the validation of SRP updates. A
server that accepts updates from DNS-SD registration protocol clients server that accepts updates from SRP clients may also accept other
may also accept other DNS updates, and those DNS updates may be DNS updates, and those DNS updates may be validated using different
validated using different rules. However, in the case of a DNS rules. However, in the case of a DNS service that accepts SRP
service that accepts SRP updates, the intersection of the SRP update updates, the intersection of the SRP update rules and whatever other
rules and whatever other update rules are present must be considered update rules are present must be considered very carefully.
very carefully.
For example, a normal, authenticated RFC2136 update to any RR that For example, a normal, authenticated DNS update to any RR that was
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 a different client. An information with information provided by an SRP client. An
implementation that allows both kinds of updates should not allow implementation that allows both kinds of updates should not allow DNS
updates to records added by SRP updates using different Update clients to updateupdate records added by SRP clients using
authentication and authorization credentials. different authentication and authorization credentials.
3.2. SIG(0) signature validation 6.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.
3.3. Required Signature Algorithm 6.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, starting with algorithm number 13. SRP clients MUST NOT table, that are numbered 13 or higher and have a "MUST",
assume that any algorithm numbered lower than 13 is available for use "RECOMMENDED", or "MAY" designation in the validation column of the
in validating SIG(0) signatures. table. SRP clients MUST NOT assume that any algorithm numbered lower
than 13 is available for use in validating SIG(0) signatures.
4. Privacy Considerations 7. 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.
5. Delegation of 'service.arpa.' 8. Delegation of 'service.arpa.'
In order to be fully functional, there must be a delegation of In order to be fully functional, the owner of the 'arpa.' zone must
'service.arpa.' in the '.arpa.' zone [RFC3172]. This delegation add a delegation of 'service.arpa.' in the '.arpa.' zone [RFC3172].
should be set up as was done for 'home.arpa', as a result of the This delegation should be set up as was done for 'home.arpa', as a
specification in [RFC8375]Section 7. result of the specification in Section 7 of [RFC8375].
6. IANA Considerations 9. IANA Considerations
6.1. Registration and Delegation of 'service.arpa' as a Special-Use 9.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 5. Section 8.
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.
6.2. 'dnssd-srp' Service Name 9.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.
6.3. 'dnssd-srp-tls' Service Name 9.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.
6.4. Anycast Address 9.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. This address is referred to Protocol anycast address, 2001:1::1. The value TBD should be
within the document as TBD1, and the document should be updated to replaced with the actual allocation in the table that follows. The
reflect the address that was allocated. values for the registry are:
7. Acknowledgments +----------------------+-----------------------------+
| Attribute | value |
+----------------------+-----------------------------+
| Address Block | 2001:1::TBD/128 |
+----------------------+-----------------------------+
| Name | DNS-SD Service Registration |
| | Protocol Anycast Address |
+----------------------+-----------------------------+
| RFC | [this document] |
+----------------------+-----------------------------+
| Allocation Date | [date of allocation] |
+----------------------+-----------------------------+
| Termination Date | N/A |
+----------------------+-----------------------------+
| Source | True |
+----------------------+-----------------------------+
| Destination | True |
+----------------------+-----------------------------+
| Forwardable | True |
+----------------------+-----------------------------+
| Global | True |
+----------------------+-----------------------------+
| Reserved-by-protocol | False |
+----------------------+-----------------------------+
Thanks to Toke Hoeiland-Joergensen for a thorough technical review, Table 1
to Tamara Kemper for doing a nice developmental edit, Tim Wattenberg
for doing a service implementation at the Montreal Hackathon at IETF
102, Tom Pusateri for reviewing during the hackathon and afterwards,
and [...] more reviewers to come, hopefully.
8. References 10. Acknowledgments
8.1. Normative References Thanks to Toke H&#248;iland-J&#248;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.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 11. Normative References
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.
[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",
draft-sekar-dns-ul-02 (work in progress), August 2018. Work in Progress, Internet-Draft, draft-sekar-dns-ul-02, 2
August 2018,
<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>.
[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,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <https://www.rfc-editor.org/info/rfc2931>.
[RFC3172] Huston, G., Ed., "Management Guidelines & Operational [RFC3172] Huston, G., Ed., "Management Guidelines & Operational
Requirements for the Address and Routing Parameter Area Requirements for the Address and Routing Parameter Area
Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
September 2001, <https://www.rfc-editor.org/info/rfc3172>. September 2001, <https://www.rfc-editor.org/info/rfc3172>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017, RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>. <https://www.rfc-editor.org/info/rfc8106>.
[RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain
'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018,
<https://www.rfc-editor.org/info/rfc8375>. <https://www.rfc-editor.org/info/rfc8375>.
[RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation
Requirements and Usage Guidance for DNSSEC", RFC 8624, Requirements and Usage Guidance for DNSSEC", RFC 8624,
DOI 10.17487/RFC8624, June 2019, DOI 10.17487/RFC8624, June 2019,
<https://www.rfc-editor.org/info/rfc8624>. <https://www.rfc-editor.org/info/rfc8624>.
[RFC8765] Pusateri, T. and S. Cheshire, "DNS Push Notifications",
RFC 8765, DOI 10.17487/RFC8765, June 2020,
<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>.
8.2. 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>.
[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,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>. <https://www.rfc-editor.org/info/rfc2181>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September specifying the location of services (DNS SRV)", RFC 2782,
2000, <https://www.rfc-editor.org/info/rfc2931>. DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
<https://www.rfc-editor.org/info/rfc3007>. <https://www.rfc-editor.org/info/rfc3007>.
[RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol
to Replace the AppleTalk Name Binding Protocol (NBP)", to Replace the AppleTalk Name Binding Protocol (NBP)",
RFC 6760, DOI 10.17487/RFC6760, February 2013, RFC 6760, DOI 10.17487/RFC6760, February 2013,
<https://www.rfc-editor.org/info/rfc6760>. <https://www.rfc-editor.org/info/rfc6760>.
skipping to change at page 21, line 14 skipping to change at page 24, line 10
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>. <https://www.rfc-editor.org/info/rfc6762>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310, for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018, DOI 10.17487/RFC8310, March 2018,
<https://www.rfc-editor.org/info/rfc8310>. <https://www.rfc-editor.org/info/rfc8310>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
[RFC8765] Pusateri, T. and S. Cheshire, "DNS Push Notifications",
RFC 8765, DOI 10.17487/RFC8765, June 2020,
<https://www.rfc-editor.org/info/rfc8765>.
[RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based [RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based
Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June
2020, <https://www.rfc-editor.org/info/rfc8766>. 2020, <https://www.rfc-editor.org/info/rfc8766>.
[I-D.cheshire-dnssd-roadmap] [I-D.cheshire-dnssd-roadmap]
Cheshire, S., "Service Discovery Road Map", draft- Cheshire, S., "Service Discovery Road Map", Work in
cheshire-dnssd-roadmap-03 (work in progress), October Progress, Internet-Draft, draft-cheshire-dnssd-roadmap-03,
2018. 23 October 2018, <https://tools.ietf.org/html/draft-
cheshire-dnssd-roadmap-03>.
[I-D.cheshire-edns0-owner-option] [I-D.cheshire-edns0-owner-option]
Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", draft- Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", Work
cheshire-edns0-owner-option-01 (work in progress), July in Progress, Internet-Draft, draft-cheshire-edns0-owner-
2017. option-01, 3 July 2017, <https://tools.ietf.org/html/
draft-cheshire-edns0-owner-option-01>.
[ZC] Cheshire, S. and D. 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
must be configured to be authoritative for "default.service.arpa", must be configured to be authoritative for "default.service.arpa",
and to accept updates from hosts on local networks for names under and to accept updates from hosts on local networks for names under
"default.service.arpa" without authentication, since such servers "default.service.arpa" without authentication, since such servers
will not have support for FCFS authentication Section 2.4.1. will not have support for FCFS authentication (Section 2.2.4.1).
A server configured in this way will be able to successfully accept A server configured in this way will be able to successfully accept
and process SRP updates from services that send SRP updates. and process SRP updates from services that send SRP updates.
However, no prerequisites will be applied, and this means that the However, no prerequisites will be applied, and this means that the
test server will accept internally inconsistent SRP updates, and will test server will accept internally inconsistent SRP updates, and will
not stop two SRP updates, sent by different services, that claim the not stop two SRP updates, sent by different services, that claim the
same name(s), from overwriting each other. same name(s), from overwriting each other.
Since SRP updates are signed with keys, validation of the SIG(0) Since SRP updates are signed with keys, validation of the SIG(0)
algorithm used by the client can be done by manually installing the algorithm used by the client can be done by manually installing the
skipping to change at page 23, line 14 skipping to change at page 26, line 4
the SRV record specifies the UDP protocol for updates, it is also the SRV record specifies the UDP protocol for updates, it is also
possible to use TCP, and TCP should be required to prevent spoofing. possible to use TCP, and TCP should be required to prevent spoofing.
Appendix C. Sample BIND9 configuration for default.service.arpa. Appendix C. Sample BIND9 configuration for default.service.arpa.
zone "default.service.arpa." { zone "default.service.arpa." {
type master; type master;
file "/etc/bind/master/service.db"; file "/etc/bind/master/service.db";
allow-update { key demo.default.service.arpa.; }; allow-update { key demo.default.service.arpa.; };
}; };
Figure 1: Zone Configuration in named.conf
Zone Configuration in named.conf
$ORIGIN . $ORIGIN .
$TTL 57600 ; 16 hours $TTL 57600 ; 16 hours
default.service.arpa IN SOA ns3.default.service.arpa. default.service.arpa IN SOA ns3.default.service.arpa.
postmaster.default.service.arpa. ( postmaster.default.service.arpa. (
2951053287 ; serial 2951053287 ; serial
3600 ; refresh (1 hour) 3600 ; refresh (1 hour)
1800 ; retry (30 minutes) 1800 ; retry (30 minutes)
604800 ; expire (1 week) 604800 ; expire (1 week)
3600 ; minimum (1 hour) 3600 ; minimum (1 hour)
skipping to change at page 23, line 51 skipping to change at page 26, line 40
$TTL 300 ; 5 minutes $TTL 300 ; 5 minutes
ns3 AAAA 2001:db8:0:1::1 ns3 AAAA 2001:db8:0:1::1
$TTL 3600 ; 1 hour $TTL 3600 ; 1 hour
demo AAAA 2001:db8:0:2::1 demo AAAA 2001:db8:0:2::1
KEY 513 3 13 ( KEY 513 3 13 (
qweEmaaq0FAWok5//ftuQtZgiZoiFSUsm0srWREdywQU qweEmaaq0FAWok5//ftuQtZgiZoiFSUsm0srWREdywQU
9dpvtOhrdKWUuPT3uEFF5TZU6B4q1z1I662GdaUwqg== 9dpvtOhrdKWUuPT3uEFF5TZU6B4q1z1I662GdaUwqg==
); alg = ECDSAP256SHA256 ; key id = 15008 ); alg = ECDSAP256SHA256 ; key id = 15008
AAAA ::1 AAAA ::1
Example Zone file Figure 2: Example Zone file
Authors' Addresses Authors' Addresses
Ted Lemon Ted Lemon
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, California 95014 Cupertino, California 95014
USA United States of America
Email: mellon@fugue.com Email: mellon@fugue.com
Stuart Cheshire Stuart Cheshire
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, California 95014 Cupertino, California 95014
USA United States of America
Phone: +1 408 974 3207 Phone: +1 408 974 3207
Email: cheshire@apple.com Email: cheshire@apple.com
 End of changes. 118 change blocks. 
264 lines changed or deleted 378 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/