< draft-ietf-dnssd-srp-11.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: 25 April 2022 22 October 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-11 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 2, line 30 skipping to change at page 2, line 30
2.2.3.1. How DNS-SD Service Registration differs from 2.2.3.1. How DNS-SD Service Registration differs from
standard RFC2136 DNS Update . . . . . . . . . . . . 8 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.4.1. First-Come First-Served Naming . . . . . . . . . 9
2.2.5. Service Behavior . . . . . . . . . . . . . . . . . . 9 2.2.5. Service Behavior . . . . . . . . . . . . . . . . . . 9
2.2.5.1. Public/Private key pair generation and storage . 9 2.2.5.1. Public/Private key pair generation and storage . 9
2.2.5.2. Name Conflict Handling . . . . . . . . . . . . . 10 2.2.5.2. Name Conflict Handling . . . . . . . . . . . . . 10
2.2.5.3. Record Lifetimes . . . . . . . . . . . . . . . . 10 2.2.5.3. Record Lifetimes . . . . . . . . . . . . . . . . 10
2.2.5.4. Compression in SRV records . . . . . . . . . . . 11 2.2.5.4. Compression in SRV records . . . . . . . . . . . 11
2.2.5.5. Removing published services . . . . . . . . . . . 11 2.2.5.5. Removing published services . . . . . . . . . . . 11
2.3. SRP Server Behavior . . . . . . . . . . . . . . . . . . . 12 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.1. Service Discovery Instruction . . . . . . . . . . 13
2.3.1.2. Service Description Instruction . . . . . . . . . 13 2.3.1.2. Service Description Instruction . . . . . . . . . 13
2.3.1.3. Host Description Instruction . . . . . . . . . . 14 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. Handling of Service Subtypes . . . . . . . . . . . . 16 2.3.4. Handling of Service Subtypes . . . . . . . . . . . . 16
2.3.5. SRP Update response . . . . . . . . . . . . . . . . . 16 2.3.5. SRP Update response . . . . . . . . . . . . . . . . . 16
2.3.6. Optional Behavior . . . . . . . . . . . . . . . . . . 16 2.3.6. Optional Behavior . . . . . . . . . . . . . . . . . . 16
3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 17 3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 17
4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 18 4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Cleaning up stale data . . . . . . . . . . . . . . . . . 18 4.1. Cleaning up stale data . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5.1. Source Validation . . . . . . . . . . . . . . . . . . . . 20 5.1. Source Validation . . . . . . . . . . . . . . . . . . . . 19
5.2. SRP Server Authentication . . . . . . . . . . . . . . . . 20 5.2. SRP Server Authentication . . . . . . . . . . . . . . . . 20
5.3. Required Signature Algorithm . . . . . . . . . . . . . . 21 5.3. Required Signature Algorithm . . . . . . . . . . . . . . 20
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
7. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 21 7. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8.1. Registration and Delegation of 'service.arpa' as a 8.1. Registration and Delegation of 'service.arpa' as a
Special-Use Domain Name . . . . . . . . . . . . . . . . . 21 Special-Use Domain Name . . . . . . . . . . . . . . . . . 21
8.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 22 8.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 21
8.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 22 8.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 22
8.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 22 8.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 22
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. Normative References . . . . . . . . . . . . . . . . . . . . 24 11. Normative References . . . . . . . . . . . . . . . . . . . . 24
12. Informative References . . . . . . . . . . . . . . . . . . . 25 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
skipping to change at page 6, line 9 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 15 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 19 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 * Constrained-Node SRP clients are allowed to send updates to the
"default.service.arpa" 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 42 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,
* the target of which is a Service Instance Name * the target of which is a Service Instance Name
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. Handling of Service Subtypes 2.3.4. Handling of Service Subtypes
SRP servers MUST treat the update instructions for a service type and 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 all its subtypes as atomic. That is, when a service and its subtypes
are being updated, whatever information appears in the SRP update is are being updated, whatever information appears in the SRP Update is
the entirety of information about that service and its subtypes. If the entirety of information about that service and its subtypes. If
any subtype appeared in a previous update but does not appear in the any subtype appeared in a previous update but does not appear in the
current update, then the DNS server MUST remove that subtype. current update, then the DNS server MUST remove that subtype.
Similarly, there is no mechanism for deleting subtypes. A delete of Similarly, there is no mechanism for deleting subtypes. A delete of
a service deletes all of its subtypes. To delete an individual a service deletes all of its subtypes. To delete an individual
subtype, an SRP update must be constructed that contains the service subtype, an SRP Update must be constructed that contains the service
type and all subtypes for that service. type and all subtypes for that service.
2.3.5. SRP Update response 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.6. Optional Behavior 2.3.6. Optional Behavior
skipping to change at page 17, line 14 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 28 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 19, line 12 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'.
skipping to change at page 20, line 4 skipping to change at page 19, line 40
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. Security Considerations 5. Security Considerations
5.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.
5.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.
skipping to change at page 21, line 17 skipping to change at page 21, line 7
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.
6. 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
skipping to change at page 22, line 15 skipping to change at page 22, line 7
8.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.
8.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
skipping to change at page 24, line 17 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.
10. 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
skipping to change at page 25, line 5 skipping to change at page 25, line 5
[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 27, line 51 skipping to change at page 27, line 51
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. 67 change blocks. 
121 lines changed or deleted 137 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/