Draft: draft-ietf-dnssd-srp

Commentary: Update terminology to change SRP server to SRP registrar and SRP client to SRP requestor , to be consistent with RFC2136 ( and also because it makes more sense ) . Terminology around service / server is also updated , now that server never refers to a registrar .
Paragraph (version A):
This document describes an enhancement to RFC6763 that allows
services to register their services using the DNS protocol rather
than using RFC6762 (mDNS).  There is already a large installed base
of DNS-SD clients that can discover services using the DNS protocol.
Paragraph (version B):
This document describes an enhancement to RFC6763 that allows servers
to register the services they offer using the DNS protocol rather
than using RFC6762 (mDNS).  There is already a large installed base
of DNS-SD clients that can discover services using the DNS protocol.
Paragraph (version A):
Existing practice for updating DNS zones is to either manually enter
new data, or else use DNS Update RFC2136.  Unfortunately DNS Update
requires either that the authoritative DNS server automatically trust
updates, or else that the DNS Update client have some kind of shared
secret or public key that is known to the DNS server and can be used
to authenticate the update.  Furthermore, DNS Update can be a fairly
chatty process, requiring multiple round trips with different
conditional predicates to complete the update process.
Paragraph (version A):
The SRP protocol adds a set of default heuristics for processing DNS
updates that eliminates the need for DNS update conditional
predicates: instead, the SRP server has a set of default predicates
that are applied to the update, and the update either succeeds
entirely, or fails in a way that allows the registering service to
know what went wrong and construct a new update.
Paragraph (version A):
SRP also adds a feature called First-Come, First-Served Naming, which
allows the registering service to claim a name that is not yet in
use, and, using SIG(0) RFC2931, to authenticate both the initial
claim and subsequent updates.  This prevents name conflicts, since a
second SRP service attempting to claim the same name will not possess
the SIG(0) key used by the first service to claim it, and so its
claim will be rejected and the second service will have to choose a
new name.
Paragraph (version A):
Finally, SRP adds the concept of a 'lease,' similar to leases in
Dynamic Host Configuration Protocol RFC8415.  The SRP registration
itself has a lease which may be on the order of an hour; if the
registering service does not renew the lease before it has elapsed,
the registration is removed.  The claim on the name can have a longer
lease, so that another service cannot claim the name, even though the
registration has expired.
Paragraph (version B):
Existing practice for updating DNS zones is to either manually enter
new data, or else use DNS Update RFC2136.  Unfortunately DNS Update
requires either that the authoritative DNS server automatically trust
updates, or else that the DNS Update requestor have some kind of
shared secret or public key that is known to the DNS server and can
be used to authenticate the update.  Furthermore, DNS Update can be a
fairly chatty process, requiring multiple round trips with different
conditional predicates to complete the update process.
Paragraph (version B):
The SRP protocol adds a set of default heuristics for processing DNS
updates that eliminates the need for DNS update conditional
predicates: instead, the SRP registrar has a set of default
predicates that are applied to the update, and the update either
succeeds entirely, or fails in a way that allows the requestor to
know what went wrong and construct a new update.
Paragraph (version B):
SRP also adds a feature called First-Come, First-Served Naming, which
allows the requestor to claim a name that is not yet in use, and,
using SIG(0) RFC2931, to authenticate both the initial claim and
subsequent updates.  This prevents name conflicts, since a second SRP
requestor attempting to claim the same name will not possess the
SIG(0) key used by the first requestor to claim it, and so its claim
will be rejected and the second requestor will have to choose a new
name.
Paragraph (version B):
Finally, SRP adds the concept of a 'lease,' similar to leases in
Dynamic Host Configuration Protocol RFC8415.  The SRP registration
itself has a lease which may be on the order of an hour; if the
requestor does not renew the lease before it has elapsed, the
registration is removed.  The claim on the name can have a longer
lease, so that another requestor cannot claim the name, even though
the registration has expired.
Paragraph (version A):
The RFC6763 ("Populating the DNS with Information"), briefly
discusses ways that services can publish their information in the DNS
namespace.  In the case of mDNS, it allows services to publish their
information on the local link, using names in the ".local" namespace,
which makes their services directly discoverable by peers attached to
that same local link.
Paragraph (version B):
The RFC6763 ("Populating the DNS with Information"), briefly
discusses ways that servers can publish their information in the DNS
namespace.  In the case of mDNS, it allows servers to publish their
information on the local link, using names in the ".local" namespace,
which makes their services directly discoverable by peers attached to
that same local link.
Paragraph (version A):
Services that implement SRP use DNS Update RFC2136 RFC3007 to publish
service information in the DNS.  Two variants exist, one for full-
featured hosts, and one for devices designed for "Constrained-Node
Networks" RFC7228.  An SRP server is most likely an authoritative DNS
server, or else is updating an authoritative DNS server.  There is no
requirement that the server that is receiving SRP requests be the
same server that is answering queries that return records that have
been registered.
Paragraph (version B):
Services that implement SRP use DNS Update RFC2136 RFC3007 to publish
service information in the DNS.  Two variants exist, one for full-
featured hosts, and one for devices designed for "Constrained-Node
Networks" RFC7228.  An SRP registrar is most likely an authoritative
DNS server, or else is updating an authoritative DNS server.  There
is no requirement that the server that is receiving SRP requests be
the same server that is answering queries that return records that
have been registered.
Paragraph (version A):
The reason for these different assumptions is that low-power devices
that typically use Constrained-Node Networks may have very limited
battery power.  The series of DNS lookups required to discover an SRP
server and then communicate with it will increase the power required
to advertise a service; for low-power devices, the additional
flexibility this provides does not justify the additional use of
power.  It is also fairly typical of such networks that some network
service information is obtained as part of the process of joining the
network, and so this can be relied upon to provide nodes with the
information they need.
Paragraph (version B):
The reason for these different assumptions is that low-power devices
that typically use Constrained-Node Networks may have very limited
battery power.  The series of DNS lookups required to discover an SRP
registrar and then communicate with it will increase the power
required to advertise a service; for low-power devices, the
additional flexibility this provides does not justify the additional
use of power.  It is also fairly typical of such networks that some
network service information is obtained as part of the process of
joining the network, and so this can be relied upon to provide nodes
with the information they need.
Paragraph (version A):
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
Discovery records, Service Description records, and Host Description
records.
Paragraph (version B):
We refer to the DNS Update message sent by servers using SRP as an
SRP Update.  Three types of updates appear in an SRP update: Service
Discovery records, Service Description records, and Host Description
records.
Paragraph (version A):
As described above, full-featured devices are responsible for knowing
in what domain they should register their services.  Devices made for
Constrained-Node Networks register in the (proposed) special use
domain name RFC6761 "default.service.arpa", and let the SRP server
handle rewriting that to a different domain if necessary.
Paragraph (version B):
As described above, full-featured devices are responsible for knowing
in what domain they should register their services.  Devices made for
Constrained-Node Networks register in the (proposed) special use
domain name RFC6761 "default.service.arpa", and let the SRP registrar
handle rewriting that to a different domain if necessary.
Paragraph (version A):
In order to allow updates to happen in a single transaction, SRP
Updates do not include update prerequisites.  The requirements
specified in server_behavior are implicit in the processing of SRP
Updates, and so there is no need for the service sending the SRP
Update to put in any explicit prerequisites.
Paragraph (version B):
In order to allow updates to happen in a single transaction, SRP
Updates do not include update prerequisites.  The requirements
specified in server_behavior are implicit in the processing of SRP
Updates, and so there is no need for the server sending the SRP
Update to put in any explicit prerequisites.
Paragraph (version A):
Traditional DNS update is secured using the TSIG protocol, which uses
a secret key shared between the DNS Update client (which issues the
update) and the server (which authenticates it).  This model does not
work for automatic service registration.
Paragraph (version B):
Traditional DNS update is secured using the TSIG protocol, which uses
a secret key shared between the DNS Update requestor (which issues
the update) and the server (which authenticates it).  This model does
not work for automatic service registration.
Paragraph (version A):
First-Come First-Serve naming provides a limited degree of security:
a service that registers its service using DNS-SD Registration
protocol is given ownership of a name for an extended period of time
based on the key used to authenticate the DNS Update.  As long as the
registration service remembers the name and the key used to register
that name, no other service can add or update the information
associated with that.  FCFS naming is used to protect both the
Service Description and the Host Description.
Paragraph (version B):
First-Come First-Serve naming provides a limited degree of security:
a server that registers its service using DNS-SD Registration
protocol is given ownership of a name for an extended period of time
based on the key used to authenticate the DNS Update.  As long as the
registration service remembers the name and the key used to register
that name, no other server can add or update the information
associated with that.  FCFS naming is used to protect both the
Service Description and the Host Description.
Paragraph (version A):
When sending DNS updates, the service includes a KEY record
containing the public portion of the key in each Host Description
Instruction and each Service Description Instruction.  Each KEY
record MUST 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 record.  The lifetimes of the records in the update is set
using the EDNS(0) Update Lease option I-D.sekar-dns-ul.
Paragraph (version B):
When sending DNS updates, the requestor includes a KEY record
containing the public portion of the key in each Host Description
Instruction and each Service Description Instruction.  Each KEY
record MUST 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 record.  The lifetimes of the records in the update is set
using the EDNS(0) Update Lease option I-D.sekar-dns-ul.
Paragraph (version A):
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
KEY record that is given for the Host Description is also given for
each Service Description for which no KEY record is provided.
Omitted KEY records are not used when computing the SIG(0) signature.
Paragraph (version B):
The KEY record in Service Description updates MAY be omitted for
brevity; if it is omitted, the SRP registrar MUST behave as if the
same KEY record that is given for the Host Description is also given
for each Service Description for which no KEY record is provided.
Omitted KEY records are not used when computing the SIG(0) signature.
Paragraph (version A):
Both Host Description records and Service Description Records can
have names that result in name conflicts.  Service Discovery records
cannot have name conflicts.  If any Host Description or Service
Description record is found by the server to have a conflict with an
existing name, the server will respond to the SRP Update with a
YXDOMAIN rcode.  In this case, the Service MUST either abandon the
service registration attempt, or else choose a new name.
Paragraph (version B):
Both Host Description records and Service Description Records can
have names that result in name conflicts.  Service Discovery records
cannot have name conflicts.  If any Host Description or Service
Description record is found by the registrar to have a conflict with
an existing name, the registrar will respond to the SRP Update with a
YXDOMAIN rcode.  In this case, the requestor MUST either abandon the
service registration attempt, or else choose a new name.
Paragraph (version A):
compressing in RFC2782 is not stated, but is assumed to be because a
caching resolver that does not understand the format of the SRV
record might store it as binary data and thus return an invalid
pointer in response to a query.  This does not apply in the case of
SRP: an SRP server needs to understand SRV records in order to
validate the SRP Update.  Compression of the target potentially saves
substantial space in the SRP Update.
Paragraph (version B):
compressing in RFC2782 is not stated, but is assumed to be because a
caching resolver that does not understand the format of the SRV
record might store it as binary data and thus return an invalid
pointer in response to a query.  This does not apply in the case of
SRP: an SRP registrar needs to understand SRV records in order to
validate the SRP Update.  Compression of the target potentially saves
substantial space in the SRP Update.
Paragraph (version A):
To remove all the services registered to a particular host, the SRP
client retransmits its most recent update with an Update Lease option
that has a LEASE value of zero.  If the registration is to be
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.
Paragraph (version A):
SRP clients are normally expected to remove all service instances
when removing a host.  However, in some cases a SRP client may not
have retained sufficient state to know that some service instance is
pointing to a host that it is removing.  This method of removing
services is intended for the case where the client is going offline
and does not want its services advertised.  Therefore, it is
sufficient for the client to send the hdi.
Paragraph (version A):
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.
Paragraph (version A):
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.  To simply remove a specific service, the client sends a
valid SRP Update where the servdis contains a single Delete an RR
from an RRset (RFC2136) update that deletes the PTR record whose
target is the service instance name.  The servdesc in this case
contains a single Delete all RRsets from a Name (RFC2136) update to
the service instance name.
Paragraph (version B):
To remove all the services registered to a particular host, the SRP
requestor retransmits its most recent update with an Update Lease
option that has a LEASE value of zero.  If the registration is to be
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 requestor is once again able to provide the
service.
Paragraph (version B):
SRP requestors are normally expected to remove all service instances
when removing a host.  However, in some cases a SRP requestor may not
have retained sufficient state to know that some service instance is
pointing to a host that it is removing.  This method of removing
services is intended for the case where the requestor is going
offline and does not want its services advertised.  Therefore, it is
sufficient for the requestor to send the hdi.
Paragraph (version B):
To support this, when removing services based on the lease time being
zero, an SRP registrar MUST remove all service instances pointing to
a host when a host is removed, even if the SRP requestor doesn't list
them explicitly.  If the key lease time is nonzero, the SRP registrar
MUST NOT delete the KEY records for these SRP requestors.
Paragraph (version B):
In some use cases a requestor may need to remove some specific
service, without removing its other services.  This can be
accomplished in one of two ways.  To simply remove a specific
service, the requestor sends a valid SRP Update where the servdis
contains a single Delete an RR from an RRset (RFC2136) update that
deletes the PTR record whose target is the service instance name.
The servdesc in this case contains a single Delete all RRsets from a
Name (RFC2136) update to the service instance name.
Paragraph (version A):
The SRP server first validates that the DNS Update is a syntactically
and semantically valid DNS Update according to the rules specified in
RFC2136.
Paragraph (version B):
The SRP registrar first validates that the DNS Update is a
syntactically and semantically valid DNS Update according to the
rules specified in RFC2136.
Paragraph (version A):
The SRP server checks each instruction in the SRP Update to see that
it is either a Service Discovery Instruction, a Service Description
Instruction, or a Host Description Instruction.  Order matters in DNS
updates.  Specifically, deletes must precede adds for records that
the deletes would affect; otherwise the add will have no effect.
This is the only ordering constraint; aside from this constraint,
updates may appear in whatever order is convenient when constructing
the update.
Paragraph (version B):
The SRP registrar checks each instruction in the SRP Update to see
that it is either a Service Discovery Instruction, a Service
Description Instruction, or a Host Description Instruction.  Order
matters in DNS updates.  Specifically, deletes must precede adds for
records that the deletes would affect; otherwise the add will have no
effect.  This is the only ordering constraint; aside from this
constraint, updates may appear in whatever order is convenient when
constructing the update.
Paragraph (version A):
An SRP server MUST correctly handle compressed names in the SRV
target.
Paragraph (version B):
An SRP registrar MUST correctly handle compressed names in the SRV
target.
Paragraph (version A):
Assuming that a DNS Update message has been validated with these
conditions and is a valid SRP Update, the server checks that the name
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
record in the Host Description Instruction.  The server performs the
same check for the KEY records in any Service Description
Instructions.  For KEY records that were omitted from Service
Description Instructions, the KEY from the Host Description
Instruction is used.  If any existing KEY record corresponding to a
KEY record in the SRP Update does not match the KEY record in the SRP
Update (whether provided or taken from the Host Description
Instruction), then the server MUST reject the SRP Update with the
YXDOMAIN RCODE.
Paragraph (version A):
Otherwise, the server validates the SRP Update using SIG(0) against
the public key in the KEY record of the Host Description Instruction.
If the validation fails, the server MUST reject the SRP Update with
the REFUSED RCODE.  Otherwise, the SRP Update is considered valid and
authentic, and is processed according to the method described in
RFC2136.
Paragraph (version B):
Assuming that a DNS Update message has been validated with these
conditions and is a valid SRP Update, the registrar checks that the
name in the Host Description Instruction exists.  If so, then the
registrar checks to see if the KEY record on that name is the same as
the KEY record in the Host Description Instruction.  The registrar
performs the same check for the KEY records in any Service
Description Instructions.  For KEY records that were omitted from
Service Description Instructions, the KEY from the Host Description
Instruction is used.  If any existing KEY record corresponding to a
KEY record in the SRP Update does not match the KEY record in the SRP
Update (whether provided or taken from the Host Description
Instruction), then the registrar MUST reject the SRP Update with the
YXDOMAIN RCODE.
Paragraph (version B):
Otherwise, the registrar validates the SRP Update using SIG(0)
against the public key in the KEY record of the Host Description
Instruction.  If the validation fails, the registrar MUST reject the
SRP Update with the REFUSED RCODE.  Otherwise, the SRP Update is
considered valid and authentic, and is processed according to the
method described in RFC2136.
Paragraph (version A):
SRP servers MUST treat the update instructions for a service type and
all its subtypes as atomic.  That is, when a service and its subtypes
are being updated, whatever information appears in the SRP Update is
the entirety of information about that service and its subtypes.  If
any subtype appeared in a previous update but does not appear in the
current update, then the DNS server MUST remove that subtype.
Paragraph (version B):
SRP registrars MUST treat the update instructions for a service type
and all its subtypes as atomic.  That is, when a service and its
subtypes are being updated, whatever information appears in the SRP
Update is the entirety of information about that service and its
subtypes.  If any subtype appeared in a previous update but does not
appear in the current update, then the SRP registrar MUST remove that
subtype.
Paragraph (version A):
The server MAY add a Reverse Mapping that corresponds to the Host
Description.  This is not required because the Reverse Mapping serves
no protocol function, but it may be useful for debugging, e.g. in
annotating network packet traces or logs.  In order for the server to
add a reverse mapping update, it must be authoritative for the zone
or have credentials to do the update.  The SRP client MAY also do a
reverse mapping update if it has credentials to do so.
Paragraph (version A):
The server MAY apply additional criteria when accepting updates.  In
some networks, it may be possible to do out-of-band registration of
keys, and only accept updates from pre-registered keys.  In this
case, an update for a key that has not been registered should be
rejected with the REFUSED RCODE.
Paragraph (version A):
There are at least two benefits to doing this rather than simply
using normal SIG(0) DNS updates.  First, the same registration
protocol can be used in both cases, so both use cases can be
addressed by the same service implementation.  Second, the
registration protocol includes maintenance functionality not present
with normal DNS updates.
Paragraph (version A):
Note that the semantics of using SRP in this way are different than
for typical RFC2136 implementations: the KEY used to sign the SRP
Update only allows the SRP client to update records that refer to its
Host Description.  RFC2136 implementations do not normally provide a
way to enforce a constraint of this type.
Paragraph (version A):
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
Instance Names that match entries in the dictionary are rejected with
YXDOMAIN.
Paragraph (version B):
The registrar MAY add a Reverse Mapping that corresponds to the Host
Description.  This is not required because the Reverse Mapping serves
no protocol function, but it may be useful for debugging, e.g. in
annotating network packet traces or logs.  In order for the registrar
to add a reverse mapping update, it must be authoritative for the
zone or have credentials to do the update.  The SRP requestor MAY
also do a reverse mapping update if it has credentials to do so.
Paragraph (version B):
The registrar MAY apply additional criteria when accepting updates.
In some networks, it may be possible to do out-of-band registration
of keys, and only accept updates from pre-registered keys.  In this
case, an update for a key that has not been registered should be
rejected with the REFUSED RCODE.
Paragraph (version B):
There are at least two benefits to doing this rather than simply
using normal SIG(0) DNS updates.  First, the same registration
protocol can be used in both cases, so both use cases can be
addressed by the same SRP requestor implementation.  Second, the
registration protocol includes maintenance functionality not present
with normal DNS updates.
Paragraph (version B):
Note that the semantics of using SRP in this way are different than
for typical RFC2136 implementations: the KEY used to sign the SRP
Update only allows the SRP requestor to update records that refer to
its Host Description.  RFC2136 implementations do not normally
provide a way to enforce a constraint of this type.
Paragraph (version B):
The registrar may also have a dictionary of names or name patterns
that are not permitted.  If such a list is used, updates for Service
Instance Names that match entries in the dictionary are rejected with
YXDOMAIN.
Paragraph (version A):
All RRs within an RRset are required to have the same TTL (RFC2181).
In order to avoid inconsistencies, SRP places restrictions on TTLs
sent by services and requires that SRP servers enforce consistency.
Paragraph (version A):
Services sending SRP Updates MUST use consistent TTLs in all RRs
within the SRP Update.
Paragraph (version A):
SRP servers MUST check that the TTLs for all RRs within the SRP
Update are the same.  If they are not, the SRP update MUST be
rejected with a REFUSED RCODE.
Paragraph (version A):
Additionally, when adding RRs to an RRset, for example when
processing Service Discovery records, the server MUST use the same
TTL on all RRs in the RRset.  How this consistency is enforced is up
to the implementation.
Paragraph (version A):
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
TTLs.  SRP servers SHOULD ensure that TTLs are reasonable: neither
too long nor too short.  The TTL should never be longer than the
lease time (stale).  Shorter TTLs will result in more frequent data
refreshes; this increases latency on the DNS-SD client side,
increases load on any caching resolvers and on the authoritative
server, and also increases network load, which may be an issue for
constrained networks.  Longer TTLs will increase the likelihood that
data in caches will be stale.  TTL minimums and maximums SHOULD be
configurable by the operator of the SRP server.
Paragraph (version B):
All RRs within an RRset are required to have the same TTL (RFC2181).
In order to avoid inconsistencies, SRP places restrictions on TTLs
sent by requestors and requires that SRP registrars enforce
consistency.
Paragraph (version B):
Requestors sending SRP Updates MUST use consistent TTLs in all RRs
within the SRP Update.
Paragraph (version B):
SRP registrars MUST check that the TTLs for all RRs within the SRP
Update are the same.  If they are not, the SRP update MUST be
rejected with a REFUSED RCODE.
Paragraph (version B):
Additionally, when adding RRs to an RRset, for example when
processing Service Discovery records, the registrar MUST use the same
TTL on all RRs in the RRset.  How this consistency is enforced is up
to the implementation.
Paragraph (version B):
TTLs sent in SRP Updates are advisory: they indicate the SRP
requestor's guess as to what a good TTL would be.  SRP registrars may
override these TTLs.  SRP registrars SHOULD ensure that TTLs are
reasonable: neither too long nor too short.  The TTL should never be
longer than the lease time (stale).  Shorter TTLs will result in more
frequent data refreshes; this increases latency on the DNS-SD client
side, increases load on any caching resolvers and on the
authoritative server, and also increases network load, which may be
an issue for constrained networks.  Longer TTLs will increase the
likelihood that data in caches will be stale.  TTL minimums and
maximums SHOULD be configurable by the operator of the SRP registrar.
Paragraph (version A):
Because the DNS-SD registration protocol is automatic, and not
managed by humans, some additional bookkeeping is required.  When an
update is constructed by the SRP client, it MUST include an EDNS(0)
Update Lease Option I-D.sekar-dns-ul.  The Update Lease Option
contains two lease times: the Lease Time and the Key Lease Time.
Paragraph (version A):
These leases are promises, similar to RFC2131, from the SRP client
that it will send a new update for the service registration before
the lease time expires.  The Lease time is chosen to represent the
time after the update during which the registered 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 record
should be assumed to be valid.
Paragraph (version B):
Because the DNS-SD registration protocol is automatic, and not
managed by humans, some additional bookkeeping is required.  When an
update is constructed by the SRP requestor, it MUST include an
EDNS(0) Update Lease Option I-D.sekar-dns-ul.  The Update Lease
Option contains two lease times: the Lease Time and the Key Lease
Time.
Paragraph (version B):
These leases are promises, similar to RFC2131, from the SRP requestor
that it will send a new update for the service registration before
the lease time expires.  The Lease time is chosen to represent the
time after the update during which the registered 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 record
should be assumed to be valid.
Paragraph (version A):
The reasoning behind the different lease times is discussed in the
section on first-come, first-served naming (fcfs).  SRP 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 currently
thought to be good choices.  Constrained devices with limited battery
that wake infrequently are likely to request longer 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 the registration
service is unavailable or under heavy load.
Paragraph (version B):
The reasoning behind the different lease times is discussed in the
section on first-come, first-served naming (fcfs).  SRP registrars
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 currently
thought to be good choices.  Constrained devices with limited battery
that wake infrequently are likely to request longer leases;
registrars that support such devices may need to set higher limits.
SRP requestors that are going to continue to use names on which they
hold leases should update well before the lease ends, in case the SRP
registrar is unavailable or under heavy load.
Paragraph (version A):
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.
Paragraph (version A):
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
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
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
those specified in the SRP Update; the SRP client must honor them in
either case.
Paragraph (version A):
SRP clients should assume that each lease ends N seconds after the
update was first transmitted, where N is the lease duration.  Servers
should assume that each lease ends N seconds after the update that
was successfully processed was received.  Because the server will
always receive the update after the SRP client sent it, this avoids
the possibility of misunderstandings.
Paragraph (version A):
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
leases, but SHOULD differentiate between SRP Updates and other
updates, and MUST reject updates that would otherwise be SRP Updates
if they do not include leases.
Paragraph (version B):
SRP registrars SHOULD also track a lease time per service instance.
The reason for doing this is that a requestor 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 registrar
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 requestor
continues to renew the host, but never mentions the stale service
again, the stale service will continue to be advertised.
Paragraph (version B):
The SRP registrar MUST include an EDNS(0) Update Lease option in the
response if the lease time proposed by the requestor has been
shortened or lengthened.  The requestor MUST check for the EDNS(0)
Update Lease option in the response and MUST use the lease times from
that option in place of the options that it sent to the registrar
when deciding when to renew its registration.  The times may be
shorter or longer than those specified in the SRP Update; the SRP
requestor must honor them in either case.
Paragraph (version B):
SRP requestors should assume that each lease ends N seconds after the
update was first transmitted, where N is the lease duration.
Registrars should assume that each lease ends N seconds after the
update that was successfully processed was received.  Because the
registrar will always receive the update after the SRP requestor sent
it, this avoids the possibility of misunderstandings.
Paragraph (version B):
SRP registrars MUST reject updates that do not include an EDNS(0)
Update Lease option.  Dual-use servers MAY accept updates that don't
include leases, but SHOULD differentiate between SRP Updates and
other updates, and MUST reject updates that would otherwise be SRP
Updates if they do not include leases.
Paragraph (version A):
SRP Updates have no authorization semantics other than first-come,
first-served.  This means that if an attacker from outside of the
administrative domain of the server knows the server's IP address, it
can in principle send updates to the server that will be processed
successfully.  Servers should therefore be configured to reject
updates from source addresses outside of the administrative domain of
the server.
Paragraph (version A):
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
Constrained-Device Network to the unconstrained portion of the
network.  For TCP updates, the initial SYN-SYN+ACK handshake prevents
updates being forged by an off-network attacker.  In order to ensure
that this handshake happens, SRP servers relying on three-way-
handshake validation MUST NOT accept TCP Fast Open payloads.  If the
network infrastructure allows it, an SRP server MAY accept TCP Fast
Open payloads if all such packets are validated along the path, and
the network is able to reject this type of spoofing at all ingress
points.
Paragraph (version 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
DNS updates, and those DNS updates may be validated using different
rules.  However, in the case of a DNS service that accepts SRP
updates, the intersection of the SRP Update rules and whatever other
update rules are present must be considered very carefully.
Paragraph (version A):
For example, a normal, authenticated DNS update to any RR that was
added using SRP, but that is authenticated using a different key,
could be used to override a promise made by the SRP Server to an SRP
client, by replacing all or part of the service registration
information with information provided by an authenticated DNS update
client.  An implementation that allows both kinds of updates should
not allow DNS Update clients that are using different authentication
and authorization credentials to to update records added by SRP
clients.
Paragraph (version A):
This specification does not provide a mechanism for validating
responses from DNS servers to SRP clients.  In the case of
Constrained Network/Constrained Node clients, such validation isn't
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
responses from the server, but this is not required, nor do we
specify a mechanism for determining which key to use.
Paragraph (version A):
For validation, SRP servers MUST implement the ECDSAP256SHA256
signature algorithm.  SRP servers SHOULD implement the algorithms
specified in RFC8624, in the validation column of the table, that are
numbered 13 or higher and have a "MUST", "RECOMMENDED", or "MAY"
designation in the validation column of the table.  SRP clients MUST
NOT assume that any algorithm numbered lower than 13 is available for
use in validating SIG(0) signatures.
Paragraph (version A):
Because DNSSD SRP Updates can be sent off-link, the privacy
implications of SRP are different than for multicast DNS responses.
Host implementations that are using TCP SHOULD also use TLS if
available.  Server implementations MUST offer TLS support.  The use
of TLS with DNS is described in RFC7858 and RFC8310.
Paragraph (version A):
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
implementation whether to use it.
Paragraph (version A):
Public keys can be used as identifiers to track hosts.  SRP servers
MAY elect not to return KEY records for queries for SRP
registrations.
Paragraph (version B):
SRP Updates have no authorization semantics other than first-come,
first-served.  This means that if an attacker from outside of the
administrative domain of the registrar knows the registrar's IP
address, it can in principle send updates to the registrar that will
be processed successfully.  Registrars should therefore be configured
to reject updates from source addresses outside of the administrative
domain of the registrar.
Paragraph (version B):
For updates sent to an anycast IP address of an SRP registrar, this
validation must be enforced by every router on the path from the
Constrained-Device Network to the unconstrained portion of the
network.  For TCP updates, the initial SYN-SYN+ACK handshake prevents
updates being forged by an off-network attacker.  In order to ensure
that this handshake happens, SRP registrars relying on three-way-
handshake validation MUST NOT accept TCP Fast Open payloads.  If the
network infrastructure allows it, an SRP registrar MAY accept TCP
Fast Open payloads if all such packets are validated along the path,
and the network is able to reject this type of spoofing at all
ingress points.
Paragraph (version B):
Note that these rules only apply to the validation of SRP Updates.  A
server that accepts updates from SRP requestors may also accept other
DNS updates, and those DNS updates may be validated using different
rules.  However, in the case of a DNS server that accepts SRP
updates, the intersection of the SRP Update rules and whatever other
update rules are present must be considered very carefully.
Paragraph (version B):
For example, a normal, authenticated DNS update to any RR that was
added using SRP, but that is authenticated using a different key,
could be used to override a promise made by the SRP registrar to an
SRP requestor, by replacing all or part of the service registration
information with information provided by an authenticated DNS update
requestor.  An implementation that allows both kinds of updates
should not allow DNS Update requestors that are using different
authentication and authorization credentials to to update records
added by SRP requestors.
Paragraph (version B):
This specification does not provide a mechanism for validating
responses from SRP Registrars to SRP requestors.  In principle, a KEY
RR could be used by a non-constrained SRP requestor to validate
responses from the registrar, but this is not required, nor do we
specify a mechanism for determining which key to use.
Paragraph (version B):
For validation, SRP registrars MUST implement the ECDSAP256SHA256
signature algorithm.  SRP registrars SHOULD implement the algorithms
specified in RFC8624, in the validation column of the table, that are
numbered 13 or higher and have a "MUST", "RECOMMENDED", or "MAY"
designation in the validation column of the table.  SRP requestors
MUST NOT assume that any algorithm numbered lower than 13 is
available for use in validating SIG(0) signatures.
Paragraph (version B):
Because DNSSD SRP Updates can be sent off-link, the privacy
implications of SRP are different than for multicast DNS responses.
Host implementations that are using TCP SHOULD also use TLS if
available.  Registrar implementations MUST offer TLS support.  The
use of TLS with DNS is described in RFC7858 and RFC8310.
Paragraph (version B):
Hosts that implement TLS support SHOULD NOT fall back to TCP; since
registrars are required to support TLS, it is entirely up to the host
implementation whether to use it.
Paragraph (version B):
Public keys can be used as identifiers to track hosts.  SRP
registrars MAY elect not to return KEY records for queries for SRP
registrations.
Paragraph (version A):
IANA is further requested to add a new entry to the "Transport-
Independent Locally-Served Zones" subregistry of the the "Locally-
Served DNS Zones" registry LSDZ.  The entry will be for the domain
'service.arpa.' with the description "DNS-SD Registration Protocol
Special-Use Domain", listing this document as the reference.
Paragraph (version B):
IANA is further requested to add a new entry to the "Transport-
Independent Locally-Served Zones" subregistry of the the "Locally-
Served DNS Zones" registry LSDZ.  The entry will be for the domain
'service.arpa.' with the description "DNS-SD Service Registration
Protocol Special-Use Domain", listing this document as the reference.
Paragraph (version A):
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
specified DNS zone using DNS update.  The other acts as an
Advertising Proxy I-D.sctl-advertising-proxy.  Both are included in
the mDNSResponder open source project mentioned above.
Paragraph (version B):
There are two related implementations of an SRP registrar.  One acts
as a DNS Update proxy, taking an SRP Update and applying it to the
specified DNS zone using DNS update.  The other acts as an
Advertising Proxy I-D.ietf-dnssd-advertising-proxy.  Both are
included in the mDNSResponder open source project mentioned above.