< draft-ietf-dnssd-srp-10.txt   draft-ietf-dnssd-srp-12.txt >
Internet Engineering Task Force T. Lemon Internet Engineering Task Force T. Lemon
Internet-Draft S. Cheshire Internet-Draft S. Cheshire
Intended status: Standards Track Apple Inc. Intended status: Standards Track Apple Inc.
Expires: 13 January 2022 12 July 2021 Expires: 25 April 2022 22 October 2021
Service Registration Protocol for DNS-Based Service Discovery Service Registration Protocol for DNS-Based Service Discovery
draft-ietf-dnssd-srp-10 draft-ietf-dnssd-srp-12
Abstract Abstract
The Service Registration Protocol for DNS-Based Service Discovery The Service Registration Protocol for DNS-Based Service Discovery
uses the standard DNS Update mechanism to enable DNS-Based Service uses the standard DNS Update mechanism to enable DNS-Based Service
Discovery using only unicast packets. This makes it possible to Discovery using only unicast packets. This makes it possible to
deploy DNS Service Discovery without multicast, which greatly deploy DNS Service Discovery without multicast, which greatly
improves scalability and improves performance on networks where improves scalability and improves performance on networks where
multicast service is not an optimal choice, particularly 802.11 multicast service is not an optimal choice, particularly 802.11
(Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 January 2022. This Internet-Draft will expire on 25 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 16 skipping to change at page 2, line 16
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Service Registration Protocol . . . . . . . . . . . . . . . . 5 2. Service Registration Protocol . . . . . . . . . . . . . . . . 5
2.1. Protocol Variants . . . . . . . . . . . . . . . . . . . . 5 2.1. Protocol Variants . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Full-featured Hosts . . . . . . . . . . . . . . . . . 5 2.1.1. Full-featured Hosts . . . . . . . . . . . . . . . . . 5
2.1.2. Constrained Hosts . . . . . . . . . . . . . . . . . . 6 2.1.2. Constrained Hosts . . . . . . . . . . . . . . . . . . 6
2.1.3. Why two variants? . . . . . . . . . . . . . . . . . . 6 2.1.3. Why two variants? . . . . . . . . . . . . . . . . . . 6
2.2. Protocol Details . . . . . . . . . . . . . . . . . . . . 6 2.2. Protocol Details . . . . . . . . . . . . . . . . . . . . 7
2.2.1. What to publish . . . . . . . . . . . . . . . . . . . 7 2.2.1. What to publish . . . . . . . . . . . . . . . . . . . 7
2.2.2. Where to publish it . . . . . . . . . . . . . . . . . 7 2.2.2. Where to publish it . . . . . . . . . . . . . . . . . 7
2.2.3. How to publish it . . . . . . . . . . . . . . . . . . 8 2.2.3. How to publish it . . . . . . . . . . . . . . . . . . 8
2.2.3.1. How DNS-SD Service Registration differs from
standard RFC2136 DNS Update . . . . . . . . . . . . 8
2.2.4. How to secure it . . . . . . . . . . . . . . . . . . 9 2.2.4. How to secure it . . . . . . . . . . . . . . . . . . 9
2.2.4.1. First-Come First-Served Naming . . . . . . . . . 9
2.2.5. Service Behavior . . . . . . . . . . . . . . . . . . 9 2.2.5. Service Behavior . . . . . . . . . . . . . . . . . . 9
2.3. SRP Server Behavior . . . . . . . . . . . . . . . . . . . 12 2.2.5.1. Public/Private key pair generation and storage . 9
2.2.5.2. Name Conflict Handling . . . . . . . . . . . . . 10
2.2.5.3. Record Lifetimes . . . . . . . . . . . . . . . . 10
2.2.5.4. Compression in SRV records . . . . . . . . . . . 11
2.2.5.5. Removing published services . . . . . . . . . . . 11
2.3. Validation and Processing of SRP Updates . . . . . . . . 12
2.3.1. Validation of Adds and Deletes . . . . . . . . . . . 12 2.3.1. Validation of Adds and Deletes . . . . . . . . . . . 12
2.3.1.1. Service Discovery Instruction . . . . . . . . . . 13
2.3.1.2. Service Description Instruction . . . . . . . . . 13
2.3.1.3. Host Description Instruction . . . . . . . . . . 14
2.3.2. Valid SRP Update Requirements . . . . . . . . . . . . 14 2.3.2. Valid SRP Update Requirements . . . . . . . . . . . . 14
2.3.3. FCFS Name And Signature Validation . . . . . . . . . 15 2.3.3. FCFS Name And Signature Validation . . . . . . . . . 15
2.3.4. SRP Update response . . . . . . . . . . . . . . . . . 16 2.3.4. Handling of Service Subtypes . . . . . . . . . . . . 16
2.3.5. Optional Behavior . . . . . . . . . . . . . . . . . . 16 2.3.5. SRP Update response . . . . . . . . . . . . . . . . . 16
2.3.6. Optional Behavior . . . . . . . . . . . . . . . . . . 16
3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 17 3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 17
4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Cleaning up stale data . . . . . . . . . . . . . . . . . 17 4.1. Cleaning up stale data . . . . . . . . . . . . . . . . . 18
5. Sleep Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5.1. Source Validation . . . . . . . . . . . . . . . . . . . . 19
6.1. Source Validation . . . . . . . . . . . . . . . . . . . . 20 5.2. SRP Server Authentication . . . . . . . . . . . . . . . . 20
6.2. SRP Server Authentication . . . . . . . . . . . . . . . . 21 5.3. Required Signature Algorithm . . . . . . . . . . . . . . 20
6.3. Required Signature Algorithm . . . . . . . . . . . . . . 21 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 7. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 21
8. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8.1. Registration and Delegation of 'service.arpa' as a
9.1. Registration and Delegation of 'service.arpa' as a Special-Use Domain Name . . . . . . . . . . . . . . . . . 21
Special-Use Domain Name . . . . . . . . . . . . . . . . . 22
9.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 22 8.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 21
9.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 22 8.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 22
9.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 23 8.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 22
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
12. Normative References . . . . . . . . . . . . . . . . . . . . 24 11. Normative References . . . . . . . . . . . . . . . . . . . . 24
13. Informative References . . . . . . . . . . . . . . . . . . . 26 12. Informative References . . . . . . . . . . . . . . . . . . . 26
Appendix A. Testing using standard RFC2136-compliant servers . . 27 Appendix A. Testing using standard RFC2136-compliant servers . . 27
Appendix B. How to allow services to update standard Appendix B. How to allow services to update standard
RFC2136-compliant servers . . . . . . . . . . . . . . . . 28 RFC2136-compliant servers . . . . . . . . . . . . . . . . 28
Appendix C. Sample BIND9 configuration for Appendix C. Sample BIND9 configuration for
default.service.arpa. . . . . . . . . . . . . . . . . . . 28 default.service.arpa. . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
DNS-Based Service Discovery [RFC6763] is a component of Zero DNS-Based Service Discovery [RFC6763] is a component of Zero
Configuration Networking [RFC6760] [ZC] [I-D.cheshire-dnssd-roadmap]. Configuration Networking [RFC6760] [ZC] [I-D.cheshire-dnssd-roadmap].
This document describes an enhancement to DNS-Based Service Discovery This document describes an enhancement to DNS-Based Service Discovery
skipping to change at page 5, line 45 skipping to change at page 6, line 9
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 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
skipping to change at page 7, line 8 skipping to change at page 7, line 15
2.2. Protocol Details 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.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.
* 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 * 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 * 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 [RFC6763] describes the details of what each of these types of
contains and is the definitive source for information about what to updates contains, with the exception of the KEY RR, which is defined
publish; the reason for summarizing this here is to provide the in [RFC2539]. These RFCs should be considered the definitive source
reader with enough information about what will be published that the for information about what to publish; the reason for summarizing
service registration process can be understood at a high level this here is to provide the reader with enough information about what
without first learning the full details of DNS-SD. Also, the will be published that the service registration process can be
"Service Instance Name" is an important aspect of first-come, first- understood at a high level without first learning the full details of
serve naming, which we describe later on in this document. DNS-SD. Also, the "Service Instance Name" is an important aspect of
first-come, first-serve naming, which we describe later on in this
document.
2.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
skipping to change at page 8, line 13 skipping to change at page 8, line 19
handle rewriting that to a different domain if necessary. handle rewriting that to a different domain if necessary.
2.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.
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.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.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:
* 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. * It enforces policy about what updates are allowed.
* It optionally performs rewriting of "default.service.arpa" to some * It optionally performs rewriting of "default.service.arpa" to some
other domain. other domain.
* It optionally performs automatic population of the address-to-name * 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 * 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
"default.service.arpa" * Constrained-Node SRP clients are allowed to send updates to the
generic domain "default.service.arpa"
2.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 DNS Update client (which issues the a secret key shared between the DNS Update client (which issues the
update) and the server (which authenticates it). This model does not update) and the server (which authenticates it). This model does not
work for 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
skipping to change at page 9, line 39 skipping to change at page 9, line 42
Service Description and the Host Description. Service Description and the Host Description.
2.2.5. Service Behavior 2.2.5. Service Behavior
2.2.5.1. Public/Private key pair generation and storage 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 SRP client, the SRP client MUST be pre-configured with a on the SRP client, the SRP client MUST be pre-configured with a
public/private key pair in read-only storage that can be used. This public/private key pair in read-only storage that can be used. This
key pair MUST be unique to the device. This key pair MUST be unique key pair MUST be unique to the device. A device with rewritable
to the device. A device with rewritable storage should retain this storage should retain this key indefinitely. When the device changes
key indefinitely. When the device changes ownership, it may be ownership, it may be appropriate to erase the old key and install a
appropriate to erase the old key and install a new one. Therefore, new one. Therefore, the SRP client on the device SHOULD provide a
the SRP client on the device SHOULD provide a mechanism to overwrite mechanism to overwrite the key, for example as the result of a
the key, for example as the result of a "factory reset." "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 Instruction and each Service Description Instruction. Each KEY
contain the same public key. The update is signed using SIG(0), record MUST contain the same public key. The update is signed using
using the private key that corresponds to the public key in the KEY SIG(0), using the private key that corresponds to the public key in
record. The lifetimes of the records in the update is set using the the KEY record. The lifetimes of the records in the update is set
EDNS(0) Update Lease option [I-D.sekar-dns-ul]. using the 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 2.2.5.2. Name Conflict Handling
Both Host Description records and Service Description Records can Both Host Description records and Service Description Records can
skipping to change at page 11, line 14 skipping to change at page 11, line 14
2.2.5.4. Compression in SRV records 2.2.5.4. Compression in SRV records
Although [RFC2782] requires that the target name in the SRV record Although [RFC2782] requires that the target name in the SRV record
not be compressed, an SRP client SHOULD compress the target in the not be compressed, an SRP client SHOULD compress the target in the
SRV record. The motivation for _not_ compressing in RFC2782 is not SRV record. The motivation for _not_ compressing in RFC2782 is not
stated, but is assumed to be because a caching resolver that does 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 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 and thus return an invalid pointer in response to a query. This does
not apply in the case of SRP: an SRP server needs to understand SRV not apply in the case of SRP: an SRP server needs to understand SRV
records in order to validate the SRP update. Compression of the records in order to validate the SRP Update. Compression of the
target potentially saves substantial space in the SRP update. target potentially saves substantial space in the SRP Update.
2.2.5.5. Removing published services 2.2.5.5. Removing published services
2.2.5.5.1. Removing all published services 2.2.5.5.1. Removing all published services
To remove all the services registered to a particular host, the SRP To remove all the services registered to a particular host, the SRP
client retransmits its most recent update with an Update Lease option client retransmits its most recent update with an Update Lease option
that has a LEASE value of zero. If the registration is to be that has a LEASE value of zero. If the registration is to be
permanently removed, KEY-LEASE should also be zero. Otherwise, it permanently removed, KEY-LEASE should also be zero. Otherwise, it
should have the same value it had previously; this holds the name in should have the same value it had previously; this holds the name in
skipping to change at page 11, line 49 skipping to change at page 11, line 49
zero, an SRP server MUST remove all service instances pointing to a zero, an SRP server MUST remove all service instances pointing to a
host when a host is removed, even if the SRP client doesn't list them host when a host is removed, even if the SRP client doesn't list them
explicitly. If the key lease time is nonzero, the SRP server MUST explicitly. If the key lease time is nonzero, the SRP server MUST
NOT delete the KEY records for these SRP clients. NOT delete the KEY records for these SRP clients.
2.2.5.5.2. Removing some published services 2.2.5.5.2. Removing some published services
In some use cases a client may need to remove some specific service, In some use cases a client may need to remove some specific service,
without removing its other services. This can be accomplished in one without removing its other services. This can be accomplished in one
of two ways. To simply remove a specific service, the client sends a of two ways. To simply remove a specific service, the client sends a
valid SRP update where the Service Discovery instruction valid SRP Update where the Service Discovery Instruction
(Section 2.3.1.1) contains a single Delete an RR from an RRset (Section 2.3.1.1) contains a single Delete an RR from an RRset
([RFC2136], Section 2.5.4) update that deletes the PTR record whose ([RFC2136], Section 2.5.4) update that deletes the PTR record whose
target is the service instance name. The Service Description target is the service instance name. The Service Description
instruction (Section 2.3.1.2) in this case contains a single Delete Instruction (Section 2.3.1.2) in this case contains a single Delete
all RRsets from a Name ([RFC2136], Section 2.5.3) update to the all RRsets from a Name ([RFC2136], Section 2.5.3) update to the
service instance name. service instance name.
The second alternative is used when some service is being replaced by The second alternative is used when some service is being replaced by
a different service with a different service instance name. In this a different service with a different service instance name. In this
case, the old service is deleted as in the first alternative. The case, the old service is deleted as in the first alternative. The
new service is added, just as it would be in an update that wasn't new service is added, just as it would be in an update that wasn't
deleting the old service. Because both the removal of the old deleting the old service. Because both the removal of the old
service and the add of the new service consist of a valid Service service and the add of the new service consist of a valid Service
Discovery instruction and a valid Service Description instruction, Discovery Instruction and a valid Service Description Instruction,
the update as a whole is a valid SRP update, and will result in the the update as a whole is a valid SRP Update, and will result in the
old service being removed and the new one added, or, to put it old service being removed and the new one added, or, to put it
differently, in the old service being replaced by the new service. differently, in the old service being replaced by the new service.
It is perhaps worth noting that if a service is being updated without It is perhaps worth noting that if a service is being updated without
the service instance name changing, that will look very much like the the service instance name changing, that will look very much like the
second alternative above. The difference is that because the target second alternative above. The difference is that because the target
for the PTR record in the Service Discovery instruction is the same for the PTR record in the Service Discovery Instruction is the same
for both the Delete An RR From An RRset update and the Add To An for both the Delete An RR From An RRset update and the Add To An
RRSet update, these will be seen as a single Service Description RRSet update, these will be seen as a single Service Description
instruction, not as two instructions. The same would be true of the Instruction, not as two Instructions. The same would be true of the
Service Description instruction. Service Description Instruction.
Whichever of these two alternatives is used, the host lease will be Whichever of these two alternatives is used, the host lease will be
updated with the lease time provided in the SRP update. In neither updated with the lease time provided in the SRP update. In neither
of these cases is it permissible to delete the host. All services of these cases is it permissible to delete the host. All services
must point to a host. If a host is to be deleted, this must be done must point to a host. If a host is to be deleted, this must be done
using the method described in Section 2.2.5.5.1, which deletes the using the method described in Section 2.2.5.5.1, which deletes the
host and all services that have that host as their target. host and all services that have that host as their target.
2.3. SRP Server Behavior 2.3. Validation and Processing of SRP Updates
2.3.1. Validation of Adds and Deletes 2.3.1. Validation of Adds and Deletes
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 or SRP Updates consist of a set of _instructions_ that together add or
remove one or more services. Each instruction consists some remove one or more services. Each instruction consists of some
combination of delete updates and add updates. When an instruction combination of delete updates and add updates. When an instruction
contains a delete and an add, the delete MUST precede the add. contains a delete and an add, the delete MUST precede the add.
The SRP server checks each instruction in the SRP update to see that 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 Instruction, a Service Description
update, or a Host Description update. Order matters in DNS updates. Instruction, or a Host Description Instruction. Order matters in DNS
Specifically, deletes must precede adds for records that the deletes updates. Specifically, deletes must precede adds for records that
would affect; otherwise the add will have no effect. This is the the deletes would affect; otherwise the add will have no effect.
only ordering constraint; aside from this constraint, updates may This is the only ordering constraint; aside from this constraint,
appear in whatever order is convenient when constructing the update. updates may appear in whatever order is convenient when constructing
the update.
Because the SRP update is a DNS update, it MUST contain a single 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 2.3.1.1. Service Discovery Instruction
An instruction is a Service Discovery Instruction if it contains An instruction is a Service Discovery Instruction if it contains
* exactly one "Add to an RRSet" or exactly one "Delete an RR from an * exactly one "Add to an RRSet" or exactly one "Delete an RR from an
RRSet" ([RFC2136], Section 2.5.1) RR update, RRSet" ([RFC2136], Section 2.5.1) RR update,
* which updates a PTR RR, * which updates a PTR RR,
* which points to a Service Instance Name * the target of which is a Service Instance Name
* for which a Service Description Instruction is present in the SRP * for which name a Service Description Instruction is present in the
Update SRP Update
* if the Service Discovery update is an "Add to an RRSet" * if the Service Discovery Instruction is an "Add to an RRSet"
instruction, the Service Description Instruction does not match if instruction, the Service Description Instruction does not match if
it does not contain an "Add to an RRset" update for the SRV RR it does not contain an "Add to an RRset" update for the SRV RR
describing that service. describing that service.
* if the Service Discovery Instruction is an "Delete an RR from an * if the Service Discovery Instruction is a "Delete an RR from an
RRSet" update, the Service Description Instruction does not match RRSet" update, the Service Description Instruction does not match
if it contains an "Add to an RRset" update. if it contains an "Add to an RRset" update.
* Service Discovery Instructions do not contain any other add or * Service Discovery Instructions do not contain any other add or
delete updates. delete updates.
2.3.1.2. Service Description Instruction 2.3.1.2. Service Description Instruction
An instruction is a Service Description Instruction if, for the An instruction is a Service Description Instruction if, for the
appropriate Service Instance Name, it contains appropriate Service Instance Name, it contains
skipping to change at page 13, line 51 skipping to change at page 14, line 4
* zero or one "Add to an RRset" KEY RR that, if present, contains * zero or one "Add to an RRset" KEY RR that, if present, contains
the public key corresponding to the private key that was used to the public key corresponding to the private key that was used to
sign the message (if present, the KEY MUST match the KEY RR given sign the message (if present, the KEY MUST match the KEY RR given
in the Host Description), in the Host Description),
* zero or more "Add to an RRset" TXT RRs, * zero or more "Add to an RRset" TXT RRs,
* If there is one "Add to an RRset" SRV update, there MUST be at * If there is one "Add to an RRset" SRV update, there MUST be at
least one "Add to an RRset" TXT update. least one "Add to an RRset" TXT update.
* the target of the SRV RR Add, if present points to a hostname for * the target of the SRV RR Add, if present points to a hostname for
which there is a Host Description Instruction in the SRP Update, which there is a Host Description Instruction in the SRP Update,
or or
* if there is no "Add to an RRset" SRV RR, then either * if there is no "Add to an RRset" SRV RR, then either
- the name to which the "Delete all RRsets from a name" applies - the name to which the "Delete all RRsets from a name" applies
does not exist, or does not exist, or
- there is an existing KEY RR on that name, which matches the key - there is an existing KEY RR on that name, which matches the key
with which the SRP Update was signed. with which the SRP Update was signed.
* Service Descriptions Instructions do not modify any other RRs. * Service Descriptions Instructions do not modify any other resource
records.
An SRP server MUST correctly handle compressed names in the SRV An SRP server MUST correctly handle compressed names in the SRV
target. target.
2.3.1.3. Host Description Instruction 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
* exactly one "Delete all RRsets from a name" RR, * exactly one "Delete all RRsets from a name" RR,
* 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,
* 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.
* 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,
* there is a Service Instance Name Instruction in the SRP update for * there is a Service Instance Name Instruction in the SRP Update for
which the SRV RR that is added points to the hostname being which the SRV RR that is added points to the hostname being
updated by this update. updated by this update.
* Host Description updates do not modify any other records. * Host Description Instructions do not modify any other resource
records.
2.3.2. Valid SRP Update Requirements 2.3.2. Valid SRP Update Requirements
An SRP Update MUST include zero or more Service Discovery An SRP Update MUST include zero or more Service Discovery
instructions. For each Service Discovery instruction, there MUST be Instructions. For each Service Discovery Instruction, there MUST be
at least one Service Description instruction. Note that in the case at least one Service Description Instruction. Note that in the case
of SRP subtypes Section 7.1 of [RFC6763], it's quite possible that of SRP subtypes (Section 7.1 of [RFC6763]), it's quite possible that
two Service Discovery instructions might reference the same Service two Service Discovery Instructions might reference the same Service
Description instruction. For each Service Description instruction Description Instruction. For each Service Description Instruction
there MUST be at least one Service Discovery instruction with its there MUST be at least one Service Discovery Instruction with its
service instance name as the target of its PTR record. There MUST be service instance name as the target of its PTR record. There MUST be
exactly one Host Description Instruction. Every Service Description exactly one Host Description Instruction. Every Service Description
instruction must have that Host Description instruction as the target Instruction must have that Host Description Instruction as the target
of its SRV record. A DNS Update that does not meet these constraints of its SRV record. A DNS Update that does not meet these constraints
is not an SRP update. is not an SRP Update.
A DNS Update that contains any additional adds or deletes that cannot A DNS Update that contains any additional adds or deletes that cannot
be identified as Service Discovery, Service Description or Host be identified as Service Discovery, Service Description or Host
Description instructions is not an SRP update. A DNS update that Description Instructions is not an SRP Update. A DNS update that
contains any prerequisites is not an SRP update. Such messages contains any prerequisites is not an SRP Update. Such messages
should either be processed as regular RFC2136 updates, including should either be processed as regular RFC2136 updates, including
access control checks and constraint checks, if supported, or else access control checks and constraint checks, if supported, or else
rejected with RCODE=REFUSED. rejected with RCODE=REFUSED.
In addition, in order for an update to be a valid SRP update, the In addition, in order for an update to be a valid SRP Update, the
target of every Service Discovery Instruction MUST be a Service target of every Service Discovery Instruction MUST be a Service
Description Instruction that is present in the SRP Update. There Description Instruction that is present in the SRP Update. There
MUST NOT be any Service Description Instruction to which no Service MUST NOT be any Service Description Instruction to which no Service
Discovery Instruction points. The target of the SRV record in every Discovery Instruction points. The target of the SRV record in every
Service Description instruction MUST be the single Host Description Service Description Instruction MUST be the single Host Description
Instruction. Instruction.
If the definitions of each of these instructions are followed If the definitions of each of these instructions are followed
carefully and the update requirements are validated correctly, many carefully and the update requirements are validated correctly, many
DNS Updates that look very much like SRP updates nevertheless will DNS Updates that look very much like SRP Updates nevertheless will
fail to validate. For example, a DNS update that contains an RRset fail to validate. For example, a DNS update that contains an Add to
Add to a Service Name and an RRset Add to a Service Instance Name, an RRset instruction for a Service Name and an Add to an RRset
where the Service Name does not reference the Service Instance Name, instruction for a Service Instance Name, where the PTR record added
is not a valid SRP update message, but may be a valid RFC2136 update. to 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 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
Instructions. 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 record in the SRP
the SRP Update (whether provided or taken from the Host Description 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) against
public key in the KEY record of the Host Description update. If the the public key in the KEY record of the Host Description Instruction.
validation fails, the server MUST reject the SRP Update with the If the validation fails, the server MUST reject the SRP Update with
REFUSED RCODE. Otherwise, the SRP update is considered valid and the 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 Instruction 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 SRP Update has been
and it must be the same KEY RR that is present in the Host applied, have a KEY RR, and it must be the same KEY RR that is
Description to which the Service Description refers. present in the Host Description to which the Service Description
refers.
2.3.4. SRP Update response 2.3.4. Handling of Service Subtypes
SRP servers MUST treat the update instructions for a service type and
all its subtypes as atomic. That is, when a service and its subtypes
are being updated, whatever information appears in the SRP Update is
the entirety of information about that service and its subtypes. If
any subtype appeared in a previous update but does not appear in the
current update, then the DNS server MUST remove that subtype.
Similarly, there is no mechanism for deleting subtypes. A delete of
a service deletes all of its subtypes. To delete an individual
subtype, an SRP Update must be constructed that contains the service
type and all subtypes for that service.
2.3.5. SRP Update response
The status that is returned depends on the result of processing the The status that is returned depends on the result of processing the
update, and can be either SUCCESS or SERVFAIL: all other possible update, and can be either SUCCESS or SERVFAIL: all other possible
outcomes should already have been accounted for when applying the outcomes should already have been accounted for when applying the
constraints that qualify the update as an SRP Update. constraints that qualify the update as an SRP Update.
2.3.5. Optional Behavior 2.3.6. Optional Behavior
The server MAY add a Reverse Mapping that corresponds to the Host The server MAY add a Reverse Mapping that corresponds to the Host
Description. This is not required because the Reverse Mapping serves Description. This is not required because the Reverse Mapping serves
no protocol function, but it may be useful for debugging, e.g. in no protocol function, but it may be useful for debugging, e.g. in
annotating network packet traces or logs. In order for the server to annotating network packet traces or logs. In order for the server to
add a reverse mapping update, it must be authoritative for the zone add a reverse mapping update, it must be authoritative for the zone
or have credentials to do the update. The SRP client MAY also do a or have credentials to do the update. The SRP client MAY also do a
reverse mapping update if it has credentials to do so. reverse mapping update if it has credentials to do so.
The server MAY apply additional criteria when accepting updates. In The server MAY apply additional criteria when accepting updates. In
skipping to change at page 16, line 43 skipping to change at page 17, line 14
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 SRP 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.
3. 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 servers MUST check that the TTLs for all RRs within the SRP
SRP update are the same. If they are not, the SRP update MUST be 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 SRP 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 4.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 DNS-SD client side, data refreshes; this increases latency on the DNS-SD client side,
increases load on any caching resolvers and on the authoritative increases load on any caching resolvers and on the authoritative
server, and also increases network load, which may be an issue for server, and also increases network load, which may be an issue for
constrained networks. Longer TTLs will increase the likelihood that constrained networks. Longer TTLs will increase the likelihood that
data in 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.
skipping to change at page 18, line 10 skipping to change at page 18, line 28
to represent the time after the update during which the registered to represent the time after the update during which the registered
records other than the KEY record should be assumed to be valid. The records other than the KEY record should be assumed to be valid. The
Key Lease time represents the time after the update during which the Key Lease time represents the time after the update during which the
KEY record 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.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. Constrained devices with currently thought to be good choices. Constrained devices with
limited battery that wake infrequently are likely to negotiate longer limited battery that wake infrequently are likely to request longer
leases. SRP clients that are going to continue to use names on which leases; servers that support such devices may need to set higher
limits. SRP clients that are going to continue to use names on which
they hold leases should update well before the lease ends, in case they hold leases should update well before the lease ends, in case
the registration service is unavailable or under heavy load. the registration service is unavailable or under heavy load.
The lease time applies specifically to the host. All service The lease time applies specifically to the host. All service
instances, and all service entries for such service instances, depend instances, and all service entries for such service instances, depend
on the host. When the lease on a host expires, the host and all on the host. When the lease on a host expires, the host and all
services that reference it MUST be removed at the same time-it is services that reference it MUST be removed at the same time-it is
never valid for a service instance to remain when the host it never valid for a service instance to remain when the host it
references has been removed. If the KEY record for the host is to references has been removed. If the KEY record for the host is to
remain, the KEY record for any services that reference it MUST also remain, the KEY record for any services that reference it MUST also
skipping to change at page 18, line 34 skipping to change at page 19, line 4
service PTR record for which there is no service instance on the service PTR record for which there is no service instance on the
target of the PTR record. target of the PTR record.
SRP Servers SHOULD also track a lease time per service instance. The SRP Servers SHOULD also track a lease time per service instance. The
reason for doing this is that a client may re-register a host with a reason for doing this is that a client may re-register a host with a
different set of services, and not remember that some different different set of services, and not remember that some different
service instance had previously been registered. In this case, when service instance had previously been registered. In this case, when
that service instance lease expires, the SRP server SHOULD remove the that service instance lease expires, the SRP server SHOULD remove the
service instance (although the KEY record for the service instance service instance (although the KEY record for the service instance
SHOULD be retained until the key lease on that service expires). SHOULD be retained until the key lease on that service expires).
This is beneficial because if the SRP client continues to renew the This is beneficial because if the SRP client continues to renew the
host, but never mentions the stale service again, the stale service host, but never mentions the stale service again, the stale service
will continue to be advertised. will continue to be advertised.
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 SRP client must honor them in those specified in the SRP Update; the SRP client must honor them in
either case. either case.
SRP clients should assume that each lease ends N seconds after the SRP clients should assume that each lease ends N seconds after the
update was first transmitted, where N is the lease duration. Servers update was first transmitted, where N is the lease duration. Servers
should assume that each lease ends N seconds after the update that should assume that each lease ends N seconds after the update that
was successfully processed was received. Because the server will was successfully processed was received. Because the server will
always receive the update after the SRP client sent it, this avoids always receive the update after the SRP client sent it, this avoids
the 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'.
5. Sleep Proxy 5. Security Considerations
Another use of SRP is for devices that sleep to reduce power
consumption.
In this case, in addition to the DNS Update Lease option
[I-D.sekar-dns-ul] described above, the device includes an EDNS(0)
OWNER Option [I-D.cheshire-edns0-owner-option].
The EDNS(0) Update Lease option constitutes a promise by the device
that it will wake up before this time elapses, to renew its
registration and thereby demonstrate that it is still attached to the
network. If it fails to renew the registration by this time, that
indicates that it is no longer attached to the network, and its
registration (except for the KEY in the Host Description) should be
deleted.
The EDNS(0) OWNER Option indicates that the device will be asleep,
and will not be receptive to normal network traffic. When a DNS
server receives a DNS Update with an EDNS(0) OWNER Option, that
signifies that the SRP server should set up a proxy for any IPv4 or
IPv6 address records in the DNS Update message. This proxy should
send ARP or ND messages claiming ownership of the IPv4 and/or IPv6
addresses in the records in question. In addition, the proxy should
answer future ARP or ND requests for those IPv4 and/or IPv6
addresses, claiming ownership of them. When the DNS server receives
a TCP SYN or UDP packet addressed to one of the IPv4 or IPv6
addresses for which it proxying, it should then wake up the sleeping
device using the information in the EDNS(0) OWNER Option. At present
version 0 of the OWNER Option specifies the "Wake-on-LAN Magic
Packet" that needs to be sent; future versions could be extended to
specify other wakeup mechanisms.
Note that although the authoritative DNS server that implements the
SRP function need not be on the same link as the sleeping host, the
Sleep Proxy must be on the same link.
It is not required that sleepy nodes on a Constrained-Node Network
support sleep proxy. Such devices may have different mechanisms for
dealing with sleep and wakeup. An SRP registration for such a device
will be useful regardless of the mechanism whereby messages are
delivered to the sleepy end device. For example, the message might
be held in a buffer for an extended period of time by an intermediate
device on a mesh network, and then delivered to the device when it
wakes up. The exact details of such behaviors are out of scope for
this document.
6. Security Considerations
6.1. Source Validation 5.1. Source Validation
SRP updates have no authorization semantics other than first-come, SRP Updates have no authorization semantics other than first-come,
first-served. This means that if an attacker from outside of the first-served. This means that if an attacker from outside of the
administrative domain of the server knows the server's IP address, it administrative domain of the server knows the server's IP address, it
can in principle send updates to the server that will be processed can in principle send updates to the server that will be processed
successfully. Servers should therefore be configured to reject successfully. Servers should therefore be configured to reject
updates from source addresses outside of the administrative domain of updates from source addresses outside of the administrative domain of
the server. the server.
For updates sent to an anycast IP address of an SRP server, this For updates sent to an anycast IP address of an SRP server, this
validation must be enforced by every router on the path from the validation must be enforced by every router on the path from the
Constrained-Device Network to the unconstrained portion of the Constrained-Device Network to the unconstrained portion of the
network. For TCP updates, the initial SYN-SYN+ACK handshake prevents network. For TCP updates, the initial SYN-SYN+ACK handshake prevents
updates being forged by an off-network attacker. In order to ensure updates being forged by an off-network attacker. In order to ensure
that this handshake happens, Service Discovery Protocol servers that this handshake happens, SRP servers relying on three-way-
relying on three-way-handshake validation MUST NOT accept TCP Fast handshake validation MUST NOT accept TCP Fast Open payloads. If the
Open payloads. If the network infrastructure allows it, an SRP network infrastructure allows it, an SRP server MAY accept TCP Fast
server MAY accept TCP Fast Open payloads if all such packets are Open payloads if all such packets are validated along the path, and
validated along the path, and the network is able to reject this type the network is able to reject this type of spoofing at all ingress
of spoofing at all ingress points. 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 SRP clients may also accept other server that accepts updates from SRP clients may also accept other
DNS updates, and those DNS updates may be validated using different DNS updates, and those DNS updates may be validated using different
rules. However, in the case of a DNS service that accepts SRP rules. However, in the case of a DNS service that accepts SRP
updates, the intersection of the SRP update rules and whatever other updates, the intersection of the SRP Update rules and whatever other
update rules are present must be considered very carefully. update rules are present must be considered very carefully.
For example, a normal, authenticated DNS update to any RR that was For example, a normal, authenticated DNS update to any RR that was
added using SRP, but that is authenticated using a different key, added using SRP, but that is authenticated using a different key,
could be used to override a promise made by the registration could be used to override a promise made by the SRP Server to an SRP
protocol, by replacing all or part of the service registration client, by replacing all or part of the service registration
information with information provided by an SRP client. An information with information provided by an authenticated DNS update
implementation that allows both kinds of updates should not allow DNS client. An implementation that allows both kinds of updates should
Update clients that are using different authentication and not allow DNS Update clients that are using different authentication
authorization credentialsto to update records added by SRP clients. and authorization credentials to to update records added by SRP
clients.
6.2. SRP Server Authentication 5.2. SRP Server Authentication
This specification does not provide a mechanism for validating This specification does not provide a mechanism for validating
responses from DNS servers to SRP clients. In the case of responses from DNS servers to SRP clients. In the case of
Constrained Network/Constrained Node clients, such validation isn't Constrained Network/Constrained Node clients, such validation isn't
practical because there's no way to establish trust. In principle, a practical because there's no way to establish trust. In principle, a
KEY RR could be used by a non-constrained SRP client to validate KEY RR could be used by a non-constrained SRP client to validate
responses from the server, but this is not required, nor do we responses from the server, but this is not required, nor do we
specify a mechanism for determining which key to use. specify a mechanism for determining which key to use.
6.3. Required Signature Algorithm 5.3. Required Signature Algorithm
For validation, SRP servers MUST implement the ECDSAP256SHA256 For validation, SRP servers MUST implement the ECDSAP256SHA256
signature algorithm. SRP servers SHOULD implement the algorithms signature algorithm. SRP servers SHOULD implement the algorithms
specified in [RFC8624], Section 3.1, in the validation column of the specified in [RFC8624], Section 3.1, in the validation column of the
table, that are numbered 13 or higher and have a "MUST", table, that are numbered 13 or higher and have a "MUST",
"RECOMMENDED", or "MAY" designation in the validation column of the "RECOMMENDED", or "MAY" designation in the validation column of the
table. SRP clients MUST NOT assume that any algorithm numbered lower table. SRP clients MUST NOT assume that any algorithm numbered lower
than 13 is available for use in validating SIG(0) signatures. than 13 is available for use in validating SIG(0) signatures.
7. Privacy Considerations 6. Privacy Considerations
Because DNSSD SRP updates can be sent off-link, the privacy Because DNSSD SRP Updates can be sent off-link, the privacy
implications of SRP are different than for multicast DNS responses. implications of SRP are different than for multicast DNS responses.
Host implementations that are using TCP SHOULD also use TLS if Host implementations that are using TCP SHOULD also use TLS if
available. Server implementations MUST offer TLS support. The use available. Server implementations MUST offer TLS support. The use
of TLS with DNS is described in [RFC7858] and [RFC8310]. of TLS with DNS is described in [RFC7858] and [RFC8310].
Hosts that implement TLS support SHOULD NOT fall back to TCP; since Hosts that implement TLS support SHOULD NOT fall back to TCP; since
servers are required to support TLS, it is entirely up to the host servers are required to support TLS, it is entirely up to the host
implementation whether to use it. implementation whether to use it.
Public keys can be used as identifiers to track hosts. SRP servers Public keys can be used as identifiers to track hosts. SRP servers
MAY elect not to return KEY records for queries for SRP MAY elect not to return KEY records for queries for SRP
registrations. registrations.
8. Delegation of 'service.arpa.' 7. Delegation of 'service.arpa.'
In order to be fully functional, the owner of the 'arpa.' zone must In order to be fully functional, the owner of the 'arpa.' zone must
add a delegation of 'service.arpa.' in the '.arpa.' zone [RFC3172]. add a delegation of 'service.arpa.' in the '.arpa.' zone [RFC3172].
This delegation should be set up as was done for 'home.arpa', as a This delegation should be set up as was done for 'home.arpa', as a
result of the specification in Section 7 of [RFC8375]. result of the specification in Section 7 of [RFC8375].
9. IANA Considerations 8. IANA Considerations
9.1. Registration and Delegation of 'service.arpa' as a Special-Use 8.1. Registration and Delegation of 'service.arpa' as a Special-Use
Domain Name Domain Name
IANA is requested to record the domain name 'service.arpa.' in the IANA is requested to record the domain name 'service.arpa.' in the
Special-Use Domain Names registry [SUDN]. IANA is requested, with Special-Use Domain Names registry [SUDN]. IANA is requested, with
the approval of IAB, to implement the delegation requested in the approval of IAB, to implement the delegation requested in
Section 8. Section 7.
IANA is further requested to add a new entry to the "Transport- IANA is further requested to add a new entry to the "Transport-
Independent Locally-Served Zones" subregistry of the the "Locally- Independent Locally-Served Zones" subregistry of the the "Locally-
Served DNS Zones" registry [LSDZ]. The entry will be for the domain Served DNS Zones" registry [LSDZ]. The entry will be for the domain
'service.arpa.' with the description "DNS-SD Registration Protocol 'service.arpa.' with the description "DNS-SD Registration Protocol
Special-Use Domain", listing this document as the reference. Special-Use Domain", listing this document as the reference.
9.2. 'dnssd-srp' Service Name 8.2. 'dnssd-srp' Service Name
IANA is also requested to add a new entry to the Service Names and IANA is also requested to add a new entry to the Service Names and
Port Numbers registry for dnssd-srp with a transport type of tcp. No Port Numbers registry for dnssd-srp with a transport type of tcp. No
port number is to be assigned. The reference should be to this port number is to be assigned. The reference should be to this
document, and the Assignee and Contact information should reference document, and the Assignee and Contact information should reference
the authors of this document. The Description should be as follows: the authors of this document. The Description should be as follows:
Availability of DNS Service Discovery Service Registration Protocol Availability of DNS Service Discovery Service Registration Protocol
Service for a given domain is advertised using the Service for a given domain is advertised using the
"_dnssd-srp._tcp.<domain>." SRV record gives the target host and "_dnssd-srp._tcp.<domain>" SRV record gives the target host and port
port where DNSSD Service Registration Service is provided for the where DNSSD Service Registration Service is provided for the named
named domain. domain.
9.3. 'dnssd-srp-tls' Service Name 8.3. 'dnssd-srp-tls' Service Name
IANA is also requested to add a new entry to the Service Names and IANA is also requested to add a new entry to the Service Names and
Port Numbers registry for dnssd-srp with a transport type of tcp. No Port Numbers registry for dnssd-srp with a transport type of tcp. No
port number is to be assigned. The reference should be to this port number is to be assigned. The reference should be to this
document, and the Assignee and Contact information should reference document, and the Assignee and Contact information should reference
the authors of this document. The Description should be as follows: the authors of this document. The Description should be as follows:
Availability of DNS Service Discovery Service Registration Protocol Availability of DNS Service Discovery Service Registration Protocol
Service for a given domain over TLS is advertised using the Service for a given domain over TLS is advertised using the
"_dnssd-srp-tls._tcp.<domain>." SRV record gives the target host and "_dnssd-srp-tls._tcp.<domain>." SRV record gives the target host and
port where DNSSD Service Registration Service is provided for the port where DNSSD Service Registration Service is provided for the
named domain. named domain.
9.4. Anycast Address 8.4. Anycast Address
IANA is requested to allocate an IPv6 Anycast address from the IPv6 IANA is requested to allocate an IPv6 Anycast address from the IPv6
Special-Purpose Address Registry, similar to the Port Control Special-Purpose Address Registry, similar to the Port Control
Protocol anycast address, 2001:1::1. The value TBD should be Protocol anycast address, 2001:1::1. The value TBD should be
replaced with the actual allocation in the table that follows. The replaced with the actual allocation in the table that follows. The
values for the registry are: values for the registry are:
+----------------------+-----------------------------+ +----------------------+-----------------------------+
| Attribute | value | | Attribute | value |
+----------------------+-----------------------------+ +----------------------+-----------------------------+
skipping to change at page 23, line 40 skipping to change at page 23, line 32
+----------------------+-----------------------------+ +----------------------+-----------------------------+
| Forwardable | True | | Forwardable | True |
+----------------------+-----------------------------+ +----------------------+-----------------------------+
| Global | True | | Global | True |
+----------------------+-----------------------------+ +----------------------+-----------------------------+
| Reserved-by-protocol | False | | Reserved-by-protocol | False |
+----------------------+-----------------------------+ +----------------------+-----------------------------+
Table 1 Table 1
10. Implementation Status 9. Implementation Status
[Note to the RFC Editor: please remove this section prior to [Note to the RFC Editor: please remove this section prior to
publication.] publication.]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC 7942. Internet-Draft, and is based on a proposal described in RFC 7942.
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
skipping to change at page 24, line 25 skipping to change at page 24, line 17
There are two known independent implementations of SRP clients: There are two known independent implementations of SRP clients:
* SRP Client for OpenThread: * SRP Client for OpenThread:
https://github.com/openthread/openthread/pull/6038 https://github.com/openthread/openthread/pull/6038
* mDNSResponder open source project: https://github.com/Abhayakara/ * mDNSResponder open source project: https://github.com/Abhayakara/
mdnsresponder mdnsresponder
There are two related implementations of an SRP server. One acts as There are two related implementations of an SRP server. One acts as
a DNS Update proxy, taking an SRP update and applying it to the a DNS Update proxy, taking an SRP Update and applying it to the
specified DNS zone using DNS update. The other acts as an specified DNS zone using DNS update. The other acts as an
Advertising Proxy [I-D.sctl-advertising-proxy]. Both are included in Advertising Proxy [I-D.sctl-advertising-proxy]. Both are included in
the mDNSResponder open source project mentioned above. the mDNSResponder open source project mentioned above.
11. Acknowledgments 10. Acknowledgments
Thanks to Toke Høiland-Jørgensen, Jonathan Hui, Esko Dijk, Kangping Thanks to Toke Høiland-Jørgensen, Jonathan Hui, Esko Dijk, Kangping
Dong and Abtin Keshavarzian for their thorough technical reviews. Dong and Abtin Keshavarzian for their thorough technical reviews.
Thanks to Kangping and Abtin as well for testing the document by Thanks to Kangping and Abtin as well for testing the document by
doing an independent implementation. Thanks to Tamara Kemper for doing an independent implementation. Thanks to Tamara Kemper for
doing a nice developmental edit, Tim Wattenberg for doing a SRP doing a nice developmental edit, Tim Wattenberg for doing a SRP
client proof-of-concept implementation at the Montreal Hackathon at client proof-of-concept implementation at the Montreal Hackathon at
IETF 102, and Tom Pusateri for reviewing during the hackathon and IETF 102, and Tom Pusateri for reviewing during the hackathon and
afterwards. afterwards.
12. Normative References 11. Normative References
[I-D.sekar-dns-ul] [I-D.sekar-dns-ul]
Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases", Cheshire, S. and T. Lemon, "An EDNS0 option to negotiate
Work in Progress, Internet-Draft, draft-sekar-dns-ul-02, 2 Leases on DNS Updates", Work in Progress, Internet-Draft,
August 2018, <https://datatracker.ietf.org/doc/html/draft- draft-sekar-dns-ul-03, 27 July 2021,
sekar-dns-ul-02>. <https://datatracker.ietf.org/doc/html/draft-sekar-dns-ul-
03>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/info/rfc2132>. <https://www.rfc-editor.org/info/rfc2132>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997, RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>. <https://www.rfc-editor.org/info/rfc2136>.
[RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the
Domain Name System (DNS)", RFC 2539, DOI 10.17487/RFC2539,
March 1999, <https://www.rfc-editor.org/info/rfc2539>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <https://www.rfc-editor.org/info/rfc2931>. 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 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
skipping to change at page 26, line 5 skipping to change at page 26, line 5
<https://www.rfc-editor.org/info/rfc8765>. <https://www.rfc-editor.org/info/rfc8765>.
[SUDN] "Special-Use Domain Names Registry", July 2012, [SUDN] "Special-Use Domain Names Registry", July 2012,
<https://www.iana.org/assignments/special-use-domain- <https://www.iana.org/assignments/special-use-domain-
names/special-use-domain-names.xhtml>. names/special-use-domain-names.xhtml>.
[LSDZ] "Locally-Served DNS Zones Registry", July 2011, [LSDZ] "Locally-Served DNS Zones Registry", July 2011,
<https://www.iana.org/assignments/locally-served-dns- <https://www.iana.org/assignments/locally-served-dns-
zones/locally-served-dns-zones.xhtml>. zones/locally-served-dns-zones.xhtml>.
13. Informative References 12. Informative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997, RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>. <https://www.rfc-editor.org/info/rfc2131>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
skipping to change at page 27, line 31 skipping to change at page 27, line 31
[I-D.cheshire-edns0-owner-option] [I-D.cheshire-edns0-owner-option]
Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", Work Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", Work
in Progress, Internet-Draft, draft-cheshire-edns0-owner- in Progress, Internet-Draft, draft-cheshire-edns0-owner-
option-01, 3 July 2017, option-01, 3 July 2017,
<https://datatracker.ietf.org/doc/html/draft-cheshire- <https://datatracker.ietf.org/doc/html/draft-cheshire-
edns0-owner-option-01>. edns0-owner-option-01>.
[I-D.sctl-advertising-proxy] [I-D.sctl-advertising-proxy]
Cheshire, S. and T. Lemon, "Advertising Proxy for DNS-SD Cheshire, S. and T. Lemon, "Advertising Proxy for DNS-SD
Service Registration Protocol", Work in Progress, Service Registration Protocol", Work in Progress,
Internet-Draft, draft-sctl-advertising-proxy-01, 22 Internet-Draft, draft-sctl-advertising-proxy-02, 12 July
February 2021, <https://datatracker.ietf.org/doc/html/ 2021, <https://datatracker.ietf.org/doc/html/draft-sctl-
draft-sctl-advertising-proxy-01>. advertising-proxy-02>.
[ZC] Cheshire, S. and D.H. Steinberg, "Zero Configuration [ZC] Cheshire, S. and D.H. Steinberg, "Zero Configuration
Networking: The Definitive Guide", O'Reilly Media, Inc. , Networking: The Definitive Guide", O'Reilly Media, Inc. ,
ISBN 0-596-10100-7, December 2005. ISBN 0-596-10100-7, December 2005.
Appendix A. Testing using standard RFC2136-compliant servers Appendix A. Testing using standard RFC2136-compliant servers
It may be useful to set up a DNS server for testing that does not It may be useful to set up a DNS server for testing that does not
implement SRP. This can be done by configuring the server to listen implement SRP. This can be done by configuring the server to listen
on the anycast address, or advertising it in the on the anycast address, or advertising it in the
_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.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
client public key on the DNS server that will be receiving the client public key on the DNS server that will be receiving the
updates. The key can then be used to authenticate the client, and updates. The key can then be used to authenticate the client, and
can be used as a requirement for the update. An example can be used as a requirement for the update. An example
configuration for testing SRP using BIND 9 is given in Appendix C. configuration for testing SRP using BIND 9 is given in Appendix C.
Appendix B. How to allow services to update standard RFC2136-compliant Appendix B. How to allow services to update standard RFC2136-compliant
servers servers
Ordinarily SRP updates will fail when sent to an RFC 2136-compliant Ordinarily SRP Updates will fail when sent to an RFC 2136-compliant
server that does not implement SRP because the zone being updated is server that does not implement SRP because the zone being updated is
"default.service.arpa", and no DNS server that is not an SRP server "default.service.arpa", and no DNS server that is not an SRP server
should normally be configured to be authoritative for should normally be configured to be authoritative for
"default.service.arpa". Therefore, a service that sends an SRP "default.service.arpa". Therefore, a service that sends an SRP
update can tell that the receiving server does not support SRP, but Update can tell that the receiving server does not support SRP, but
does support RFC2136, because the RCODE will either be NOTZONE, does support RFC2136, because the RCODE will either be NOTZONE,
NOTAUTH or REFUSED, or because there is no response to the update NOTAUTH or REFUSED, or because there is no response to the update
request (when using the anycast address) request (when using the anycast address)
In this case a service MAY attempt to register itself using regular In this case a service MAY attempt to register itself using regular
RFC2136 DNS updates. To do so, it must discover the default RFC2136 DNS updates. To do so, it must discover the default
registration zone and the DNS server designated to receive updates registration zone and the DNS server designated to receive updates
for that zone, as described earlier, using the _dns-update._udp SRV for that zone, as described earlier, using the _dns-update._udp SRV
record. It can then make the update using the port and host pointed record. It can then make the update using the port and host pointed
to by the SRV record, and should use appropriate prerequisites to to by the SRV record, and should use appropriate prerequisites to
 End of changes. 90 change blocks. 
218 lines changed or deleted 213 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/