idnits 2.17.1 draft-ietf-dnssd-hybrid-00.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 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 10, 2014) is 3449 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 (-06) exists of draft-sekar-dns-llq-01 ** Downref: Normative reference to an Informational draft: draft-sekar-dns-llq (ref. 'I-D.sekar-dns-llq') Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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 November 10, 2014 5 Expires: May 14, 2015 7 Hybrid Unicast/Multicast DNS-Based Service Discovery 8 draft-ietf-dnssd-hybrid-00 10 Abstract 12 Performing DNS-Based Service Discovery using purely link-local 13 Multicast DNS enables discovery of services that are on the local 14 link, but not (without some kind of proxy or similar special support) 15 of services that are outside the local link. Using a very large 16 local link with thousands of hosts improves service discovery, but at 17 the cost of large amounts of multicast traffic. 19 Performing DNS-Based Service Discovery using purely Unicast DNS is 20 more efficient, but requires configuration of DNS Update keys on the 21 devices offering the services, which can be onerous for simple 22 devices like printers and network cameras. 24 Hence a compromise is needed, that provides easy service discovery 25 without requiring either large amounts of multicast traffic or 26 onerous configuration. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 14, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions and Terminology Used in this Document . . . . . . 4 64 3. Hybrid Proxy Operation . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Domain Enumeration . . . . . . . . . . . . . . . . . . . . 6 66 3.2. Delegated Subdomain for LDH Host Names . . . . . . . . . . 7 67 3.3. Delegated Subdomain for Reverse Mapping . . . . . . . . . 9 68 3.4. Data Translation . . . . . . . . . . . . . . . . . . . . . 10 69 3.4.1. DNS TTL limiting . . . . . . . . . . . . . . . . . . . 10 70 3.4.2. Suppressing Unusable Records . . . . . . . . . . . . . 10 71 3.4.3. Application-Specific Data Translation . . . . . . . . 11 72 3.5. Answer Aggregation . . . . . . . . . . . . . . . . . . . . 12 73 3.5.1. Discovery of LLQ Service . . . . . . . . . . . . . . . 14 74 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 75 4.1. Already Implemented and Deployed . . . . . . . . . . . . . 15 76 4.2. Partially Implemented . . . . . . . . . . . . . . . . . . 15 77 4.3. Not Yet Implemented . . . . . . . . . . . . . . . . . . . 16 78 5. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 6.1. Authenticity . . . . . . . . . . . . . . . . . . . . . . . 17 81 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 17 83 7. Intelectual Property Rights . . . . . . . . . . . . . . . . . 18 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Introduction 93 Multicast DNS [RFC6762] and its companion technology DNS-based 94 Service Discovery [RFC6763] were created to provide IP networking 95 with the ease-of-use and autoconfiguration for which AppleTalk was 96 well known [RFC6760] [ZC]. 98 For a small network consisting of just a single link (or several 99 physical links bridged together to appear as a single logical link to 100 IP) Multicast DNS [RFC6762] is sufficient for client devices to look 101 up the dot-local host names of peers on the same home network, and 102 perform DNS-Based Service Discovery (DNS-SD) [RFC6763] of services 103 offered on that home network. 105 For a larger network consisting of multiple links that are 106 interconnected using IP-layer routing instead of link-layer bridging, 107 link-local Multicast DNS alone is insufficient because link-local 108 Multicast DNS packets, by design, do not cross between links. 109 (This was a deliberate design choice for Multicast DNS, since even on 110 a single link multicast traffic is expensive -- especially on Wi-Fi 111 links -- and multiplying the amount of multicast traffic by flooding 112 it across multiple links would make that problem even worse.) 113 In this environment, Unicast DNS would be preferable to Multicast 114 DNS. (Unicast DNS can be used either with a traditionally assigned 115 globally unique domain name, or with a private local unicast domain 116 name such as ".home" [HOME].) 118 To use Unicast DNS, the names of hosts and services need to be made 119 available in the Unicast DNS namespace. In the DNS-SD specification 120 [RFC6763] Section 10 ("Populating the DNS with Information") 121 discusses various possible ways that a service's PTR, SRV, TXT and 122 address records can make their way into the Unicast DNS namespace, 123 including manual zone file configuration [RFC1034] [RFC1035], 124 DNS Update [RFC2136] [RFC3007] and proxies of various kinds. 126 This document specifies a type of proxy called a Hybrid Proxy that 127 uses Multicast DNS [RFC6762] to discover Multicast DNS records on its 128 local link, and makes corresponding DNS records visible in the 129 Unicast DNS namespace. 131 2. Conventions and Terminology Used in this Document 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in 136 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 138 The Hybrid Proxy builds on Multicast DNS, which works between hosts 139 on the same link. A set of hosts is considered to be "on the same 140 link" if: 142 o when any host A from that set sends a packet to any other host B 143 in that set, using unicast, multicast, or broadcast, the entire 144 link-layer packet payload arrives unmodified, and 146 o a broadcast sent over that link by any host from that set of hosts 147 can be received by every other host in that set 149 The link-layer *header* may be modified, such as in Token Ring Source 150 Routing [802.5], but not the link-layer *payload*. In particular, if 151 any device forwarding a packet modifies any part of the IP header or 152 IP payload then the packet is no longer considered to be on the same 153 link. This means that the packet may pass through devices such as 154 repeaters, bridges, hubs or switches and still be considered to be on 155 the same link for the purpose of this document, but not through a 156 device such as an IP router that decrements the IP TTL or otherwise 157 modifies the IP header. 159 3. Hybrid Proxy Operation 161 In its simplest form, each physical link in an organization is 162 assigned a unique Unicast DNS domain name, such as 163 "Building 1.example.com" or "4th Floor.Building 1.example.com". 164 Grouping multiple links under a single Unicast DNS domain name is to 165 be specified in a future companion document, but for the purposes of 166 this document, assume that each link has its own unique Unicast DNS 167 domain name. In a graphical user interface these names are not 168 displayed as strings with dots as shown above, but something more 169 akin to a typical file browser graphical user interface (which is 170 harder to illustrate in a text-only document) showing folders, 171 subfolders and files in a file system. 173 Each named link in an organization has a Hybrid Proxy which serves 174 it. This Hybrid Proxy function could be performed by a router on 175 that link, or, with appropriate VLAN configuration, a single Hybrid 176 Proxy could have a logical presence on, and serve as the Hybrid Proxy 177 for, many links. In the parent domain, NS records are used to 178 delegate ownership of each defined link name 179 (e.g., "Building 1.example.com") to the Hybrid Proxy that serves the 180 named link. In other words, the Hybrid Proxy is the authoritative 181 name server for that subdomain. 183 When a DNS-SD client issues a Unicast DNS query to discover services 184 in a particular Unicast DNS subdomain 185 (e.g., "_printer._tcp.Building 1.example.com. PTR ?") the normal DNS 186 delegation mechanism results in that query being forwarded until it 187 reaches the delegated authoritative name server for that subdomain, 188 namely the Hybrid Proxy on the link in question. Like a conventional 189 Unicast DNS server, a Hybrid Proxy implements the usual Unicast DNS 190 protocol [RFC1034] [RFC1035] over UDP and TCP. However, unlike a 191 conventional Unicast DNS server that generates answers from the data 192 in its manually-configured zone file, a Hybrid Proxy generates 193 answers using Multicast DNS. A Hybrid Proxy does this by consulting 194 its Multicast DNS cache and/or issuing Multicast DNS queries for the 195 corresponding Multicast DNS name, type and class, (e.g., in this 196 case, "_printer._tcp.local. PTR ?"). Then, from the received 197 Multicast DNS data, the Hybrid Proxy synthesizes the appropriate 198 Unicast DNS response. 200 Naturally, the existing Multicast DNS caching mechanism is used to 201 avoid issuing unnecessary Multicast DNS queries on the wire. The 202 Hybrid Proxy is acting as a client of the underlying Multicast DNS 203 subsystem, and benefits from the same caching and efficiency measures 204 as any other client using that subsystem. 206 3.1. Domain Enumeration 208 The administrator creates Domain Enumeration PTR records [RFC6763] to 209 inform clients of available service discovery domains, e.g.,: 211 b._dns-sd._udp.example.com. PTR Building 1.example.com. 212 PTR Building 2.example.com. 213 PTR Building 3.example.com. 214 PTR Building 4.example.com. 216 db._dns-sd._udp.example.com. PTR Building 1.example.com. 218 lb._dns-sd._udp.example.com. PTR Building 1.example.com. 220 The "b" ("browse") records tell the client device the list of 221 browsing domains to display for the user to select from and the "db" 222 ("default browse") record tells the client device which domain in 223 that list should be selected by default. The "lb" ("legacy browse") 224 record tells the client device which domain to automatically browse 225 on behalf of applications that don't implement UI for multi-domain 226 browsing (which is most of them, today). The "lb" domain is usually 227 the same as the "db" domain. 229 DNS responses are limited to a maximum size of 65535 bytes. This 230 limits the maximum number of domains that can be returned for a 231 Domain Enumeration query, as follows: 233 A DNS response header is 12 bytes. That's typically followed by a 234 single qname (up to 256 bytes) plus qtype (2 bytes) and qclass 235 (2 bytes), leaving 65275 for the Answer Section. 237 An Answer Section Resource Record consists of: 238 o Owner name, encoded as a two-byte compression pointer 239 o Two-byte rrtype (type PTR) 240 o Two-byte rrclass (class IN) 241 o Four-byte ttl 242 o Two-byte rdlength 243 o rdata (domain name, up to 256 bytes) 245 This means that each Resource Record in the Answer Section can take 246 up to 268 bytes total, which means that the Answer Section can 247 contain, in the worst case, no more than 243 domains. 249 In a more typical scenario, where the domain names are not all 250 maximum-sized names, and there is some similarity between names so 251 that reasonable name compression is possible, each Answer Section 252 Resource Record may average 140 bytes, which means that the Answer 253 Section can contain up to 466 domains. 255 3.2. Delegated Subdomain for LDH Host Names 257 The rules for DNS-SD service instance names and domains are more 258 permissive than the traditional rules for host names. 260 Users typically interact with DNS-SD by viewing a list of discovered 261 service instance names on the display and selecting one of them by 262 pointing, touching, or clicking. Similarly, in software that 263 provides a multi-domain DNS-SD user interface, users view a list of 264 offered domains on the display and select one of them by pointing, 265 touching, or clicking. To use a service, users don't have to 266 remember domain or instance names, or type them; users just have to 267 be able to recognize what they see on the display and click on the 268 thing they want. 270 In contrast, host names are often remembered and typed. Also, host 271 names are often used in command-line interfaces where spaces can be 272 inconvenient. For this reason, host names have traditionally been 273 restricted to letters, digits and hyphens, with no spaces or other 274 punctuation. 276 While we still want to allow rich text for DNS-SD service instance 277 names and domains, it is advisable, for maximum compatibility with 278 existing software, to restrict host names to the traditional letter- 279 digit-hyphen rules. This means that while a service name 280 "My Printer._ipp._tcp.Building 1.example.com" is acceptable and 281 desirable (it is displayed in a graphical user interface as an 282 instance called "My Printer" in the domain "Building 1" at 283 "example.com"), a host name "My-Printer.Building 1.example.com" is 284 not advisable (because of the space in "Building 1"). 286 To accomodate this difference in allowable characters, a Hybrid Proxy 287 MUST support having two subdomains delegated to it, one to be used 288 for host names (names of 'A' and 'AAAA' address records), which is 289 restricted to the traditional letter-digit-hyphen rules, and another 290 to be used for other records (including the PTR, SRV and TXT records 291 used by DNS-SD), which is allowed to be arbitrary Net-Unicode text 292 [RFC5198]. 294 For example, a Hybrid Proxy could have the two subdomains 295 "Building 1.example.com" and "bldg1.example.com" delegated to it. 296 The Hybrid Proxy would then translate these two Multicast DNS 297 records: 299 My Printer._ipp._tcp.local. SRV 0 0 631 prnt.local. 300 prnt.local. A 10.0.1.2 302 into Unicast DNS records as follows: 304 My Printer._ipp._tcp.Building 1.example.com. 305 SRV 0 0 631 prnt.bldg1.example.com. 306 prnt.bldg1.example.com. A 10.0.1.2 308 Note that the SRV record name is translated using the rich-text 309 domain name ("Building 1.example.com") and the address record name is 310 translated using the LDH domain ("bldg1.example.com"). 312 3.3. Delegated Subdomain for Reverse Mapping 314 A Hybrid Proxy can facilitate easier management of reverse mapping 315 domains, particularly for IPv6 addresses where manual management may 316 be more onerous than it is for IPv4 addresses. 318 To achieve this, in the parent domain, NS records are used to 319 delegate ownership of the appropriate reverse mapping domain to the 320 Hybrid Proxy. In other words, the Hybrid Proxy becomes the 321 authoritative name server for the reverse mapping domain. 323 For example, if a given link is using the IPv4 subnet 10.1/16, then 324 the domain "1.10.in-addr.arpa" is delegated to the Hybrid Proxy for 325 that link. 327 If a given link is using the IPv6 prefix 2001:0DB8/32, then the 328 domain "8.b.d.0.1.0.0.2.ip6.arpa" is delegated to the Hybrid Proxy 329 for that link. 331 When a reverse mapping query arrives at the Hybrid Proxy, it issues 332 the identical query on its local link as a Multicast DNS query. 333 (In the Apple "/usr/include/dns_sd.h" APIs, using ForceMulticast 334 indicates that the DNSServiceQueryRecord() call should perform the 335 query using Multicast DNS.) When the host owning that IPv4 or IPv6 336 address responds with a name of the form "something.local", the 337 Hybrid Proxy rewrites that to use its configured LDH host name domain 338 instead of "local" and returns the response to the caller. 340 For example, a Hybrid Proxy with the two subdomains 341 "1.10.in-addr.arpa" and "bldg1.example.com" delegated to it would 342 translate this Multicast DNS record: 344 3.2.1.10.in-addr.arpa. PTR prnt.local. 346 into this Unicast DNS response: 348 3.2.1.10.in-addr.arpa. PTR prnt.bldg1.example.com. 350 Subsequent queries for the prnt.bldg1.example.com address record, 351 falling as it does within the bldg1.example.com domain, which is 352 delegated to the Hybrid Proxy, will arrive at the Hybrid Proxy, where 353 they are answered by issuing Multicast DNS queries and using the 354 received Multicast DNS answers to synthesize Unicast DNS responses, 355 as described above. 357 3.4. Data Translation 359 Generating the appropriate Multicast DNS queries involves, at the 360 very least, translating from the configured DNS domain 361 (e.g., "Building 1.example.com") on the Unicast DNS side to "local" 362 on the Multicast DNS side. 364 Generating the appropriate Unicast DNS responses involves translating 365 back from "local" to the configured DNS Unicast domain. 367 Other beneficial translation and filtering operations are described 368 below. 370 3.4.1. DNS TTL limiting 372 For efficiency, Multicast DNS typically uses moderately high DNS TTL 373 values. For example, the typical TTL on DNS-SD PTR records is 75 374 minutes. What makes these moderately high TTLs acceptable is the 375 cache coherency mechanisms built in to the Multicast DNS protocol 376 which protect against stale data persisting for too long. When a 377 service shuts down gracefully, it sends goodbye packets to remove its 378 PTR records immediately from neighbouring caches. If a service shuts 379 down abruptly without sending goodbye packets, the Passive 380 Observation Of Failures (POOF) mechanism described in Section 10.5 of 381 the Multicast DNS specification [RFC6762] comes into play to purge 382 the cache of stale data. 384 A Unicast DNS client on a remote link does not get to participate in 385 these Multicast DNS cache coherency mechanisms on the local link. 386 For Unicast DNS requests received without any LLQ option the DNS TTLs 387 reported in the resulting Unicast DNS response SHOULD be capped to be 388 no more than ten seconds. For received Unicast DNS requests that 389 contain an LLQ option, the Multicast DNS record's TTL SHOULD be 390 returned unmodified, because the LLQ notification channel exists to 391 inform the remote client as records come and go. For further details 392 about the LLQ option, see Section 3.5. 394 3.4.2. Suppressing Unusable Records 396 A Hybrid Proxy SHOULD suppress Unicast DNS answers for records that 397 are not useful outside the local link. For example, DNS A and AAAA 398 records for IPv4 link-local addresses [RFC3927] and IPv6 link-local 399 addresses [RFC4862] should be suppressed. Similarly, for sites that 400 have multiple private address realms [RFC1918], private addresses 401 from one private address realm should not be communicated to clients 402 in a different private address realm. 404 By the same logic, DNS SRV records that reference target host names 405 that have no addresses usable by the requester should be suppressed, 406 and likewise, DNS PTR records that point to unusable SRV records 407 should be similarly be suppressed. 409 3.4.3. Application-Specific Data Translation 411 There may be cases where Application-Specific Data Translation is 412 appropriate. 414 For example, AirPrint printers tend to advertise fairly verbose 415 information about their capabilities in their DNS-SD TXT record. 416 This information is a legacy from LPR printing, because LPR does not 417 have in-band capability negotiation, so all of this information is 418 conveyed using the DNS-SD TXT record instead. IPP printing does have 419 in-band capability negotiation, but for convenience printers tend to 420 include the same capability information in their IPP DNS-SD TXT 421 records as well. For local mDNS use this extra TXT record 422 information is inefficient, but not fatal. However, when a Hybrid 423 Proxy aggregates data from multiple printers on a link, and sends it 424 via unicast (via UDP or TCP) this amount of unnecessary TXT record 425 information can result in large responses. Therefore, a Hybrid Proxy 426 that is aware of the specifics of an application-layer protocol such 427 as Apple's AirPrint (which uses IPP) can elide unnecessary key/value 428 pairs from the DNS-SD TXT record for better network efficiency. 430 Note that this kind of Application-Specific Data Translation is 431 expected to be very rare. It is the exception, rather than the rule. 432 This is an example of a common theme in computing. It is frequently 433 the case that it is wise to start with a clean, layered design, with 434 clear boundaries. Then, in certain special cases, those layer 435 boundaries may be violated, where the performance and efficiency 436 benefits outweigh the inelegance of the layer violation. 438 As in other similar situations, these layer violations optional. 439 They are done only for efficiency reasons, and are not required for 440 correct operation. A Hybrid Proxy can operate solely at the mDNS 441 layer, without any knowledge of semantics at the DNS-SD layer or 442 above. 444 3.5. Answer Aggregation 446 In a simple analysis, simply gathering multicast answers and 447 forwarding them in a unicast response seems adequate, but it raises 448 the question of how long the Hybrid Proxy should wait to be sure that 449 it has received all the Multicast DNS answers it needs to form a 450 complete Unicast DNS response. If it waits too little time, then it 451 risks its Unicast DNS response being incomplete. If it waits too 452 long, then it creates a poor user experience at the client end. In 453 fact, there may no time which is both short enough to produce a good 454 user experience and at the same time long enough to reliably produce 455 complete results. 457 Similarly, the Hybrid Proxy -- the authoritative name server for the 458 subdomain in question -- needs to decide what DNS TTL to report for 459 these records. If the TTL is too long then the recursive (caching) 460 name servers issuing queries on behalf of their clients risk caching 461 stale data for too long. If the TTL is too short then the amount of 462 network traffic will be more than necessary. In fact, there may no 463 TTL which is both short enough to avoid undesirable stale data and at 464 the same time long enough to be efficient on the network. 466 These dilemmas are solved by use of DNS Long-Lived Queries (DNS LLQ) 467 [I-D.sekar-dns-llq]. The Hybrid Proxy responds immediately to the 468 Unicast DNS query using the Multicast DNS records it already has in 469 its cache (if any). This provides a good client user experience by 470 providing a near-instantaneous response. Simultaneously, the Hybrid 471 Proxy issues a Multicast DNS query on the local link to discover if 472 there are any additional Multicast DNS records it did not already 473 know about. Should additional Multicast DNS responses be received, 474 these are then delivered to the client using DNS LLQ update messages. 475 The timeliness of such LLQ updates is limited only by the timeliness 476 of the device responding to the Multicast DNS query. If the 477 Multicast DNS device responds quickly, then the LLQ update is 478 delivered quickly. If the Multicast DNS device responds slowly, then 479 the LLQ update is delivered slowly. The benefit of using LLQ is that 480 the Hybrid Proxy can respond promptly because it doesn't have to 481 delay its unicast response to allow for the expected worst-case delay 482 for receiving all the Multicast DNS responses. Even if a proxy were 483 to try to provide reliability by assuming an excessively pessimistic 484 worst-case time (thereby giving a very poor user experience) there 485 would still be the risk of a slow Multicast DNS device taking even 486 longer than that (e.g, a device that is not even powered on until ten 487 seconds after the initial query is received) resulting in incomplete 488 responses. Using LLQs solves this dilemma: even very late responses 489 are not lost; they are delivered in subsequent LLQ update messages. 491 There are two factors that determine specifically how responses are 492 generated: 494 The first factor is whether the query from the client included the 495 LLQ option (typical with long-lived service browsing PTR queries) or 496 not (typical with one-shot operations like SRV or address record 497 queries). Note that queries containing the LLQ option are received 498 directly from the client (see Section 3.5.1). Queries containing no 499 LLQ option are generally received via the client's configured 500 recursive (caching) name server. 502 The second factor is whether the Hybrid Proxy already has at least 503 one record in its cache that positively answers the question. 505 o No LLQ option; no answer in cache: 506 Do local mDNS query up to three times, return answers if received, 507 otherwise return negative response if no answer after three tries. 508 DNS TTLs in responses are capped to at most ten seconds. 510 o No LLQ option; at least one answer in cache: 511 Send response right away to minimise delay. 512 DNS TTLs in responses are capped to at most ten seconds. 513 No local mDNS queries are performed. 514 (Reasoning: Given RRSet TTL harmonisation, if the proxy has one 515 Multicast DNS answer in its cache, it can reasonably assume that 516 it has all of them.) 518 o Query contains LLQ option; no answer in cache: 519 As above, do local mDNS query up to three times, and return 520 answers if received. 521 If no answer after three tries, return negative response. 522 (Reasoning: We don't need to rush to send an empty answer.) 523 In both cases the query remains active for as long as the client 524 maintains the LLQ state, and if mDNS answers are received later, 525 LLQ update messages are sent. 526 DNS TTLs in responses are returned unmodified. 528 o Query contains LLQ option; at least one answer in cache: 529 As above, send response right away to minimise delay. 530 The query remains active for as long as the client maintains the 531 LLQ state, and if additional mDNS answers are received later, LLQ 532 update messages are sent. 533 (Reasoning: We want UI that is displayed very rapidly, yet 534 continues to remain accurate even as the network environment 535 changes.) 536 DNS TTLs in responses are returned unmodified. 538 Note that the "negative responses" referred to above are "no error no 539 answer" negative responses, not NXDOMAIN. This is because the Hybrid 540 Proxy cannot know all the Multicast DNS domain names that may exist 541 on a link at any given time, so any name with no answers may have 542 child names that do exist, making it an "empty nonterminal" name. 544 3.5.1. Discovery of LLQ Service 546 To issue LLQ queries, clients need to communicate directly with the 547 authoritative Hybrid Proxy. The procedure by which the client 548 locates the authoritative Hybrid Proxy is described in the LLQ 549 specification [I-D.sekar-dns-llq]. 551 Briefly, the procedure is as follows: To discover the LLQ service for 552 a given domain name, a client first performs DNS zone apex discovery, 553 and then, having discovered , the client then issues a DNS 554 query for the SRV record with the name _dns-llq._udp. to find 555 the target host and port for the LLQ service for that zone. By 556 default LLQ service runs on port 5352, but since SRV records are 557 used, the LLQ service can be offered on any port. 559 A client performs DNS zone apex discovery using the procedure below: 561 1. The client issues a DNS query for the SOA record with the given 562 domain name. 564 2. A conformant recursive (caching) name server will either send a 565 positive response, or a negative response containing the SOA 566 record of the zone apex in the Authority Section. 568 3. If the name server sends a negative response that does not 569 contain the SOA record of the zone apex, the client trims the 570 first label off the given domain name and returns to step 1 to 571 try again. 573 By this method, the client iterates until it learns the name of the 574 zone apex, or (in pathological failure cases) reaches the root and 575 gives up. 577 Normal DNS caching is used to avoid repetitive queries on the wire. 579 4. Implementation Status 581 Some aspects of the mechanism specified in this document already 582 exist in deployed software. Some aspects are new. This section 583 outlines which aspects already exist and which are new. 585 4.1. Already Implemented and Deployed 587 Domain enumeration by the client (the "b._dns-sd._udp" queries) is 588 already implemented and deployed. 590 Unicast queries to the indicated discovery domain is already 591 implemented and deployed. 593 These are implemented and deployed in Mac OS X 10.4 and later 594 (including all versions of Apple iOS, on all iPhone and iPads), in 595 Bonjour for Windows, and in Android 4.1 "Jelly Bean" (API Level 16) 596 and later. 598 Domain enumeration and unicast querying have been used for several 599 years at IETF meetings to make Terminal Room printers discoverable 600 from outside the Terminal room. When you Press Cmd-P on your Mac, or 601 select AirPrint on your iPad or iPhone, and the Terminal room 602 printers appear, that is because your client is doing unicast DNS 603 queries to the IETF DNS servers. 605 4.2. Partially Implemented 607 The current APIs make multiple domains visible to client software, 608 but most client UI today lumps all discovered services into a single 609 flat list. This is largely a chicken-and-egg problem. Application 610 writers were naturally reluctant to spend time writing domain-aware 611 UI code when few customers today would benefit from it. If Hybrid 612 Proxy deployment becomes common, then application writers will have a 613 reason to provide better UI. Existing applications will work with 614 the Hybrid Proxy, but will show all services in a single flat list. 615 Applications with improved UI will group services by domain. 617 The Long-Lived Query mechanism [I-D.sekar-dns-llq] referred to in 618 this specification exists and is deployed, but has not been 619 standardized by the IETF. It is possible that the IETF may choose to 620 standardize a different or better Long-Lived Query mechanism. In 621 that case, the pragmatic deployment approach would be for vendors to 622 produce Hybrid Proxies that implement both the deployed Long-Lived 623 Query mechanism [I-D.sekar-dns-llq] (for today's clients) and a new 624 IETF Standard Long-Lived Query mechanism (as the future long-term 625 direction). 627 The translating/filtering Hybrid Proxy specified in this document. 628 Implementations are under development, and operational experience 629 with these implementations has guided updates to this document. 631 4.3. Not Yet Implemented 633 A mechanism to 'stitch' together multiple ".local." zones so that 634 they appear as one. Such a mechanism will be specified in a future 635 companion document. 637 5. IPv6 Considerations 639 An IPv4-only host and an IPv6-only host behave as "ships that pass in 640 the night". Even if they are on the same Ethernet, neither is aware 641 of the other's traffic. For this reason, each physical link may have 642 *two* unrelated ".local." zones, one for IPv4 and one for IPv6. 643 Since for practical purposes, a group of IPv4-only hosts and a group 644 of IPv6-only hosts on the same Ethernet act as if they were on two 645 entirely separate Ethernet segments, it is unsurprising that their 646 use of the ".local." zone should occur exactly as it would if they 647 really were on two entirely separate Ethernet segments. 649 It will be desirable to have a mechanism to 'stitch' together these 650 two unrelated ".local." zones so that they appear as one. Such 651 mechanism will need to be able to differentiate between a dual-stack 652 (v4/v6) host participating in both ".local." zones, and two different 653 hosts, one IPv4-only and the other IPv6-only, which are both trying 654 to use the same name(s). Such a mechanism will be specified in a 655 future companion document. 657 6. Security Considerations 659 6.1. Authenticity 661 A service proves its presence on a link by its ability to answer 662 link-local multicast queries on that link. If greater security is 663 desired, then the Hybrid Proxy mechanism should not be used, and 664 something with stronger security should be used instead, such as 665 authenticated secure DNS Update [RFC2136] [RFC3007]. 667 6.2. Privacy 669 The Domain Name System is, generally speaking, a global public 670 database. Records that exist in the Domain Name System name 671 hierarchy can be queried by name from, in principle, anywhere in the 672 world. If services on a mobile device (like a laptop computer) are 673 made visible via the Hybrid Proxy mechanism, then when those services 674 become visibile in a domain such as "My House.example.com" that might 675 indicate to (potentially hostile) observers that the mobile device is 676 in my house. When those services disappear from 677 "My House.example.com" that change could be used by observers to 678 infer when the mobile device (and possibly its owner) may have left 679 the house. The privacy of this information may be protected using 680 techniques like firewalls and split-view DNS, as are customarily used 681 today to protect the privacy of corporate DNS information. 683 6.3. Denial of Service 685 A remote attacker could use a rapid series of unique Unicast DNS 686 queries to induce a Hybrid Proxy to generate a rapid series of 687 corresponding Multicast DNS queries on one or more of its local 688 links. Multicast traffic is expensive -- especially on Wi-Fi links 689 -- which makes this attack particularly serious. To limit the damage 690 that can be caused by such attacks, a Hybrid Proxy (or the underlying 691 Multicast DNS subsystem which it utilizes) MUST implement Multicast 692 DNS query rate limiting appropriate to the link technology in 693 question. For Wi-Fi links the Multicast DNS subsystem SHOULD NOT 694 issue more than 20 Multicast DNS query packets per second. On other 695 link technologies like Gigabit Ethernet higher limits may be 696 appropriate. 698 7. Intelectual Property Rights 700 Apple has submitted an IPR disclosure concerning the technique 701 proposed in this document. Details are available on the IETF IPR 702 disclosure page [IPR2119]. 704 8. IANA Considerations 706 This document has no IANA Considerations. 708 9. Acknowledgments 710 Thanks to Markus Stenberg for helping develop the policy regarding 711 the four styles of unicast response according to what data is 712 immediately available in the cache. Thanks to Andrew Yourtchenko for 713 comments about privacy issues. [Partial list; more names to be 714 added.] 716 10. References 718 10.1. Normative References 720 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 721 STD 13, RFC 1034, November 1987. 723 [RFC1035] Mockapetris, P., "Domain names - implementation and 724 specification", STD 13, RFC 1035, November 1987. 726 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 727 E. Lear, "Address Allocation for Private Internets", 728 BCP 5, RFC 1918, February 1996. 730 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 731 Requirement Levels", BCP 14, RFC 2119, March 1997. 733 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 734 Configuration of IPv4 Link-Local Addresses", RFC 3927, 735 May 2005. 737 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 738 Address Autoconfiguration", RFC 4862, September 2007. 740 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 741 Interchange", RFC 5198, March 2008. 743 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 744 December 2012. 746 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 747 Discovery", RFC 6763, December 2012. 749 [I-D.sekar-dns-llq] 750 Sekar, K., "DNS Long-Lived Queries", 751 draft-sekar-dns-llq-01 (work in progress), August 2006. 753 10.2. Informative References 755 [HOME] Cheshire, S., "Special Use Top Level Domain 'home'", 756 draft-cheshire-homenet-dot-home (work in progress), 757 November 2014. 759 [IPR2119] "Apple Inc.'s Statement about IPR related to Hybrid 760 Unicast/Multicast DNS-Based Service Discovery", 761 . 763 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 764 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 765 RFC 2136, April 1997. 767 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 768 Update", RFC 3007, November 2000. 770 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 771 to Replace the AppleTalk Name Binding Protocol (NBP)", 772 RFC 6760, December 2012. 774 [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration 775 Networking: The Definitive Guide", O'Reilly Media, Inc. , 776 ISBN 0-596-10100-7, December 2005. 778 Author's Address 780 Stuart Cheshire 781 Apple Inc. 782 1 Infinite Loop 783 Cupertino, California 95014 784 USA 786 Phone: +1 408 974 3207 787 Email: cheshire@apple.com