draft-ietf-dnssd-srp-06.txt   draft-ietf-dnssd-srp-07.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: 22 May 2021 18 November 2020 Expires: 21 June 2021 18 December 2020
Service Registration Protocol for DNS-Based Service Discovery Service Registration Protocol for DNS-Based Service Discovery
draft-ietf-dnssd-srp-06 draft-ietf-dnssd-srp-07
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 22 May 2021. This Internet-Draft will expire on 21 June 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (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 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . . . . 6
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.4. How to secure it . . . . . . . . . . . . . . . . . . 9 2.2.4. How to secure it . . . . . . . . . . . . . . . . . . 9
2.2.5. Service Behavior . . . . . . . . . . . . . . . . . . 9 2.2.5. Service Behavior . . . . . . . . . . . . . . . . . . 9
2.3. SRP Server Behavior . . . . . . . . . . . . . . . . . . . 11 2.3. SRP Server Behavior . . . . . . . . . . . . . . . . . . . 12
2.3.1. Validation of Adds . . . . . . . . . . . . . . . . . 11 2.3.1. Validation of Adds . . . . . . . . . . . . . . . . . 12
2.3.2. Valid SRP Update Requirements . . . . . . . . . . . . 13 2.3.2. Valid SRP Update Requirements . . . . . . . . . . . . 14
2.3.3. FCFS Name And Signature Validation . . . . . . . . . 14 2.3.3. FCFS Name And Signature Validation . . . . . . . . . 14
2.3.4. SRP Update response . . . . . . . . . . . . . . . . . 14 2.3.4. SRP Update response . . . . . . . . . . . . . . . . . 15
2.3.5. Optional Behavior . . . . . . . . . . . . . . . . . . 14 2.3.5. Optional Behavior . . . . . . . . . . . . . . . . . . 15
3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 15 3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 16
4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Cleaning up stale data . . . . . . . . . . . . . . . . . 16 4.1. Cleaning up stale data . . . . . . . . . . . . . . . . . 17
5. Sleep Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Sleep Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6.1. Source Validation . . . . . . . . . . . . . . . . . . . . 18 6.1. Source Validation . . . . . . . . . . . . . . . . . . . . 20
6.2. SRP Server Authentication . . . . . . . . . . . . . . . . 19 6.2. SRP Server Authentication . . . . . . . . . . . . . . . . 20
6.3. Required Signature Algorithm . . . . . . . . . . . . . . 19 6.3. Required Signature Algorithm . . . . . . . . . . . . . . 21
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
8. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 20 8. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.1. Registration and Delegation of 'service.arpa' as a 9.1. Registration and Delegation of 'service.arpa' as a
Special-Use Domain Name . . . . . . . . . . . . . . . . . 20 Special-Use Domain Name . . . . . . . . . . . . . . . . . 21
9.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 20 9.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 22
9.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 20 9.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 22
9.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 21 9.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
11. Normative References . . . . . . . . . . . . . . . . . . . . 22 11. Normative References . . . . . . . . . . . . . . . . . . . . 23
12. Informative References . . . . . . . . . . . . . . . . . . . 23 12. Informative References . . . . . . . . . . . . . . . . . . . 25
Appendix A. Testing using standard RFC2136-compliant servers . . 24 Appendix A. Testing using standard RFC2136-compliant servers . . 26
Appendix B. How to allow services to update standard Appendix B. How to allow services to update standard
RFC2136-compliant servers . . . . . . . . . . . . . . . . 25 RFC2136-compliant servers . . . . . . . . . . . . . . . . 27
Appendix C. Sample BIND9 configuration for Appendix C. Sample BIND9 configuration for
default.service.arpa. . . . . . . . . . . . . . . . . . . 25 default.service.arpa. . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
DNS-Based Service Discovery [RFC6763] is a component of Zero DNS-Based Service Discovery [RFC6763] is a component of Zero
Configuration Networking [RFC6760] [ZC] [I-D.cheshire-dnssd-roadmap]. Configuration Networking [RFC6760] [ZC] [I-D.cheshire-dnssd-roadmap].
This document describes an enhancement to DNS-Based Service Discovery This document describes an enhancement to DNS-Based Service Discovery
[RFC6763] that allows services to register their services using the [RFC6763] that allows services to register their services using the
DNS protocol rather than using Multicast DNS [RFC6762] (mDNS). There DNS protocol rather than using Multicast DNS [RFC6762] (mDNS). There
is already a large installed base of DNS-SD clients that can discover is already a large installed base of DNS-SD clients that can discover
skipping to change at page 9, line 42 skipping to change at page 9, line 42
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. This key pair MUST be unique
to the device. A device with rewritable storage should retain this to the device. A device with rewritable storage should retain this
key indefinitely. When the device changes ownership, it may be key indefinitely. When the device changes ownership, it may be
appropriate to erase the old key and install a new one. Therefore appropriate to erase the old key and install a new one. Therefore,
the key MAY be overwritten as a result of a full reset of the device the SRP client on the device SHOULD provide a mechanism to overwrite
(e.g., a "factory reset"). the key, for example as the result of a "factory reset."
When sending DNS updates, the service includes a KEY record When sending DNS updates, the service includes a KEY record
containing the public portion of the key in each Host Description containing the public portion of the key in each Host Description
update and each Service Description update. Each KEY record MUST update and each Service Description update. Each KEY record MUST
contain the same public key. The update is signed using SIG(0), contain the same public key. The update is signed using SIG(0),
using the private key that corresponds to the public key in the KEY using the private key that corresponds to the public key in the KEY
record. The lifetimes of the records in the update is set using the record. The lifetimes of the records in the update is set using the
EDNS(0) Update Lease option [I-D.sekar-dns-ul]. EDNS(0) Update Lease option [I-D.sekar-dns-ul].
The KEY record in Service Description updates MAY be omitted for The KEY record in Service Description updates MAY be omitted for
skipping to change at page 11, line 13 skipping to change at page 11, line 13
cleaned up and made available for re-use. cleaned up and made available for re-use.
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 case: an SRP server needs to understand not apply in the case of SRP: an SRP server needs to understand SRV
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
To remove a service registration, the SRP client retransmits its most 2.2.5.5.1. Removing all published services
recent update with an Update Lease option that has a LEASE value of
zero. If the registration is to be permanently removed, KEY-LEASE To remove all the services registered to a particular host, the SRP
should also be zero. Otherwise, it should have the same value it had client retransmits its most recent update with an Update Lease option
previously; this holds the name in reserve for when the SRP client is that has a LEASE value of zero. If the registration is to be
once again able to provide the service. permanently removed, KEY-LEASE should also be zero. Otherwise, it
should have the same value it had previously; this holds the name in
reserve for when the SRP client is once again able to provide the
service.
SRP clients are normally expected to remove all service instances SRP clients are normally expected to remove all service instances
when removing a host. However, in some cases a SRP client may not when removing a host. However, in some cases a SRP client may not
have retained sufficient state to know that some service instance is have retained sufficient state to know that some service instance is
pointing to a host that it is removing. An SRP server can assume pointing to a host that it is removing. This method of removing
that all service instances pointing to a host entry that's being services is intended for the case where the client is going offline
removed are no longer valid. Therefore, SRP servers MAY remove all and does not want its services advertised. Therefore, it is
service instances pointing to a host when a host is removed, even if sufficient for the client to send the Host Description Instruction
the SRP client doesn't remove them explicitly. (Section 2.3.1.3).
To support this, when removing services based on the lease time being
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
explicitly. If the key lease time is nonzero, the SRP server MUST
NOT delete the KEY records for these SRP clients.
2.2.5.5.2. Removing some published services
In some use cases a client may need to remove some specific service,
without removing its other services. This can be accomplished in one
of two ways. The first alternative is to send a valid SRP update
where the only Service Discovery instruction is a remove-only
instruction, and the only Service Description instruction is a
remove-only instruction. In this case, the host lease will be
updated with the lease time provided in the SRP update.
The second alternative is to send a normal SRP update, but as in the
first alternative, including a Service Discovery Instruction and a
Service Description that delete the service being removed. This can
be particularly useful when one service is being replaced with
another, since this can be done in a single SRP Update.
In neither 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 using the zero-lease deletion method.
2.3. SRP Server Behavior 2.3. SRP Server Behavior
2.3.1. Validation of Adds 2.3.1. Validation of Adds
The SRP server first validates that the DNS Update is a syntactically The SRP server first validates that the DNS Update is a syntactically
and semantically valid DNS Update according to the rules specified in and semantically valid DNS Update according to the rules specified in
RFC2136. RFC2136.
SRP Updates consist of a set of _instructions_ that together add one SRP Updates consist of a set of _instructions_ that together add or
or more services. Each instruction consists either of a single add, remove one or more services. Each instruction consists either of a
or a delete followed by an add. When an instruction contains a single add, a single delete, or a delete optionally followed by an
delete and an add, the delete MUST precede the add. add. When an instruction 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 update, a Service Description
update, or a Host Description update. Order matters in DNS updates. update, or a Host Description update. Order matters in DNS updates.
Specifically, deletes must precede adds for records that the deletes Specifically, deletes must precede adds for records that the deletes
would affect; otherwise the add will have no effect. This is the would affect; otherwise the add will have no effect. This is the
only ordering constraint; aside from this constraint, updates may only ordering constraint; aside from this constraint, updates may
appear in whatever order is convenient when constructing the update. appear in whatever order is convenient when constructing the update.
Because the SRP update is a DNS update, it MUST contain a single Because the SRP update is a DNS update, it MUST contain a single
question that indicates the zone to be updated. Every delete and question that indicates the zone to be updated. Every delete and
update in an SRP update MUST be within the zone that is specified for update in an SRP update MUST be within the zone that is specified for
the SRP Update. the SRP Update.
2.3.1.1. Service Discovery Instruction 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" ([RFC2136], Section 2.5.1) RR, * exactly one "Add to an RRSet" or one "Delete an RR from an RRSet"
* which is a PTR RR, ([RFC2136], Section 2.5.1) RR update,
* which updates a PTR RR,
* which points to a Service Instance Name * which points to a Service Instance Name
* for which a Service Description Instruction is present in the SRP * for which a Service Description Instruction is present in the SRP
Update. Update
* Service Discovery Instructions do not contain any deletes, and do
not contain any other adds. * if the Service Discovery update is an "Add to an RRSet"
instruction, the Service Description Instruction does not match if
it does not contain an "Add to an RRset" update for the SRV RR
describing that service.
* if the Service Discovery Instruction is an "Delete an RR from an
RRSet" update, the Service Description Instruction does not match
if it contains an "Add to an RRset" update.
* Service Discovery Instructions do not contain any other add or
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
* exactly one "Delete all RRsets from a name" update for the service * exactly one "Delete all RRsets from a name" update for the service
instance name ([RFC2136], Section 2.5.3), instance name ([RFC2136], Section 2.5.3),
* exactly one "Add to an RRset" SRV RR, * zero or one "Add to an RRset" SRV RR,
* zero or one "Add to an RRset" KEY RR that contains the public key * zero or one "Add to an RRset" KEY RR that, if present, contains
corresponding to the private key that was used to sign the message the public key corresponding to the private key that was used to
(if present, the KEY MUST match the KEY RR given in the Host sign the message (if present, the KEY MUST match the KEY RR given
Description), in the Host Description),
* one or more "Add to an RRset" TXT RRs, * zero or more "Add to an RRset" TXT RRs,
* and the target of the SRV RR Add points to a hostname for which * If there is one "Add to an RRset" SRV update, there MUST be at
there is a Host Description Instruction in the SRP Update. least one "Add to an RRset" TXT update.
* 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,
or
* if there is no "Add to an RRset" SRV RR, then there is an existing
SRV RR on the name specified in the "Delete all RRsets from a
name" update that to a hostname for which there is a Host
Description Instruction in the SRP Update, and there is a KEY RR
on that name which matches the key with which the SRP Update was
signed.
* Service Descriptions Instructions do not modify any other RRs. * Service Descriptions Instructions do not modify any other RRs.
An SRP server MUST correctly handle compressed names in the SRV 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
skipping to change at page 16, line 39 skipping to change at page 17, line 33
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 negotiate longer
leases. SRP clients that are going to continue to use names on which leases. 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
instances, and all service entries for such service instances, depend
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
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
remain, the KEY record for any services that reference it MUST also
remain. However, the service PTR record MUST be removed, since it
has no key associated with it, and since it is never valid to have a
service PTR record for which there is no service instance on the
target of the PTR record.
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
different set of services, and not remember that some different
service instance had previously been registered. In this case, when
that service instance lease expires, the SRP server SHOULD remove the
service instance (although the KEY record for the service instance
SHOULD be retained until the key lease on that service expires).
This is beneficial because if the SRP client continues to renew the
host, but never mentions the stale service again, the stale service
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
skipping to change at page 19, line 18 skipping to change at page 20, line 39
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 registration
protocol, by replacing all or part of the service registration protocol, by replacing all or part of the service registration
information with information provided by an SRP client. An information with information provided by an SRP client. An
implementation that allows both kinds of updates should not allow DNS implementation that allows both kinds of updates should not allow DNS
Update clients to updateupdate records added by SRP clients using Update clients that are using different authentication and
different authentication and authorization credentials. authorization credentialsto to update records added by SRP clients.
6.2. SRP Server Authentication 6.2. SRP Server Authentication
This specification does not provide a mechanism for validating This specification does not provide a mechanism for validating
responses from DNS servers to SRP clients. In the case of responses from DNS servers to SRP clients. In the case of
Constrained Network/Constrained Node clients, such validation isn't Constrained Network/Constrained Node clients, such validation isn't
practical because there's no way to establish trust. In principle, a practical because there's no way to establish trust. In principle, a
KEY RR could be used by a non-constrained SRP client to validate KEY RR could be used by a non-constrained SRP client to validate
responses from the server, but this is not required, nor do we responses from the server, but this is not required, nor do we
specify a mechanism for determining which key to use. specify a mechanism for determining which key to use.
skipping to change at page 21, line 48 skipping to change at page 23, line 34
+----------------------+-----------------------------+ +----------------------+-----------------------------+
| Global | True | | Global | True |
+----------------------+-----------------------------+ +----------------------+-----------------------------+
| Reserved-by-protocol | False | | Reserved-by-protocol | False |
+----------------------+-----------------------------+ +----------------------+-----------------------------+
Table 1 Table 1
10. Acknowledgments 10. Acknowledgments
Thanks to Toke Høiland-Jørgensen, Jonathan Hui and Esko Thanks to Toke Høiland-Jørgensen, Jonathan Hui and Esko Dijk for
Dijk for their thorough technical reviews, to Tamara Kemper for doing their thorough technical reviews, to Tamara Kemper for doing a nice
a nice developmental edit, Tim Wattenberg for doing a service developmental edit, Tim Wattenberg for doing a service implementation
implementation at the Montreal Hackathon at IETF 102, and Tom at the Montreal Hackathon at IETF 102, and Tom Pusateri for reviewing
Pusateri for reviewing during the hackathon and afterwards. during the hackathon and afterwards.
11. 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, "Dynamic DNS Update Leases",
Work in Progress, Internet-Draft, draft-sekar-dns-ul-02, 2 Work in Progress, Internet-Draft, draft-sekar-dns-ul-02, 2
August 2018, August 2018,
<https://tools.ietf.org/html/draft-sekar-dns-ul-02>. <https://tools.ietf.org/html/draft-sekar-dns-ul-02>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
 End of changes. 23 change blocks. 
73 lines changed or deleted 144 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/