rfc9665v3.txt   rfc9665.txt 
skipping to change at line 149 skipping to change at line 149
This document is intended for three audiences: Implementers of This document is intended for three audiences: Implementers of
software that provides services that should be advertised using software that provides services that should be advertised using
DNS-SD, implementers of authoritative DNS servers that will be used DNS-SD, implementers of authoritative DNS servers that will be used
in contexts where DNS-SD registration is needed, and administrators in contexts where DNS-SD registration is needed, and administrators
of networks where DNS-SD service is required. The document is of networks where DNS-SD service is required. The document is
expected to provide sufficient information to allow interoperable expected to provide sufficient information to allow interoperable
implementation of the Service Registration Protocol. implementation of the Service Registration Protocol.
DNS-SD allows servers to publish the information required to access DNS-SD allows servers to publish the information required to access
the services they provide. DNS-SD clients can then discover the set the services they provide. DNS-SD clients can then discover the set
of services of a particular type that are available. They can then of service instances of a particular type that are available. They
select a service from among those that are available and obtain the can then select an instance from among those that are available and
information required to use it. Although DNS-SD using the DNS obtain the information required to use it. Although DNS-SD using the
protocol can be more efficient and versatile than using mDNS, it is DNS protocol can be more efficient and versatile than using mDNS, it
not common in practice because of the difficulties associated with is not common in practice because of the difficulties associated with
updating authoritative DNS services with service information. updating authoritative DNS services with service information.
The existing practice for updating DNS zones is either to enter new The existing practice for updating DNS zones is either to enter new
data manually or to use DNS Update [RFC2136]. Unfortunately, DNS data manually or to use DNS Update [RFC2136]. Unfortunately, DNS
Update requires either: Update requires either:
* that the authoritative DNS server automatically trust updates or * that the authoritative DNS server automatically trust updates or
* that the DNS Update requester have some kind of shared secret or * that the DNS Update requester have some kind of shared secret or
public key that is known to the authoritative DNS server and can public key that is known to the authoritative DNS server and can
skipping to change at line 235 skipping to change at line 235
record content that can be registered here. Or it might require record content that can be registered here. Or it might require
establishment of trust, and add an authorization model to the establishment of trust, and add an authorization model to the
authentication model we now have. But that is work for a future authentication model we now have. But that is work for a future
document. document.
Finally, SRP adds the concept of a "lease" [RFC9664], analogous to Finally, SRP adds the concept of a "lease" [RFC9664], analogous to
leases in DHCP [RFC2131] [RFC8415]. The SRP registration itself has leases in DHCP [RFC2131] [RFC8415]. The SRP registration itself has
a lease that may be on the order of two hours; if the requester does a lease that may be on the order of two hours; if the requester does
not renew the lease before it has elapsed, the registration is not renew the lease before it has elapsed, the registration is
removed. The claim on the name can have a longer lease so that removed. The claim on the name can have a longer lease so that
another requester cannot claim the name, even though the registration another requester cannot immediately claim the name, even though the
has expired. registration itself has expired.
The Service Registration Protocol for DNS-SD specified in this The Service Registration Protocol for DNS-SD specified in this
document provides a reasonably secure mechanism for publishing this document provides a reasonably secure mechanism for publishing this
information. Once published, these services can be readily information. Once published, these services can be readily
discovered by DNS-SD clients using standard DNS lookups. discovered by DNS-SD clients using standard DNS lookups.
Section 10 of the DNS-SD specification [RFC6763] briefly discusses Section 10 of the DNS-SD specification [RFC6763] briefly discusses
ways that servers can advertise the services they provide in the DNS ways that servers can advertise the services they provide in the DNS
namespace. In the case of mDNS, it allows servers to advertise their namespace. In the case of mDNS, it allows servers to advertise their
services on the local link, using names in the "local." namespace, services on the local link, using names in the "local." namespace,
skipping to change at line 349 skipping to change at line 349
For devices designed for CNNs [RFC7228], some simplifications are For devices designed for CNNs [RFC7228], some simplifications are
available. Instead of being configured with (or discovering) the available. Instead of being configured with (or discovering) the
service registration domain, the special-use domain name [RFC6761] service registration domain, the special-use domain name [RFC6761]
"default.service.arpa." is used. The details of how SRP registrars "default.service.arpa." is used. The details of how SRP registrars
are discovered will be specific to the constrained network; are discovered will be specific to the constrained network;
therefore, we do not suggest a specific mechanism here. therefore, we do not suggest a specific mechanism here.
SRP requesters on CNNs are expected to receive, from the network, a SRP requesters on CNNs are expected to receive, from the network, a
list of SRP registrars with which to register. It is the list of SRP registrars with which to register. It is the
responsibility of a CNN supporting SRP to provide one or more responsibility of a CNN supporting SRP to provide at least one
registrar addresses. It is the responsibility of the registrar registrar address and port. It is the responsibility of the
supporting a CNN to handle the updates appropriately. In some registrar supporting a CNN to handle the updates appropriately. In
network environments, updates may be accepted directly into a local some network environments, updates may be accepted directly into a
"default.service.arpa." zone, which has only local visibility. In local "default.service.arpa." zone, which has only local visibility.
other network environments, updates for names ending in In other network environments, updates for names ending in
"default.service.arpa." may be rewritten by the registrar to names "default.service.arpa." may be rewritten by the registrar to names
with broader visibility. Domain name rewriting should be performed with broader visibility. Domain name rewriting should be performed
as appropriate for the network environment in question. Some as appropriate for the network environment in question. Some
suggested techniques for how domain names can be translated from a suggested techniques for how domain names can be translated from a
locally scoped name to a domain name with larger scope can be found locally scoped name to a domain name with larger scope can be found
in the discussion of data translation for names in Multicast DNS in the discussion of data translation for names in Multicast DNS
answers in Section 5.5 of the Discovery Proxy specification answers in Section 5.5 of the Discovery Proxy specification
[RFC8766]. [RFC8766].
3.1.3. Why two variants? 3.1.3. Why two variants?
skipping to change at line 383 skipping to change at line 383
is obtained as part of the process of joining the network; thus, this is obtained as part of the process of joining the network; thus, this
can be relied upon to provide nodes with the information they need. can be relied upon to provide nodes with the information they need.
Networks that are not CNNs can have more complicated topologies at Networks that are not CNNs can have more complicated topologies at
the IP layer. Nodes connected to such networks can be assumed to be the IP layer. Nodes connected to such networks can be assumed to be
able to do DNS-SD service registration domain discovery. Such able to do DNS-SD service registration domain discovery. Such
networks are generally able to provide registration domain discovery networks are generally able to provide registration domain discovery
and routing. This creates the possibility of off-network spoofing, and routing. This creates the possibility of off-network spoofing,
where a device from a foreign network registers a service on the where a device from a foreign network registers a service on the
local network in order to attack devices on the local network. To local network in order to attack devices on the local network. To
prevent such spoofing, TCP is required for such networks. guard against off-path spoofing, TCP is required for such networks.
3.2. Protocol Details 3.2. Protocol Details
We will discuss several parts to this process: We will discuss several parts to this process:
* how to know what to publish (Section 3.2.1), * how to know what to publish (Section 3.2.1),
* how to know where to publish it (under what name) (Section 3.2.2), * how to know where to publish it (under what name) (Section 3.2.2),
* how to publish it (Section 3.2.3), * how to publish it (Section 3.2.3),
* how to secure its publication (Section 3.2.4), and * how to secure its publication (Section 3.2.4), and
* how to maintain the information once published (Section 5). * how to maintain the information once published (Section 5).
skipping to change at line 435 skipping to change at line 435
(used for FCFS Naming). Depending on the use case, an SRP (used for FCFS Naming). Depending on the use case, an SRP
requester may be required to suppress some addresses that would requester may be required to suppress some addresses that would
not be usable by hosts discovering the service through the SRP not be usable by hosts discovering the service through the SRP
registrar. The exact address record suppression behavior required registrar. The exact address record suppression behavior required
may vary for different types of SRP requesters. Some suggested may vary for different types of SRP requesters. Some suggested
policies for suppressing unusable records can be found in policies for suppressing unusable records can be found in
Section 5.5.2 of the Discovery Proxy specification [RFC8766]. Section 5.5.2 of the Discovery Proxy specification [RFC8766].
The DNS-Based Service Discovery specification [RFC6763] describes the The DNS-Based Service Discovery specification [RFC6763] describes the
details of what each of these RR types mean, with the exception of details of what each of these RR types mean, with the exception of
the KEY RR, which was defined in the specification for how to store the KEY RR, which is defined in the specification for how to store
Diffie-Hellman Keys in the DNS [RFC2539]. These specifications Diffie-Hellman Keys in the DNS [RFC2539]. These specifications
should be considered the definitive sources for information about should be considered the definitive sources for information about
what to publish; the reason for summarizing this here is to provide what to publish; the reason for summarizing this here is to provide
the reader with enough information about what will be published that the reader with enough information about what will be published that
the service registration process can be understood at a high level the service registration process can be understood at a high level
without first learning the full details of DNS-SD. Also, the without first learning the full details of DNS-SD. Also, the
"service instance name" is an important aspect of FCFS Naming, which "service instance name" is an important aspect of FCFS Naming, which
we describe later on in this document. we describe later on in this document.
3.2.2. Where to Publish It 3.2.2. Where to Publish It
skipping to change at line 462 skipping to change at line 462
As described above, full-featured devices are responsible for knowing As described above, full-featured devices are responsible for knowing
the domain in which to register their services. Such devices MAY the domain in which to register their services. Such devices MAY
optionally support configuration of a registration domain by the optionally support configuration of a registration domain by the
operator of the device. However, such devices MUST support operator of the device. However, such devices MUST support
registration domain discovery as described in Section 11 of the registration domain discovery as described in Section 11 of the
DNS-SD specification [RFC6763]. DNS-SD specification [RFC6763].
Devices made for CNNs register in the special-use domain name Devices made for CNNs register in the special-use domain name
[RFC6761] "default.service.arpa." and let the SRP registrar handle [RFC6761] "default.service.arpa." and let the SRP registrar handle
rewriting that to a different domain if necessary, as described in rewriting that to a different domain if necessary, as mentioned in
Section 3.1.2. Section 3.1.2.
3.2.3. How to Publish It 3.2.3. How to Publish It
It is possible to send a DNS Update message that does several things It is possible to send a DNS Update message that does several things
at once: For example, it's possible in a single transaction to add or at once: For example, it's possible in a single transaction to add or
update a single Host Description while also adding or updating the update a single Host Description while also adding or updating the
RRs comprising the Service Description(s) for one or more service RRs comprising the Service Description(s) for one or more service
instance(s) available on that host and adding or updating the RRs instance(s) available on that host and adding or updating the RRs
comprising the Service Discovery instruction(s) for those service comprising the Service Discovery instruction(s) for those service
instance(s). instance(s).
An SRP Update takes advantage of this: It is implemented as a single An SRP Update takes advantage of this: It is implemented as a single
DNS Update message that contains a service's Service Discovery DNS Update message that contains a service's Service Discovery
records, Service Description records, and Host Description records. records, Service Description records, and Host Description records.
Updates done according to this specification are somewhat different Updates done according to this specification are somewhat different
from normal DNS Updates [RFC2136] where the update process could from normal DNS Updates [RFC2136] where the update process could
involve many update attempts. You might first attempt to add a name involve many update attempts. The requester might first attempt to
if it doesn't exist; if that fails, then in a second message you add a name if it doesn't exist; if that fails, then in a second
might update the name if it does exist but matches certain message the requester might update the name if it does exist but
preconditions. Because the Service Registration Protocol described matches certain preconditions. Because the Service Registration
in this document uses a single transaction, some of this adaptability Protocol described in this document uses a single transaction, some
is lost. of this adaptability is lost.
In order to allow updates to happen in a single transaction, SRP In order to allow updates to happen in a single transaction, SRP
Updates do not include update prerequisites. The requirements Updates do not include update prerequisites. The requirements
specified in Section 3.3 are implicit in the processing of SRP specified in Section 3.3 are implicit in the processing of SRP
Updates; thus, there is no need for the SRP requester to put in any Updates; thus, there is no need for the SRP requester to put in any
explicit prerequisites. explicit prerequisites.
3.2.3.1. How the DNS-SD Service Registration Process Differs from DNS 3.2.3.1. How the DNS-SD Service Registration Process Differs from DNS
Update Update
skipping to change at line 519 skipping to change at line 519
* An SRP registrar is not required to implement general DNS Update * An SRP registrar is not required to implement general DNS Update
prerequisite processing. prerequisite processing.
* CNN SRP requesters are allowed to send updates to the generic * CNN SRP requesters are allowed to send updates to the generic
domain "default.service.arpa.". domain "default.service.arpa.".
3.2.3.2. Retransmission Strategy 3.2.3.2. Retransmission Strategy
The DNS protocol, including DNS updates, can operate over UDP or TCP. The DNS protocol, including DNS updates, can operate over UDP or TCP.
When using UDP, reliable transmission must be guaranteed by For UDP updates from CNN devices, reliable transmission must be
retransmitting if a DNS UDP message is not acknowledged in a guaranteed by retransmitting when a DNS UDP message is not
reasonable interval. Section 4.2.1 of the DNS specification acknowledged in a reasonable interval. Section 4.2.1 of the DNS
[RFC1035] provides some guidance on this topic, as does Section 1 of specification [RFC1035] provides some guidance on this topic, as does
the IETF document describing common DNS implementation errors Section 1 of the IETF document describing common DNS implementation
[RFC1536]. Section 3.1.3 of the UDP Usage Guidelines document errors [RFC1536]. Section 3.1.3 of the UDP Usage Guidelines document
[RFC8085] also provides useful guidance that is particularly relevant [RFC8085] also provides useful guidance that is particularly relevant
to DNS. to DNS.
3.2.3.3. Successive Updates 3.2.3.3. Successive Updates
SRP does not require that every update contain the same information. SRP does not require that every update contain the same information.
When an SRP requester needs to send more than one SRP Update to the When an SRP requester needs to send more than one SRP Update to the
SRP registrar, it SHOULD combine these into a single SRP Update, when SRP registrar, it SHOULD combine these into a single SRP Update, when
possible, subject to DNS message size limits and link-specific size possible, subject to DNS message size limits and link-specific size
limits (e.g., an IEEE 802.15.4 network will perform poorly when asked limits (e.g., an IEEE 802.15.4 network will perform poorly when asked
skipping to change at line 592 skipping to change at line 592
ownership, it may be appropriate for the former owner to erase the ownership, it may be appropriate for the former owner to erase the
old key pair, which would then require the new owner to install a new old key pair, which would then require the new owner to install a new
one. Therefore, the SRP requester on the device SHOULD provide a one. Therefore, the SRP requester on the device SHOULD provide a
mechanism to erase the key (for example, as the result of a "factory mechanism to erase the key (for example, as the result of a "factory
reset") and to generate a new key. reset") and to generate a new key.
Note that when a new key is generated, this will prevent the device Note that when a new key is generated, this will prevent the device
from registering with the name associated with the old key in the from registering with the name associated with the old key in the
same domain where it had previously registered. So, implicit in the same domain where it had previously registered. So, implicit in the
generation of a new key is the generation of a new name; this can be generation of a new key is the generation of a new name; this can be
done either proactively when regenerating a key or when the SRP done either proactively when regenerating a key or only in the event
update produces a name conflict. that the SRP update produces a name conflict.
The policy described here for managing keys assumes that the keys are The policy described here for managing keys assumes that the keys are
only used for SRP. If a key that is used for SRP is also used for only used for SRP. If a key that is used for SRP is also used for
other purposes, the policy described here is likely to be other purposes, the policy described here is likely to be
insufficient. The policy stated here is NOT RECOMMENDED in such a insufficient. The policy stated here is NOT RECOMMENDED in such a
situation: a policy appropriate to the full set of uses for the key situation: a policy appropriate to the full set of uses for the key
must be chosen. Specifying such a policy is out of scope for this must be chosen. Specifying such a policy is out of scope for this
document. document.
When sending DNS updates, the requester includes a KEY record When sending DNS updates, the requester includes a KEY record
skipping to change at line 654 skipping to change at line 654
The lifetime of the DNS-SD PTR, SRV, A, AAAA, and TXT records The lifetime of the DNS-SD PTR, SRV, A, AAAA, and TXT records
[RFC6763] uses the LEASE field of the Update Lease option and is [RFC6763] uses the LEASE field of the Update Lease option and is
typically set to two hours. Thus, if a device is disconnected from typically set to two hours. Thus, if a device is disconnected from
the network, it does not continue to appear for too long in the user the network, it does not continue to appear for too long in the user
interfaces of devices looking for instances of that service type. interfaces of devices looking for instances of that service type.
The lifetime of the KEY records is set using the KEY-LEASE field of The lifetime of the KEY records is set using the KEY-LEASE field of
the Update Lease Option and SHOULD be set to a much longer time, the Update Lease Option and SHOULD be set to a much longer time,
typically 14 days. The result being that even though a device may be typically 14 days. The result being that even though a device may be
temporarily unplugged -- disappearing from the network for a few days temporarily disconnected or powered off -- disappearing from the
-- it makes a claim on its name that lasts much longer. network for a few days -- it makes a claim on its name that lasts
much longer.
Therefore, even if a device is unplugged from the network for a few Therefore, even if a device is disconnected from the network for a
days, and its services are not available for that time, no other few days, and its services are not available for that time, no other
device can come along and claim its name the moment it disappears device can come along and claim its name the moment it disappears
from the network. In the event that a device is unplugged from the from the network. In the event that a device is disconnected from
network and permanently discarded, then its name is eventually the network and permanently discarded, then its name is eventually
cleaned up and made available for reuse. cleaned up and made available for reuse.
3.2.5.4. Compression in SRV Records 3.2.5.4. Compression in SRV Records
Although the original SRV specification [RFC2782] requires that the Although the original SRV specification [RFC2782] requires that the
target hostname in the rdata of an SRV record not be compressed in target hostname in the RDATA of an SRV record not be compressed in
DNS queries and responses, an SRP requester MAY compress the target DNS queries and responses, an SRP requester MAY compress the target
in the SRV record, since an SRP Update is neither a DNS query nor a in the SRV record, since an SRP Update is neither a DNS query nor a
DNS response. The motivation for _not_ compressing is not stated in DNS response. The motivation for _not_ compressing is not stated in
the SRV specification but is assumed to be because a recursive the SRV specification but is assumed to be because a recursive
resolver (caching server) that does not understand the format of the resolver (caching server) that does not understand the format of the
SRV record might store it as binary data without decoding a SRV record might store it as binary data without decoding a
compression pointer embedded with the target hostname field and thus compression pointer embedded with the target hostname field and thus
return nonsensical rdata in response to a query. This concern does return nonsensical RDATA in response to a query. This concern does
not apply in the case of SRP. An SRP registrar needs to understand 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 SRV records in order to validate the SRP Update. Compression of the
target can save space in the SRP Update, so we want SRP requesters to target can save space in the SRP Update, so we want SRP requesters to
be able to assume that the registrar will handle this. Therefore, be able to assume that the registrar will handle this. Therefore,
SRP registrars MUST support compression of SRV RR targets. SRP registrars MUST support compression of SRV RR targets.
Note that this document does not update the SRV specification Note that this document does not update the SRV specification
[RFC2782]: Authoritative DNS servers still MUST NOT compress SRV [RFC2782]: Authoritative DNS servers still MUST NOT compress SRV
record targets. The requirement to accept compressed SRV records in record targets. The requirement to accept compressed SRV records in
updates only applies to SRP registrars, and SRP registrars that are updates only applies to SRP registrars. SRP registrars that are also
also authoritative DNS servers still MUST NOT compress SRV record authoritative DNS servers still MUST NOT compress SRV record targets
targets in DNS responses. We note also that Multicast DNS [RFC6762] in DNS responses. We note also that Multicast DNS [RFC6762]
similarly compresses SRV records in mDNS messages. similarly compresses SRV records in mDNS messages.
In addition, we note that an implementer of an SRP requester might In addition, we note that an implementer of an SRP requester might
update existing code that creates SRV records or compresses DNS update existing code that creates SRV records or compresses DNS
messages so that it compresses the target of an SRV record. Care messages so that it compresses the target of an SRV record. Care
must be taken if such code is used both in requesters and in must be taken if such code is used both in requesters and in
authoritative DNS servers that the code only compresses in the case authoritative DNS servers that the code only compresses SRV targets
where a requester is generating an SRP Update. in the case where a requester is generating an SRP Update.
3.2.5.5. Removing Published Services 3.2.5.5. Removing Published Services
3.2.5.5.1. Removing All Published Services 3.2.5.5.1. Removing All Published Services
To remove all the services registered to a particular hostname, the To remove all the services registered to a particular hostname, the
SRP requester transmits an SRP Update for that hostname with an SRP requester transmits an SRP Update for that hostname with an
Update Lease option that has a LEASE value of zero. The SRP Update Update Lease option that has a LEASE value of zero. The SRP Update
MUST contain exactly one Host Description Instruction that contains MUST contain exactly one Host Description Instruction that contains
exactly one "Delete All RRsets From A Name" instruction for the exactly one "Delete All RRsets From A Name" instruction for the
skipping to change at line 721 skipping to change at line 722
This method of removing services is intended for the case where the This method of removing services is intended for the case where the
requester is going offline and does not want any of its services to requester is going offline and does not want any of its services to
continue being advertised. continue being advertised.
To support this, when removing a hostname, an SRP registrar MUST To support this, when removing a hostname, an SRP registrar MUST
remove all service instances pointing to that hostname and all remove all service instances pointing to that hostname and all
Service Discovery PTR records pointing to those service instances, Service Discovery PTR records pointing to those service instances,
even if the SRP requester doesn't list them explicitly. If the KEY even if the SRP requester doesn't list them explicitly. If the KEY
lease time is nonzero, the SRP registrar MUST NOT delete the KEY lease time is nonzero, the SRP registrar MUST NOT delete the KEY
records for these SRP requesters. records for these service instances.
3.2.5.5.2. Removing Some Published Services 3.2.5.5.2. Removing Some Published Services
In some use cases, a requester may need to remove a specific service In some use cases, a requester may need to remove a specific service
without removing its other services. For example, a device may shut instance without removing its other services. For example, a device
down its remote screen access (_rfb._tcp) service while retaining its may shut down its remote screen access (_rfb._tcp) service while
command-line login (_ssh._tcp) service. This can be accomplished in retaining its command-line login (_ssh._tcp) service. This can be
one of two ways: accomplished in one of two ways:
1. To simply remove a specific service, the requester sends a valid 1. To simply remove a specific service instance, the requester sends
SRP Update with a Service Description Instruction a valid SRP Update with a Service Description Instruction
(Section 3.3.1.2) containing a single "Delete All RRsets From A (Section 3.3.1.2) containing a single "Delete All RRsets From A
Name" update to the service instance name. The SRP Update SHOULD Name" update to the service instance name. The SRP Update SHOULD
include Service Discovery Instructions (Section 3.3.1.1) include Service Discovery Instructions (Section 3.3.1.1)
consisting of "Delete An RR From An RRset" updates [RFC2136] that consisting of "Delete An RR From An RRset" updates [RFC2136] that
delete any Service Discovery PTR records whose target is the delete any Service Discovery PTR records whose target is the
service instance name. However, even in the absence of such service instance name. However, even in the absence of such
Service Discovery Instructions, the SRP registrar MUST delete any Service Discovery Instructions, the SRP registrar MUST delete any
Service Discovery PTR records that point to the deleted service Service Discovery PTR records that point to the deleted service
instance name. instance name.
2. When deleting one service instance while simultaneously creating 2. When deleting one service instance while simultaneously creating
a new service instance with a different service instance name, an a new service instance with a different service instance name, an
alternative is to perform both operations using a single SRP alternative is to perform both operations using a single SRP
Update. In this case, the old service is deleted as in the first Update. In this case, the old service is deleted as in the first
alternative. The new service is added, just as it would be in an alternative. The new service is added, just as it would be in an
update that wasn't deleting the old service. Because both the update that wasn't deleting the old service. Because both the
removal of the old service and the add of the new service removal of the old service and the add of the new service consist
consists of a valid Service Discovery Instruction and a valid of a valid Service Discovery Instruction and a valid Service
Service Description Instruction, the update as a whole is a valid Description Instruction, the update as a whole is a valid SRP
SRP Update and will result in the old service being removed and Update and will result in the old service being removed and the
the new one added; or, to put it differently, the SRP Update will new one added; or, to put it differently, the SRP Update will
result in the old service being replaced by the new service. result in the old service being replaced by the new service.
It is perhaps worth noting that if a service is being updated without It is perhaps worth noting that if a service is being updated without
the service instance name changing (for example, when only the target the service instance name changing (for example, when only the target
port in the SRV record is being updated), then that SRP Update will port in the SRV record is being updated), then that SRP Update will
look very much like the second alternative above. The PTR record in look very much like the second alternative above. The PTR record in
the Service Discovery Instruction will be the same for both the the Service Discovery Instruction will be the same for both the
"Delete An RR From An RRset" update and the "Add To An RRset" update "Delete An RR From An RRset" update and the "Add To An RRset" update
[RFC2136]. Since the removal of the old service and the addition of [RFC2136]. Since the removal of the old service and the addition of
the new service are both valid SRP Update operations, the combined the new service are both valid SRP Update operations, the combined
skipping to change at line 800 skipping to change at line 801
that it is either a Service Discovery Instruction, a Service that it is either a Service Discovery Instruction, a Service
Description Instruction, or a Host Description Instruction. Order Description Instruction, or a Host Description Instruction. Order
matters in DNS updates. Specifically, deletes must precede adds for matters in DNS updates. Specifically, deletes must precede adds for
records that the deletes would affect; otherwise, the add will have records that the deletes would affect; otherwise, the add will have
no effect. This is the only ordering constraint: Aside from this no effect. This is the only ordering constraint: Aside from this
constraint, updates may appear in whatever order is convenient when constraint, updates may appear in whatever order is convenient when
constructing the update. 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
entry in the Zone Section (what would be the Question Section in a entry in the Zone Section (what would be the Question Section in a
traditional DNS message) that indicates the zone to be updated. DNS query or response) that indicates the zone to be updated. Every
Every delete and update in an SRP Update MUST be within the zone that delete and update in an SRP Update MUST be within the zone that is
is specified for the SRP Update. specified for the SRP Update.
3.3.1.1. Service Discovery Instruction 3.3.1.1. Service Discovery Instruction
An instruction is a Service Discovery Instruction if it: An instruction is a Service Discovery Instruction if it:
* consists of exactly one "Add To An RRSet" or exactly one "Delete * consists of exactly one "Add To An RRSet" or exactly one "Delete
An RR From An RRSet" RR update (Section 2.5 of the DNS Update An RR From An RRSet" RR update (Section 2.5 of the DNS Update
specification [RFC2136]), specification [RFC2136]),
* which updates a PTR RR, * which updates a PTR RR,
* the target of which is a service instance name * the target of which is a service instance name
skipping to change at line 825 skipping to change at line 826
- if the Service Discovery Instruction is an "Add To An RRSet" - if the Service Discovery Instruction is an "Add To An RRSet"
instruction, that Service Description Instruction contains a instruction, that Service Description Instruction contains a
"Delete All RRsets From A Name" instruction for that service "Delete All RRsets From A Name" instruction for that service
instance name followed by "Add To An RRset" instructions for instance name followed by "Add To An RRset" instructions for
the SRV and TXT records describing that service; or the SRV and TXT records describing that service; or
- if the Service Discovery Instruction is a "Delete An RR From An - if the Service Discovery Instruction is a "Delete An RR From An
RRSet" instruction, that Service Description Instruction RRSet" instruction, that Service Description Instruction
contains a "Delete All RRsets From A Name" instruction for that contains a "Delete All RRsets From A Name" instruction for that
service instance name with no following "Add To An RRset" service instance name with no following "Add To An RRset"
instructions for the SRV and TXT records describing that instructions for the SRV and TXT records describing that
service. service. An "Add to an RRset" instruction for the KEY record
here is allowed but not implicit.
Note that there can be more than one Service Discovery Instruction Note that there can be more than one Service Discovery Instruction
for the same service name (the owner name of the Service Discovery for the same service name (the owner name of the Service Discovery
PTR record) if the SRP requester is advertising more than one PTR record) if the SRP requester is advertising more than one
instance of the same service type or is changing the target of a PTR instance of the same service type or is changing the target of a PTR
RR. When subtypes are being used (Section 7.1 of the DNS-SD RR. When subtypes are being used (Section 7.1 of the DNS-SD
specification [RFC6763]), each subtype is a separate Service specification [RFC6763]), each subtype is a separate Service
Discovery Instruction. For each such PTR RR add or delete, the above Discovery Instruction. For each such PTR RR add or delete, the above
constraints must be met. constraints must be met.
skipping to change at line 862 skipping to change at line 864
hostname given in the Host Description Instruction in the SRP hostname given in the Host Description Instruction in the SRP
Update, or Update, or
* If there is no "Add To An RRset" update for an SRV RR, then there * If there is no "Add To An RRset" update for an SRV RR, then there
MUST be no "Add To An RRset" updates for the corresponding TXT RR, MUST be no "Add To An RRset" updates for the corresponding TXT RR,
and either: and either:
- the name to which the "Delete All RRsets From A Name" applies - the name to which the "Delete All RRsets From A Name" applies
does not exist, or does not exist, or
- there is an existing KEY RR on that name that matches the key - there is an existing KEY RR on that name that matches the key
with which the SRP Update was signed. with which the SRP Update was signed.
Service Description Instructions do not modify any other resource Service Description Instructions do not add any other resource
records. records.
An SRP registrar MUST correctly handle compressed names in the SRV An SRP registrar MUST correctly handle compressed names in the SRV
target. target.
3.3.1.3. Host Description Instruction 3.3.1.3. Host Description Instruction
Every SRP Update alway contains exactly one Host Description Every SRP Update alway contains exactly one Host Description
Instruction. Instruction.
skipping to change at line 886 skipping to change at line 888
* exactly one "Delete All RRsets From A Name" RR * exactly one "Delete All RRsets From A Name" RR
* exactly one "Add To An RRset" RR that adds a KEY RR that contains * exactly one "Add To An RRset" RR that adds a KEY RR that contains
the public key corresponding to the private key that was used to the public key corresponding to the private key that was used to
sign the message sign the message
* zero "Add To An RRset" operations (in the case of deleting a * zero "Add To An RRset" operations (in the case of deleting a
registration) or one or more "Add To An RRset" RRs of type A and/ registration) or one or more "Add To An RRset" RRs of type A and/
or AAAA (in the case of creating or updating a registration) or AAAA (in the case of creating or updating a registration)
Host Description Instructions do not modify any other resource Host Description Instructions do not add any other resource records.
records.
A and/or AAAA records that are not of sufficient scope to be validly A and/or AAAA records that are not of sufficient scope to be validly
published in a DNS zone MAY be ignored by the SRP registrar, which published in a DNS zone MAY be ignored by the SRP registrar, which
could result in a Host Description effectively containing zero could result in a Host Description effectively containing zero
reachable addresses even when it contains one or more addresses. reachable addresses even when it contains one or more addresses.
For example, if an IPv4 link-local address [RFC3927] or an IPv6 link- For example, if an IPv4 link-local address [RFC3927] or an IPv6 link-
local address [RFC4862] is provided by the SRP requester, the SRP local address [RFC4862] is provided by the SRP requester, the SRP
registrar could elect not to publish this in a DNS zone. However, in registrar could elect not to publish this in a DNS zone. However, in
some situations, the registrar might make the records available some situations, the registrar might make the records available
skipping to change at line 948 skipping to change at line 949
the name in the Host Description Instruction exists in the zone being the name in the Host Description Instruction exists in the zone being
updated. If so, then the registrar checks to see if the KEY record updated. 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 on that name is the same as the KEY record in the Host Description
Instruction. The registrar performs the same check for the KEY Instruction. The registrar performs the same check for the KEY
records in any Service Description Instructions. For KEY records records in any Service Description Instructions. For KEY records
that were omitted from Service Description Instructions, the KEY from that were omitted from Service Description Instructions, the KEY from
the Host Description Instruction is used. If any existing KEY record the Host Description Instruction is used. If any existing KEY record
corresponding to a KEY record in the SRP Update does not match the 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 KEY record in the SRP Update (whether provided or taken from the Host
Description Instruction), then the SRP registrar MUST reject the SRP Description Instruction), then the SRP registrar MUST reject the SRP
Update with an YXDomain RCODE indicating that the desired name is Update with a YXDomain RCODE indicating that the desired name is
already owned by a different SIG(0) key. This informs the SRP already owned by a different SIG(0) key. This informs the SRP
requester that it should select a different name and try again. requester that it should select a different name and try again.
If the SRP Update is not in conflict with existing data in the zone If the SRP Update is not in conflict with existing data in the zone
being updated, the SRP registrar validates the SRP Update using being updated, the SRP registrar validates the SRP Update using
SIG(0) against the public key in the KEY record of the Host SIG(0) against the public key in the KEY record of the Host
Description Instruction. If the validation fails, the SRP Update is Description Instruction. If the validation fails, the SRP Update is
malformed, and the registrar MUST reject the SRP Update with the malformed, and the registrar MUST reject the SRP Update with the
Refused RCODE. Otherwise, the SRP Update is considered valid and Refused RCODE. Otherwise, the SRP Update is considered valid and
authentic and is processed as for a normal DNS Update [RFC2136]. authentic and is processed as for a normal DNS Update [RFC2136].
KEY record updates omitted from Service Description Instruction(s) KEY record updates omitted from Service Description Instruction(s)
are processed as if they had been explicitly present. After the SRP are processed as if they had been explicitly present. After the SRP
Update has been applied, every Service Description that is updated Update has been applied, every Service Description that is updated
MUST have a KEY RR, which MUST have the same valua as the KEY RR that MUST have a KEY RR, which MUST have the same value as the KEY RR that
is present in the Host Description to which the Service Description is present in the Host Description to which the Service Description
refers. refers.
The IETF specification for DNSSEC Resource Records [RFC4034] states The IETF specification for DNSSEC Resource Records [RFC4034] states
that the flags field in the KEY RR MUST be zero except for bit 7, that the flags field in the KEY RR MUST be zero except for bit 7,
which can be one in the case of a zone key. SRP requesters which can be one in the case of a zone key. SRP requesters
implementing this version of the SRP specification MUST set the flags implementing this version of the SRP specification MUST set the flags
field in the KEY RR to all zeroes. SRP registrars implementing this field in the KEY RR to all zeroes. SRP registrars implementing this
version of the SRP specification MUST accept and store the flags version of the SRP specification MUST accept and store the flags
field in the KEY RR as received, without checking or modifying its field in the KEY RR as received, without checking or modifying its
skipping to change at line 1016 skipping to change at line 1017
response. It is possible that a future SRP extension may include response. It is possible that a future SRP extension may include
per-RR indications as to why the update failed, but at the time of per-RR indications as to why the update failed, but at the time of
writing this is not specified. So, if an SRP requester were to writing this is not specified. So, if an SRP requester were to
attempt to validate the RRs in the response, it might reject such a attempt to validate the RRs in the response, it might reject such a
response, since it would contain RRs but probably not a set of RRs response, since it would contain RRs but probably not a set of RRs
identical to what was sent in the SRP Update. identical to what was sent in the SRP Update.
3.3.6. Optional Behavior 3.3.6. Optional Behavior
The SRP registrar MAY add a Reverse Mapping PTR record (described for The SRP registrar MAY add a Reverse Mapping PTR record (described for
IPv4 in Section 3.5 of [RFC1035] of the DNS specification [RFC1035] IPv4 in Section 3.5 of the DNS specification [RFC1035] and for IPv6
and for IPv6 in Section 2.5 of [RFC3596] of the later document in Section 2.5 of the later document updating DNS for IPv6 [RFC3596])
updating DNS for IPv6 [RFC3596]) that corresponds to the Host that corresponds to the Host Description. This is optional: The
Description. This is optional: The reverse mapping PTR record serves reverse mapping PTR record serves no essential protocol function.
no essential protocol function. One reason to provide reverse One reason to provide reverse mappings is that they can be used to
mappings is that they can be used to annotate logs and network packet annotate logs and network packet traces. In order for the registrar
traces. In order for the registrar to do a reverse mapping update, to do a reverse mapping update, it must be authoritative for the zone
it must be authoritative for the zone that would need to be updated that would need to be updated or have credentials to do the update.
or have credentials to do the update. The SRP requester MAY also do The SRP requester MAY also do a reverse mapping update if it has
a reverse mapping update if it has credentials to do so. credentials to do so.
The SRP registrar MAY apply additional criteria when accepting The SRP registrar MAY apply additional criteria when accepting
updates. In some networks, it may be possible to do out-of-band updates. In some networks, it may be possible to do out-of-band
registration of keys and only accept updates from preregistered keys. registration of keys and only accept updates from preregistered keys.
In this case, an update for a key that has not been registered SHOULD In this case, an update for a key that has not been registered SHOULD
be rejected with the Refused RCODE. When use of managed keys is be rejected with the Refused RCODE. When use of managed keys is
desired, there are at least two benefits to doing this in conjunction desired, there are at least two benefits to doing this in conjunction
with SRP rather than simply performing traditional DNS Updates using with SRP rather than simply performing traditional DNS Updates using
SIG(0) keys: SIG(0) keys:
1. The same over-the-air registration protocol is used in both 1. The same over-the-air registration protocol is used in both
cases, so both use cases can be addressed by the same SRP cases, so both use cases can be addressed by the same SRP
requester implementation. requester implementation.
2. The Service Registration Protocol includes maintenance 2. The Service Registration Protocol includes maintenance
functionality not present with normal DNS updates. functionality not present with normal DNS updates.
Note that the semantics of using SRP in this way are different from Note that the semantics of using SRP in this way are different from
the semantics of typical implementations of DNS Update. The KEY used the semantics of typical implementations of DNS Update. The KEY used
to sign the SRP Update only allows the SRP requester to update to sign the SRP Update only allows the SRP requester to update
records that refer to its Host Description. Implementations of a records that refer to its Host Description. Implementations of
traditional DNS Update [RFC2136] do not normally provide a way to traditional DNS Update [RFC2136] do not normally provide a way to
enforce a constraint of this type. enforce a constraint of this type.
The SRP registrar could also have a dictionary of names or name The SRP registrar could also have a dictionary of names or name
patterns that are not permitted. If such a list is used, updates for patterns that are not permitted. If such a list is used, updates for
service instance names that match entries in the dictionary are service instance names that match entries in the dictionary are
rejected with a Refused RCODE. rejected with a Refused RCODE.
4. TTL Consistency 4. TTL Consistency
skipping to change at line 1143 skipping to change at line 1144
the service instance, and any associated Service Discovery PTR the service instance, and any associated Service Discovery PTR
records pointing to that service instance, (although the KEY record records pointing to that service instance, (although the KEY record
for the service instance SHOULD be retained until the KEY lease on for the service instance SHOULD be retained until the KEY lease on
that service expires). This is beneficial because it avoids stale that service expires). This is beneficial because it avoids stale
services continuing to be advertised after the SRP requester has services continuing to be advertised after the SRP requester has
forgotten about them. forgotten about them.
The SRP registrar MUST include an EDNS(0) Update Lease option in the The SRP registrar MUST include an EDNS(0) Update Lease option in the
response. The requester MUST check for the EDNS(0) Update Lease response. The requester MUST check for the EDNS(0) Update Lease
option in the response, and when deciding when to renew its option in the response, and when deciding when to renew its
registration the requester MUST use the lease times from that registration the requester MUST use the lease times from the Update
received option in place of the lease times that it originally Lease option in the response in place of the lease times that it
requested from the registrar. The times may be shorter or longer originally requested from the registrar. The times may be shorter or
than those specified in the SRP Update. The SRP requester must honor longer than those specified in the SRP Update. The SRP requester
them in either case. must honor them in either case.
SRP requesters SHOULD assume that each lease ends N seconds after the SRP requesters SHOULD assume that each lease ends N seconds after the
update was first transmitted (where N is the granted lease duration). update was first transmitted (where N is the granted lease duration).
SRP registrars SHOULD assume that each lease ends N seconds after the SRP registrars SHOULD assume that each lease ends N seconds after the
update that was successfully processed was received. Because the update that was successfully processed was received. Because the
registrar will always receive the update after the SRP requester sent registrar will always receive the update after the SRP requester sent
it, this avoids the possibility of a race condition where the SRP it, this avoids the possibility of a race condition where the SRP
registrar prematurely removes a service when the SRP requester thinks registrar prematurely removes a service when the SRP requester thinks
the lease has not yet expired. In addition, the SRP requester MUST the lease has not yet expired. In addition, the SRP requester MUST
begin attempting to renew its lease in advance of the expected begin attempting to renew its lease in advance of the expected
skipping to change at line 1234 skipping to change at line 1235
information with information provided by an authenticated DNS update information with information provided by an authenticated DNS update
requester. An implementation that allows both kinds of updates requester. An implementation that allows both kinds of updates
SHOULD NOT allow DNS Update requesters that are using different SHOULD NOT allow DNS Update requesters that are using different
authentication and authorization credentials to update records added authentication and authorization credentials to update records added
by SRP requesters. by SRP requesters.
6.3. Risks of Allowing Arbitrary Names to be Registered in SRP Updates 6.3. Risks of Allowing Arbitrary Names to be Registered in SRP Updates
It is possible to set up SRP Updates for a zone that is also used for It is possible to set up SRP Updates for a zone that is also used for
non-DNS-SD records. For example, imagine that you set up SRP service non-DNS-SD records. For example, imagine that you set up SRP service
for example.com. SRP requesters can now register names like "www" or for "example.com". SRP requesters can now register names like "www"
"mail" or "smtp" in this domain. In addition, SRP Updates using FCFS or "mail" or "smtp" in this domain. In addition, SRP Updates using
Naming can insert names that are obscene or offensive into the zone. FCFS Naming can insert names that are obscene or offensive into the
There is no simple solution to these problems. However, we have two zone. There is no simple solution to these problems. However, we
recommendations to address this problem: have two recommendations to address this problem:
* Do not provide SRP service in organization-level zones. Use * Do not provide SRP service in organization-level zones. Use
subdomains of the organizational domain for DNS-SD. This does not subdomains of the organizational domain for DNS-SD. This does not
prevent registering names as mentioned above but does ensure that prevent registering names as mentioned above but does ensure that
genuinely important names are not accidentally claimed by SRP genuinely important names are not accidentally claimed by SRP
requesters. So, for example, the zone "dnssd.example.com." could requesters. So, for example, the zone "dnssd.example.com." could
be used instead of "example.com." for SRP Updates. Because of the be used instead of "example.com." for SRP Updates. Because of the
way that DNS-browsing domains are discovered, there is no need for way that DNS-browsing domains are discovered, there is no need for
the DNS-SD discovery zone that is updated by SRP to have a user- the DNS-SD discovery zone that is updated by SRP to have a user-
friendly or important-sounding name. friendly or important-sounding name.
skipping to change at line 1330 skipping to change at line 1331
Since all SRP registrars are required to support TLS, whether to use Since all SRP registrars are required to support TLS, whether to use
TLS is entirely the decision of the SRP requester. TLS is entirely the decision of the SRP requester.
Public keys can be used as identifiers to track hosts. SRP Public keys can be used as identifiers to track hosts. SRP
registrars MAY elect not to return KEY records for queries for SRP registrars MAY elect not to return KEY records for queries for SRP
registrations. To avoid DNSSEC validation failures, an SRP registrar registrations. To avoid DNSSEC validation failures, an SRP registrar
that signs the zone for DNSSEC but refuses to return a KEY record that signs the zone for DNSSEC but refuses to return a KEY record
MUST NOT store the KEY record in the zone itself. Because the KEY MUST NOT store the KEY record in the zone itself. Because the KEY
record isn't in the zone, the nonexistence of the KEY record can be record isn't in the zone, the nonexistence of the KEY record can be
validated. If the zone is not signed, the authoritative DNS server validated. If the zone is not signed, the authoritative DNS server
MAY instead return a negative non-error response (either NXDOMAIN or MAY instead return a negative response (either NXDOMAIN or no data).
no data).
8. Domain Name Reservation Considerations 8. Domain Name Reservation Considerations
This section specifies considerations for systems involved in domain This section specifies considerations for systems involved in domain
name resolution when resolving queries for names ending with name resolution when resolving queries for names ending with
".service.arpa.". Each item in this section addresses some aspect of ".service.arpa.". Each item in this section addresses some aspect of
the DNS or the process of resolving domain names that would be the DNS or the process of resolving domain names that would be
affected by this special-use allocation. Detailed explanations of affected by this special-use allocation. Detailed explanations of
these items can be found in Section 5 of the Special-Use Domain Names these items can be found in Section 5 of the Special-Use Domain Names
specification [RFC6761]. specification [RFC6761].
skipping to change at line 1487 skipping to change at line 1487
with the description "DNS-SD Service Registration Protocol Special- with the description "DNS-SD Service Registration Protocol Special-
Use Domain" and lists this document as the reference. Use Domain" and lists this document as the reference.
10.3. Subdomains of "service.arpa." 10.3. Subdomains of "service.arpa."
This document only makes use of the "default.service.arpa." subdomain This document only makes use of the "default.service.arpa." subdomain
of "service.arpa." Other subdomains are reserved for future use by of "service.arpa." Other subdomains are reserved for future use by
DNS-SD or related work. IANA has created the "service.arpa. DNS-SD or related work. IANA has created the "service.arpa.
Subdomain" registry [SUB]. The IETF has change control for this Subdomain" registry [SUB]. The IETF has change control for this
registry. New entries may be added either as a result of Standards registry. New entries may be added either as a result of Standards
Action (Section 4.9 of [RFC8126]) or with IESG Approval (Section 4.10 Action (Section 4.9 of the IANA Guidelines) or with IESG Approval
of [RFC8126]), provided that the values and their meanings are (Section 4.10 of the IANA Guidelines) [RFC8126], provided that the
documented in a permanent and readily available public specification, values and their meanings are documented in a permanent and readily
in sufficient detail so that interoperability between independent available public specification, in sufficient detail so that
implementations is possible. interoperability between independent implementations is possible.
IANA has grouped the "service.arpa. Subdomain" registry with the IANA has grouped the "service.arpa. Subdomain" registry with the
"Locally-Served DNS Zones" group. The registry is a table with three "Locally-Served DNS Zones" group. The registry is a table with three
columns: the subdomain name (expressed as a fully qualified domain columns: the subdomain name (expressed as a fully qualified domain
name), a brief description of how it is used, and a reference to the name), a brief description of how it is used, and a reference to the
document that describes its use in detail. document that describes its use in detail.
This initial contents of this registry are as follows: This initial contents of this registry are as follows:
+=======================+=================+===========+ +=======================+=================+===========+
 End of changes. 32 change blocks. 
92 lines changed or deleted 92 lines changed or added

This html diff was produced by rfcdiff 1.48.