idnits 2.17.00 (12 Aug 2021) /tmp/idnits57895/draft-lemon-srp-replication-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 351: '...lication Partner MUST maintain an ongo...' RFC 2119 keyword, line 381: '... MUST propose a zone name using one ...' RFC 2119 keyword, line 457: '... connecting partner SHOULD discontinue...' RFC 2119 keyword, line 746: '... partner MUST drop the connection....' RFC 2119 keyword, line 749: '...Session response MUST include an SRPL ...' (35 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 320 has weird spacing: '...dataset a 64-...' == Line 328 has weird spacing: '... prec a 32-...' == Line 331 has weird spacing: '... domain the d...' -- The document date (7 November 2021) is 188 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Thread' is mentioned on line 254, but not defined == Missing Reference: 'RFC6763' is mentioned on line 302, but not defined == Missing Reference: 'RFC4086' is mentioned on line 321, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'SUDN' -- Possible downref: Non-RFC (?) normative reference: ref. 'LSDZ' Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Lemon 3 Internet-Draft Apple Inc. 4 Intended status: Standards Track 7 November 2021 5 Expires: 11 May 2022 7 Automatic Replication of DNS-SD Service Registration Protocol Zones 8 draft-lemon-srp-replication-01 10 Abstract 12 This document describes a protocol that can be used for ad-hoc 13 replication of a DNS zone by multiple servers where a single primary 14 DNS authoritative server is not available and the use of stable 15 storage is not desirable. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 11 May 2022. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Alternatives for maintaining SRP state . . . . . . . . . 3 52 1.1.1. Primary authoritative DNS service . . . . . . . . . . 3 53 1.1.2. Multicast DNS Advertising Proxy . . . . . . . . . . . 4 54 1.1.3. SRP Replication . . . . . . . . . . . . . . . . . . . 4 55 2. Implementation . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.1. Naming of a common service zone . . . . . . . . . . . . . 5 57 2.1.1. Zone name based on network name . . . . . . . . . . . 5 58 2.1.2. Zone name based on local configuration . . . . . . . 6 59 2.1.3. Zone name based on DNS-SD discovery . . . . . . . . . 6 60 2.2. Advertising one's own replication service . . . . . . . . 7 61 2.3. Discovering other replication services . . . . . . . . . 8 62 2.3.1. Getting an SRP zone name from other SRP services . . 8 63 2.3.2. Establishing Replication with an existing Dataset . . 9 64 2.3.3. Establishing Replication When There Is No Existing 65 Dataset . . . . . . . . . . . . . . . . . . . . . . . 11 66 2.3.4. Conflicting precedence values . . . . . . . . . . . . 11 67 2.3.5. Handling primary transitions . . . . . . . . . . . . 11 68 2.4. Discovering the addresses of partners . . . . . . . . . . 12 69 2.5. Establishing Communication with a replication partner . . 12 70 2.6. Incoming connections . . . . . . . . . . . . . . . . . . 13 71 2.7. Eliminating extra connections . . . . . . . . . . . . . . 13 72 2.8. Initial synchronization . . . . . . . . . . . . . . . . . 13 73 2.8.1. Sending candidates . . . . . . . . . . . . . . . . . 14 74 2.9. Routine Operation . . . . . . . . . . . . . . . . . . . . 15 75 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 15 76 3.1. DNS Stateful Operations considerations . . . . . . . . . 15 77 3.1.1. DSO Session Establishment . . . . . . . . . . . . . . 15 78 3.1.2. DSO Session maintenance . . . . . . . . . . . . . . . 16 79 3.2. DSO Primary TLVs . . . . . . . . . . . . . . . . . . . . 16 80 3.2.1. SRPL Session . . . . . . . . . . . . . . . . . . . . 16 81 3.2.2. SRPL Send Candidates . . . . . . . . . . . . . . . . 17 82 3.2.3. SRPL Candidate . . . . . . . . . . . . . . . . . . . 18 83 3.2.4. SRPL Host . . . . . . . . . . . . . . . . . . . . . . 19 84 3.3. DSO Secondary TLVs . . . . . . . . . . . . . . . . . . . 20 85 3.3.1. SRPL Candidate Yes . . . . . . . . . . . . . . . . . 20 86 3.3.2. SRPL Candidate No . . . . . . . . . . . . . . . . . . 21 87 3.3.3. SRPL Conflict . . . . . . . . . . . . . . . . . . . . 21 88 3.3.4. SRPL Hostname . . . . . . . . . . . . . . . . . . . . 21 89 3.3.5. SRPL Host Message . . . . . . . . . . . . . . . . . . 21 90 3.3.6. SRPL Time Offset . . . . . . . . . . . . . . . . . . 22 91 3.3.7. SRPL Key ID . . . . . . . . . . . . . . . . . . . . . 22 92 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 93 5. Delegation of 'local.arpa.' . . . . . . . . . . . . . . . . . 23 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 95 6.1. 'srpl-tls' Service Name . . . . . . . . . . . . . . . . . 23 96 6.2. DSO TLV type code . . . . . . . . . . . . . . . . . . . . 23 97 6.3. Registration and Delegation of 'local.arpa' as a 98 Special-Use Domain Name . . . . . . . . . . . . . . . . . 24 99 7. Informative References . . . . . . . . . . . . . . . . . . . 25 100 8. Normative References . . . . . . . . . . . . . . . . . . . . 25 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 103 1. Introduction 105 The DNS-SD Service Registration Protocol provides a way for network 106 services to update a DNS zone with DNS-SD information. SRP uses 107 unicast DNS Updates, rather than multicast DNS, to advertise 108 services. This has several advantages over multicast DNS: 110 * Reduces reliance on multicast 112 * Reduces traffic to devices providing services, which may be 113 constrained devices operating on battery power 115 * Allows the advertisement of services on one network link to 116 consumers of such services on a different network link 118 1.1. Alternatives for maintaining SRP state 120 1.1.1. Primary authoritative DNS service 122 Ideally, SRP updates a primary authoritative DNS server for a 123 particular zone. This DNS server acts as the sole source of truth 124 for names within the DNS zone in which SRP services are published. 125 Redundancy is provided by secondary DNS servers, if needed. However, 126 this approach has some drawbacks. 128 First, it requires 100% availability on the part of a DNS primary 129 authoritative server for the zone. If the primary server is not 130 available for some period of time, new services appearing on the 131 network cannot be registered until primary authoritative service is 132 restored. 134 The second drawback is that there is no automatic method for managing 135 DNS authoritative service. This means that such a service requires 136 an operator to set it up. What it means to set up such a service is 137 that the following capabilities are provided: 139 * An host must be available to act as a primary authoritative DNS 140 server 142 * The zone advertised by that server must be delegated, so that the 143 local resolver can successfully answer queries in that zone 145 * The local resolver must be able to provide local browsing domain 146 advertisements [RFC6763 section 11]. 148 1.1.2. Multicast DNS Advertising Proxy 150 An existing alternative to the use of DNS authoritative services for 151 advertising SRP registrations the advertising proxy [draft-tlsc- 152 advertising-proxy]. An advertising proxy advertises the contents of 153 the SRP update zone using multicast DNS on links on which the need 154 for such advertisements is anticipated. This works well for stub 155 networks [draft-lemon-stub-networks], where services advertised on 156 the stub network must be visible both on the stub network and on the 157 adjacent infrastructure network, but do not generally need to be 158 discoverable on other networks. 160 One drawback of the advertising proxy model, however, is that there 161 is no shared database from which to advertise services registered by 162 SRP. As a consequence, some of the guarantees provided by SRP, 163 particularly first come, first served naming [draft-ietf-dnssd-srp]. 164 Because advertising proxies are set up automatically on an ad-hoc 165 basis, coordination between advertising proxies is not present, which 166 means that if two devices claim the same name, but register with 167 different SRP servers, the conflict is not detected until the service 168 is advertised using mDNS. In practice, this results in frequent 169 renaming of services, which means that consumers of services need to 170 carefully follow each service that they use as the name changes over 171 time. 173 An additional drawback is that, from the perspective of the SRP 174 client, SRP service is not unified: SRP servers tend to come and go, 175 and whenever the SRP service with which a particular client has 176 registered goes offline, the client has to notice that this has 177 happened, discover a new SRP server, and re-register, or else it 178 becomes unreachable. 180 1.1.3. SRP Replication 182 This document describes a replication mechanism which eliminates the 183 need for a single authoritative source of truth, as in the Primary 184 Authoritative DNS model, while eliminating the drawbacks of the 185 Advertising Proxy model. SRP Replication servers discover each other 186 automatically. Each replication server maintains a copy of the SRP 187 zone which is kept up to date on a best-effort basis. 189 SRP Replication has several benefits: 191 * As long as one SRP replication partner remains online at all 192 times, SRP state is maintained when individual SRP replication 193 partners go offline 195 * Name collisions when SRP clients change servers are avoided 197 * SRP service on a stub network can appear as an anycast service, so 198 that SRP clients do not see an apparent change in servers and re- 199 register when the server with which they most recently registered 200 goes offline 202 2. Implementation 204 SRP Replication relies on the fact that any given client is always 205 registering with exactly one SRP server at any given time. This 206 means that when an SRP server receives an SRP update from a client, 207 it can be sure that no other SRP server has a more recent version of 208 that SRP client's registration. Consequently, that SRP server can 209 behave as if it is the source of truth for that client's 210 registration, and other SRP servers can safely assume that any data 211 they have about the client that is less recent can be replaced with 212 the new registration data. 214 2.1. Naming of a common service zone 216 In order for SRP replication partners to replicate a zone, they must 217 agree upon a common name for the zone. We will describe two 218 mechanisms for agreeing on a common zone here. 220 2.1.1. Zone name based on network name 222 Network names aren't guaranteed to be unique, but tend to be unique 223 for any given site. In the case of ad-hoc (permissionless) SRP-based 224 service, such as an advertising proxy or an authoritative service 225 using a locally-served zone [https://www.iana.org/assignments/ 226 locally-served-dns-zones/locally-served-dns-zones.xhtml], because the 227 DNS zone name isn't required to be globally unique, a zone name based 228 on the network name is an easy solution to generating a unique zone 229 name. 231 When generating a zone name based on a network name, the zone name 232 could be based on a locally configured global zone name, e.g. 233 'example.com'. It could be based on a locally-managed locally-served 234 name, e.g. 'home.arpa'. Or it could be based on an unmanaged 235 locally-served name, for which we propose to use the root name 236 'local.arpa.' For the rest of this section we will assume that the 237 specific setting determines which of these domains will be used, and 238 refer to whichever domain that is as DOMAIN. 240 For zone names based on the network name, the network type should be 241 used as a differentiator, in case there are two different local 242 network types with the same name. So, for example, 'WiFi.DOMAIN.' 244 2.1.1.1. Zone name based on WiFi SSID 246 If the zone being represented is a WiFi network, then the zone name 247 for the network should be constructed using the WiFi SSID followed by 248 'WiFi.DOMAIN'. For example, if the SSID is "Example Home" then the 249 zone name would be 'Example Home.WiFi.DOMAIN.' Note that spaces and 250 special characters are allowed in domain names. 252 2.1.1.2. Zone name based on Thread network name 254 If the zone being represented is a Thread [Thread] network, then the 255 zone name for the network should be constructed using the Thread 256 network name. For example, if the Thread network name is 257 "openthread" then the zone name would be 'openthread.thread.DOMAIN.' 259 2.1.2. Zone name based on local configuration 261 The above examples assume that it makes sense for each separate 262 subnet to be its own separate zone. However, since SRP guarantees 263 name uniqueness using the first-come, first-served mechanism, it 264 doesn't rely on mDNS's guarantee of per-link uniqueness. 265 Consequently, it is not required that an SRP zone be constrained to 266 the set of services advertised on a single link. For this reason, 267 when it is possible to know that some set of links are all managed by 268 the same set of SRP replication partners, and a name is known for 269 that set of links, that name can be used. To avoid possible 270 collisions, the subdomain 'srp' is used to indicate that this zone is 271 an SRP zone. So in this case the link name would be the locally- 272 known shared name, followed by 'srp.DOMAIN.' 274 An example of such a scenario would be Apple's HomeKit, in which all 275 HomeKit accessories, regardless of which home network link they are 276 attached to, all are shared in the same namespace. Suppose the 277 HomeKit home's name is "Example Home". In such a situation, the 278 domain name 'Example Home.srp.DOMAIN' could be used. 280 2.1.3. Zone name based on DNS-SD discovery 282 Another option for naming the local SRP Replication zone would be to 283 use DNS-SD advertisements. This is particularly useful since each 284 SRP replication partner advertises itself using DNS-SD, so there is a 285 convenient place to put this information. To advertise a zone name 286 based on DNS-SD discovery, the SRP replication partner should add two 287 fields to the TXT record of the service instance. The first field is 288 the domain field: 'domain=name'. This indicates a proposed SRP 289 replication zone name. The second is the join field. If 'join=yes' 290 then other SRP replication servers are encouraged to use the domain 291 name that appears in the domain field rather than creating a new 292 domain. 294 2.2. Advertising one's own replication service 296 An SRP replication service only advertises its replication service if 297 no other service for the domain it is replicating is already present, 298 or else if it has successfully connected to and synchronized with all 299 of the SRP services it sees advertised for the domain it is 300 configured to replicate. 302 SRP replication service is advertised using DNS-SD [RFC6763]. The 303 service name is '_srpl-tls._tcp'. Each SRP replication partner 304 should have its own hostname, which when combined with the service 305 instance name and the local DNS-SD domain name will produce a service 306 instance name, for example 'example-host._srpl-tls._tcp.local.' The 307 domain under which the service instance name appears will be 'local' 308 for mDNS, and will be whatever domain is used for service 309 registration in the case of a non-mDNS local DNS-SD service. 311 SRP replication uses DNS port 853 [RFC7858] and is based on DNS 312 Stateful Operations [RFC8490]. Therefore, the SRV record for the 313 example we've given would be: 315 example-host._srpl-tls._tcp.local. IN SRV 0 0 853 example- 316 host.local. 318 The TXT record for SRP replication advertises the following fields: 320 dataset a 64-bit number encoded as hexadecimal ASCII, produced with 321 a high-quality random number generator [RFC4086]. The dataset ID 322 is used by SRP servers to establish a common SRP dataset for a 323 domain. 325 join 'yes' or 'no'. Indicates whether other SRP replication servers 326 are invited to join in replicating the dataset. 328 prec a 32-bit number representing the precedence of the server 329 advertising the TXT record, represented in decimal 331 domain the domain name that this dataset is intended to represent 333 This identifier need not be persistent across SRP replication partner 334 restarts. So in our example the TXT record might look like this: 336 #domain=openthread.thread.home.arpa.\025dataset=eb5bb51919a15cec\006p 337 rec=1\008join=yes 339 (Note that each name/value pair in the TXT record is length-encoded, 340 so the '#', the '\025', the '\006' and the '\008' are the lengths of 341 the four name/value pairs.) 343 2.3. Discovering other replication services 345 SRP Replication is a cooperative process. In order to ensure 346 cooperation between SRP replication partners on a link, it is 347 necessary that each replication partner be aware of other potential 348 partners. This is accomplished by maintaining a continuous browse 349 for services of the service type "_srpl-tls._tcp". 351 An SRP Replication Partner MUST maintain an ongoing DNS-SD browse on 352 the service name '_srpl-tls._tcp' within the local browsing domain. 353 The ongoing browse will produce two different types of events: 'add' 354 events and 'remove' events. When the browse is started, it should 355 produce an 'add' event for every SRP replication partner currently 356 present on the network, including the partner that is doing the 357 browsing. Whenever a partner goes offline, a 'remove' event should 358 be produced. 'remove' events are not guaranteed, however. 360 When a new service is added, the SRP partner checks to see if it is 361 in a compatible domain. If the SRP partner has a domain to 362 advertise, it compares that domain to the domain advertised in the 363 added service instance: if they are not the same, then this instance 364 is not a candidate for connection, and should be ignored. 366 2.3.1. Getting an SRP zone name from other SRP services 368 If the SRP partner does not have a domain to advertise, then when it 369 begins to browse for partners, it sets a timer for 370 DOMAIN_DISCOVERY_TIMEOUT seconds. 372 If the SRP partner does not have a domain to advertise, and is 373 therefore willing to join an existing domain, it checks to see if the 374 TXT record for the service indicates that joining is permitted. If 375 so, the SRP partner adopts the provided domain name. Once it has 376 adopted such a domain name, it updates its own TXT record to indicate 377 that domain name, and sets the 'join=yes' key/value pair in the TXT 378 record. It also cancels the DOMAIN_DISCOVERY_TIMEOUT timer. 380 If the DOMAIN_DISCOVERY_TIMEOUT timer goes off, then the SRP partner 381 MUST propose a zone name using one of the methods mentioned 382 previously in Section 2.1. It advertises that zone name in its TXT 383 record, with 'join=yes'. It then sets a new timer for 384 DOMAIN_PROPOSE_TIMEOUT seconds. 386 While waiting for the DOMAIN_PROPOSE_TIMEOUT timer to go off, any new 387 'add' events that arrive are examined to see if they are potential 388 domains to join. If a potential domain to join is seen, and it is 389 the same as the proposed domain, then the partner adopts that domain 390 and treats it as its domain to advertise. It then cancels the 391 DOMAIN_DISCOVERY_TIMEOUT timer. 393 At this point the SRP replication partner has a domain to advertise: 394 either the one it produced, or one that it discovered. 396 2.3.2. Establishing Replication with an existing Dataset 398 Once an SRP replication partner has settled on a domain to advertise, 399 it must either join other SRP replication partners in replicating 400 that domain, or if it is the first, it must advertise its willingness 401 to participate in replicating the domain. In order to do this, it 402 must settle on a dataset ID. 404 The dataset ID is a random 64-bit number, generated by the first 405 server to offer that dataset. There should always be exactly one 406 dataset ID per domain, but the dataset ID has a separate purpose: it 407 represents the set of data that is being replicated by a set of 408 cooperating SRP replication partners. This data is then offered 409 under the agreed-upon domain, but it's possible that there might be 410 several sets of SRP replication partners that agree to replicate a 411 particular domain, and then some event occurs which renders these 412 partners visible to each other. When this happens, the independent 413 sets of partners must converge on a single dataset. This is done 414 using the dataset ID. 416 When more than one dataset ID is present for a particular domain, the 417 dataset ID that is numerically lowest is preferred. This means that 418 SRP replication partners that are currently replicating a dataset 419 with a numerically higher dataset ID will have to abandon that 420 dataset and join together in replicating the numerically lowest 421 dataset. Servers that are not replicating the numerically lowest 422 dataset will therefore stop advertising SRP replication service and 423 begin attempting to join in in replicating the preferred dataset. 425 When a set of servers are advertising a particular dataset ID, the 426 server with the lowest precedence is primary. The primary server is 427 responsible for handing out precedence values to new partners as they 428 join in replicating the dataset. Precedence IDs are always allocated 429 starting with the precedence that is one greater than the primary's 430 precedence. 432 When an SRP replication partner has stopped advertising a particular 433 dataset ID, or has just started and therefore hasn't started 434 advertising a particular dataset ID, and there is a dataset ID 435 present that it can join in replicating, it attempts to connect to 436 the SRP replication partner that is primary for the dataset. If the 437 startup handshake succeeds, the primary will assign a new precedence 438 to the connecting partner as part of the handshake. 440 Once the synchronization phase has finished, the connecting partner 441 will begin advertising the SRP service for the chosen domain using 442 the new dataset ID and the precedence it received from the primary. 443 The connecting server will then also attempt to connect to every SRP 444 partner it sees advertising the same dataset ID and a lower 445 precedence. 447 It is possible that an SRP partner will attempt to join in 448 replicating a dataset, but the primary for that dataset may have 449 discontinued service, but the advertisement for the primary is still 450 in the cache. In this case, the SRP partner will attempt to 451 reconfirm the primary's advertisement. In mDNS, this is done as 452 described in Section 10.4 of [RFC6762]. For DNS Push connections, 453 this is done using the RECONFIRM messsage, described in Section 6.5 454 of [RFC8765]. For regular (polled) DNS, the SRP partner must trigger 455 a new DNS query. If the primary advertisement is successfully 456 confirmed, this indicates that there is a problem connecting to the 457 primary, in which case the connecting partner SHOULD discontinue 458 attempting to connect for at least MIN_RECONNECT_AFTER_FAILURE 459 seconds. 461 Otherwise, the connecting partner will attempt to connect to the new 462 primary if there is one. If there are no other servers advertising 463 the dataset ID, then the connecting partner reverts to attempting to 464 start its own replication of that dataset. 466 2.3.3. Establishing Replication When There Is No Existing Dataset 468 When an SRP replication partner has attempted to discover partners 469 with which to connect, and failed to do so, it then creates its own 470 dataset ID and precedence and begins advertising that dataset. Both 471 the dataset ID and precedence should be generated using a non- 472 deterministic random number generator. The dataset ID should be a 473 random number greater than or equal to zero and less than 2^64. The 474 precedence should be a random number greater than or equal to 0 and 475 less than 2^15. The reason for the upper limit is to allow for a 476 large range of numbers toward which the predence can increase. 478 The replication partner begins advertising this new dataset as soon 479 as the dataset ID and precedence have been generated. As in the 480 previous section, if a new dataset ID is seen shortly afterwards, 481 this most likely indicates that two SRP replication instances came up 482 at the same time; in this case as with the previous one, the lower 483 dataset ID is preferred, and the partner advertising the higher 484 dataset ID abandons that dataset ID to join the partner with the 485 lower dataset ID. 487 The replication partner that first advertises the dataset is the 488 primary replication partner for that dataset. It is responsible for 489 assigning precedences to new partners. 491 2.3.4. Conflicting precedence values 493 It is possible that two SRP replication partners that see different 494 service advertisements could identify different SRP replication 495 servers as primary and attempt to get their precedence values from 496 those different servers. When this happens, it's possible that they 497 might both get the same precedence value. When this occurs, as soon 498 each partner sees another partner advertising its precedence in an 499 SRP replication advertisement, it must discontinue advertising and 500 restart the dataset discovery process. 502 2.3.5. Handling primary transitions 504 An SRP partner either identifies itself as primary or not. When an 505 SRP partner is primary, it never connects to other SRP servers--it 506 only receives connections. When a non-primary partner connects to 507 the primary partner, it knows it is connecting to the primary 508 partner. If the connection with the primary drops, or if the 509 primary's advertisement goes away, then the non-primary evaluates the 510 set of advertisements that it sees. If its precedence is lowest, it 511 identifies itself as primary. 513 Non-primary servers receive updates from the primary whenever the 514 maximum precedence value changes. Non-primary servers should track 515 this precedence value. When a non-primary becomes primary, it should 516 add ten to the most recently received precedence value, so as to skip 517 any possible precedence assignments that haven't yet propagated. 519 2.4. Discovering the addresses of partners 521 When a partner is discovered, two new ongoing mDNS queries are 522 started on the hostname indicated in the SRV record of the partner: 523 one for A records, and one for AAAA records. Each time an address 524 'add' event is seen, either for an 'A' record or an 'AAAA' record, 525 the partner adds the address to the list of addresses belonging to 526 that partner. 528 2.5. Establishing Communication with a replication partner 530 When an address is added to a partner's address list, the partner 531 first checks to see if the address is one of its own addresses. If 532 so, then the partner is marked "me", and no connection is attempted 533 to it. This is somewhat safer than comparing hostnames, since a 534 hostname collision can result in renaming. 536 If the partner is not marked 'me', then the partner checks to see if 537 it has an existing outgoing connection to that partner. If it does 538 not, then it checks to see whether it has disabled outgoing 539 connections to that partner. If not, then it attempts to connect on 540 the new address. 542 When a connection fails, it advances to the next address in the list, 543 if there is one. If there are no remaining addresses, the partner 544 sets a timer for RECONNECT_INTERVAL seconds. When this timer 545 expires, it starts again at the beginning of the list and attempts to 546 connect to the first address, iterating again across the list until a 547 connection succeeds or it runs out of addresses. 549 Additionally, when an address is added, it is checked against the 550 list of unidentified incoming connections. If a match is found, and 551 the partner is marked "me," then the unidentified connection is 552 removed from the list and dropped. Otherwise, it is attributed to 553 the matching partner, and the protocol is started at the point of 554 receiving an incoming connection. 556 When an outgoing connection succeeds, the partner sends its server 557 ID. 559 2.6. Incoming connections 561 When an incoming connection is received, it is checked against the 562 partner list based on the source address of the incoming connection. 563 If the address appears on the list of addresses for a partner, then 564 the connection is attributed to that partner. If no matching partner 565 is found, a timer of UNIDENTIFIED_PARTNER_TIMEOUT seconds is set, and 566 the incoming connection is added to the list of "unidentified" 567 connections. 569 If a matching partner is found, then the partner waits for an 570 incoming partner ID. When such an ID is received, it is compared to 571 the partner's server-id. If the incoming server ID is the same as or 572 greater than the partner's server ID, the connection is dropped. 573 Otherwise, the connection proceeds to the "initial synchronization" 574 state. 576 2.7. Eliminating extra connections 578 When an outgoing connection succeeds, the partner sends its server ID 579 to the partner. When an incoming connection succeeds, the partner 580 waits for a server ID. Because both connections are partner 581 connections, and we only need one connection, the partner with the 582 higher server ID acts as the client and the partner with the lower 583 server ID acts as the server. If the server IDs are equal, then the 584 connecting server generates a new server ID, updates its TXT record, 585 and re-does the comparison. 587 2.8. Initial synchronization 589 The connecting partner begins the session by sending its server ID. 590 The receiving partner waits for a server ID, and when it receives 591 one, does the server ID comparison mentioned earlier. If the 592 connection survives the comparison, then the server sends a response 593 to the session message and waits for the client to request a list of 594 update candidates. 596 The connecting partner waits for a response to the initial session 597 message, and when it is received, requests that the server send 598 candidates. 600 2.8.1. Sending candidates 602 When a partner receives a "send candidates" message that it is 603 expecting to receive, it generates a candidate list from the list of 604 known SRP clients. This list includes SRP clients that have 605 registered directly with the partner, and SRP clients that have been 606 received through SRP replication updates. Each candidate contains a 607 hostname, a time offset, and a key identifier. 609 The key identifier is computed as follows: 611 uint32_t key_id(uint8_t *key_data, int key_len) { 612 uint32_t key_id = 0; 613 for (int i = 0; i < key_data_len; i += 4) { 614 key_id += ((key_data[i] << 24) | (key_data[i + 1] << 16) | 615 (key_data[i + 2] << 8) | (key_data[i + 3])); 616 } 617 return key_id; 618 } 620 When a partner receives a candidate message during the 621 synchronization process, it first searches for an SRP registration 622 with a hostname that matches the hostname in the candidate message. 623 It then compares the key ID to the key ID in the candidate message. 624 If the key ID doesn't match, it sends back a candidate response 625 status of "conflict". If the key ID does match, it compares the time 626 provided to the time the existing host entry was received. If the 627 time of the update is later, it sends a "send host" response. If it 628 is earlier or the same, it sends a "continue" response. If there is 629 no matching host entry for the candidate message, the partner sends a 630 "send host" response. 632 When a partner receives a candidate response with a status of "send 633 host", it generates a host message, which contains the hostname, the 634 time offset, and the SRP message that was received from the host. 635 The partner then applies the SRP update message as if it had been 636 received directly from the SRP client. The host update time sent by 637 the partner is remembered as the time when the update was received 638 from the client, for the purposes of future synchronization. 640 When a partner is finished iterating across its list of candidates, 641 it sends a "send candidates" response. 643 When a partner receives a "send candidates" response, if it is the 644 server, it sends its own "send candidates" message, and processes any 645 proposed candidates. 647 When a partner that is a server receives a "send candidates" 648 response, it goes into the "routine operation" state. When a partner 649 that is a client sends its "send candidates" response, it goes into 650 the "routine operation" state. 652 2.9. Routine Operation 654 During routine operation, whenever an update is successfully 655 processed from an SRP client, the partner that received that update 656 queues that update to be sent to each partner to which it has a 657 connection, whether server or client. If there are no updates 658 pending to a particular client, the update is sent immediately. 659 Otherwise, it's send when the outstanding update is acknowledged. 661 When during routine operation a partner receives a host update from 662 its partner, it immediately applies that update to its local SRP 663 zone. This is based on the assumption that a new update is always 664 more current than a copy of the host information in its database. 666 3. Protocol Details 668 The DNS-SD SRP Replication Protocol (henceforth SRPL) is based on DNS 669 Stateful Operations [RFC8490]. Each SRP replication partner creates 670 a listener on port 853, the DNS-over-TLS [RFC7858] reserved port. 671 This listener can be used for other DNS requests as well. 673 Participants in the protocol are partners. To distinguish between 674 partners, the terms "partner" and "partner" are used. "Partner" 675 refers to the partner that is communicating or receiving 676 communication. "Partner" refers to the other partner. Partners can 677 be clients or servers: a partner that has established a connection to 678 a partner is a client; a partner that has received a connection from 679 a partner is a server. 681 3.1. DNS Stateful Operations considerations 683 DNS Stateful Operations is a DNS per-connection session management 684 protocol. DNS Push session management includes session establishment 685 as well as session maintenance. 687 3.1.1. DSO Session Establishment 689 An DSO session for an SRPL connection can be established either by 690 simply sending the first SRPL message, or by sending a DSO Keepalive 691 message. Section 5.1 of [RFC8490]. 693 3.1.2. DSO Session maintenance 695 DSO sessions can be active or idle. As long as the SRPL protocol is 696 active on a connection, the DSO state of the connection is active. 697 DSO sessions require occasional keepalive messages. The default of 698 fifteen seconds is adequate for SRPL. 700 An idle DSO session must persist for long enough that there is a 701 chance for the browse that identifies it to succeed. Therefore, the 702 minimum DSO session inactivity timeout is 703 2*UNIDENTIFIED_PARTNER_TIMEOUT seconds. 705 3.2. DSO Primary TLVs 707 Each DSO message begins with a primary TLV, and contains secondary 708 TLVs with additional information. The primary TLVs used in the SRPL 709 protocol are as follows: 711 3.2.1. SRPL Session 713 DSO-TYPE code: SRPLSession. Introduces the SRPL session. The SRPL 714 session TLV contains no data, just the type and length. SRPL Session 715 primary TLV requests do not include any secondary TLVs. SRPL Session 716 requests are DSO requests: the recipient is expected to send a 717 response TLV. Both request and response TLVs have the same format. 718 An SRPL Session response may include an SRPL Precedence secondary 719 TLV. 721 3.2.1.1. SRPL client behavior 723 The SRPL Session request is sent by a partner acting as a client to 724 its partner once the TLS connection to the partner, acting as a 725 server, has succeeded. The SRPL session message establishes the DSO 726 connection as an SRP protocol connection. If it is the first DSO 727 message sent by the partner acting as a client, then it also 728 establishes the DSO session. 730 When the SRPL partner acting as a client receives a response to its 731 SRPL session message, it sends an SRPL Send Candidates message. 733 When an SRPL partner receives an SRPL Precedence secondary TLV in an 734 SRPL Session response, if it thinks it is connected to the primary 735 partner, it sets its precedence to the assigned value. If it thinks 736 it is connecting to a non-primary, then it disconnects and waits 737 NON_PRIMARY_RESETTLE_TIME seconds before reconnecting. It also 738 attempts to reconfirm the service advertisement for the partner it 739 thinks is primary. 741 3.2.1.2. SRPL server behavior 743 An SRPL partner acting as a server that receives an SRPL Session 744 request checks to see if the connection on which it was received is 745 already established. If so, this is a protocol error, and the SRPL 746 partner MUST drop the connection. 748 When an SRPL partner that is primary receives an SRPL Session 749 request, the SRPL Session response MUST include an SRPL Precedence 750 secondary TLV, which assigns a precedence to the connecting SRPL 751 partner. 753 3.2.2. SRPL Send Candidates 755 DSO-TYPE code: SRPLSendCandidates. Requests the partner to send its 756 candidates list. The SRPL Send Candidates message contains no 757 additional data. The SRPL Send Candidates primary TLV does not 758 include any secondary TLVs. SRPL Send Candidates messages are DSO 759 requests: the recipient is expected to send a response TLV. Both 760 request and response TLVs have the same format. 762 3.2.2.1. SRPL client behavior 764 An SRPL partner acting as a client MUST send an SRPL Send Candidates 765 request after it has received an SRPL Session response. It MUST NOT 766 send this request at any other time. 768 An SRPL partner acting as a client expects to receive an SRPL Send 769 Candidates message after it has received an SRPL Send Candidates 770 response. If it receives an SRPL Send Candidates message at any 771 other time, this is a protocol error, and the SRPL partner should 772 drop its connection to the server. 774 3.2.2.2. SRPL server behavior 776 An SRPL partner acting as a server expects to receive an SRPL Send 777 Candidates request after it has sent an SRPL Session response. If it 778 receives an SRPL Candidates request at any other time, this is a 779 protocol error, and it MUST drop the connection. 781 An SRPL partner acting as a server MUST send an SRPL Send Candidates 782 request after it has sent an SRPL Send Candidates response. 784 An SRPL partner acting as a server MUST enter the "normal operations" 785 state after receiving an SRPL Send Candidates response from its 786 partner. 788 3.2.3. SRPL Candidate 790 DSO-TYPE code: SRPLCandidate. Announces the availability of a 791 specific candidate SRP client registration. The SRPL Candidate 792 message contains no additional data. SRPL Candidate messages are DSO 793 requests: the recipient is expected to send a response TLV. Both 794 request and response TLVs have the same format. 796 3.2.3.1. Required secondary TLVs 798 The SRPL Candidate request MUST include the following secondary TLVs: 799 SRPL Hostname, SRPL Time Offset, and SRPL Key ID. If an SRPL partner 800 receives an SRPL Candidate request that doesn't contain all of these 801 secondary TLVs, this is a protocol error, and the partner MUST drop 802 the connection. 804 The SRPL Candidate response MUST include one of the following status 805 TLVs: SRPL Candidate Yes, SRPL Candidate No, or SRPL Conflict. If an 806 SRPL partner receives an SRPL Candidate response which does not 807 contain exactly one of these TLVS, this is a protocol error, and the 808 partner MUST drop the connection. 810 3.2.3.2. SRPL partner common behavior 812 SRPL partners expect to receive SRPL Candidate messages between the 813 time that they have sent an SRPL Send Candidates message and the time 814 that they have received an SRPL Send Candidates response. If an SRPL 815 Candidate message is received at any other time, this is a protocol 816 error, and the partner MUST drop the connection. 818 Partners MUST NOT send SRPL Candidate requests if they have sent any 819 SRPL Candidate or SRPL host requests that have not yet received 820 responses. Partners receiving SRPL Candidate requests when they have 821 not yet responded to an outstanding SRPL Candidate request or SRPL 822 Host request MUST treat this as a protocol failure and drop the 823 connection. 825 When a partner receives a valid SRPL Candidate message, it checks its 826 SRP registration database for a host that matches both the SRPL 827 Hostname and SRPL Key ID TLVs. If such a match is not found, the 828 partner sends an SRPL Candidate response that includes the SRPL 829 Candidate Yes secondary TLV. 831 If a match is found for the hostname, but the Key ID doesn't match, 832 this is a conflict, and the partner sends an SRPL Candidate response 833 with the SRPL Conflict secondary TLV. 835 If a match is found for the hostname, and the key ID matches, then 836 the partner computes the update time of the candidate by subtracting 837 the value of the SRPL Time Offset TLV from the current time in 838 seconds. This computation should be done when the SRPL Candidate 839 message is received to avoid clock skew. If 'candidate update time' 840 - 'local update time' is greater than SRPL_UPDATE_SKEW_WINDOW, then 841 the candidate update is more recent than the current SRP 842 registration. In this case, the partner sends an SRPL Candidate 843 response and includes the SRPL Candidate Yes secondary TLV. The 844 reason for adding in some skew is to account for network transmission 845 delays. 847 3.2.4. SRPL Host 849 DSO-TYPE code: SRPLHost. Provides the content of a particular SRP 850 client registration. The SRPL Host message contains no additional 851 data. SRPL Host messages are DSO requests: the recipient is expected 852 to send a response TLV. Both request and response TLVs have the same 853 format. 855 3.2.4.1. Required secondary TLVs 857 The SRPL Host request MUST include the following secondary TLVs: SRPL 858 Hostname, SRPL Key ID, and one or more SRPL Host Message TLVs. If an 859 SRPL partner receives an SRPL Candidate request that doesn't contain 860 all of these secondary TLVs, this is a protocol error, and the 861 partner MUST drop the connection. 863 The SRPL Host message always includes at least one SRPL Host Message 864 TLV, which contains the most recent update the SRP server has 865 received for that host. However, in some cases an update for a host 866 may update some, but not all, service instances that reference that 867 host; in this case, the SRPL Host request MUST include all of the 868 previously received SRP updates that would be required to reconstruct 869 the current state of the host registration on the server sending the 870 SRPL Host request. 872 3.2.4.2. SRPL partner common behavior during synchronization 874 SRPL partners expect to receive either zero or one SRPL Host requests 875 after sending an SRPL Candidate response with a SRPL Candidate Yes 876 secondary TLV. If an SRPL Host request is received at any other time 877 during synchronization, this is a protocol error, and the partner 878 MUST drop the connection. The only time that an SRPL Host request 879 would _not_ follow a positive SRPL Candidate response would be when 880 the candidate host entry's lease expired after the SRPL Candidate 881 request was sent but before the SRPL Candidate response was received. 883 SRPL partners send SRPL Host requests during synchronization when a 884 valid SRPL Candidate response has been received that includes an SRPL 885 Candidate Yes secondary TLV. The host request is generated based on 886 the current candidate (the one for which the SRPL Candidate request 887 being responded to was send). 889 3.2.4.3. SRPL partner common behavior during normal operations 891 When an SRPL partner during normal operations receives and has 892 successfully validated an SRP update from an SRP client, it MUST send 893 that update to each of its connected partners as an SRPL Host 894 request. If the connection to a particular partner is not busy, and 895 there are no updates already queued to be sent, it MUST send the SRPL 896 Host message immediately. Otherwise, it MUST queue the update to 897 send when possible. The queue MUST be first-in, first-out. 899 After an SRPL partner has sent an SRPL Host request to a partner, and 900 before it receives a corresponding SRPL Host response, it MUST NOT 901 send any more SRPL Host messages to that partner. 903 When an SRPL partner receives an SRPL Host request during normal 904 operations, it MUST apply it immediately. While it is being applied, 905 it MUST NOT send any other SRPL Host requests to that partner. 907 When an SRPL Host request has been successfully applied by an SRPL 908 partner, the partner MUST send an SRPL Host response. 910 If an SRPL partner receives an SRPL Host request while another SRPL 911 Host request is being processed, this is a protocol error, and the 912 partner MUST drop the connection to its partner. 914 3.3. DSO Secondary TLVs 916 In addition to the Primary TLVs used to send requests between SRPL 917 partners, we define secondary TLVs to carry formatter information 918 needed for various SRPL requests. 920 3.3.1. SRPL Candidate Yes 922 DSO-TYPE code: SRPLCandidateYes. In an SRPL Candidate response, 923 indicates to the partner that an SRPL Host message for the candidate 924 is wanted and should be sent. 926 Appears as a secondary TLV in SRPL Candidate responses. MUST NOT 927 appear in any other SRPL request or response. MUST NOT appear in 928 addition to either SRPL Conflict or SRPL Candidate No secondary TLVs. 930 3.3.2. SRPL Candidate No 932 DSO-TYPE code: SRPLCandidateNo. In an SRPL Candidate response, 933 indicates to the partner that an SRPL Host message for the candidate 934 is not wanted and should not be sent. 936 Appears as a secondary TLV in SRPL Candidate responses. MUST NOT 937 appear in any other SRPL request or response. MUST NOT appear in 938 addition to either SRPL Conflict or SRPL Candidate Yes secondary 939 TLVs. 941 3.3.3. SRPL Conflict 943 DSO-TYPE code: SRPLConflict. In an SRPL Candidate response, 944 indicates to the partner that an SRPL Host message for the candidate 945 is not wanted and should not be sent. Additionally indicates that 946 the proposed host conflicts with local data. This indication is 947 informative and has no effect on processing. 949 Appears as a secondary TLV in SRPL Candidate responses. MUST NOT 950 appear in any other SRPL request or response. MUST NOT appear in 951 addition to either SRPL Candidate Yes or SRPL Candidate No secondary 952 TLVs. 954 3.3.4. SRPL Hostname 956 DSO-TYPE code: SRPLHostname. In an SRPL Candidate or SRPL Host 957 request, indicates to the partner the hostname of an SRP 958 registration. The hostname is represented in DNS wire format 959 Section 3.1 of [RFC1035]. 961 Required as a secondary TLV in SRPL Candidate and SRPL Host requests. 962 MUST NOT appear in any other SRPL request or response. 964 3.3.5. SRPL Host Message 966 DSO-TYPE code: SRPLHostMessage. In an SRPL Host request, conveys 967 four data objects in order: 969 * the lease time and key lease time returned to the client, 970 represented as two unsigned 32-bit numbers in units of seconds. 972 * the time offset at which the message was received, represented as 973 a 32-bit unsigned number of seconds. The time offset is computed 974 as the difference between the time when the SRPL Host Message TLV 975 is being constructed for transmission, and the time when the SRP 976 update contained in the SRPL Host Message was received. 978 * the SRP Update message received from the SRP client. This 979 contains the contents of the message, but not any IP, UDP, TCP or 980 TLS headers that may have encapsulated it. 982 The content of the SRPL Host Message is used to update the host on 983 the partner receiving the request. Note that the SRP message being 984 sent can't be modified by the SRPL partner sending it, so in order to 985 validate the message (assuming that the signature includes a nonzero 986 time), the validation process should adjust the current time by the 987 time offset included in the SRPL Time Offset TLV when comparing 988 against the signature time when checking for replay attacks. The 989 computation of the current time of signing should be done when the 990 message is received to avoid clock skew that might result from 991 processing delays. 993 Required as a secondary TLV in SRPL Host requests. MUST NOT appear 994 in any other SRPL request or response. 996 3.3.6. SRPL Time Offset 998 DSO-TYPE code: SRPLTimeOffset. In an SRPL Candidate, conveys the 999 difference between the time the SRP update was received from the SRP 1000 client and the current time on the partner generating the request, in 1001 seconds. 1003 Required as a secondary TLV in SRPL Candidate and SRPL Host requests. 1004 MUST NOT appear in any other SRPL request or response. 1006 3.3.7. SRPL Key ID 1008 DSO-TYPE code: SRPLKeyID. In an SRPL Candidate, conveys the key ID 1009 of the SRP client. 1011 Required as a secondary TLV in SRPL Candidate requests. MUST NOT 1012 appear in any other SRPL request or response. 1014 4. Security Considerations 1016 SRP replication basically relies on the trustworthiness of hosts on 1017 the local network. Since SRP itself relies on the same level of 1018 trust, SRP replication doesn't make things worse. However, when the 1019 option to have a central SRP server is available, that is likely to 1020 be more trustworthy. 1022 5. Delegation of 'local.arpa.' 1024 In order to be fully functional, the owner of the 'arpa.' zone must 1025 add a delegation of 'local.arpa.' in the '.arpa.' zone [RFC3172]. 1026 This delegation should be set up as was done for 'home.arpa', as a 1027 result of the specification in Section 7 of [RFC8375]. 1029 6. IANA Considerations 1031 6.1. 'srpl-tls' Service Name 1033 IANA is requested to add a new entry to the Service Names and Port 1034 Numbers registry for srpl-tls with a transport type of tcp. No port 1035 number is to be assigned. The reference should be to this document, 1036 and the Assignee and Contact information should reference the authors 1037 of this document. The Description should be as follows: 1039 Availability of DNS-SD SRP Replication Service for a given domain is 1040 advertised using the "_srpl-tls._tcp.." SRV record gives the 1041 target host and port where DNS-SD SRP Replication Service is provided 1042 for the named domain. 1044 6.2. DSO TLV type code 1046 The IANA is requested to add the following entries to the 16-bit DSO 1047 Type Code Registry. Each type mnemonic should be replaced with an 1048 allocated type code, both in this table and elsewhere in the 1049 document. RFC-TBD should be replaced with the name of this document 1050 once it becomes an RFC. 1052 +--------------------+---------------+-------+--------+-----------+ 1053 | Type | Name | Early | Status | Reference | 1054 | | | Data | | | 1055 +--------------------+---------------+-------+--------+-----------+ 1056 | SRPLSession | SRPL Session | No | STD | RFC-TBD | 1057 +--------------------+---------------+-------+--------+-----------+ 1058 | SRPLSendCandidates | SRPL Send | No | STD | RFC-TBD | 1059 | | Candidates | | | | 1060 +--------------------+---------------+-------+--------+-----------+ 1061 | SRPLCandidate | SRPL | No | STD | RFC-TBD | 1062 | | Candidate | | | | 1063 +--------------------+---------------+-------+--------+-----------+ 1064 | SRPLHost | SRPL Host | No | STD | RFC-TBD | 1065 +--------------------+---------------+-------+--------+-----------+ 1066 | SRPLCandidateYes | SRPL | No | STD | RFC-TBD | 1067 | | Candidate Yes | | | | 1068 +--------------------+---------------+-------+--------+-----------+ 1069 | SRPLCandidateNo | SRPL | No | STD | RFC-TBD | 1070 | | Candidate No | | | | 1071 +--------------------+---------------+-------+--------+-----------+ 1072 | SRPLConflict | SRPL Conflict | No | STD | RFC-TBD | 1073 +--------------------+---------------+-------+--------+-----------+ 1074 | SRPLHostname | SRPL Hostname | No | STD | RFC-TBD | 1075 +--------------------+---------------+-------+--------+-----------+ 1076 | SRPLHostMessage | SRPL Host | No | STD | RFC-TBD | 1077 | | Message | | | | 1078 +--------------------+---------------+-------+--------+-----------+ 1079 | SRPLTimeOffset | SRPL Time | No | STD | RFC-TBD | 1080 | | Offset | | | | 1081 +--------------------+---------------+-------+--------+-----------+ 1082 | SRPLKeyID | SRPL Key ID | No | STD | RFC-TBD | 1083 +--------------------+---------------+-------+--------+-----------+ 1085 Table 1 1087 6.3. Registration and Delegation of 'local.arpa' as a Special-Use 1088 Domain Name 1090 IANA is requested to record the domain name local.arpa.' in the 1091 Special-Use Domain Names registry [SUDN]. IANA is requested, with 1092 the approval of IAB, to implement the delegation requested in 1093 Section 5. 1095 IANA is further requested to add a new entry to the "Transport- 1096 Independent Locally-Served Zones" subregistry of the the "Locally- 1097 Served DNS Zones" registry [LSDZ]. The entry will be for the domain 1098 local.arpa.' with the description "Ad-hoc DNS-SD Special-Use Domain", 1099 listing this document as the reference. 1101 7. Informative References 1103 8. Normative References 1105 [RFC1035] Mockapetris, P., "Domain names - implementation and 1106 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1107 November 1987, . 1109 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 1110 Requirements for the Address and Routing Parameter Area 1111 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 1112 September 2001, . 1114 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1115 DOI 10.17487/RFC6762, February 2013, 1116 . 1118 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1119 and P. Hoffman, "Specification for DNS over Transport 1120 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1121 2016, . 1123 [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 1124 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, 1125 . 1127 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 1128 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 1129 RFC 8490, DOI 10.17487/RFC8490, March 2019, 1130 . 1132 [RFC8765] Pusateri, T. and S. Cheshire, "DNS Push Notifications", 1133 RFC 8765, DOI 10.17487/RFC8765, June 2020, 1134 . 1136 [SUDN] "Special-Use Domain Names Registry", July 2012, 1137 . 1140 [LSDZ] "Locally-Served DNS Zones Registry", July 2011, 1141 . 1144 Author's Address 1146 Ted Lemon 1147 Apple Inc. 1148 One Apple Park Way 1149 Cupertino, California 95014 1150 United States of America 1152 Email: mellon@fugue.com