Draft: draft-ietf-dnssd-srp

Commentary: This fixes a multitude of issues that Esko raised . The details of these fixes are included in my reply to Esko , which can be found here :
Mailing list commentary: Thanks, Esko! Comments below, pull request is here: URL Open issues “The Service Instance Name MUST be referenced by one or more Service Discovery PTR records, unless it is a placeholder service registration for an intentionally non-discoverable service name.” -> This bit is a fairly detailed requirement, with a hard-to-grasp exception case also. Why not include such requirements only in 2.3.x which anyway has all the formal rules? I thought 2.2.1 was more like an intro sketching at high level what it looks like, and 2.3.x has details. The MUST requirement is already present in 2.3.2. The exception case seems not listed there – is that a bug? Yikes. Actually this whole section says way too much, and some of it is wrong, including this text that you’ve called out. “The SRP requestor SHOULD follow the advice given in Section 5.5.2 of [RFC8766]” -> this automatically makes RFC 8766 a normative reference, per the IETF rules for that. (Even if it was a MAY this would be the case. The point is that an implementer OPTIONALLY will use the rules and if so, 8766 becomes normative on how to do these rules. ) So, ok to make RFC 8766 normative? I think given that we have applications where this advice is not what’s specified (e.g. NAME), we shouldn’t make the 8766 behavior normative. I’ve updated this text to refer to it as an example rather than normatively. “so there is no need for the server sending the SRP Update” -> “no need for the SRP requestor” ? “server” seems wrong here. Sorry this is almost a nit but I don’t think we should rely here on reader’s internal autocorrect… This escaped my review of the server->requestor changes. I think it should say “SRP requestor” rather than “server sending the SRP update.” “So for instance, it might try URL, then host-URL, then host- .arpa, then host-URL” -> here the domain should be “URL”? If so, it must be fixed to avoid interpretation errors (does the implementation also need to be fixed for this?). If not, then there’s a bunch of clarification missing why “default” can be omitted here. (But I assume that doesn’t apply here.) Oops, nice catch. Not really a serious problem, but you’re right to ask for consistency here. “Although [RFC2782] requires that the target name in the SRV record not be compressed, an SRP requestor SHOULD compress the target in the SRV record.” -> This means RFC 2782 is formally Updated. The draft should indicate this in the usual IETF way at the top as “Updates: 2782”. It actually doesn’t mean that. It means that SRP requestors and registrars have to support compressing of SRV record targets. No other DNS requestor or responder is so constrained. I think this has come up before, actually. I think that the RFC should be updated, but it’s not really our bailiwick. The Method 2 of only removing the Host record is still a bit unclear – as explained in my previous email about “Host instructions with no address”. NAME says “Therefore, it is sufficient for the requestor to send the Host Description Instruction” but the latter requires a “Service Description Instruction” to be present which contradicts the stated. This has been addressed in an earlier pull request. Last bullet - See previous email on “Host instructions with no address” ; it would seem we do have a case where the Service Description Instruction can be absent in the SRP Update – if lease-time=0. All the host’s services would then get auto-removed. Also I think addressed in the earlier pull request, but let me know if you disagree. “and can be either SUCCESS or SERVFAIL” -> In the IANA registry it’s listed as NoError instead of SUCCESS. RFC 1035 calls it “No error condition”. So we could adopt ‘NoError’ ? (Since the original spec doesn’t use CAPS for the name) Ouch, there were actually a lot of those. I think I got them all. Thanks for pointing this out. See section 11 ref update. “SRP registrars SHOULD also track a lease time per service instance” -> this seems problematic to have as a ‘SHOULD’ because you can’t count on the SRP Registrar doing it properly. E.g. if this is not done, you could get the following situation: At time t=0, requestor registers service X with lease = 10 mins At time t=5 min, requestor registers service Y with lease = 8 hours At this time the Registrar extends the life of the host and all its services to 8 hours (since it doesn’t track lease time per service instance) (Requestor expects at time t=10, that service X will time out) At times t=10 min – t=8 hours, service X remains in the Registry unintentionally. So better is to either do it (MUST) or don’t do it at all. In the first case, partial updates like in the example above and below are possible. When not doing it, partial updates should typically be discouraged since it gets tricky to get it right. NAME. You’re right. This MUST be a MUST. Another example of ‘partial update’ enabled – this situation works even when the SRP Registrar doesn’t track lease time per service : requestor registers service X at time t=0 for a lease time of 8 hours ; at t=1 hour it registers service Y for a lease time of 1 hour. at times t=1 to 2 hours, both services X/Y are active. And at t=2 hours, both services X/Y and the host will time out at the same time if the requestor doesn’t renew before that. So in this case the first lease time 8 hours applies to the host and to service X, and the second 1-hour lease time applies to the host and to service Y, not directly to service X (which still has 7 hours to go) but due to the host removal service X is also removed at time T=2 hours. What is perhaps missing/unclear in the spec if the SRP requestor is even allowed to do such fractional updates where the SRP Update doesn’t contain all the registered services. I don’t think this is mentioned anywhere. Matter is assuming that this is allowed, and I think the text you quoted admits that it is allowed, so I think we’re okay here. If you think we need to say more, can you suggest text? “The times may be shorter or longer than those specified in the SRP Update; the SRP requestor must honor them in either case.” -> Is it an idea to also require (“SHOULD”) a configuration mechanism here just like for the TTL to set a Min and NAME ? For example, in a network with sleepy devices a longer allowed lease time NAME could be configured on the SRP Registrar. And if a network is getting busy with registration traffic, the Registrar could be reconfigured to have a longer Min lease time. This all seems clearly to be within bounds based on the text you’re quoting. I’ve added “by the registrar” after “shortened or lengthened” to make this clear. I don’t think this document should specify behavior, but I’m open to arguments to the contrary. Should we say anything about the subdomains under “URL”? In this document we use “URL”, but what about in the future when someone wants to use “URL” etc ? Is there a registry, or is an RFC needed to define these names? Maybe this is more of a question than an open issue for the document. But if we know how this is handled we could just mention it briefly. I had a case in the past in IETF where a registry was forgotten where it would have been handy. Ick. Yeah. Ref update URL by URL Yup. RFC 8310 is informative, however it defines a profile that updates 7858 normatively. So shouldn’t it be in ‘normative’ section 11? If not, does that mean that nothing of the profile of 8310 is used in any implementation? (Maybe it doesn’t matter much, since 7858 is normative and that one is being automatically updated by 8310 whether we like it or not.) This is a bit touchy. We don’t actually require (nor can we) any of the profiles in 8310, since our SRP registrar may not even be able to use ACME to get a validatable CERT. I’ve taken our the reference to 8310. RFC 1035 needs to be normative – impossible to implement SRP without using e.g. the record formats defined there. Same for 2782 (need SRV records to implement), and 2181. (Again I may be wrong here – maybe 2181 is automatically normative if we make 1035 normative and it doesn’t matter where it’s placed.) No, you’re right. Improvements/nits/editorial Entire doc “SRP Update” / “SRP update” used interchangeably without apparent reason(?) True, but I’m going to leave for the RFC editor, so that this pull request isn’t full of chaff. First occurrence of “registrar” does not define the term. There’s also no terminology section to look it up. This term should be defined in Section 1 ideally. Section 2.0 doesn’t really define it either, it only mentions it in terms of “most likely”. I added a parenthetical. I think adding a terminology section at this point is too big a change unless we have a serious problem. “SRP requests” -> better to use SRP Updates here, since “SRP requests” is only used once so is probably not the intended term. Or, “SRP Update requests”. Yeah, that’s just a mistake. Mention “default registration domain” first and then calls it “default registration zone”. Is this correct? 6763 calls it only “domain”. Good point. Should be domain. Nit: “using SOA queries [NAME]” -> it would be good to refer to a specific section here, e.g. 6.1 Yup. “The reason for these different assumptions” -> “The reason for these different variants” Nit: The standalone words “power” can all be changed to “energy” to be more correct. “By requiring the use of TCP,” -> clarify that this applies to full-featured hosts only. Is that intended, or do constrained devices also require TCP? I’ve rephrased that. The reason to require TCP is to prevent spoofing when the SRP update is traveling across multiple hops. “We will discuss … and how to maintain the information … “ -> part of the “maintain” part is in section 4, so it’s a bit strange to announce it here as part of 2.2.x. Maybe add a forward pointer to 4 here also. Ooh, good point. Last bullet -> add “.” at end check “TSIG protocol” -> add informative reference to [rfc8945] Good point! “using DNS-SD Registration protocol” -> “using the DNS-SD Service Registration Protocol” “First-Come First-Serve” -> “First-Come First-Serve (FCFS)” – there’s a need to introduce the acronym here Yup. Title “Service Behavior” -> shouldn’t this be “SRP Requestor Behavior” ? Since we just before talked about “registration service” the term “service” here is unclear. Sure. “"factory reset."" -> “"factory reset".” The former is correct. “Service Description Records” -> set ‘R’ to lowercase OK “ The lifetime of the DNS-SD PTR, SRV, A, AAAA and TXT records [RFC6763] uses the LEASE field” -> we could clarify that it also holds for other record types. E.g. for everything that’s not KEY, the LEASE field is used. Since 2.2.1 specifies that other record types may be used for Service Description and 4.1 specifies this too. Maybe it’s enough we say here “DNS-SD PTR, SRV, A, AAAA, TXT and other non-KEY records” or give a pointer to 4.1. We don’t actually support this, so not needed. “these will be seen as a single Service Description Instruction” -> could clarify what “these” refers to here. I didn’t immediately parse it. I assume it refers to both mentioned *-RRset updates. So “these updates will be seen … “ How about: The difference is that because the target 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 RRSet update, there is no way to tell whether they were intended to be one or two Instructions. “hostname being updated by this update” -> more correct seems “hostname being updated by this instruction”. That text got deleted by a previous PR. “Every Service Description Instruction must have that Host Description Instruction as the target” -> MUST Also deleted “The target of the SRV record in every Service Description Instruction MUST be the single Host Description Instruction” -> “ … MUST be the hostname used in the single Host Description Instruction” (more correct) Also deleted. “RCODE=REFUSED” -> for style consistency, call it “REFUSED RCODE”. OK “present in the Host Description to which the Service Description refers” -> “present in the Host Description Instruction to which the Service Description Instruction refers” why “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 zone” here is a bit unclear. We could say “the associated zone” to indicate the zone that’s to be used for the reverse mapping update? Without going into unnecessary details. Otherwise it could mean “the zone of the SRP Update” which isn’t intended I think. In order for the registrar to do a reverse mapping update, it must be authoritative for the zone that would need to be updated, or have credentials to do the update. “The registrar may also have a dictionary of names” -> MAY Making it normative is better here to force a requestor implementation to consider this case of (unexpectedly?) getting RCODE YXDOMAIN for a valid SRP Update. MAY is not normative. The response is the same you’d get for a duplicate name, so the requestor is already required to handle it. However, you’re right that this is a problem, because if it does a pattern match, EXPLETIVE-4387 is going to fail just as badly as EXPLETIVE did. So maybe it should return REFUSED in this case. Section title should also mention the “lease time” concept – it is such an important part of this section. E.g. “Lease Time and Stale Data Cleanup” or “Cleaning Up Stale Data and Lease Time” That title doesn’t make sense. We aren’t cleaning up the lease time. I this this is fine as is. “validation must be enforced by every router on the path from the Constrained-Device Network to the unconstrained portion of the Network” -> it’s strange this this only considers constrained-network scenarios. Needs some rewording e.g. “validation must be enforced by every router on the path from any potential SRP requestor to the SRP registrar. In case of a router that is a constrained device, this validation is recommended but not required.” I deleted that sentence and added a paragraph referencing RFC7084. Perhaps 6lowpan Routers generally won’t validate all this; while NAME could do more extensive validation. Send text? Second paragraph -> still a grammar error in there Second paragraph -> same grammar error. There’s also an extra dot ‘.’ After here and not in 8.2, why’s that? These sections were just wrong. See pull request for fix.
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 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 A):
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):
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 (a DNS server that supports
SRP updates) 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 (FCFS)
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 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 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 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 updates be
the same server that is answering queries that return records that
have been registered.
Paragraph (version A):
Full-featured hosts either are configured manually with a
registration domain, or discover the default registration domain as
described in RFC6763.  If this process does not produce a default
registration zone, the Service Registration protocol is not
discoverable on the local network using this mechanism.  Other
discovery mechanisms are possible, but are out of scope for this
document.
Paragraph (version B):
Full-featured hosts either are configured manually with a
registration domain, or discover the default registration domain as
described in RFC6763.  If this process does not produce a default
registration domain, the Service Registration protocol is not
discoverable on the local network using this mechanism.  Other
discovery mechanisms are possible, but are out of scope for this
document.
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
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 B):
The reason for these different variants is that low-power devices
that typically use Constrained-Node Networks may have very limited
battery storage.  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 energy.  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):
Networks that are not constrained networks can have more complicated
topologies at the Internet layer.  Nodes connected to such networks
can be assumed to be able to do DNSSD service registration domain
discovery.  Such networks are generally able to provide registration
domain discovery and routing.  By requiring the use of TCP, the
possibility of off-network spoofing is eliminated.
Paragraph (version A):
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 it, how to secure its publication, and how to maintain the
information once published.
Paragraph (version A):
We refer to a DNS Update message that is constructed so as to conform
to the constraints described in server_behavior as an SRP update.
SRP Updates are sent by SRP requestors to SRP registrars.  Three
types of updates appear in an SRP update: Service Discovery records,
Service Description records, and Host Description records.
Paragraph (version A):
RFC6763 describes the details of what each of these types of updates
contains, with the exception of the KEY RR, which is defined in
RFC2539.  These RFCs should be considered the definitive source for
information about what to publish; the reason for summarizing this
here is to provide the reader with enough information about what will
be published that the service registration process can be understood
at a high level without first learning the full details of 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.
Paragraph (version B):
Networks that are not constrained networks can have more complicated
topologies at the Internet layer.  Nodes connected to such networks
can be assumed to be able to do DNSSD service registration domain
discovery.  Such networks are generally able to provide registration
domain discovery and routing.  This creates the possibility of off-
network spoofing.  To prevent such spoofing, TCP is required for such
networks.
Paragraph (version B):
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 it, and how to secure its publication.  In maintenance, we
specify how to maintain the information once published.
Paragraph (version B):
RFC6763 describes the details of what each of these types of RR mean,
with the exception of the KEY RR, which is defined in RFC2539.  These
RFCs should be considered the definitive source for information about
what to publish; the reason for summarizing this here is to provide
the reader with enough information about what will be published that
the service registration process can be understood at a high level
without first learning the full details of 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.
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 server 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 SRP requestor 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 requestor (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, RFC8945,
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):
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 B):
Both Host Description RR adds and Service Description RR adds can
have names that result in name conflicts.  Service Discovery record
adds 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 B):
There is no specific requirement for how this is done; typically,
however, the requestor will append a number to the preferred name.
This number could be sequentially increasing, or could be chosen
randomly.  One existing implementation attempts several sequential
numbers before choosing randomly.  So for instance, it might try
host.default.service.arpa, then host-1.default.service.arpa, then
host-2.default.service.arpa, then host-31773.default.service.arpa.
Paragraph (version A):
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
second alternative above.  The difference is that because the target
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
RRSet update, these will be seen as a single Service Description
Instruction, not as two Instructions.  The same would be true of the
Service Description Instruction.
Paragraph (version B):
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
second alternative above.  The difference is that because the target
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
RRSet update, there is no way to tell whether they were intended to
be one or two Instructions.  The same would be true of the Service
Description Instruction.
Paragraph (version A):
An SRP Update MUST contain exactly one Host Description Instruction.
In addition, there MUST NOT be any Service Description Instruction to
which no Service Discovery Instruction points.  A DNS Update that
contains any additional adds or deletes that cannot be identified as
Service Discovery, Service Description or Host Description
Instructions is not an SRP Update.  A DNS update that contains any
prerequisites is not an SRP Update.  An SRP registrar MAY either
process such messages are either processed as regular RFC2136
updates, including access control checks and constraint checks, if
supported, or MAY reject them with RCODE=REFUSED.
Paragraph (version B):
An SRP Update MUST contain exactly one Host Description Instruction.
In addition, there MUST NOT be any Service Description Instruction to
which no Service Discovery Instruction points.  A DNS Update that
contains any additional adds or deletes that cannot be identified as
Service Discovery, Service Description or Host Description
Instructions is not an SRP Update.  A DNS update that contains any
prerequisites is not an SRP Update.  An SRP registrar MAY either
process such messages are either processed as regular RFC2136
updates, including access control checks and constraint checks, if
supported, or MAY reject them with Refused RCODE.
Paragraph (version A):
The status that is returned depends on the result of processing the
update, and can be either SUCCESS or SERVFAIL: all other possible
outcomes should already have been accounted for when applying the
constraints that qualify the update as an SRP Update.
Paragraph (version B):
The status that is returned depends on the result of processing the
update, and can be either NoError or ServFail: all other possible
outcomes should already have been accounted for when applying the
constraints that qualify the update as an SRP Update.
Paragraph (version A):
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 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 do a reverse mapping update, it must be authoritative for the zone
that would need to be updated, 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 A):
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 B):
The registrar could 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
Refused.
Paragraph (version A):
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 A):
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 registrars MUST 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
MUST 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 otherwise 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 by the registrar.  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 A):
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):
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 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.  Registrar implementations MUST offer TLS support.  The
use of TLS with DNS is described in RFC7858 and RFC8310.
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.
Paragraph (version A):
Availability of DNS Service Discovery Service Registration Protocol
Service for a given domain is advertised using the
"_dnssd-srp._tcp.<domain>" SRV record gives the target host and port
where DNSSD Service Registration Service is provided for the named
domain.
Paragraph (version A):
Availability of DNS Service Discovery Service Registration Protocol
Service for a given domain over TLS is advertised using the
"_dnssd-srp-tls._tcp.<domain>."  SRV record gives the target host and
port where DNSSD Service Registration Service is provided for the
named domain.
Paragraph (version B):
IANA is also requested to add a new entry to the Service Names and
Port Numbers registry for dnssd-srp-tls with a transport type of tcp.
No port number is to be assigned.  The reference should be to this
document, and the Assignee and Contact information should reference
the authors of this document.  The Description should be "DNS-SD
Service Registration (TLS).