idnits 2.17.1 draft-ietf-dnssd-hybrid-10.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 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 24, 2019) is 1860 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) == Outdated reference: A later version (-25) exists of draft-ietf-dnssd-push-19 == Outdated reference: A later version (-03) exists of draft-sekar-dns-ul-01 == Outdated reference: A later version (-06) exists of draft-sekar-dns-llq-03 == Outdated reference: A later version (-02) exists of draft-sctl-service-registration-00 == Outdated reference: A later version (-15) exists of draft-ietf-mboned-ieee802-mcast-problems-04 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Cheshire 3 Internet-Draft Apple Inc. 4 Intended status: Standards Track March 24, 2019 5 Expires: September 25, 2019 7 Discovery Proxy for Multicast DNS-Based Service Discovery 8 draft-ietf-dnssd-hybrid-10 10 Abstract 12 This document specifies a network proxy that uses Multicast DNS to 13 automatically populate the wide-area unicast Domain Name System 14 namespace with records describing devices and services found on the 15 local link. 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 http://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 September 25, 2019. 34 Copyright Notice 36 Copyright (c) 2019 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 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Operational Analogy . . . . . . . . . . . . . . . . . . . . . 6 53 3. Conventions and Terminology Used in this Document . . . . . . 7 54 4. Compatibility Considerations . . . . . . . . . . . . . . . . 7 55 5. Discovery Proxy Operation . . . . . . . . . . . . . . . . . . 8 56 5.1. Delegated Subdomain for Service Discovery Records . . . . 9 57 5.2. Domain Enumeration . . . . . . . . . . . . . . . . . . . 11 58 5.2.1. Domain Enumeration via Unicast Queries . . . . . . . 11 59 5.2.2. Domain Enumeration via Multicast Queries . . . . . . 13 60 5.3. Delegated Subdomain for LDH Host Names . . . . . . . . . 14 61 5.4. Delegated Subdomain for Reverse Mapping . . . . . . . . . 16 62 5.5. Data Translation . . . . . . . . . . . . . . . . . . . . 18 63 5.5.1. DNS TTL limiting . . . . . . . . . . . . . . . . . . 18 64 5.5.2. Suppressing Unusable Records . . . . . . . . . . . . 19 65 5.5.3. NSEC and NSEC3 queries . . . . . . . . . . . . . . . 20 66 5.5.4. No Text Encoding Translation . . . . . . . . . . . . 20 67 5.5.5. Application-Specific Data Translation . . . . . . . . 21 68 5.6. Answer Aggregation . . . . . . . . . . . . . . . . . . . 23 69 6. Administrative DNS Records . . . . . . . . . . . . . . . . . 27 70 6.1. DNS SOA (Start of Authority) Record . . . . . . . . . . . 27 71 6.2. DNS NS Records . . . . . . . . . . . . . . . . . . . . . 28 72 6.3. DNS Delegation Records . . . . . . . . . . . . . . . . . 28 73 6.4. DNS SRV Records . . . . . . . . . . . . . . . . . . . . . 29 74 7. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 30 75 7.1. On-line signing only . . . . . . . . . . . . . . . . . . 30 76 7.2. NSEC and NSEC3 Records . . . . . . . . . . . . . . . . . 30 77 8. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 31 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 79 9.1. Authenticity . . . . . . . . . . . . . . . . . . . . . . 32 80 9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 32 81 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 32 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 83 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 85 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 86 12.2. Informative References . . . . . . . . . . . . . . . . . 35 87 Appendix A. Implementation Status . . . . . . . . . . . . . . . 38 88 A.1. Already Implemented and Deployed . . . . . . . . . . . . 38 89 A.2. Already Implemented . . . . . . . . . . . . . . . . . . . 38 90 A.3. Partially Implemented . . . . . . . . . . . . . . . . . . 39 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39 93 1. Introduction 95 Multicast DNS [RFC6762] and its companion technology DNS-based 96 Service Discovery [RFC6763] were created to provide IP networking 97 with the ease-of-use and autoconfiguration for which AppleTalk was 98 well known [RFC6760] [ZC] [Roadmap]. 100 For a small home network consisting of just a single link (or a few 101 physical links bridged together to appear as a single logical link 102 from the point of view of IP) Multicast DNS [RFC6762] is sufficient 103 for client devices to look up the ".local" host names of peers on the 104 same home network, and to use Multicast DNS-Based Service Discovery 105 (DNS-SD) [RFC6763] to discover services offered on that home network. 107 For a larger network consisting of multiple links that are 108 interconnected using IP-layer routing instead of link-layer bridging, 109 link-local Multicast DNS alone is insufficient because link-local 110 Multicast DNS packets, by design, are not propagated onto other 111 links. 113 Using link-local multicast packets for Multicast DNS was a conscious 114 design choice [RFC6762]. Even when limited to a single link, 115 multicast traffic is still generally considered to be more expensive 116 than unicast, because multicast traffic impacts many devices, instead 117 of just a single recipient. In addition, with some technologies like 118 Wi-Fi [IEEE-11], multicast traffic is inherently less efficient and 119 less reliable than unicast, because Wi-Fi multicast traffic is sent 120 at lower data rates, and is not acknowledged [Mcast]. Increasing the 121 amount of expensive multicast traffic by flooding it across multiple 122 links would make the traffic load even worse. 124 Partitioning the network into many small links curtails the spread of 125 expensive multicast traffic, but limits the discoverability of 126 services. At the opposite end of the spectrum, using a very large 127 local link with thousands of hosts enables better service discovery, 128 but at the cost of larger amounts of multicast traffic. 130 Performing DNS-Based Service Discovery using purely Unicast DNS is 131 more efficient and doesn't require large multicast domains, but does 132 require that the relevant data be available in the Unicast DNS 133 namespace. The Unicast DNS namespace in question could fall within a 134 traditionally assigned globally unique domain name, or could use a 135 private local unicast domain name such as ".home.arpa" [RFC8375]. 137 In the DNS-SD specification [RFC6763], Section 10 ("Populating the 138 DNS with Information") discusses various possible ways that a 139 service's PTR, SRV, TXT and address records can make their way into 140 the Unicast DNS namespace, including manual zone file configuration 142 [RFC1034] [RFC1035], DNS Update [RFC2136] [RFC3007] and proxies of 143 various kinds. 145 Making the relevant data available in the Unicast DNS namespace by 146 manual DNS configuration is one option. This option has been used 147 for many years at IETF meetings to advertise the IETF Terminal Room 148 printer. Details of this example are given in Appendix A of the 149 Roadmap document [Roadmap]. However, this manual DNS configuration 150 is labor intensive, error prone, and requires a reasonable degree of 151 DNS expertise. 153 Populating the Unicast DNS namespace via DNS Update by the devices 154 offering the services themselves is another option [RegProt] 155 [DNS-UL]. However, this requires configuration of DNS Update keys on 156 those devices, which has proven onerous and impractical for simple 157 devices like printers and network cameras. 159 Hence, to facilitate efficient and reliable DNS-Based Service 160 Discovery, a compromise is needed that combines the ease-of-use of 161 Multicast DNS with the efficiency and scalability of Unicast DNS. 163 This document specifies a type of proxy called a "Discovery Proxy" 164 that uses Multicast DNS [RFC6762] to discover Multicast DNS records 165 on its local link, and makes corresponding DNS records visible in the 166 Unicast DNS namespace. 168 In principle, similar mechanisms could be defined using other local 169 service discovery protocols, to discover local information and then 170 make corresponding DNS records visible in the Unicast DNS namespace. 171 Such mechanisms for other local service discovery protocols could be 172 addressed in future documents. 174 The design of the Discovery Proxy is guided by the previously 175 published requirements document [RFC7558]. 177 In simple terms, a descriptive DNS name is chosen for each link in an 178 organization. Using a DNS NS record, responsibility for that DNS 179 name is delegated to a Discovery Proxy physically attached to that 180 link. Now, when a remote client issues a unicast query for a name 181 falling within the delegated subdomain, the normal DNS delegation 182 mechanism results in the unicast query arriving at the Discovery 183 Proxy, since it has been declared authoritative for those names. 184 Now, instead of consulting a textual zone file on disk to discover 185 the answer to the query, as a traditional DNS server would, a 186 Discovery Proxy consults its local link, using Multicast DNS, to find 187 the answer to the question. 189 For fault tolerance reasons there may be more than one Discovery 190 Proxy serving a given link. 192 Note that the Discovery Proxy uses a "pull" model. The local link is 193 not queried using Multicast DNS until some remote client has 194 requested that data. In the idle state, in the absence of client 195 requests, the Discovery Proxy sends no packets and imposes no burden 196 on the network. It operates purely "on demand". 198 An alternative proposal that has been discussed is a proxy that 199 performs DNS updates to a remote DNS server on behalf of the 200 Multicast DNS devices on the local network. The difficulty with this 201 is is that Multicast DNS devices do not routinely announce their 202 records on the network. Generally they remain silent until queried. 203 This means that the complete set of Multicast DNS records in use on a 204 link can only be discovered by active querying, not by passive 205 listening. Because of this, a proxy can only know what names exist 206 on a link by issuing queries for them, and since it would be 207 impractical to issue queries for every possible name just to find out 208 which names exist and which do not, there is no reasonable way for a 209 proxy to programmatically learn all the answers it would need to push 210 up to the remote DNS server using DNS Update. Even if such a 211 mechanism were possible, it would risk generating high load on the 212 network continuously, even when there are no clients with any 213 interest in that data. 215 Hence, having a model where the query comes to the Discovery Proxy is 216 much more efficient than a model where the Discovery Proxy pushes the 217 answers out to some other remote DNS server. 219 A client seeking to discover services and other information achieves 220 this by sending traditional DNS queries to the Discovery Proxy, or by 221 sending DNS Push Notification subscription requests [Push]. 223 How a client discovers what domain name(s) to use for its service 224 discovery queries, (and consequently what Discovery Proxy or Proxies 225 to use) is described in Section 5.2. 227 The diagram below illustrates a network topology using a Discovery 228 Proxy to provide discovery service to a remote client. 230 +--------+ Unicast +-----------+ +---------+ +---------+ 231 | Remote | Communcation | Discovery | | Network | | Network | 232 | Client |---- . . . -----| Proxy | | Printer | | Camera | 233 +--------+ +-----------+ +---------+ +---------+ 234 | | | 235 -------------------------------------------- 236 Multicast-capable LAN segment (e.g., Ethernet) 238 2. Operational Analogy 240 A Discovery Proxy does not operate as a multicast relay, or multicast 241 forwarder. There is no danger of multicast forwarding loops that 242 result in traffic storms, because no multicast packets are forwarded. 243 A Discovery Proxy operates as a *proxy* for a remote client, 244 performing queries on its behalf and reporting the results back. 246 A reasonable analogy is making a telephone call to a colleague at 247 your workplace and saying, "I'm out of the office right now. Would 248 you mind bringing up a printer browser window and telling me the 249 names of the printers you see?" That entails no risk of a forwarding 250 loop causing a traffic storm, because no multicast packets are sent 251 over the telephone call. 253 A similar analogy, instead of enlisting another human being to 254 initiate the service discovery operation on your behalf, is to log 255 into your own desktop work computer using screen sharing, and then 256 run the printer browser yourself to see the list of printers. Or log 257 in using ssh and type "dns-sd -B _ipp._tcp" and observe the list of 258 discovered printer names. In neither case is there any risk of a 259 forwarding loop causing a traffic storm, because no multicast packets 260 are being sent over the screen sharing or ssh connection. 262 The Discovery Proxy provides another way of performing remote 263 queries, except using a different protocol instead of screen sharing 264 or ssh. 266 When the Discovery Proxy software performs Multicast DNS operations, 267 the exact same Multicast DNS caching mechanisms are applied as when 268 any other client software on that Discovery Proxy device performs 269 Multicast DNS operations, whether that be running a printer browser 270 client locally, or a remote user running the printer browser client 271 via a screen sharing connection, or a remote user logged in via ssh 272 running a command-line tool like "dns-sd", or a remote user sending 273 DNS requests that cause a Discovery Proxy to perform discovery 274 operations on its behalf. 276 3. Conventions and Terminology Used in this Document 278 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 279 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 280 and "OPTIONAL" in this document are to be interpreted as described 281 in "Key words for use in RFCs to Indicate Requirement Levels", 282 when, and only when, they appear in all capitals, as shown here 283 [RFC2119] [RFC8174]. 285 The Discovery Proxy builds on Multicast DNS, which works between 286 hosts on the same link. For the purposes of this document a set of 287 hosts is considered to be "on the same link" if: 289 o when any host from that set sends a packet to any other host in 290 that set, using unicast, multicast, or broadcast, the entire link- 291 layer packet payload arrives unmodified, and 293 o a broadcast sent over that link, by any host from that set of 294 hosts, can be received by every other host in that set. 296 The link-layer *header* may be modified, such as in Token Ring Source 297 Routing [IEEE-5], but not the link-layer *payload*. In particular, 298 if any device forwarding a packet modifies any part of the IP header 299 or IP payload then the packet is no longer considered to be on the 300 same link. This means that the packet may pass through devices such 301 as repeaters, bridges, hubs or switches and still be considered to be 302 on the same link for the purpose of this document, but not through a 303 device such as an IP router that decrements the IP TTL or otherwise 304 modifies the IP header. 306 4. Compatibility Considerations 308 No changes to existing devices are required to work with a Discovery 309 Proxy. 311 Existing devices that advertise services using Multicast DNS work 312 with Discovery Proxy. 314 Existing clients that support DNS-Based Service Discovery over 315 Unicast DNS work with Discovery Proxy. Service Discovery over 316 Unicast DNS was introduced in Mac OS X 10.4 in April 2005, as is 317 included in Apple products introduced since then, including iPhone 318 and iPad, as well as products from other vendors, such as Microsoft 319 Windows 10. 321 An overview of the larger collection of related Service Discovery 322 technologies, and how Discovery Proxy relates to those, is given in 323 the Service Discovery Road Map document [Roadmap]. 325 5. Discovery Proxy Operation 327 In a typical configuration, a Discovery Proxy is configured to be 328 authoritative [RFC1034] [RFC1035] for four or more DNS subdomains, 329 and authority for these subdomains is delegated to it via NS records: 331 A DNS subdomain for service discovery records. 332 This subdomain name may contain rich text, including spaces and 333 other punctuation. This is because this subdomain name is used 334 only in graphical user interfaces, where rich text is appropriate. 336 A DNS subdomain for host name records. 337 This subdomain name SHOULD be limited to letters, digits and 338 hyphens, to facilitate convenient use of host names in command- 339 line interfaces. 341 One or more DNS subdomains for IPv4 Reverse Mapping records. 342 These subdomains will have names that ends in "in-addr.arpa." 344 One or more DNS subdomains for IPv6 Reverse Mapping records. 345 These subdomains will have names that ends in "ip6.arpa." 347 In an enterprise network the naming and delegation of these 348 subdomains is typically performed by conscious action of the network 349 administrator. In a home network naming and delegation would 350 typically be performed using some automatic configuration mechanism 351 such as HNCP [RFC7788]. 353 These three varieties of delegated subdomains (service discovery, 354 host names, and reverse mapping) are described below in Section 5.1, 355 Section 5.3 and Section 5.4. 357 How a client discovers where to issue its service discovery queries 358 is described below in Section 5.2. 360 5.1. Delegated Subdomain for Service Discovery Records 362 In its simplest form, each link in an organization is assigned a 363 unique Unicast DNS domain name, such as "Building 1.example.com" or 364 "2nd Floor.Building 3.example.com". Grouping multiple links under a 365 single Unicast DNS domain name is to be specified in a future 366 companion document, but for the purposes of this document, assume 367 that each link has its own unique Unicast DNS domain name. In a 368 graphical user interface these names are not displayed as strings 369 with dots as shown above, but something more akin to a typical file 370 browser graphical user interface (which is harder to illustrate in a 371 text-only document) showing folders, subfolders and files in a file 372 system. 374 +---------------+--------------+-------------+-------------------+ 375 | *example.com* | Building 1 | 1st Floor | Alice's printer | 376 | | Building 2 | *2nd Floor* | Bob's printer | 377 | | *Building 3* | 3rd Floor | Charlie's printer | 378 | | Building 4 | 4th Floor | | 379 | | Building 5 | | | 380 | | Building 6 | | | 381 +---------------+--------------+-------------+-------------------+ 383 Figure 1: Illustrative GUI 385 Each named link in an organization has one or more Discovery Proxies 386 which serve it. This Discovery Proxy function for each link could be 387 performed by a device like a router or switch that is physically 388 attached to that link. In the parent domain, NS records are used to 389 delegate ownership of each defined link name 390 (e.g., "Building 1.example.com") to the one or more Discovery Proxies 391 that serve the named link. In other words, the Discovery Proxies are 392 the authoritative name servers for that subdomain. As in the rest of 393 DNS-Based Service Discovery, all names are represented as-is using 394 plain UTF-8 encoding, and, as described in Section 5.5.4, no text 395 encoding translations are performed. 397 With appropriate VLAN configuration [IEEE-1Q] a single Discovery 398 Proxy device could have a logical presence on many links, and serve 399 as the Discovery Proxy for all those links. In such a configuration 400 the Discovery Proxy device would have a single physical Ethernet 401 [IEEE-3] port, configured as a VLAN trunk port, which would appear to 402 software on that device as multiple virtual Ethernet interfaces, one 403 connected to each of the VLAN links. 405 As an alternative to using VLAN technology, using a Multicast DNS 406 Discovery Relay [Relay] is another way that a Discovery Proxy can 407 have a 'virtual' presence on a remote link. 409 When a DNS-SD client issues a Unicast DNS query to discover services 410 in a particular Unicast DNS subdomain 411 (e.g., "_printer._tcp.Building 1.example.com. PTR ?") the normal DNS 412 delegation mechanism results in that query being forwarded until it 413 reaches the delegated authoritative name server for that subdomain, 414 namely the Discovery Proxy on the link in question. Like a 415 conventional Unicast DNS server, a Discovery Proxy implements the 416 usual Unicast DNS protocol [RFC1034] [RFC1035] over UDP and TCP. 417 However, unlike a conventional Unicast DNS server that generates 418 answers from the data in its manually-configured zone file, a 419 Discovery Proxy generates answers using Multicast DNS. A Discovery 420 Proxy does this by consulting its Multicast DNS cache and/or issuing 421 Multicast DNS queries, as appropriate, according to the usual 422 protocol rules of Multicast DNS [RFC6762], for the corresponding 423 Multicast DNS name, type and class, with the delegated zone part of 424 the name replaced with ".local" (e.g., in this case, 425 "_printer._tcp.local. PTR ?"). Then, from the received Multicast DNS 426 data, the Discovery Proxy synthesizes the appropriate Unicast DNS 427 response, with the ".local" top-level label replaced with with the 428 name of the delegated zone. How long the Discovery Proxy should wait 429 to accumulate Multicast DNS responses before sending its unicast 430 reply is described below in Section 5.6. 432 The existing Multicast DNS caching mechanism is used to minimize 433 unnecessary Multicast DNS queries on the wire. The Discovery Proxy 434 is acting as a client of the underlying Multicast DNS subsystem, and 435 benefits from the same caching and efficiency measures as any other 436 client using that subsystem. 438 Note that the contents of the delegated zone, generated as it is by 439 performing ".local" Multicast DNS queries, mirrors the records 440 available on the local link via Multicast DNS very closely, but not 441 precisely. There is not a full bidirectional equivalence between the 442 two. Certain records that are available via Multicast DNS may not 443 have equivalents in the delegated zone, possibly because they are 444 invalid or not relevant in the delegated zone, or because they are 445 being supressed because they are unusable outside the local link (see 446 Section 5.5.2). Conversely, certain records that appear in the 447 delegated zone may not have corresponding records available on the 448 local link via Multicast DNS. In particular there are certain 449 administrative SRV records (see Section 6) that logically fall within 450 the delegated zone, but semantically represent metadata *about* the 451 zone rather than records *within* the zone, and consequently these 452 administrative records in the delegated zone do not have any 453 corresponding counterparts in the Multicast DNS namespace of the 454 local link. 456 5.2. Domain Enumeration 458 A DNS-SD client performs Domain Enumeration [RFC6763] via certain PTR 459 queries, using both unicast and multicast. If it receives a Domain 460 Name configuration via DHCP option 15 [RFC2132], then it issues 461 unicast queries using this domain. It issues unicast queries using 462 names derived from its IPv4 subnet address(es) and IPv6 prefix(es). 463 These are described below in Section 5.2.1. It also issues multicast 464 Domain Enumeration queries in the "local" domain [RFC6762]. These 465 are described below in Section 5.2.2. The results of all the Domain 466 Enumeration queries are combined for Service Discovery purposes. 468 5.2.1. Domain Enumeration via Unicast Queries 470 The administrator creates Domain Enumeration PTR records [RFC6763] to 471 inform clients of available service discovery domains. Two varieties 472 of such Domain Enumeration PTR records exist; those with names 473 derived from the domain name communicated to the clients via DHCP, 474 and those with names derived from IPv4 subnet address(es) and IPv6 475 prefix(es) in use by the clients. Below is an example showing the 476 name-based variety: 478 b._dns-sd._udp.example.com. PTR Building 1.example.com. 479 PTR Building 2.example.com. 480 PTR Building 3.example.com. 481 PTR Building 4.example.com. 483 db._dns-sd._udp.example.com. PTR Building 1.example.com. 485 lb._dns-sd._udp.example.com. PTR Building 1.example.com. 487 The meaning of these records is defined in the DNS Service Discovery 488 specification [RFC6763] but for convenience is repeated here. The 489 "b" ("browse") records tell the client device the list of browsing 490 domains to display for the user to select from. The "db" ("default 491 browse") record tells the client device which domain in that list 492 should be selected by default. The "db" domain MUST be one of the 493 domains in the "b" list; if not then no domain is selected by 494 default. The "lb" ("legacy browse") record tells the client device 495 which domain to automatically browse on behalf of applications that 496 don't implement UI for multi-domain browsing (which is most of them, 497 at the time of writing). The "lb" domain is often the same as the 498 "db" domain, or sometimes the "db" domain plus one or more others 499 that should be included in the list of automatic browsing domains for 500 legacy clients. 502 Note that in the example above, for clarity, space characters in 503 names are shown as actual spaces. If this data is manually entered 504 into a textual zone file for authoritative server software such as 505 BIND, care must be taken because the space character is used as a 506 field separator, and other characters like dot ('.'), semicolon 507 (';'), dollar ('$'), backslash ('\'), etc., also have special 508 meaning. These characters have to be escaped when entered into a 509 textual zone file, following the rules in Section 5.1 of the DNS 510 specification [RFC1035]. For example, a literal space in a name is 511 represented in the textual zone file using '\032', so "Building 512 1.example.com." is entered as "Building\0321.example.com." 514 DNS responses are limited to a maximum size of 65535 bytes. This 515 limits the maximum number of domains that can be returned for a 516 Domain Enumeration query, as follows: 518 A DNS response header is 12 bytes. That's typically followed by a 519 single qname (up to 256 bytes) plus qtype (2 bytes) and qclass 520 (2 bytes), leaving 65275 for the Answer Section. 522 An Answer Section Resource Record consists of: 524 o Owner name, encoded as a two-byte compression pointer 525 o Two-byte rrtype (type PTR) 526 o Two-byte rrclass (class IN) 527 o Four-byte ttl 528 o Two-byte rdlength 529 o rdata (domain name, up to 256 bytes) 531 This means that each Resource Record in the Answer Section can take 532 up to 268 bytes total, which means that the Answer Section can 533 contain, in the worst case, no more than 243 domains. 535 In a more typical scenario, where the domain names are not all 536 maximum-sized names, and there is some similarity between names so 537 that reasonable name compression is possible, each Answer 538 Section Resource Record may average 140 bytes, which means that the 539 Answer Section can contain up to 466 domains. 541 It is anticipated that this should be sufficient for even a large 542 corporate network or university campus. 544 5.2.2. Domain Enumeration via Multicast Queries 546 In the case where Discovery Proxy functionality is widely deployed 547 within an enterprise (either by having a Discovery Proxy on each 548 link, or by having a Discovery Proxy with a remote 'virtual' presence 549 on each link using VLANs or Multicast DNS Discovery Relays [Relay]) 550 this offers an additional way to provide Domain Enumeration data for 551 clients. 553 A Discovery Proxy can be configured to generate Multicast DNS 554 responses for the following Multicast DNS Domain Enumeration queries 555 issued by clients: 557 b._dns-sd._udp.local. PTR ? 558 db._dns-sd._udp.local. PTR ? 559 lb._dns-sd._udp.local. PTR ? 561 This provides the ability for Discovery Proxies to indicate 562 recommended browsing domains to DNS-SD clients on a per-link 563 granularity. In some enterprises it may be preferable to provide 564 this per-link configuration data in the form of Discovery Proxy 565 configuration, rather than populating the Unicast DNS servers with 566 the same data (in the "ip6.arpa" or "in-addr.arpa" domains). 568 Regardless of how the network operator chooses to provide this 569 configuration data, clients will perform Domain Enumeration via both 570 unicast and multicast queries, and then combine the results of these 571 queries. 573 5.3. Delegated Subdomain for LDH Host Names 575 DNS-SD service instance names and domains are allowed to contain 576 arbitrary Net-Unicode text [RFC5198], encoded as precomposed UTF-8 577 [RFC3629]. 579 Users typically interact with service discovery software by viewing a 580 list of discovered service instance names on a display, and selecting 581 one of them by pointing, touching, or clicking. Similarly, in 582 software that provides a multi-domain DNS-SD user interface, users 583 view a list of offered domains on the display and select one of them 584 by pointing, touching, or clicking. To use a service, users don't 585 have to remember domain or instance names, or type them; users just 586 have to be able to recognize what they see on the display and touch 587 or click on the thing they want. 589 In contrast, host names are often remembered and typed. Also, host 590 names have historically been used in command-line interfaces where 591 spaces can be inconvenient. For this reason, host names have 592 traditionally been restricted to letters, digits and hyphens (LDH), 593 with no spaces or other punctuation. 595 While we do want to allow rich text for DNS-SD service instance names 596 and domains, it is advisable, for maximum compatibility with existing 597 usage, to restrict host names to the traditional letter-digit-hyphen 598 rules. This means that while a service name 599 "My Printer._ipp._tcp.Building 1.example.com" is acceptable and 600 desirable (it is displayed in a graphical user interface as an 601 instance called "My Printer" in the domain "Building 1" at 602 "example.com"), a host name "My-Printer.Building 1.example.com" is 603 less desirable (because of the space in "Building 1"). 605 To accomodate this difference in allowable characters, a Discovery 606 Proxy SHOULD support having two separate subdomains delegated to it 607 for each link it serves, one whose name is allowed to contain 608 arbitrary Net-Unicode text [RFC5198], and a second more constrained 609 subdomain whose name is restricted to contain only letters, digits, 610 and hyphens, to be used for host name records (names of 'A' and 611 'AAAA' address records). The restricted names may be any valid name 612 consisting of only letters, digits, and hyphens, including Punycode- 613 encoded names [RFC3492]. 615 For example, a Discovery Proxy could have the two subdomains 616 "Building 1.example.com" and "bldg1.example.com" delegated to it. 617 The Discovery Proxy would then translate these two Multicast DNS 618 records: 620 My Printer._ipp._tcp.local. SRV 0 0 631 prnt.local. 621 prnt.local. A 203.0.113.2 623 into Unicast DNS records as follows: 625 My Printer._ipp._tcp.Building 1.example.com. 626 SRV 0 0 631 prnt.bldg1.example.com. 627 prnt.bldg1.example.com. A 203.0.113.2 629 Note that the SRV record name is translated using the rich-text 630 domain name ("Building 1.example.com") and the address record name is 631 translated using the LDH domain ("bldg1.example.com"). 633 A Discovery Proxy MAY support only a single rich text Net-Unicode 634 domain, and use that domain for all records, including 'A' and 'AAAA' 635 address records, but implementers choosing this option should be 636 aware that this choice may produce host names that are awkward to use 637 in command-line environments. Whether this is an issue depends on 638 whether users in the target environment are expected to be using 639 command-line interfaces. 641 A Discovery Proxy MUST NOT be restricted to support only a letter- 642 digit-hyphen subdomain, because that results in an unnecessarily poor 643 user experience. 645 As described above in Section 5.2.1, for clarity, space characters in 646 names are shown as actual spaces. If this data were to be manually 647 entered into a textual zone file (which it isn't) then spaces would 648 need to be represented using '\032', so 649 "My Printer._ipp._tcp.Building 1.example.com." would become 650 "My\032Printer._ipp._tcp.Building\0321.example.com." 651 Note that the '\032' representation does not appear in the network 652 packets sent over the air. In the wire format of DNS messages, 653 spaces are sent as spaces, not as '\032', and likewise, in a 654 graphical user interface at the client device, spaces are shown as 655 spaces, not as '\032'. 657 5.4. Delegated Subdomain for Reverse Mapping 659 A Discovery Proxy can facilitate easier management of reverse mapping 660 domains, particularly for IPv6 addresses where manual management may 661 be more onerous than it is for IPv4 addresses. 663 To achieve this, in the parent domain, NS records are used to 664 delegate ownership of the appropriate reverse mapping domain to the 665 Discovery Proxy. In other words, the Discovery Proxy becomes the 666 authoritative name server for the reverse mapping domain. For fault 667 tolerance reasons there may be more than one Discovery Proxy serving 668 a given link. 670 If a given link is using the IPv4 subnet 203.0.113/24, 671 then the domain "113.0.203.in-addr.arpa" 672 is delegated to the Discovery Proxy for that link. 674 For example, if a given link is using the 675 IPv6 prefix 2001:0DB8:1234:5678/64, 676 then the domain "8.7.6.5.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa" 677 is delegated to the Discovery Proxy for that link. 679 When a reverse mapping query arrives at the Discovery Proxy, it 680 issues the identical query on its local link as a Multicast DNS 681 query. The mechanism to force an apparently unicast name to be 682 resolved using link-local Multicast DNS varies depending on the API 683 set being used. For example, in the "dns_sd.h" APIs 684 (available on macOS, iOS, Bonjour for Windows, Linux and Android), 685 using kDNSServiceFlagsForceMulticast indicates that the 686 DNSServiceQueryRecord() call should perform the query using Multicast 687 DNS. Other APIs sets have different ways of forcing multicast 688 queries. When the host owning that IPv4 or IPv6 address responds 689 with a name of the form "something.local", the Discovery Proxy 690 rewrites that to use its configured LDH host name domain instead of 691 "local", and returns the response to the caller. 693 For example, a Discovery Proxy with the two subdomains 694 "113.0.203.in-addr.arpa" and "bldg1.example.com" delegated to it 695 would translate this Multicast DNS record: 697 2.113.0.203.in-addr.arpa. PTR prnt.local. 699 into this Unicast DNS response: 701 2.113.0.203.in-addr.arpa. PTR prnt.bldg1.example.com. 703 Subsequent queries for the prnt.bldg1.example.com address record, 704 falling as it does within the bldg1.example.com domain, which is 705 delegated to the Discovery Proxy, will arrive at the Discovery Proxy, 706 where they are answered by issuing Multicast DNS queries and using 707 the received Multicast DNS answers to synthesize Unicast DNS 708 responses, as described above. 710 Note that this design assumes that all addresses on a given IPv4 711 subnet or IPv6 prefix are mapped to hostnames using the Discovery 712 Proxy mechanism. It would be possible to implement a Discovery Proxy 713 that can be configured so that some address-to-name mappings are 714 performed using Multicast DNS on the local link, while other address- 715 to-name mappings within the same IPv4 subnet or IPv6 prefix are 716 configured manually. 718 5.5. Data Translation 720 Generating the appropriate Multicast DNS queries involves, 721 at the very least, translating from the configured DNS domain 722 (e.g., "Building 1.example.com") on the Unicast DNS side to "local" 723 on the Multicast DNS side. 725 Generating the appropriate Unicast DNS responses involves translating 726 back from "local" to the appropriate configured DNS Unicast domain. 728 Other beneficial translation and filtering operations are described 729 below. 731 5.5.1. DNS TTL limiting 733 For efficiency, Multicast DNS typically uses moderately high DNS TTL 734 values. For example, the typical TTL on DNS-SD PTR records is 75 735 minutes. What makes these moderately high TTLs acceptable is the 736 cache coherency mechanisms built in to the Multicast DNS protocol 737 which protect against stale data persisting for too long. When a 738 service shuts down gracefully, it sends goodbye packets to remove its 739 PTR records immediately from neighboring caches. If a service shuts 740 down abruptly without sending goodbye packets, the Passive 741 Observation Of Failures (POOF) mechanism described in Section 10.5 of 742 the Multicast DNS specification [RFC6762] comes into play to purge 743 the cache of stale data. 745 A traditional Unicast DNS client on a distant remote link does not 746 get to participate in these Multicast DNS cache coherency mechanisms 747 on the local link. For traditional Unicast DNS queries (those 748 received without using Long-Lived Query [LLQ] or DNS Push 749 Notification subscriptions [Push]) the DNS TTLs reported in the 750 resulting Unicast DNS response MUST be capped to be no more than ten 751 seconds. 753 Similarly, for negative responses, the negative caching TTL indicated 754 in the SOA record [RFC2308] should also be ten seconds (Section 6.1). 756 This value of ten seconds is chosen based on user-experience 757 considerations. 759 For negative caching, suppose a user is attempting to access a remote 760 device (e.g., a printer), and they are unsuccessful because that 761 device is powered off. Suppose they then place a telephone call and 762 ask for the device to be powered on. We want the device to become 763 available to the user within a reasonable time period. It is 764 reasonable to expect it to take on the order of ten seconds for a 765 simple device with a simple embedded operating system to power on. 767 Once the device is powered on and has announced its presence on the 768 network via Multicast DNS, we would like it to take no more than a 769 further ten seconds for stale negative cache entries to expire from 770 Unicast DNS caches, making the device available to the user desiring 771 to access it. 773 Similar reasoning applies to capping positive TTLs at ten seconds. 774 In the event of a device moving location, getting a new DHCP address, 775 or other renumbering events, we would like the updated information to 776 be available to remote clients in a relatively timely fashion. 778 However, network administrators should be aware that many recursive 779 (caching) DNS servers by default are configured to impose a minimum 780 TTL of 30 seconds. If stale data appears to be persisting in the 781 network to the extent that it adversely impacts user experience, 782 network administrators are advised to check the configuration of 783 their recursive DNS servers. 785 For received Unicast DNS queries that use LLQ [LLQ] or DNS Push 786 Notifications [Push], the Multicast DNS record's TTL SHOULD be 787 returned unmodified, because the Push Notification channel exists to 788 inform the remote client as records come and go. For further details 789 about Long-Lived Queries, and its newer replacement, DNS Push 790 Notifications, see Section 5.6. 792 5.5.2. Suppressing Unusable Records 794 A Discovery Proxy SHOULD offer a configurable option, enabled by 795 default, to suppress Unicast DNS answers for records that are not 796 useful outside the local link. When the option to suppress unusable 797 records is enabled: 799 o DNS A and AAAA records for IPv4 link-local addresses [RFC3927] and 800 IPv6 link-local addresses [RFC4862] SHOULD be suppressed. 802 o Similarly, for sites that have multiple private address realms 803 [RFC1918], in cases where the Discovery Proxy can determine that 804 the querying client is in a different address realm, private 805 addresses SHOULD NOT be communicated to that client. 807 o IPv6 Unique Local Addresses [RFC4193] SHOULD be suppressed in 808 cases where the Discovery Proxy can determine that the querying 809 client is in a different IPv6 address realm. 811 o By the same logic, DNS SRV records that reference target host 812 names that have no addresses usable by the requester should be 813 suppressed, and likewise, DNS PTR records that point to unusable 814 SRV records should be similarly be suppressed. 816 5.5.3. NSEC and NSEC3 queries 818 Multicast DNS devices do not routinely announce their records on the 819 network. Generally they remain silent until queried. This means 820 that the complete set of Multicast DNS records in use on a link can 821 only be discovered by active querying, not by passive listening. 822 Because of this, a Discovery Proxy can only know what names exist on 823 a link by issuing queries for them, and since it would be impractical 824 to issue queries for every possible name just to find out which names 825 exist and which do not, a Discovery Proxy cannot programmatically 826 generate the traditional NSEC [RFC4034] and NSEC3 [RFC5155] records 827 which assert the nonexistence of a large range of names. 829 When queried for an NSEC or NSEC3 record type, the Discovery Proxy 830 issues a qtype "ANY" query using Multicast DNS on the local link, and 831 then generates an NSEC or NSEC3 response with a Type Bit Map 832 signifying which record types do and do not exist for just the 833 specific name queried, and no other names. 835 Multicast DNS NSEC records received on the local link MUST NOT be 836 forwarded unmodified to a unicast querier, because there are slight 837 differences in the NSEC record data. In particular, Multicast DNS 838 NSEC records do not have the NSEC bit set in the Type Bit Map, 839 whereas conventional Unicast DNS NSEC records do have the NSEC bit 840 set. 842 5.5.4. No Text Encoding Translation 844 A Discovery Proxy does no translation between text encodings. 845 Specifically, a Discovery Proxy does no translation between Punycode 846 encoding [RFC3492] and UTF-8 encoding [RFC3629], either in the owner 847 name of DNS records, or anywhere in the RDATA of DNS records (such as 848 the RDATA of PTR records, SRV records, NS records, or other record 849 types like TXT, where it is ambiguous whether the RDATA may contain 850 DNS names). All bytes are treated as-is, with no attempt at text 851 encoding translation. A client implementing DNS-based Service 852 Discovery [RFC6763] will use UTF-8 encoding for its service discovery 853 queries, which the Discovery Proxy passes through without any text 854 encoding translation to the Multicast DNS subsystem. Responses from 855 the Multicast DNS subsystem are similarly returned, without any text 856 encoding translation, back to the requesting client. 858 5.5.5. Application-Specific Data Translation 860 There may be cases where Application-Specific Data Translation is 861 appropriate. 863 For example, AirPrint printers tend to advertise fairly verbose 864 information about their capabilities in their DNS-SD TXT record. TXT 865 record sizes in the range 500-1000 bytes are not uncommon. This 866 information is a legacy from LPR printing, because LPR does not have 867 in-band capability negotiation, so all of this information is 868 conveyed using the DNS-SD TXT record instead. IPP printing does have 869 in-band capability negotiation, but for convenience printers tend to 870 include the same capability information in their IPP DNS-SD TXT 871 records as well. For local mDNS use this extra TXT record 872 information is inefficient, but not fatal. However, when a Discovery 873 Proxy aggregates data from multiple printers on a link, and sends it 874 via unicast (via UDP or TCP) this amount of unnecessary TXT record 875 information can result in large responses. A DNS reply over TCP 876 carrying information about 70 printers with an average of 700 bytes 877 per printer adds up to about 50 kilobytes of data. Therefore, a 878 Discovery Proxy that is aware of the specifics of an application- 879 layer protocol such as AirPrint (which uses IPP) can elide 880 unnecessary key/value pairs from the DNS-SD TXT record for better 881 network efficiency. 883 Also, the DNS-SD TXT record for many printers contains an "adminurl" 884 key something like "adminurl=http://printername.local/status.html". 885 For this URL to be useful outside the local link, the embedded 886 ".local" hostname needs to be translated to an appropriate name with 887 larger scope. It is easy to translate ".local" names when they 888 appear in well-defined places, either as a record's name, or in the 889 rdata of record types like PTR and SRV. In the printing case, some 890 application-specific knowledge about the semantics of the "adminurl" 891 key is needed for the Discovery Proxy to know that it contains a name 892 that needs to be translated. This is somewhat analogous to the need 893 for NAT gateways to contain ALGs (Application-Specific Gateways) to 894 facilitate the correct translation of protocols that embed addresses 895 in unexpected places. 897 To avoid the need for application-specific knowledge about the 898 semantics of particular TXT record keys, protocol designers are 899 advised to avoid placing link-local names or link-local IP addresses 900 in TXT record keys, if translation of those names or addresses would 901 be required for off-link operation. In the printing case, the 902 operational failure of failing to translate the "adminurl" key 903 correctly is that, when accessed from a different link, printing will 904 still work, but clicking the "Admin" UI button will fail to open the 905 printer's administration page. Rather than duplicating the host name 906 from the service's SRV record in its "adminurl" key, thereby having 907 the same host name appear in two places, a better design might have 908 been to omit the host name from the "adminurl" key, and instead have 909 the client implicitly substitute the target host name from the 910 service's SRV record in place of a missing host name in the 911 "adminurl" key. That way the desired host name only appears once, 912 and it is in a well-defined place where software like the Discovery 913 Proxy is expecting to find it. 915 Note that this kind of Application-Specific Data Translation is 916 expected to be very rare. It is the exception, rather than the rule. 917 This is an example of a common theme in computing. It is frequently 918 the case that it is wise to start with a clean, layered design, with 919 clear boundaries. Then, in certain special cases, those layer 920 boundaries may be violated, where the performance and efficiency 921 benefits outweigh the inelegance of the layer violation. 923 These layer violations are optional. They are done primarily for 924 efficiency reasons, and generally should not be required for correct 925 operation. A Discovery Proxy MAY operate solely at the mDNS layer, 926 without any knowledge of semantics at the DNS-SD layer or above. 928 5.6. Answer Aggregation 930 In a simple analysis, simply gathering multicast answers and 931 forwarding them in a unicast response seems adequate, but it raises 932 the question of how long the Discovery Proxy should wait to be sure 933 that it has received all the Multicast DNS answers it needs to form a 934 complete Unicast DNS response. If it waits too little time, then it 935 risks its Unicast DNS response being incomplete. If it waits too 936 long, then it creates a poor user experience at the client end. In 937 fact, there may be no time which is both short enough to produce a 938 good user experience and at the same time long enough to reliably 939 produce complete results. 941 Similarly, the Discovery Proxy -- the authoritative name server for 942 the subdomain in question -- needs to decide what DNS TTL to report 943 for these records. If the TTL is too long then the recursive 944 (caching) name servers issuing queries on behalf of their clients 945 risk caching stale data for too long. If the TTL is too short then 946 the amount of network traffic will be more than necessary. In fact, 947 there may be no TTL which is both short enough to avoid undesirable 948 stale data and at the same time long enough to be efficient on the 949 network. 951 Both these dilemmas are solved by use of DNS Long-Lived Queries 952 (DNS LLQ) [LLQ] or its newer replacement, DNS Push Notifications 953 [Push]. 955 Clients supporting unicast DNS Service Discovery SHOULD implement DNS 956 Push Notifications [Push] for improved user experience. 958 Clients and Discovery Proxies MAY support both DNS LLQ and DNS Push, 959 and when talking to a Discovery Proxy that supports both, the client 960 may use either protocol, as it chooses, though it is expected that 961 only DNS Push will continue to be supported in the long run. 963 When a Discovery Proxy receives a query using DNS LLQ or DNS Push 964 Notifications, it responds immediately using the Multicast DNS 965 records it already has in its cache (if any). This provides a good 966 client user experience by providing a near-instantaneous response. 967 Simultaneously, the Discovery Proxy issues a Multicast DNS query on 968 the local link to discover if there are any additional Multicast DNS 969 records it did not already know about. Should additional Multicast 970 DNS responses be received, these are then delivered to the client 971 using additional DNS LLQ or DNS Push Notification update messages. 972 The timeliness of such update messages is limited only by the 973 timeliness of the device responding to the Multicast DNS query. If 974 the Multicast DNS device responds quickly, then the update message is 975 delivered quickly. If the Multicast DNS device responds slowly, then 976 the update message is delivered slowly. The benefit of using update 977 messages is that the Discovery Proxy can respond promptly because it 978 doesn't have to delay its unicast response to allow for the expected 979 worst-case delay for receiving all the Multicast DNS responses. Even 980 if a proxy were to try to provide reliability by assuming an 981 excessively pessimistic worst-case time (thereby giving a very poor 982 user experience) there would still be the risk of a slow Multicast 983 DNS device taking even longer than that (e.g., a device that is not 984 even powered on until ten seconds after the initial query is 985 received) resulting in incomplete responses. Using update message 986 solves this dilemma: even very late responses are not lost; they are 987 delivered in subsequent update messages. 989 There are two factors that determine specifically how responses are 990 generated: 992 The first factor is whether the query from the client used LLQ or DNS 993 Push Notifications (used for long-lived service browsing PTR queries) 994 or not (used for one-shot operations like SRV or address record 995 queries). Note that queries using LLQ or DNS Push Notifications are 996 received directly from the client. Queries not using LLQ or DNS Push 997 Notifications are generally received via the client's configured 998 recursive (caching) name server. 1000 The second factor is whether the Discovery Proxy already has at least 1001 one record in its cache that positively answers the question. 1003 o Not using LLQ or Push Notifications; no answer in cache: 1004 Issue an mDNS query, exactly as a local client would issue an mDNS 1005 query on the local link for the desired record name, type and 1006 class, including retransmissions, as appropriate, according to the 1007 established mDNS retransmission schedule [RFC6762]. As soon as 1008 any Multicast DNS response packet is received that contains one or 1009 more positive answers to that question (with or without the Cache 1010 Flush bit [RFC6762] set), or a negative answer (signified via a 1011 Multicast DNS NSEC record [RFC6762]), the Discovery Proxy 1012 generates a Unicast DNS response packet containing the 1013 corresponding (filtered and translated) answers and sends it to 1014 the remote client. If after six seconds no Multicast DNS answers 1015 have been received, cancel the mDNS query and return a negative 1016 response to the remote client. Six seconds is enough time to 1017 transmit three mDNS queries, and allow some time for responses to 1018 arrive. 1019 DNS TTLs in responses MUST be capped to at most ten seconds. 1020 (Reasoning: Queries not using LLQ or Push Notifications are 1021 generally queries that that expect an answer from only one device, 1022 so the first response is also the only response.) 1024 o Not using LLQ or Push Notifications; at least one answer in cache: 1025 Send response right away to minimise delay. 1026 DNS TTLs in responses MUST be capped to at most ten seconds. 1027 No local mDNS queries are performed. 1028 (Reasoning: Queries not using LLQ or Push Notifications are 1029 generally queries that that expect an answer from only one device. 1030 Given RRSet TTL harmonisation, if the proxy has one Multicast DNS 1031 answer in its cache, it can reasonably assume that it has all of 1032 them.) 1034 o Using LLQ or Push Notifications; no answer in cache: 1035 As in the case above with no answer in the cache, perform mDNS 1036 querying for six seconds, and send a response to the remote client 1037 as soon as any relevant mDNS response is received. 1038 If after six seconds no relevant mDNS response has been received, 1039 return negative response to the remote client (for LLQ; not 1040 applicable for Push Notifications). 1041 (Reasoning: We don't need to rush to send an empty answer.) 1042 Whether or not a relevant mDNS response is received within six 1043 seconds, the query remains active for as long as the client 1044 maintains the LLQ or Push Notification state, and if mDNS answers 1045 are received later, LLQ or Push Notification messages are sent. 1046 DNS TTLs in responses are returned unmodified. 1048 o Using LLQ or Push Notifications; at least one answer in cache: 1049 As in the case above with at least one answer in cache, send 1050 response right away to minimise delay. 1051 The query remains active for as long as the client maintains the 1052 LLQ or Push Notification state, and results in transmission of 1053 mDNS queries, with appropriate Known Answer lists, to determine if 1054 further answers are available. If additional mDNS answers are 1055 received later, LLQ or Push Notification messages are sent. 1056 (Reasoning: We want UI that is displayed very rapidly, yet 1057 continues to remain accurate even as the network environment 1058 changes.) 1059 DNS TTLs in responses are returned unmodified. 1061 The "negative responses" referred to above are "no error no answer" 1062 negative responses, not NXDOMAIN. This is because the Discovery 1063 Proxy cannot know all the Multicast DNS domain names that may exist 1064 on a link at any given time, so any name with no answers may have 1065 child names that do exist, making it an "empty nonterminal" name. 1067 Note that certain aspects of the behavior described here do not have 1068 to be implemented overtly by the Discovery Proxy; they occur 1069 naturally as a result of using existing Multicast DNS APIs. 1071 For example, in the first case above (no LLQ or Push Notifications, 1072 and no answers in the cache) if a new Multicast DNS query is 1073 requested (either by a local client, or by the Discovery Proxy on 1074 behalf of a remote client), and there is not already an identical 1075 Multicast DNS query active, and there are no matching answers already 1076 in the Multicast DNS cache on the Discovery Proxy device, then this 1077 will cause a series of Multicast DNS query packets to be issued with 1078 exponential backoff. The exponential backoff sequence in some 1079 implementations starts at one second and then doubles for each 1080 retransmission (0, 1, 3, 7 seconds, etc.) and in others starts at one 1081 second and then triples for each retransmission (0, 1, 4, 13 seconds, 1082 etc.). In either case, if no response has been received after six 1083 seconds, that is long enough that the underlying Multicast DNS 1084 implementation will have sent three query packets without receiving 1085 any response. At that point the Discovery Proxy cancels its 1086 Multicast DNS query (so no further Multicast DNS query packets will 1087 be sent for this query) and returns a negative response to the remote 1088 client via unicast. 1090 The six-second delay is chosen to be long enough to give enough time 1091 for devices to respond, yet short enough not to be too onerous for a 1092 human user waiting for a response. For example, using the "dig" DNS 1093 debugging tool, the current default settings result in it waiting a 1094 total of 15 seconds for a reply (three transmissions of the query 1095 packet, with a wait of 5 seconds after each packet) which is ample 1096 time for it to have received a negative reply from a Discovery Proxy 1097 after six seconds. 1099 The statement that for a one-shot query (i.e., no LLQ or Push 1100 Notifications requested), if at least one answer is already available 1101 in the cache then a Discovery Proxy should not issue additional mDNS 1102 query packets, also occurs naturally as a result of using existing 1103 Multicast DNS APIs. If a new Multicast DNS query is requested 1104 (either locally, or by the Discovery Proxy on behalf of a remote 1105 client), for which there are relevant answers already in the 1106 Multicast DNS cache on the Discovery Proxy device, and after the 1107 answers are delivered the Multicast DNS query is then cancelled 1108 immediately, then no Multicast DNS query packets will be generated 1109 for this query. 1111 6. Administrative DNS Records 1113 6.1. DNS SOA (Start of Authority) Record 1115 The MNAME field SHOULD contain the host name of the Discovery Proxy 1116 device (i.e., the same domain name as the rdata of the NS record 1117 delegating the relevant zone(s) to this Discovery Proxy device). 1119 The RNAME field SHOULD contain the mailbox of the person responsible 1120 for administering this Discovery Proxy device. 1122 The SERIAL field MUST be zero. 1124 Zone transfers are undefined for Discovery Proxy zones, and 1125 consequently the REFRESH, RETRY and EXPIRE fields have no useful 1126 meaning for Discovery Proxy zones. These fields SHOULD contain 1127 reasonable default values. The RECOMMENDED values are: REFRESH 7200, 1128 RETRY 3600, EXPIRE 86400. 1130 The MINIMUM field (used to control the lifetime of negative cache 1131 entries) SHOULD contain the value 10. The value of ten seconds is 1132 chosen based on user-experience considerations (see Section 5.5.1). 1134 In the event that there are multiple Discovery Proxy devices on a 1135 link for fault tolerance reasons, this will result in clients 1136 receiving inconsistent SOA records (different MNAME, and possibly 1137 RNAME) depending on which Discovery Proxy answers their SOA query. 1138 However, since clients generally have no reason to use the MNAME or 1139 RNAME data, this is unlikely to cause any problems. 1141 6.2. DNS NS Records 1143 In the event that there are multiple Discovery Proxy devices on a 1144 link for fault tolerance reasons, the parent zone MUST be configured 1145 with NS records giving the names of all the Discovery Proxy devices 1146 on the link. 1148 Each Discovery Proxy device MUST be configured to answer NS queries 1149 for the zone apex name by giving its own NS record, and the NS 1150 records of its fellow Discovery Proxy devices on the same link, so 1151 that it can return the correct answers for NS queries. 1153 The target host name in the RDATA of an NS record MUST NOT reference 1154 a name that falls within any zone delegated to a Discovery Proxy. 1155 Apart from the zone apex name, all other host names that fall within 1156 a zone delegated to a Discovery Proxy correspond to local Multicast 1157 DNS host names, which logically belong to the respective Multicast 1158 DNS hosts defending those names, not the Discovery Proxy. Generally 1159 speaking, the Discovery Proxy does not own or control the delegated 1160 zone; it is merely a conduit to the corresponding ".local" namespace, 1161 which is controlled by the Multicast DNS hosts on that link. If an 1162 NS record were to reference a manually-determined host name that 1163 falls within a delegated zone, that manually-determined host name may 1164 inadvertently conflict with a corresponding ".local" host name that 1165 is owned and controlled by some device on that link. 1167 6.3. DNS Delegation Records 1169 Since the Multicast DNS specification [RFC6762] states that there can 1170 be no delegation (subdomains) within a ".local" namespace, this 1171 implies that any name within a zone delegated to a Discovery Proxy 1172 (except for the zone apex name itself) cannot have any answers for 1173 any DNS queries for RRTYPEs SOA, NS, or DS. Consequently: 1175 o for any query for the zone apex name of a zone delegated to a 1176 Discovery Proxy, the Discovery Proxy MUST generate the appropriate 1177 immediate answers as described above, and 1179 o for any query for RRTYPEs SOA, NS, or DS, for any name within a 1180 zone delegated to a Discovery Proxy, other than the zone apex 1181 name, instead of translating the query to its corresponding 1182 Multicast DNS ".local" equivalent, a Discovery Proxy MUST generate 1183 an immediate negative answer. 1185 6.4. DNS SRV Records 1187 There are certain special DNS records that logically fall within the 1188 delegated unicast DNS subdomain, but rather than mapping to their 1189 corresponding ".local" namesakes, they actually contain metadata 1190 pertaining to the operation of the delegated unicast DNS subdomain 1191 itself. They do not exist in the corresponding ".local" namespace of 1192 the local link. For these queries a Discovery Proxy MUST generate 1193 immediate answers, whether positive or negative, to avoid delays 1194 while clients wait for their query to be answered. For example, if a 1195 Discovery Proxy does not implement Long-Lived Queries [LLQ] then it 1196 MUST return an immediate negative answer to tell the client this 1197 without delay, instead of passing the query through to the local 1198 network as a query for "_dns-llq._udp.local.", and then waiting 1199 unsuccessfully for answers that will not be forthcoming. 1201 If a Discovery Proxy implements Long-Lived Queries [LLQ] then it MUST 1202 positively respond to "_dns-llq._udp. SRV" queries, 1203 "_dns-llq._tcp. SRV" queries, and 1204 "_dns-llq-tls._tcp. SRV" queries as appropriate, else it MUST 1205 return an immediate negative answer for those queries. 1207 If a Discovery Proxy implements DNS Push Notifications [Push] then it 1208 MUST positively respond to "_dns-push-tls._tcp." queries, else 1209 it MUST return an immediate negative answer for those queries. 1211 A Discovery Proxy MUST return an immediate negative answer for 1212 "_dns-update._udp. SRV" queries, "_dns-update._tcp. SRV" 1213 queries, and "_dns-update-tls._tcp. SRV" queries, since using 1214 DNS Update [RFC2136] to change zones generated dynamically from local 1215 Multicast DNS data is not possible. 1217 7. DNSSEC Considerations 1219 7.1. On-line signing only 1221 The Discovery Proxy acts as the authoritative name server for 1222 designated subdomains, and if DNSSEC is to be used, the Discovery 1223 Proxy needs to possess a copy of the signing keys, in order to 1224 generate authoritative signed data from the local Multicast DNS 1225 responses it receives. Off-line signing is not applicable to 1226 Discovery Proxy. 1228 7.2. NSEC and NSEC3 Records 1230 In DNSSEC NSEC [RFC4034] and NSEC3 [RFC5155] records are used to 1231 assert the nonexistence of certain names, also described as 1232 "authenticated denial of existence". 1234 Since a Discovery Proxy only knows what names exist on the local link 1235 by issuing queries for them, and since it would be impractical to 1236 issue queries for every possible name just to find out which names 1237 exist and which do not, a Discovery Proxy cannot programmatically 1238 synthesize the traditional NSEC and NSEC3 records which assert the 1239 nonexistence of a large range of names. Instead, when generating a 1240 negative response, a Discovery Proxy programmatically synthesizes a 1241 single NSEC record assert the nonexistence of just the specific name 1242 queried, and no others. Since the Discovery Proxy has the zone 1243 signing key, it can do this on demand. Since the NSEC record asserts 1244 the nonexistence of only a single name, zone walking is not a 1245 concern, so NSEC3 is not necessary. 1247 Note that this applies only to traditional immediate DNS queries, 1248 which may return immediate negative answers when no immediate 1249 positive answer is available. When used with a DNS Push Notification 1250 subscription [Push] there are no negative answers, merely the absence 1251 of answers so far, which may change in the future if answers become 1252 available. 1254 8. IPv6 Considerations 1256 An IPv4-only host and an IPv6-only host behave as "ships that pass in 1257 the night". Even if they are on the same Ethernet [IEEE-3], neither 1258 is aware of the other's traffic. For this reason, each link may have 1259 *two* unrelated ".local." zones, one for IPv4 and one for IPv6. 1260 Since for practical purposes, a group of IPv4-only hosts and a group 1261 of IPv6-only hosts on the same Ethernet act as if they were on two 1262 entirely separate Ethernet segments, it is unsurprising that their 1263 use of the ".local." zone should occur exactly as it would if they 1264 really were on two entirely separate Ethernet segments. 1266 It will be desirable to have a mechanism to 'stitch' together these 1267 two unrelated ".local." zones so that they appear as one. Such 1268 mechanism will need to be able to differentiate between a dual-stack 1269 (v4/v6) host participating in both ".local." zones, and two different 1270 hosts, one IPv4-only and the other IPv6-only, which are both trying 1271 to use the same name(s). Such a mechanism will be specified in a 1272 future companion document. 1274 At present, it is RECOMMENDED that a Discovery Proxy be configured 1275 with a single domain name for both the IPv4 and IPv6 ".local." zones 1276 on the local link, and when a unicast query is received, it should 1277 issue Multicast DNS queries using both IPv4 and IPv6 on the local 1278 link, and then combine the results. 1280 9. Security Considerations 1282 9.1. Authenticity 1284 A service proves its presence on a link by its ability to answer 1285 link-local multicast queries on that link. If greater security is 1286 desired, then the Discovery Proxy mechanism should not be used, and 1287 something with stronger security should be used instead, such as 1288 authenticated secure DNS Update [RFC2136] [RFC3007]. 1290 9.2. Privacy 1292 The Domain Name System is, generally speaking, a global public 1293 database. Records that exist in the Domain Name System name 1294 hierarchy can be queried by name from, in principle, anywhere in the 1295 world. If services on a mobile device (like a laptop computer) are 1296 made visible via the Discovery Proxy mechanism, then when those 1297 services become visible in a domain such as "My House.example.com" 1298 that might indicate to (potentially hostile) observers that the 1299 mobile device is in my house. When those services disappear from 1300 "My House.example.com" that change could be used by observers to 1301 infer when the mobile device (and possibly its owner) may have left 1302 the house. The privacy of this information may be protected using 1303 techniques like firewalls, split-view DNS, and Virtual Private 1304 Networks (VPNs), as are customarily used today to protect the privacy 1305 of corporate DNS information. 1307 The privacy issue is particularly serious for the IPv4 and IPv6 1308 reverse zones. If the public delegation of the reverse zones points 1309 to the Discovery Proxy, and the Discovery Proxy is reachable 1310 globally, then it could leak a significant amount of information. 1311 Attackers could discover hosts that otherwise might not be easy to 1312 identify, and learn their hostnames. Attackers could also discover 1313 the existence of links where hosts frequently come and go. 1315 The Discovery Proxy could also provide sensitive records only to 1316 authenticated users. This is a general DNS problem, not specific to 1317 the Discovery Proxy. Work is underway in the IETF to tackle this 1318 problem [RFC7626]. 1320 9.3. Denial of Service 1322 A remote attacker could use a rapid series of unique Unicast DNS 1323 queries to induce a Discovery Proxy to generate a rapid series of 1324 corresponding Multicast DNS queries on one or more of its local 1325 links. Multicast traffic is generally more expensive than unicast 1326 traffic -- especially on Wi-Fi links -- which makes this attack 1327 particularly serious. To limit the damage that can be caused by such 1328 attacks, a Discovery Proxy (or the underlying Multicast DNS subsystem 1329 which it utilizes) MUST implement Multicast DNS query rate limiting 1330 appropriate to the link technology in question. For today's 1331 802.11b/g/n/ac Wi-Fi links (for which approximately 200 multicast 1332 packets per second is sufficient to consume approximately 100% of the 1333 wireless spectrum) a limit of 20 Multicast DNS query packets per 1334 second is RECOMMENDED. On other link technologies like Gigabit 1335 Ethernet higher limits may be appropriate. A consequence of this 1336 rate limiting is that a rogue remote client could issue an excessive 1337 number of queries, resulting in denial of service to other legitimate 1338 remote clients attempting to use that Discovery Proxy. However, this 1339 is preferable to a rogue remote client being able to inflict even 1340 greater harm on the local network, which could impact the correct 1341 operation of all local clients on that network. 1343 10. IANA Considerations 1345 This document has no IANA Considerations. 1347 11. Acknowledgments 1349 Thanks to Markus Stenberg for helping develop the policy regarding 1350 the four styles of unicast response according to what data is 1351 immediately available in the cache. Thanks to Anders Brandt, Ben 1352 Campbell, Tim Chown, Alissa Cooper, Spencer Dawkins, Ralph Droms, 1353 Joel Halpern, Ray Hunter, Joel Jaeggli, Warren Kumari, Ted Lemon, 1354 Alexey Melnikov, Kathleen Moriarty, Tom Pusateri, Eric Rescorla, Adam 1355 Roach, David Schinazi, Markus Stenberg, Dave Thaler, and Andrew 1356 Yourtchenko for their comments. 1358 12. References 1360 12.1. Normative References 1362 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1363 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1364 . 1366 [RFC1035] Mockapetris, P., "Domain names - implementation and 1367 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1368 November 1987, . 1370 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1371 and E. Lear, "Address Allocation for Private Internets", 1372 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1373 . 1375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1376 Requirement Levels", BCP 14, RFC 2119, 1377 DOI 10.17487/RFC2119, March 1997, . 1380 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1381 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 1382 . 1384 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1385 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1386 2003, . 1388 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1389 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1390 DOI 10.17487/RFC3927, May 2005, . 1393 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1394 Rose, "Resource Records for the DNS Security Extensions", 1395 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1396 . 1398 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1399 Address Autoconfiguration", RFC 4862, 1400 DOI 10.17487/RFC4862, September 2007, . 1403 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1404 Security (DNSSEC) Hashed Authenticated Denial of 1405 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 1406 . 1408 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 1409 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 1410 . 1412 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1413 DOI 10.17487/RFC6762, February 2013, . 1416 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1417 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1418 . 1420 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1421 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1422 May 2017, . 1424 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 1425 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 1426 RFC 8490, DOI 10.17487/RFC8490, March 2019, 1427 . 1429 [Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", 1430 draft-ietf-dnssd-push-19 (work in progress), March 2019. 1432 12.2. Informative References 1434 [Roadmap] Cheshire, S., "Service Discovery Road Map", draft- 1435 cheshire-dnssd-roadmap-03 (work in progress), October 1436 2018. 1438 [DNS-UL] Sekar, K., "Dynamic DNS Update Leases", draft-sekar-dns- 1439 ul-01 (work in progress), August 2006. 1441 [LLQ] Cheshire, S. and M. Krochmal, "DNS Long-Lived Queries", 1442 draft-sekar-dns-llq-03 (work in progress), March 2019. 1444 [RegProt] Cheshire, S. and T. Lemon, "Service Registration Protocol 1445 for DNS-Based Service Discovery", draft-sctl-service- 1446 registration-00 (work in progress), July 2017. 1448 [Relay] Cheshire, S. and T. Lemon, "Multicast DNS Discovery 1449 Relay", draft-sctl-dnssd-mdns-relay-04 (work in progress), 1450 March 2018. 1452 [Mcast] Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. 1453 Zuniga, "Multicast Considerations over IEEE 802 Wireless 1454 Media", draft-ietf-mboned-ieee802-mcast-problems-04 (work 1455 in progress), November 2018. 1457 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1458 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 1459 . 1461 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1462 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1463 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1464 . 1466 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1467 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 1468 . 1470 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 1471 for Internationalized Domain Names in Applications 1472 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 1473 . 1475 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1476 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1477 . 1479 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 1480 to Replace the AppleTalk Name Binding Protocol (NBP)", 1481 RFC 6760, DOI 10.17487/RFC6760, February 2013, 1482 . 1484 [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 1485 "Requirements for Scalable DNS-Based Service Discovery 1486 (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, 1487 DOI 10.17487/RFC7558, July 2015, . 1490 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 1491 DOI 10.17487/RFC7626, August 2015, . 1494 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1495 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 1496 2016, . 1498 [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 1499 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, 1500 . 1502 [ohp] "Discovery Proxy (Hybrid Proxy) implementation for 1503 OpenWrt", . 1505 [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration 1506 Networking: The Definitive Guide", O'Reilly Media, Inc. , 1507 ISBN 0-596-10100-7, December 2005. 1509 [IEEE-1Q] "IEEE Standard for Local and metropolitan area networks -- 1510 Bridges and Bridged Networks", IEEE Std 802.1Q-2014, 1511 November 2014, . 1514 [IEEE-3] "Information technology - Telecommunications and 1515 information exchange between systems - Local and 1516 metropolitan area networks - Specific requirements - Part 1517 3: Carrier Sense Multiple Access with Collision Detection 1518 (CMSA/CD) Access Method and Physical Layer 1519 Specifications", IEEE Std 802.3-2008, December 2008, 1520 . 1522 [IEEE-5] Institute of Electrical and Electronics Engineers, 1523 "Information technology - Telecommunications and 1524 information exchange between systems - Local and 1525 metropolitan area networks - Specific requirements - Part 1526 5: Token ring access method and physical layer 1527 specification", IEEE Std 802.5-1998, 1995. 1529 [IEEE-11] "Information technology - Telecommunications and 1530 information exchange between systems - Local and 1531 metropolitan area networks - Specific requirements - Part 1532 11: Wireless LAN Medium Access Control (MAC) and Physical 1533 Layer (PHY) Specifications", IEEE Std 802.11-2007, June 1534 2007, . 1536 Appendix A. Implementation Status 1538 Some aspects of the mechanism specified in this document already 1539 exist in deployed software. Some aspects are new. This section 1540 outlines which aspects already exist and which are new. 1542 A.1. Already Implemented and Deployed 1544 Domain enumeration by the client (the "b._dns-sd._udp" queries) is 1545 already implemented and deployed. 1547 Unicast queries to the indicated discovery domain is already 1548 implemented and deployed. 1550 These are implemented and deployed in Mac OS X 10.4 and later 1551 (including all versions of Apple iOS, on all iPhone and iPads), in 1552 Bonjour for Windows, and in Android 4.1 "Jelly Bean" (API Level 16) 1553 and later. 1555 Domain enumeration and unicast querying have been used for several 1556 years at IETF meetings to make Terminal Room printers discoverable 1557 from outside the Terminal room. When an IETF attendee presses Cmd-P 1558 on a Mac, or selects AirPrint on an iPad or iPhone, and the Terminal 1559 room printers appear, that is because the client is sending unicast 1560 DNS queries to the IETF DNS servers. A walk-through giving the 1561 details of this particular specific example is given in Appendix A of 1562 the Roadmap document [Roadmap]. 1564 A.2. Already Implemented 1566 A minimal portable Discovery Proxy implementation has been produced 1567 by Markus Stenberg and Steven Barth, which runs on OS X and several 1568 Linux variants including OpenWrt [ohp]. It was demonstrated at the 1569 Berlin IETF in July 2013. 1571 Tom Pusateri has an implementation that runs on any Unix/Linux. It 1572 has a RESTful interface for management and an experimental demo CLI 1573 and web interface. 1575 Ted Lemon also has produced a portable implementation of Discovery 1576 Proxy, which is available in the mDNSResponder open source code. 1578 The Long-Lived Query mechanism [LLQ] referred to in this 1579 specification exists and is deployed, but was not standardized by the 1580 IETF. The IETF has developed a superior Long-Lived Query mechanism 1581 called DNS Push Notifications [Push], which is built on DNS Stateful 1582 Operations [RFC8490]. The pragmatic short-term deployment approach 1583 is for vendors to produce Discovery Proxies that implement both the 1584 deployed Long-Lived Query mechanism [LLQ] (for today's clients) and 1585 the new DNS Push Notifications mechanism [Push] as the preferred 1586 long-term direction. 1588 A.3. Partially Implemented 1590 The current APIs make multiple domains visible to client software, 1591 but most client UI today lumps all discovered services into a single 1592 flat list. This is largely a chicken-and-egg problem. Application 1593 writers were naturally reluctant to spend time writing domain-aware 1594 UI code when few customers today would benefit from it. If Discovery 1595 Proxy deployment becomes common, then application writers will have a 1596 reason to provide better UI. Existing applications will work with 1597 the Discovery Proxy, but will show all services in a single flat 1598 list. Applications with improved UI will group services by domain. 1600 Author's Address 1602 Stuart Cheshire 1603 Apple Inc. 1604 One Apple Park Way 1605 Cupertino, California 95014 1606 USA 1608 Phone: +1 (408) 996-1010 1609 Email: cheshire@apple.com