--- 1/draft-ietf-dnssd-hybrid-09.txt 2019-03-24 07:13:25.030557397 -0700 +++ 2/draft-ietf-dnssd-hybrid-10.txt 2019-03-24 07:13:25.146560190 -0700 @@ -1,18 +1,18 @@ Internet Engineering Task Force S. Cheshire Internet-Draft Apple Inc. -Intended status: Standards Track March 11, 2019 -Expires: September 12, 2019 +Intended status: Standards Track March 24, 2019 +Expires: September 25, 2019 Discovery Proxy for Multicast DNS-Based Service Discovery - draft-ietf-dnssd-hybrid-09 + draft-ietf-dnssd-hybrid-10 Abstract This document specifies a network proxy that uses Multicast DNS to automatically populate the wide-area unicast Domain Name System namespace with records describing devices and services found on the local link. Status of This Memo @@ -22,21 +22,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 12, 2019. + This Internet-Draft will expire on September 25, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -59,43 +59,43 @@ 5.2.2. Domain Enumeration via Multicast Queries . . . . . . 13 5.3. Delegated Subdomain for LDH Host Names . . . . . . . . . 14 5.4. Delegated Subdomain for Reverse Mapping . . . . . . . . . 16 5.5. Data Translation . . . . . . . . . . . . . . . . . . . . 18 5.5.1. DNS TTL limiting . . . . . . . . . . . . . . . . . . 18 5.5.2. Suppressing Unusable Records . . . . . . . . . . . . 19 5.5.3. NSEC and NSEC3 queries . . . . . . . . . . . . . . . 20 5.5.4. No Text Encoding Translation . . . . . . . . . . . . 20 5.5.5. Application-Specific Data Translation . . . . . . . . 21 5.6. Answer Aggregation . . . . . . . . . . . . . . . . . . . 23 - 6. Administrative DNS Records . . . . . . . . . . . . . . . . . 26 - 6.1. DNS SOA (Start of Authority) Record . . . . . . . . . . . 26 - 6.2. DNS NS Records . . . . . . . . . . . . . . . . . . . . . 27 - 6.3. DNS SRV Records . . . . . . . . . . . . . . . . . . . . . 27 - 7. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 28 - 7.1. On-line signing only . . . . . . . . . . . . . . . . . . 28 - 7.2. NSEC and NSEC3 Records . . . . . . . . . . . . . . . . . 28 - 8. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 29 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 - 9.1. Authenticity . . . . . . . . . . . . . . . . . . . . . . 30 - 9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 30 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 32 - 12.2. Informative References . . . . . . . . . . . . . . . . . 33 - Appendix A. Implementation Status . . . . . . . . . . . . . . . 36 - A.1. Already Implemented and Deployed . . . . . . . . . . . . 36 - A.2. Already Implemented . . . . . . . . . . . . . . . . . . . 36 - A.3. Partially Implemented . . . . . . . . . . . . . . . . . . 36 - A.4. Not Yet Implemented . . . . . . . . . . . . . . . . . . . 37 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37 + 6. Administrative DNS Records . . . . . . . . . . . . . . . . . 27 + 6.1. DNS SOA (Start of Authority) Record . . . . . . . . . . . 27 + 6.2. DNS NS Records . . . . . . . . . . . . . . . . . . . . . 28 + 6.3. DNS Delegation Records . . . . . . . . . . . . . . . . . 28 + 6.4. DNS SRV Records . . . . . . . . . . . . . . . . . . . . . 29 + 7. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 30 + 7.1. On-line signing only . . . . . . . . . . . . . . . . . . 30 + 7.2. NSEC and NSEC3 Records . . . . . . . . . . . . . . . . . 30 + 8. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 31 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 + 9.1. Authenticity . . . . . . . . . . . . . . . . . . . . . . 32 + 9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 32 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 + 12.2. Informative References . . . . . . . . . . . . . . . . . 35 + Appendix A. Implementation Status . . . . . . . . . . . . . . . 38 + A.1. Already Implemented and Deployed . . . . . . . . . . . . 38 + A.2. Already Implemented . . . . . . . . . . . . . . . . . . . 38 + A.3. Partially Implemented . . . . . . . . . . . . . . . . . . 39 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction Multicast DNS [RFC6762] and its companion technology DNS-based Service Discovery [RFC6763] were created to provide IP networking with the ease-of-use and autoconfiguration for which AppleTalk was well known [RFC6760] [ZC] [Roadmap]. For a small home network consisting of just a single link (or a few physical links bridged together to appear as a single logical link @@ -110,42 +110,42 @@ Multicast DNS packets, by design, are not propagated onto other links. Using link-local multicast packets for Multicast DNS was a conscious design choice [RFC6762]. Even when limited to a single link, multicast traffic is still generally considered to be more expensive than unicast, because multicast traffic impacts many devices, instead of just a single recipient. In addition, with some technologies like Wi-Fi [IEEE-11], multicast traffic is inherently less efficient and less reliable than unicast, because Wi-Fi multicast traffic is sent - at lower data rates, and is not acknowledged. Increasing the amount - of expensive multicast traffic by flooding it across multiple links - would make the traffic load even worse. + at lower data rates, and is not acknowledged [Mcast]. Increasing the + amount of expensive multicast traffic by flooding it across multiple + links would make the traffic load even worse. Partitioning the network into many small links curtails the spread of expensive multicast traffic, but limits the discoverability of services. At the opposite end of the spectrum, using a very large local link with thousands of hosts enables better service discovery, but at the cost of larger amounts of multicast traffic. Performing DNS-Based Service Discovery using purely Unicast DNS is more efficient and doesn't require large multicast domains, but does require that the relevant data be available in the Unicast DNS namespace. The Unicast DNS namespace in question could fall within a traditionally assigned globally unique domain name, or could use a - private local unicast domain name such as ".home.arpa" - [I-D.ietf-homenet-dot].) + private local unicast domain name such as ".home.arpa" [RFC8375]. In the DNS-SD specification [RFC6763], Section 10 ("Populating the DNS with Information") discusses various possible ways that a service's PTR, SRV, TXT and address records can make their way into the Unicast DNS namespace, including manual zone file configuration + [RFC1034] [RFC1035], DNS Update [RFC2136] [RFC3007] and proxies of various kinds. Making the relevant data available in the Unicast DNS namespace by manual DNS configuration is one option. This option has been used for many years at IETF meetings to advertise the IETF Terminal Room printer. Details of this example are given in Appendix A of the Roadmap document [Roadmap]. However, this manual DNS configuration is labor intensive, error prone, and requires a reasonable degree of DNS expertise. @@ -253,30 +253,32 @@ A similar analogy, instead of enlisting another human being to initiate the service discovery operation on your behalf, is to log into your own desktop work computer using screen sharing, and then run the printer browser yourself to see the list of printers. Or log in using ssh and type "dns-sd -B _ipp._tcp" and observe the list of discovered printer names. In neither case is there any risk of a forwarding loop causing a traffic storm, because no multicast packets are being sent over the screen sharing or ssh connection. The Discovery Proxy provides another way of performing remote - queries, just using a different protocol instead of screen sharing or - ssh. + queries, except using a different protocol instead of screen sharing + or ssh. When the Discovery Proxy software performs Multicast DNS operations, the exact same Multicast DNS caching mechanisms are applied as when any other client software on that Discovery Proxy device performs Multicast DNS operations, whether that be running a printer browser client locally, or a remote user running the printer browser client via a screen sharing connection, or a remote user logged in via ssh - running a command-line tool like "dns-sd". + running a command-line tool like "dns-sd", or a remote user sending + DNS requests that cause a Discovery Proxy to perform discovery + operations on its behalf. 3. Conventions and Terminology Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels", when, and only when, they appear in all capitals, as shown here [RFC2119] [RFC8174]. @@ -411,32 +413,53 @@ reaches the delegated authoritative name server for that subdomain, namely the Discovery Proxy on the link in question. Like a conventional Unicast DNS server, a Discovery Proxy implements the usual Unicast DNS protocol [RFC1034] [RFC1035] over UDP and TCP. However, unlike a conventional Unicast DNS server that generates answers from the data in its manually-configured zone file, a Discovery Proxy generates answers using Multicast DNS. A Discovery Proxy does this by consulting its Multicast DNS cache and/or issuing Multicast DNS queries, as appropriate, according to the usual protocol rules of Multicast DNS [RFC6762], for the corresponding - Multicast DNS name, type and class, (e.g., in this case, + Multicast DNS name, type and class, with the delegated zone part of + the name replaced with ".local" (e.g., in this case, "_printer._tcp.local. PTR ?"). Then, from the received Multicast DNS data, the Discovery Proxy synthesizes the appropriate Unicast DNS - response. How long the Discovery Proxy should wait to accumulate - Multicast DNS responses is described below in Section 5.6. + response, with the ".local" top-level label replaced with with the + name of the delegated zone. How long the Discovery Proxy should wait + to accumulate Multicast DNS responses before sending its unicast + reply is described below in Section 5.6. The existing Multicast DNS caching mechanism is used to minimize unnecessary Multicast DNS queries on the wire. The Discovery Proxy is acting as a client of the underlying Multicast DNS subsystem, and benefits from the same caching and efficiency measures as any other client using that subsystem. + Note that the contents of the delegated zone, generated as it is by + performing ".local" Multicast DNS queries, mirrors the records + available on the local link via Multicast DNS very closely, but not + precisely. There is not a full bidirectional equivalence between the + two. Certain records that are available via Multicast DNS may not + have equivalents in the delegated zone, possibly because they are + invalid or not relevant in the delegated zone, or because they are + being supressed because they are unusable outside the local link (see + Section 5.5.2). Conversely, certain records that appear in the + delegated zone may not have corresponding records available on the + local link via Multicast DNS. In particular there are certain + administrative SRV records (see Section 6) that logically fall within + the delegated zone, but semantically represent metadata *about* the + zone rather than records *within* the zone, and consequently these + administrative records in the delegated zone do not have any + corresponding counterparts in the Multicast DNS namespace of the + local link. + 5.2. Domain Enumeration A DNS-SD client performs Domain Enumeration [RFC6763] via certain PTR queries, using both unicast and multicast. If it receives a Domain Name configuration via DHCP option 15 [RFC2132], then it issues unicast queries using this domain. It issues unicast queries using names derived from its IPv4 subnet address(es) and IPv6 prefix(es). These are described below in Section 5.2.1. It also issues multicast Domain Enumeration queries in the "local" domain [RFC6762]. These are described below in Section 5.2.2. The results of all the Domain @@ -715,21 +738,21 @@ service shuts down gracefully, it sends goodbye packets to remove its PTR records immediately from neighboring caches. If a service shuts down abruptly without sending goodbye packets, the Passive Observation Of Failures (POOF) mechanism described in Section 10.5 of the Multicast DNS specification [RFC6762] comes into play to purge the cache of stale data. A traditional Unicast DNS client on a distant remote link does not get to participate in these Multicast DNS cache coherency mechanisms on the local link. For traditional Unicast DNS queries (those - received without using Long-Lived Query [DNS-LLQ] or DNS Push + received without using Long-Lived Query [LLQ] or DNS Push Notification subscriptions [Push]) the DNS TTLs reported in the resulting Unicast DNS response MUST be capped to be no more than ten seconds. Similarly, for negative responses, the negative caching TTL indicated in the SOA record [RFC2308] should also be ten seconds (Section 6.1). This value of ten seconds is chosen based on user-experience considerations. @@ -752,44 +775,50 @@ or other renumbering events, we would like the updated information to be available to remote clients in a relatively timely fashion. However, network administrators should be aware that many recursive (caching) DNS servers by default are configured to impose a minimum TTL of 30 seconds. If stale data appears to be persisting in the network to the extent that it adversely impacts user experience, network administrators are advised to check the configuration of their recursive DNS servers. - For received Unicast DNS queries that use LLQ [DNS-LLQ] or DNS Push + For received Unicast DNS queries that use LLQ [LLQ] or DNS Push Notifications [Push], the Multicast DNS record's TTL SHOULD be returned unmodified, because the Push Notification channel exists to inform the remote client as records come and go. For further details about Long-Lived Queries, and its newer replacement, DNS Push Notifications, see Section 5.6. 5.5.2. Suppressing Unusable Records - A Discovery Proxy SHOULD suppress Unicast DNS answers for records - that are not useful outside the local link. For example, DNS A and - AAAA records for IPv4 link-local addresses [RFC3927] and IPv6 link- - local addresses [RFC4862] SHOULD be suppressed. Similarly, for sites - that have multiple private address realms [RFC1918], in cases where - the Discovery Proxy can determine that the querying client is in a - different address realm, private addresses SHOULD NOT be communicated - to that client. IPv6 Unique Local Addresses [RFC4193] SHOULD be - suppressed in cases where the Discovery Proxy can determine that the - querying client is in a different IPv6 address realm. + A Discovery Proxy SHOULD offer a configurable option, enabled by + default, to suppress Unicast DNS answers for records that are not + useful outside the local link. When the option to suppress unusable + records is enabled: - By the same logic, DNS SRV records that reference target host names - that have no addresses usable by the requester should be suppressed, - and likewise, DNS PTR records that point to unusable SRV records - should be similarly be suppressed. + o DNS A and AAAA records for IPv4 link-local addresses [RFC3927] and + IPv6 link-local addresses [RFC4862] SHOULD be suppressed. + + o Similarly, for sites that have multiple private address realms + [RFC1918], in cases where the Discovery Proxy can determine that + the querying client is in a different address realm, private + addresses SHOULD NOT be communicated to that client. + + o IPv6 Unique Local Addresses [RFC4193] SHOULD be suppressed in + cases where the Discovery Proxy can determine that the querying + client is in a different IPv6 address realm. + + o By the same logic, DNS SRV records that reference target host + names that have no addresses usable by the requester should be + suppressed, and likewise, DNS PTR records that point to unusable + SRV records should be similarly be suppressed. 5.5.3. NSEC and NSEC3 queries Multicast DNS devices do not routinely announce their records on the network. Generally they remain silent until queried. This means that the complete set of Multicast DNS records in use on a link can only be discovered by active querying, not by passive listening. Because of this, a Discovery Proxy can only know what names exist on a link by issuing queries for them, and since it would be impractical to issue queries for every possible name just to find out which names @@ -913,21 +942,21 @@ the subdomain in question -- needs to decide what DNS TTL to report for these records. If the TTL is too long then the recursive (caching) name servers issuing queries on behalf of their clients risk caching stale data for too long. If the TTL is too short then the amount of network traffic will be more than necessary. In fact, there may be no TTL which is both short enough to avoid undesirable stale data and at the same time long enough to be efficient on the network. Both these dilemmas are solved by use of DNS Long-Lived Queries - (DNS LLQ) [DNS-LLQ] or its newer replacement, DNS Push Notifications + (DNS LLQ) [LLQ] or its newer replacement, DNS Push Notifications [Push]. Clients supporting unicast DNS Service Discovery SHOULD implement DNS Push Notifications [Push] for improved user experience. Clients and Discovery Proxies MAY support both DNS LLQ and DNS Push, and when talking to a Discovery Proxy that supports both, the client may use either protocol, as it chooses, though it is expected that only DNS Push will continue to be supported in the long run. @@ -976,23 +1005,24 @@ query on the local link for the desired record name, type and class, including retransmissions, as appropriate, according to the established mDNS retransmission schedule [RFC6762]. As soon as any Multicast DNS response packet is received that contains one or more positive answers to that question (with or without the Cache Flush bit [RFC6762] set), or a negative answer (signified via a Multicast DNS NSEC record [RFC6762]), the Discovery Proxy generates a Unicast DNS response packet containing the corresponding (filtered and translated) answers and sends it to the remote client. If after six seconds no Multicast DNS answers - have been received, return a negative response to the remote - client. Six seconds is enough time to transmit three mDNS - queries, and allow some time for responses to arrive. + have been received, cancel the mDNS query and return a negative + response to the remote client. Six seconds is enough time to + transmit three mDNS queries, and allow some time for responses to + arrive. DNS TTLs in responses MUST be capped to at most ten seconds. (Reasoning: Queries not using LLQ or Push Notifications are generally queries that that expect an answer from only one device, so the first response is also the only response.) o Not using LLQ or Push Notifications; at least one answer in cache: Send response right away to minimise delay. DNS TTLs in responses MUST be capped to at most ten seconds. No local mDNS queries are performed. (Reasoning: Queries not using LLQ or Push Notifications are @@ -1021,26 +1051,69 @@ The query remains active for as long as the client maintains the LLQ or Push Notification state, and results in transmission of mDNS queries, with appropriate Known Answer lists, to determine if further answers are available. If additional mDNS answers are received later, LLQ or Push Notification messages are sent. (Reasoning: We want UI that is displayed very rapidly, yet continues to remain accurate even as the network environment changes.) DNS TTLs in responses are returned unmodified. - Note that the "negative responses" referred to above are "no error no - answer" negative responses, not NXDOMAIN. This is because the - Discovery Proxy cannot know all the Multicast DNS domain names that - may exist on a link at any given time, so any name with no answers - may have child names that do exist, making it an "empty nonterminal" - name. + The "negative responses" referred to above are "no error no answer" + negative responses, not NXDOMAIN. This is because the Discovery + Proxy cannot know all the Multicast DNS domain names that may exist + on a link at any given time, so any name with no answers may have + child names that do exist, making it an "empty nonterminal" name. + + Note that certain aspects of the behavior described here do not have + to be implemented overtly by the Discovery Proxy; they occur + naturally as a result of using existing Multicast DNS APIs. + + For example, in the first case above (no LLQ or Push Notifications, + and no answers in the cache) if a new Multicast DNS query is + requested (either by a local client, or by the Discovery Proxy on + behalf of a remote client), and there is not already an identical + Multicast DNS query active, and there are no matching answers already + in the Multicast DNS cache on the Discovery Proxy device, then this + will cause a series of Multicast DNS query packets to be issued with + exponential backoff. The exponential backoff sequence in some + implementations starts at one second and then doubles for each + retransmission (0, 1, 3, 7 seconds, etc.) and in others starts at one + second and then triples for each retransmission (0, 1, 4, 13 seconds, + etc.). In either case, if no response has been received after six + seconds, that is long enough that the underlying Multicast DNS + implementation will have sent three query packets without receiving + any response. At that point the Discovery Proxy cancels its + Multicast DNS query (so no further Multicast DNS query packets will + be sent for this query) and returns a negative response to the remote + client via unicast. + + The six-second delay is chosen to be long enough to give enough time + for devices to respond, yet short enough not to be too onerous for a + human user waiting for a response. For example, using the "dig" DNS + debugging tool, the current default settings result in it waiting a + total of 15 seconds for a reply (three transmissions of the query + packet, with a wait of 5 seconds after each packet) which is ample + time for it to have received a negative reply from a Discovery Proxy + after six seconds. + + The statement that for a one-shot query (i.e., no LLQ or Push + Notifications requested), if at least one answer is already available + in the cache then a Discovery Proxy should not issue additional mDNS + query packets, also occurs naturally as a result of using existing + Multicast DNS APIs. If a new Multicast DNS query is requested + (either locally, or by the Discovery Proxy on behalf of a remote + client), for which there are relevant answers already in the + Multicast DNS cache on the Discovery Proxy device, and after the + answers are delivered the Multicast DNS query is then cancelled + immediately, then no Multicast DNS query packets will be generated + for this query. 6. Administrative DNS Records 6.1. DNS SOA (Start of Authority) Record The MNAME field SHOULD contain the host name of the Discovery Proxy device (i.e., the same domain name as the rdata of the NS record delegating the relevant zone(s) to this Discovery Proxy device). The RNAME field SHOULD contain the mailbox of the person responsible @@ -1062,49 +1135,81 @@ link for fault tolerance reasons, this will result in clients receiving inconsistent SOA records (different MNAME, and possibly RNAME) depending on which Discovery Proxy answers their SOA query. However, since clients generally have no reason to use the MNAME or RNAME data, this is unlikely to cause any problems. 6.2. DNS NS Records In the event that there are multiple Discovery Proxy devices on a link for fault tolerance reasons, the parent zone MUST be configured - with glue records giving the names and addresses of all the Discovery - Proxy devices on the link. + with NS records giving the names of all the Discovery Proxy devices + on the link. - Each Discovery Proxy device MUST be configured with its own NS - record, and with the NS records of its fellow Discovery Proxy devices - on the same link, so that it can return the correct answers for NS - queries. + Each Discovery Proxy device MUST be configured to answer NS queries + for the zone apex name by giving its own NS record, and the NS + records of its fellow Discovery Proxy devices on the same link, so + that it can return the correct answers for NS queries. -6.3. DNS SRV Records + The target host name in the RDATA of an NS record MUST NOT reference + a name that falls within any zone delegated to a Discovery Proxy. + Apart from the zone apex name, all other host names that fall within + a zone delegated to a Discovery Proxy correspond to local Multicast + DNS host names, which logically belong to the respective Multicast + DNS hosts defending those names, not the Discovery Proxy. Generally + speaking, the Discovery Proxy does not own or control the delegated + zone; it is merely a conduit to the corresponding ".local" namespace, + which is controlled by the Multicast DNS hosts on that link. If an + NS record were to reference a manually-determined host name that + falls within a delegated zone, that manually-determined host name may + inadvertently conflict with a corresponding ".local" host name that + is owned and controlled by some device on that link. + +6.3. DNS Delegation Records + + Since the Multicast DNS specification [RFC6762] states that there can + be no delegation (subdomains) within a ".local" namespace, this + implies that any name within a zone delegated to a Discovery Proxy + (except for the zone apex name itself) cannot have any answers for + any DNS queries for RRTYPEs SOA, NS, or DS. Consequently: + + o for any query for the zone apex name of a zone delegated to a + Discovery Proxy, the Discovery Proxy MUST generate the appropriate + immediate answers as described above, and + + o for any query for RRTYPEs SOA, NS, or DS, for any name within a + zone delegated to a Discovery Proxy, other than the zone apex + name, instead of translating the query to its corresponding + Multicast DNS ".local" equivalent, a Discovery Proxy MUST generate + an immediate negative answer. + +6.4. DNS SRV Records There are certain special DNS records that logically fall within the delegated unicast DNS subdomain, but rather than mapping to their corresponding ".local" namesakes, they actually contain metadata pertaining to the operation of the delegated unicast DNS subdomain itself. They do not exist in the corresponding ".local" namespace of the local link. For these queries a Discovery Proxy MUST generate immediate answers, whether positive or negative, to avoid delays while clients wait for their query to be answered. For example, if a - Discovery Proxy does not implement Long-Lived Queries [DNS-LLQ] then - it MUST return an immediate negative answer to tell the client this + Discovery Proxy does not implement Long-Lived Queries [LLQ] then it + MUST return an immediate negative answer to tell the client this without delay, instead of passing the query through to the local network as a query for "_dns-llq._udp.local.", and then waiting unsuccessfully for answers that will not be forthcoming. - If a Discovery Proxy implements Long-Lived Queries [DNS-LLQ] then it - MUST positively respond to "_dns-llq._udp. SRV" queries, - "_dns-llq._tcp. SRV" queries, and "_dns-llq-tls._tcp. - SRV" queries as appropriate, else it MUST return an immediate - negative answer for those queries. + If a Discovery Proxy implements Long-Lived Queries [LLQ] then it MUST + positively respond to "_dns-llq._udp. SRV" queries, + "_dns-llq._tcp. SRV" queries, and + "_dns-llq-tls._tcp. SRV" queries as appropriate, else it MUST + return an immediate negative answer for those queries. If a Discovery Proxy implements DNS Push Notifications [Push] then it MUST positively respond to "_dns-push-tls._tcp." queries, else it MUST return an immediate negative answer for those queries. A Discovery Proxy MUST return an immediate negative answer for "_dns-update._udp. SRV" queries, "_dns-update._tcp. SRV" queries, and "_dns-update-tls._tcp. SRV" queries, since using DNS Update [RFC2136] to change zones generated dynamically from local Multicast DNS data is not possible. @@ -1309,53 +1414,53 @@ editor.org/info/rfc6762>. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . - [Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", - draft-ietf-dnssd-push-14 (work in progress), March 2018. - - [DSO] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., + [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., Lemon, T., and T. Pusateri, "DNS Stateful Operations", - draft-ietf-dnsop-session-signal-07 (work in progress), - March 2018. + RFC 8490, DOI 10.17487/RFC8490, March 2019, + . -12.2. Informative References + [Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", + draft-ietf-dnssd-push-19 (work in progress), March 2019. - [I-D.ietf-homenet-dot] - Pfister, P. and T. Lemon, "Special Use Domain - 'home.arpa.'", draft-ietf-homenet-dot-14 (work in - progress), September 2017. +12.2. Informative References [Roadmap] Cheshire, S., "Service Discovery Road Map", draft- cheshire-dnssd-roadmap-03 (work in progress), October 2018. [DNS-UL] Sekar, K., "Dynamic DNS Update Leases", draft-sekar-dns- ul-01 (work in progress), August 2006. - [DNS-LLQ] Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns- - llq-01 (work in progress), August 2006. + [LLQ] Cheshire, S. and M. Krochmal, "DNS Long-Lived Queries", + draft-sekar-dns-llq-03 (work in progress), March 2019. [RegProt] Cheshire, S. and T. Lemon, "Service Registration Protocol for DNS-Based Service Discovery", draft-sctl-service- registration-00 (work in progress), July 2017. [Relay] Cheshire, S. and T. Lemon, "Multicast DNS Discovery Relay", draft-sctl-dnssd-mdns-relay-04 (work in progress), March 2018. + [Mcast] Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. + Zuniga, "Multicast Considerations over IEEE 802 Wireless + Media", draft-ietf-mboned-ieee802-mcast-problems-04 (work + in progress), November 2018. + [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, . [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, . [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic @@ -1383,20 +1488,24 @@ editor.org/info/rfc7558>. [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, . [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, . + [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain + 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, + . + [ohp] "Discovery Proxy (Hybrid Proxy) implementation for OpenWrt", . [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration Networking: The Definitive Guide", O'Reilly Media, Inc. , ISBN 0-596-10100-7, December 2005. [IEEE-1Q] "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", IEEE Std 802.1Q-2014, November 2014,