draft-ietf-dnssd-srp-04.txt   draft-ietf-dnssd-srp-05.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: Informational Apple Inc.
Expires: January 14, 2021 July 13, 2020 Expires: April 29, 2021 October 26, 2020
Service Registration Protocol for DNS-Based Service Discovery Service Registration Protocol for DNS-Based Service Discovery
draft-ietf-dnssd-srp-04 draft-ietf-dnssd-srp-05
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 January 14, 2021. This Internet-Draft will expire on April 29, 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are 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 . . . . . . . . . . . . . . . . 4
2.1. What to publish . . . . . . . . . . . . . . . . . . . . . 5 2.1. What to publish . . . . . . . . . . . . . . . . . . . . . 6
2.2. Where to publish it . . . . . . . . . . . . . . . . . . . 6 2.2. Where to publish it . . . . . . . . . . . . . . . . . . . 7
2.3. How to publish it . . . . . . . . . . . . . . . . . . . . 6 2.3. How to publish it . . . . . . . . . . . . . . . . . . . . 7
2.3.1. How DNS-SD Service Registration differs from standard 2.3.1. How DNS-SD Service Registration differs from standard
RFC2136 DNS Update . . . . . . . . . . . . . . . . . 7 RFC2136 DNS Update . . . . . . . . . . . . . . . . . 8
2.4. How to secure it . . . . . . . . . . . . . . . . . . . . 7 2.4. How to secure it . . . . . . . . . . . . . . . . . . . . 8
2.4.1. First-Come First-Served Naming . . . . . . . . . . . 8 2.4.1. First-Come First-Served Naming . . . . . . . . . . . 8
2.4.2. Removing published services . . . . . . . . . . . . . 9 2.4.2. Removing published services . . . . . . . . . . . . . 10
2.4.3. SRP Server Behavior . . . . . . . . . . . . . . . . . 9 2.4.3. SRP Server Behavior . . . . . . . . . . . . . . . . . 10
2.5. TTL Consistency . . . . . . . . . . . . . . . . . . . . . 12 2.5. TTL Consistency . . . . . . . . . . . . . . . . . . . . . 13
2.6. Maintenance . . . . . . . . . . . . . . . . . . . . . . . 13 2.6. Maintenance . . . . . . . . . . . . . . . . . . . . . . . 14
2.6.1. Cleaning up stale data . . . . . . . . . . . . . . . 13 2.6.1. Cleaning up stale data . . . . . . . . . . . . . . . 14
2.6.2. Sleep Proxy . . . . . . . . . . . . . . . . . . . . . 14 2.6.2. Sleep Proxy . . . . . . . . . . . . . . . . . . . . . 15
3. Security Considerations . . . . . . . . . . . . . . . . . . . 15 3. Security Considerations . . . . . . . . . . . . . . . . . . . 16
3.1. Source Validation . . . . . . . . . . . . . . . . . . . . 15 3.1. Source Validation . . . . . . . . . . . . . . . . . . . . 16
3.2. SIG(0) signature validation . . . . . . . . . . . . . . . 16 3.2. SIG(0) signature validation . . . . . . . . . . . . . . . 17
3.3. Required Signature Algorithm . . . . . . . . . . . . . . 16 3.3. Required Signature Algorithm . . . . . . . . . . . . . . 17
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
5. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 16 5. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.1. Registration and Delegation of 'service.arpa' as a 6.1. Registration and Delegation of 'service.arpa' as a
Special-Use Domain Name . . . . . . . . . . . . . . . . . 17 Special-Use Domain Name . . . . . . . . . . . . . . . . . 18
6.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 17 6.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 18
6.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 17 6.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 18
6.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 17 6.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Testing using standard RFC2136-compliant servers . . 20 Appendix A. Testing using standard RFC2136-compliant servers . . 22
Appendix B. How to allow services to update standard Appendix B. How to allow services to update standard
RFC2136-compliant servers . . . . . . . . . . . . . 21 RFC2136-compliant servers . . . . . . . . . . . . . 22
Appendix C. Sample BIND9 configuration for default.service.arpa. 21 Appendix C. Sample BIND9 configuration for default.service.arpa. 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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 automatically register their [RFC6763] that allows services to register their services using the
services using the DNS protocol rather than using Multicast DNS DNS protocol rather than using Multicast DNS [RFC6762] (mDNS). There
[RFC6762] (mDNS). There is already a large installed base of DNS-SD is already a large installed base of DNS-SD clients that can discover
clients that can discover services using the DNS protocol. This services using the DNS protocol.
extension makes it much easier to take advantage of this existing
functionality.
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. Clients can then discover the set
of services of a particular type that are available. They can then of services of a particular type that are available. They can then
select a service from among those that are available and obtain the select a service from among those that are available and obtain the
information required to use it. information required to use it. Although DNS-SD using the DNS
protocol (as opposed to mDNS) can be more efficient and versatile, it
is not common in practice, because of the difficulties associated
with updating authoritative DNS services with service information.
Existing practice for updating DNS zones is to either manually enter
new data, or else use DNS Update [RFC2136]. Unfortunately DNS Update
requires either that the authoritative DNS server automatically trust
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
to authenticate the update. Furthermore, DNS Update can be a fairly
chatty process, requiring multiple round trips with different
conditional predicates to complete the update process.
The SRP protocol adds a set of default heuristics for processing DNS
updates that eliminates the need for DNS update conditional
predicates: instead, the SRP server has a set of default predicates
that are applied to the update, and the update either succeeds
entirely, or fails in a way that allows the registering service to
know what went wrong and construct a new update.
SRP also adds a feature called First-Come, First-Served Naming, which
allows the registering service to claim a name that is not yet in
use, and, using SIG(0) [RFC2931], to authenticate both the initial
claim and subsequent updates. This prevents name conflicts, since a
second SRP service attempting to claim the same name will not possess
the SIG(0) key used by the first service to claim it, and so its
claim will be rejected and the second service will have to choose a
new name.
Finally, SRP adds the concept of a 'lease,' similar to leases in
Dynamic Host Configuration Protocol [RFC8415]. The SRP registration
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,
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
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 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
skipping to change at page 4, line 5 skipping to change at page 4, line 39
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
administrator manually configure service information in the DNS, but administrator manually configure service information in the DNS, but
manually populating DNS authoritative server databases is costly and manually populating DNS authoritative server databases is costly and
potentially error-prone, and requires a knowledgable network potentially error-prone, and requires a knowledgable network
administrator. Consequently, although all DNS-SD client administrator. Consequently, although all DNS-SD client
implementations of which we are aware support DNS-SD using DNS implementations of which we are aware support DNS-SD using DNS
queries, in practice it is used much less frequently than mDNS. queries, in practice it is used much less frequently than mDNS.
The Discovery Proxy [I-D.ietf-dnssd-hybrid] provides one way to The Discovery Proxy [RFC8766] provides one way to automatically
automatically populate the DNS namespace, but is only appropriate on populate the DNS namespace, but is only appropriate on networks where
networks where services are easily advertised using mDNS. This services are easily advertised using mDNS. This document describes a
document describes a solution more suitable for networks where solution more suitable for networks where multicast is inefficient,
multicast is inefficient, or where sleepy devices are common, by or where sleepy devices are common, by supporting both offering of
supporting both offering of services, and discovery of services, services, and discovery of services, using unicast.
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].
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 registraton 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 apex of the closest enclosing DNS zone using SOA queries [RFC8765].
[I-D.ietf-dnssd-push]. Having discovered the enclosing DNS zone, Having discovered the enclosing DNS zone, they query for the
they query for the "_dnssd-srp._tcp<zone>" SRV record to discover the "_dnssd-srp._tcp<zone>" SRV record to discover the server to which
server to which they should send DNS updates. Hosts that support SRP they should send DNS updates. Hosts that support SRP updates using
updates using TLS use the "_dnssd-srp-tls._tcp<zone>" SRV record TLS use the "_dnssd-srp-tls._tcp<zone>" SRV record instead.
instead.
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
skipping to change at page 7, line 33 skipping to change at page 8, line 23
o It enforces policy about what updates are allowed. o It enforces policy about what updates are allowed.
o 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.
o 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.
o An SRP server is not required to implement general DNS Update o An SRP server is not required to implement general DNS Update
prerequsite processing. prerequisite processing.
o 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.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 client (which issues the update) and
the server (which authenticates it). This model does not work for the server (which authenticates it). This model does not work for
automatic service registration. automatic service registration.
skipping to change at page 8, line 22 skipping to change at page 9, line 11
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.4.1.1. Service Behavior
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 client, the client MUST be pre-configured with a public/
private key pair in read-only storage that can be used. This key private key pair in read-only storage that can be used. This key
pair MUST be unique to the device. pair MUST be unique to the device. This key pair MUST be unique to
the device. A device with rewritable storage + should retain this
key indefinitely; 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
skipping to change at page 10, line 35 skipping to change at page 11, line 30
o one or more "Add to an RRset" TXT RRs, o one or more "Add to an RRset" TXT RRs,
o and the target of the SRV RR Add points to a hostname for which o 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. o Service Descriptions Instructions do not modify any other RRs.
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, o exactly one "Delete all RRsets from a name" RR,
o one or more "Add to an RRset" RRs of type A and/or AAAA, o 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
by all hosts that might query the DNS. If a link-scope address or
IPv4 autoconfiguration address is provided by the SRP client, the
SRP server MUST treat this as if no address records were received;
that is, the Host Description is not valid.
o exactly one "Add to an RRset" RR that adds a KEY RR that contains o 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 o 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. o Host Description updates do not modify any other records.
An SRP Update MUST include at least one Service Discovery An SRP Update MUST include at least one Service Discovery
Instruction, at least one Service Description Instruction, and Instruction, at least one Service Description Instruction, and
skipping to change at page 13, line 4 skipping to change at page 14, line 4
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 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 2.6.1. Shorter TTLs will result in more frequent
data refreshes; this increases latency on the client side, and data refreshes; this increases latency on the client side, increases
increases load on any caching resolvers and on the authoritative load on any caching resolvers and on the authoritative server, and
server. Longer TTLs will increase the likelihood that data in caches also increases network load, which may be an + issue for constrained
will be stale. TTL minimums and maximums SHOULD be configurable by networks. Longer TTLs will increase the likelihood that data in
the operator of the SRP server. caches will be stale. TTL minimums and maximums SHOULD be
configurable by the operator of the SRP server.
2.6. Maintenance 2.6. Maintenance
2.6.1. Cleaning up stale data 2.6.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 include an update is constructed by the client, it MUST include an EDNS(0)
EDNS(0) Update Lease Option [I-D.sekar-dns-ul]. The Update Lease Update Lease Option [I-D.sekar-dns-ul]. The Update Lease Option
Option contains two lease times: the Lease Time and the Key Lease contains two lease times: the Lease Time and the Key Lease Time.
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 client that it will send a new update for the service registration
before the lease time expires. The Lease time is chosen to represent before the lease time expires. The Lease time is chosen to represent
the time after the update during which the registered records other the time after the update during which the registered records other
than the KEY record should be assumed to be valid. The Key Lease than the KEY record should be assumed to be valid. The Key Lease
time represents the time after the update during which the KEY record time represents the time after the update during which the KEY record
should be assumed to be valid. 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
skipping to change at page 14, line 11 skipping to change at page 15, line 11
was first transmitted, where N is the lease duration. Servers should was first transmitted, where N is the lease duration. Servers should
assume that each lease ends N seconds after the update that was assume that each lease ends N seconds after the update that was
successfully processed was received. Because the server will always successfully processed was received. Because the server will always
receive the update after the client sent it, this avoids the receive the update after the client sent it, this avoids the
possibility of misunderstandings. 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
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 2.6.2. Sleep Proxy
skipping to change at page 14, line 44 skipping to change at page 15, line 44
indicates that it is no longer attached to the network, and its indicates that it is no longer attached to the network, and its
registration (except for the KEY in the Host Description) should be registration (except for the KEY in the Host Description) should be
deleted. deleted.
The EDNS(0) OWNER Option indicates that the device will be asleep, The EDNS(0) OWNER Option indicates that the device will be asleep,
and will not be receptive to normal network traffic. When a DNS and will not be receptive to normal network traffic. When a DNS
server receives a DNS Update with an EDNS(0) OWNER Option, that server receives a DNS Update with an EDNS(0) OWNER Option, that
signifies that the SRP server should set up a proxy for any IPv4 or signifies that the SRP server should set up a proxy for any IPv4 or
IPv6 address records in the DNS Update message. This proxy should IPv6 address records in the DNS Update message. This proxy should
send ARP or ND messages claiming ownership of the IPv4 and/or IPv6 send ARP or ND messages claiming ownership of the IPv4 and/or IPv6
addresses in the records in question. In addition, proxy should addresses in the records in question. In addition, the proxy should
answer future ARP or ND requests for those IPv4 and/or IPv6 answer future ARP or ND requests for those IPv4 and/or IPv6
addresses, claiming ownership of them. When the DNS server receives addresses, claiming ownership of them. When the DNS server receives
a TCP SYN or UDP packet addressed to one of the IPv4 or IPv6 a TCP SYN or UDP packet addressed to one of the IPv4 or IPv6
addresses for which it proxying, it should then wake up the sleeping addresses for which it proxying, it should then wake up the sleeping
device using the information in the EDNS(0) OWNER Option. At present device using the information in the EDNS(0) OWNER Option. At present
version 0 of the OWNER Option specifies the "Wake-on-LAN Magic version 0 of the OWNER Option specifies the "Wake-on-LAN Magic
Packet" that needs to be sent; future versions could be extended to Packet" that needs to be sent; future versions could be extended to
specify other wakeup mechanisms. specify other wakeup mechanisms.
Note that although the authoritative DNS server that implements the Note that although the authoritative DNS server that implements the
skipping to change at page 16, line 23 skipping to change at page 17, line 23
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 3.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 [I-D.ietf-dnsop-algorithm-update] section 3.1, in the specified in [RFC8624] section 3.1, in the validation column of the
validation column of the table, starting with algorithm number 13. table, starting with algorithm number 13. SRP clients MUST NOT
SRP clients MUST NOT assume that any algorithm numbered lower than 13 assume that any algorithm numbered lower than 13 is available for use
is available for use in validating SIG(0) signatures. in validating SIG(0) signatures.
4. Privacy Considerations 4. 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
MAY elect not to return KEY records for queries for SRP
registrations.
5. Delegation of 'service.arpa.' 5. Delegation of 'service.arpa.'
In order to be fully functional, there must be a delegation of In order to be fully functional, there must be a delegation of
'service.arpa.' in the '.arpa.' zone [RFC3172]. This delegation 'service.arpa.' in the '.arpa.' zone [RFC3172]. This delegation
should be set up as was done for 'home.arpa', as a result of the should be set up as was done for 'home.arpa', as a result of the
specification in [RFC8375]Section 7. specification in [RFC8375]Section 7.
6. IANA Considerations 6. IANA Considerations
6.1. Registration and Delegation of 'service.arpa' as a Special-Use 6.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 5.
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-
skipping to change at page 18, line 45 skipping to change at page 20, line 5
[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>.
[I-D.ietf-dnsop-algorithm-update] [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation
Wouters, P. and O. Sury, "Algorithm Implementation Requirements and Usage Guidance for DNSSEC", RFC 8624,
Requirements and Usage Guidance for DNSSEC", draft-ietf- DOI 10.17487/RFC8624, June 2019,
dnsop-algorithm-update-10 (work in progress), April 2019. <https://www.rfc-editor.org/info/rfc8624>.
[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 8.2. Informative References
skipping to change at page 20, line 20 skipping to change at page 21, line 24
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 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>.
[I-D.ietf-dnssd-hybrid] [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Cheshire, S., "Discovery Proxy for Multicast DNS-Based Richardson, M., Jiang, S., Lemon, T., and T. Winters,
Service Discovery", draft-ietf-dnssd-hybrid-10 (work in "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
progress), March 2019. RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[I-D.ietf-dnssd-push] [RFC8765] Pusateri, T. and S. Cheshire, "DNS Push Notifications",
Pusateri, T. and S. Cheshire, "DNS Push Notifications", RFC 8765, DOI 10.17487/RFC8765, June 2020,
draft-ietf-dnssd-push-25 (work in progress), October 2019. <https://www.rfc-editor.org/info/rfc8765>.
[RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based
Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June
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", draft-
cheshire-dnssd-roadmap-03 (work in progress), October cheshire-dnssd-roadmap-03 (work in progress), October
2018. 2018.
[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", draft-
cheshire-edns0-owner-option-01 (work in progress), July cheshire-edns0-owner-option-01 (work in progress), July
2017. 2017.
skipping to change at page 22, line 16 skipping to change at page 23, line 20
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.; };
}; };
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)
) )
NS ns3.default.service.arpa. NS ns3.default.service.arpa.
SRV 0 0 53 ns3.default.service.arpa. SRV 0 0 53 ns3.default.service.arpa.
$ORIGIN default.service.arpa. $ORIGIN default.service.arpa.
$TTL 3600 ; 1 hour $TTL 3600 ; 1 hour
 End of changes. 27 change blocks. 
83 lines changed or deleted 133 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/