idnits 2.17.00 (12 Aug 2021) /tmp/idnits52444/draft-tljd-dnssd-zone-discover-00.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 5 instances 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 272: '...ns for discovery MUST NOT use 'home.ar...' RFC 2119 keyword, line 296: '... For this reason, authorities MUST NOT...' RFC 2119 keyword, line 317: '...main, the authority MUST validate that...' RFC 2119 keyword, line 321: '...nism is being used, the authority MUST...' RFC 2119 keyword, line 328: '... it SHOULD use that name, since it r...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 110 has weird spacing: '...ertiser a ser...' == Line 113 has weird spacing: '...thority a dev...' == Line 116 has weird spacing: '...Dataset a col...' == Line 123 has weird spacing: '...Browser a dev...' -- The document date (26 July 2021) is 292 days in the past. Is this intentional? 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 section? 'RFC6762' on line 78 looks like a reference -- Missing reference section? 'RFCxxx' on line 141 looks like a reference -- Missing reference section? 'RFC6763' on line 403 looks like a reference -- Missing reference section? 'SRP' on line 255 looks like a reference -- Missing reference section? 'RFC1034' on line 412 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 6 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 邓 乔宇 (J. Deng) 4 Intended status: Standards Track Apple Inc. 5 Expires: 27 January 2022 26 July 2021 7 Permissionless Advertising and Discovery of DNS-SD Authoritative Zones 8 draft-tljd-dnssd-zone-discover-00 10 Abstract 12 This document describes how to make DNS-SD browsing domains available 13 for browsing and discovery without requiring special cooperation from 14 the network infrastructure. Zones made available in this way are 15 browsed using DNS or DNS Push. The mechanism for advertising them is 16 Multicast DNS (mDNS). This allows DNS-SD browsers to benefit from 17 the permissionless aspects of mDNS without relying on mDNS for all 18 queries, which improves scalability and reliability in applications 19 where many services may be advertised. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 27 January 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Authority Datasets . . . . . . . . . . . . . . . . . . . 4 58 3.1.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 4 59 3.1.2. Authoritative DNS . . . . . . . . . . . . . . . . . . 4 60 3.1.3. SRP Replication . . . . . . . . . . . . . . . . . . . 5 61 3.2. DNSSD Browsing Domains . . . . . . . . . . . . . . . . . 5 62 4. Advertising an Authority Dataset to be Used for Service 63 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. Choosing a Domain to Advertise . . . . . . . . . . . . . 6 65 4.2. Advertising DNS Authoritative Service for a Domain using 66 multicast DNS . . . . . . . . . . . . . . . . . . . . . . 7 67 4.3. Advertising Address information for an Authority . . . . 8 68 4.4. Advertising the Availability of Service Discovery for a 69 Domain . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5. Discovering Authority Datasets . . . . . . . . . . . . . . . 8 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 7. Informative References . . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 DNS-SD currently provides permissionless advertising and discovery 78 using multicast DNS [RFC6762]. Unfortunately, multicast DNS has some 79 limitations. In addition to the obvious limitation that it only 80 works between services and users that are connected to a single 81 multicast domain (generally a single link), in many situations 82 excessive use of multicast is unreliable, which can cause discovery 83 to fail when a service is actually present. 85 By contrast, DNS service discovery using unicast traffic is not 86 limited by the scope of reachability of link-local multicast. On 87 networks where multicast is less reliable, or more costly, unicast 88 DNS-SD is clearly advantageous. However, because of the hierarchical 89 nature of DNS, existing solutions for providing unicast DNS rely on 90 coordination with the network infrastructure. In many settings, 91 particularly on home networks, this coordination is not available, 92 and so we must fall back on multicast DNS, despite its limitations. 94 This document defines a new mechanism for discovering the 95 availability of unicast DNS service discovery using multicast DNS. 96 Although somewhat limited in the sense that this mechanism still 97 relies on multicast DNS as a means of discovering the unicast 98 service, this mechanism can substantially reduce reliance on 99 multicast DNS, so that its limitations are minimized. Additionally, 100 it makes it possible for devices that provide discovery to adjacent 101 networks, such as stub networks, to overcome the limitations of link- 102 local multicast for this application. 104 This document describes how to advertise and discover authoritative 105 service for a DNS domain, and how to advertise the availability of 106 service discovery for a DNS domain, using multicast DNS. 108 2. Glossary 110 Advertiser a service that is advertising its availability through 111 some authority 113 Authority a device, connected to an infrastructure link, that is 114 advertising service discovery for an authority dataset using mDNS. 116 Authority Dataset a collection of authoritative data to be 117 advertised, and which can be treated as a single coherent set. 118 More than one authority may advertise the same dataset; what makes 119 it "the same dataset" is the expectation that whichever authority 120 is asked for an answer to a particular question will generally 121 give the same answer as any other authority. 123 DNSSD Browser a device, connected to an infrastructure link, that 124 discovers authorities and uses them to discover services 125 advertised by advertisers. 127 3. Data Model 129 The goal of the mechanism described in this document is to enable 130 permissionless advertising and discovery of authoritative DNS servers 131 that can be used for service discovery. From the perspective of a 132 consumer of such a service on a particular IP link, there may be more 133 than one such service. Each such service can be thought of as 134 providing an authority dataset. 136 3.1. Authority Datasets 138 3.1.1. Multicast DNS 140 One example of an authority dataset is the set of services that can 141 be discovered by a DNSSD Discovery Proxy [RFCxxx]. A discovery proxy 142 acts as an authoritative DNS server mapping information advertised 143 using multicast DNS on a particular link to a DNS zone. 145 There may be more than one discovery proxy for a particular multicast 146 DNS link. If so, both discovery proxies can be expected to return 147 the same answers to any questions asked by a DNS-SD client that is 148 browsing for services within that zone. This is what is meant by an 149 "authority dataset": the data returned by one authoritative server 150 that answers for that dataset should be the same as the data returned 151 by the other server. 153 Because of the dynamic nature of mDNS, there is no enforcement 154 mechanism to ensure that two discovery proxies would answer the same 155 DNS question in exactly the same way, but each server is functionally 156 equivalent: there is no reason to prefer one server over the other, 157 nor to query both servers to avoid missing data known to one but not 158 the other. 160 3.1.2. Authoritative DNS 162 Another example of an authority dataset is an authoritative DNS 163 server that maintains a DNS zone for DNS Service Discovery using the 164 DNS-SD Service Registration Protocol. In this case, there is one 165 primary authoritative server and, potentially, more than one 166 secondary authoritative server. The secondary server databases are 167 all dependent on the primary server's database, and are maintained 168 using DNS zone transfers or some other hierarchical replication 169 mechanism. 171 In this case, the primary and the secondary servers are all serving 172 an authoritative zone, which is another example of an authority 173 dataset. The authoritative zone may have different versions, which 174 can be known using the zone serial number, but in principle each 175 authoritative server is equivalently valid: there is no reason to 176 prefer one over the other. This is another example of an authority 177 dataset. 179 3.1.3. SRP Replication 181 A third example of an authority dataset would be a set of one or more 182 SRP servers that cooperate to maintain a common database using the 183 SRP replication protocol [SRP Replication]. These servers are each 184 authoritative DNS servers, in the sense that they answer 185 authoritatively for questions within the DNS zone that they manage, 186 but unlike a typical DNS authoritative service configuration, there 187 is no hierarchy-no server is primary-and there are no discrete 188 versions of the zone database, so there is no way to generate a 189 meaningful serial number that could be used to manage zone transfers. 191 As with Discovery Proxies, although it's quite possible at any given 192 moment in time that the same query to two different SRP replication 193 peers will yield different answers, the dataset being managed by 194 these servers is the same dataset, and therefore is also an authority 195 dataset. 197 3.2. DNSSD Browsing Domains 199 Service discovery on a local link always implicitly includes one 200 authority dataset: the set of all mDNS services advertised on that 201 link. DNSSD browsers always search for services within this dataset. 202 Additional datasets are made available by advertising additional 203 legacy browsing domains locally. So each authority dataset other 204 than the link-local authority dataset must be explicitly advertised 205 using mDNS; when the DNSSD browser is asked to browse for local 206 services without explicitly specifying a domain in which to browse, 207 it attempts to discover that service in each of the authority 208 datasets advertised locally for discovery, and also in the link-local 209 dataset provided by mDNS. 211 Note that DNSSD [RFC6763] also provides for discovering browsing 212 domains using DNS, either using the domain name search list or using 213 the DNS reverse domain query [RFC6763 section ???]. DNS browsing 214 domains are provided by the network infrastructure, and complement 215 browsing domains that may be provided permissionlessly using mDNS. 217 4. Advertising an Authority Dataset to be Used for Service Discovery 219 There are four steps an authority must follow to advertise the 220 availability of an authority dataset for service discovery: 222 * Choose a domain to represent that authority dataset 223 * Advertise itself as an authority that provides name service for 224 that domain (and hence that dataset) 226 * Advertise its address information 228 * Advertise the availability of service discovery for that domain 230 4.1. Choosing a Domain to Advertise 232 When advertising a domain for discovery, it must be the case that all 233 authorities servers that advertise that domain are advertising the 234 same information. Thus, the domain being advertised can be treated 235 as an identifier for a particular authority dataset. How this is 236 accomplished is out of scope for this document; one solution is 237 described in [SRP Replication]. 239 Because the domain is being advertised using multicast DNS, we assume 240 that there is no delegation in the global DNS; if there were, there 241 would be no reason to advertise the domain using mDNS. Furthermore, 242 in order to prevent domain spoofing using the technique described 243 here, the DNS resolver that is discovering this domain is required to 244 prove that no delegation for the domain being advertised using mDNS 245 exists in the global DNS hierarchy. 247 Given that most stub resolvers at present do not support DNSSEC, the 248 domain being advertised will have to be a subdomain of some domain 249 that is known to be a locally-served domain [RFC6761?]. In this case 250 the client can be sure that this domain never appears in the DNS by 251 definition, rather than by validating the non-existence of the 252 delegation. 254 Two domains that are ideal for this purpose are 'home.arpa' [Dot 255 Home] and 'service.arpa' [SRP]. The 'home.arpa' domain is generally 256 intended for use in home networks, so this is appropriate for use in 257 cases where the device advertising the domain is expected to be 258 installed in a home network; for devices that are not expected to be 259 installed in a home network, 'service.arpa' is preferable. 261 Given that there is no way for a particular device to know for 262 certain that the network setting in which it is installed is in fact 263 'a home' or 'not a home,' this advice is merely a suggestion: a 264 consumer product should probably use 'home.arpa' and a commercial 265 product should probably use 'service.arpa', and perhaps either device 266 should be configurable, but in practice it is not crucial to get this 267 perfectly correct. 269 Bearing in mind that there may be multiple authorities and multiple 270 authority datasets being provided on the same infrastructure link, it 271 is important to choose a domain that is not ambiguous. Therefore, 272 devices advertising domains for discovery MUST NOT use 'home.arpa' or 273 'service.arpa' directly: when using these domains, a unique subdomain 274 must be chosen below that domain, rather than using the root domain. 276 It may be useful to identify the subdomain in terms of some visible 277 network identifier. For instance, if the authority dataset contains 278 the set of services for a particular WiFi link, it might make sense 279 to use the name 'SSID.wifi.home.arpa'. This shows the SSID of the 280 WiFi link, and differentiates between WiFi and other technologies 281 (e.g. Thread) that use something like an SSID. For Thread networks, 282 the domain 'thread.home.arpa' is used for this purpose, for example, 283 and the thread network name is used as the leftmost label (e.g., 'my- 284 home.thread.home.arpa.'). 286 We have stated that the domain must be provably nonexistent, which is 287 a slight simplification. For completeness, we will point out that if 288 the delegation is secure, and the server being advertised is able to 289 sign records such that they validate, this is also permissible. But 290 in this case, there's likely no utility to using mDNS to advertise 291 the authoritative server and, furthermore, this solution requires the 292 stub resolver to do DNSSEC validation, which is not commonly 293 supported at present. 295 Although '.local' is a locally-served domain, it is by definition 296 served using multicast DNS. For this reason, authorities MUST NOT 297 use '.local' to advertise their authority dataset. 299 4.2. Advertising DNS Authoritative Service for a Domain using multicast 300 DNS 302 To advertise DNS authoritative service for a domain, the 303 authoritative server publishes an NS record for that domain using 304 multicast DNS. For example, to publish DNS service for 305 example.thread.home.arpa., the NS record published with mDNS would 306 be: 308 example.thread.home.arpa. IN NS thread-server-1.local 310 Note that the DNS server for example.com has a .local suffix, meaning 311 that its address can be discovered using mDNS. This is not required. 312 If the DNS server is in a domain that can be looked up using ordinary 313 DNS service, multicast DNS service is not required. This solution is 314 preferred, but requires coordination with infrastructure, so doesn't 315 address the core use case of this document. 317 Before publishing its chosen domain, the authority MUST validate that 318 no other authority is advertising that domain for a different 319 authority dataset. The mechanism for this validation is out of scope 320 for this document, and is specific to the replication mechanism being 321 used. If no replication mechanism is being used, the authority MUST 322 publish its NS record as a unique record. 324 4.3. Advertising Address information for an Authority 326 Address information for an authority may be advertised using DNS or 327 mDNS. If the authority happens to have a name published in the DNS, 328 it SHOULD use that name, since it reduces reliance on multicast. In 329 most cases, this will not be possible, in which case the authority 330 MUST advertise addresses that can be used to reach it using mDNS. 332 4.4. Advertising the Availability of Service Discovery for a Domain 334 In order for services within an authority dataset to be discovered by 335 DNSSD browsers, the domain that identifies that authority dataset 336 must be advertised as a domain in which discovery should be done. 337 This is accomplished by advertising a PTR record in .local for the 338 legacy browsing domain [RFC6763]. For example, if the domain being 339 used is 'example.wifi.home.arpa.', then the PTR record would be as 340 follows: 342 lb._dns-sd._udp.local IN PTR example.wifi.home.arpa. 344 When more than one authority is advertising discoverability for a 345 particular authority dataset, there will be more than one of these 346 records advertised, but this isn't a problem since they are not 347 required to be unique. This record should not be advertised until 348 the authority has successfully generated or discovered a domain that 349 is unique to the authority dataset being advertised. 351 5. Discovering Authority Datasets 353 A DNSSD browser discovers the set of datasets available locally by 354 issuing an mDNS query for lb._dns-sd._udp.local. This query will 355 return zero or more PTR records. As each PTR record is returned, it 356 is compared against the existing set of legacy browsing domains that 357 the DNSSD browser maintains. If the target of the PTR record is not 358 in this set, then it is checked for validity and, if valid, added to 359 the set, and any ongoing browse operations begin to try to browse the 360 new domain. 362 A browsing domain discovered using mDNS can only be valid if one of 363 the following is true: 365 * It is a subdomain of a domain that is defined to be a locally 366 served domain [???] 368 * The DNSSD browser has found a secure denial of existence for the 369 domain and validated it using DNSSEC 371 * The DNSSD browser has found a secure delegation for the domain (in 372 which case it MUST validate answers in that domain using DNSSEC). 374 In addition, a host on which a DNSSD browser is running may have 375 discovered domains that would be considered valid because it is a 376 locally-served domain, or because it can be proven not to exist in 377 the DNS hierarchy, but for which authoritative service is already 378 provided by the network infrastructure. In this case, the DNSSD 379 browser MUST consider the information provided in multicast DNS to be 380 invalid, and MUST only use the service information provided by the 381 network infrastructure for that domain. 383 Examples of this would be a domain like 'home.arpa' that is served by 384 the local infrastructure. In this case, if for example the local 385 infrastructure answers with NXDOMAIN for 'example.wifi.home.arpa.' 386 then even if the browser is not able to validate this answer, is MUST 387 treat the mDNS advertisement for this domain as valid, since 388 otherwise the presence of the locally served domain would prevent 389 discovery in mDNS-advertised subdomains even though there is no 390 conflict. 392 There are three types of browsing domains that might exist in the set 393 of browsing domains maintained by the DNSSD browser. 395 * Link-Local: one for each network link to which the DNSSD browser 396 is directly connected 398 * Infrastructure: browsing domains provided by the infrastructure 400 * Permissionless: browsing domains discovered using mDNS on local 401 links 403 [RFC6763] and [DNS Push] already describe how to manage link-local 404 and infrastructure browsing domains. Permissionless browsing domains 405 are managed similarly. Each such domain will have one or more name 406 servers. Each name server will, or will not, provide DNS Push 407 service. If one or more servers provide DNS Push service, then the 408 DNSSD browser will, when browsing, attempt to connect to one of the 409 DNS Push servers for that browsing domain, until a successful 410 connection is established or failure is detected. If failure is 411 detected, or if there are no DNS Push servers, the DNSSD browser will 412 use DNS datagrams [RFC1034] to browse that domain. 414 6. Security Considerations 416 Multicast DNS provides no mechanism for trust establishment other 417 than the common connection to a shared link. DNSSD browsers are 418 required to treat information about local authority datasets that are 419 advertised using mDNS skeptically. The requirement in section [???] 420 to validate 422 7. Informative References 424 Authors' Addresses 426 Ted Lemon 427 Apple Inc. 428 One Apple Park Way 429 Cupertino, California 95014 430 United States of America 432 Email: mellon@fugue.com 434 Joey Deng 435 Apple Inc. 436 One Apple Park Way 437 Cupertino, California 95014 438 United States of America 440 Email: deng.qiaoyu@gmail.com 442 Additional contact information: 444 邓乔宇 445 Apple Inc. 446 One Apple Park Way 447 Cupertino, California 95014 448 United States of America