draft-ietf-dnssd-hybrid-03.txt   draft-ietf-dnssd-hybrid-04.txt 
Internet Engineering Task Force S. Cheshire Internet Engineering Task Force S. Cheshire
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Standards Track February 4, 2016 Intended status: Standards Track October 31, 2016
Expires: August 7, 2016 Expires: May 4, 2017
Hybrid Unicast/Multicast DNS-Based Service Discovery Hybrid Unicast/Multicast DNS-Based Service Discovery
draft-ietf-dnssd-hybrid-03 draft-ietf-dnssd-hybrid-04
Abstract Abstract
Performing DNS-Based Service Discovery using purely link-local Performing DNS-Based Service Discovery using purely link-local
Multicast DNS enables discovery of services that are on the local Multicast DNS enables discovery of services that are on the local
link, but not (without some kind of proxy or similar special support) link, but not (without some kind of proxy or similar special support)
discovery of services that are outside the local link. Using a very discovery of services that are outside the local link. Using a very
large local link with thousands of hosts facilitates service large local link with thousands of hosts facilitates service
discovery, but at the cost of large amounts of multicast traffic. discovery, but at the cost of large amounts of multicast traffic.
skipping to change at page 2, line 6 skipping to change at page 2, line 6
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 7, 2016. This Internet-Draft will expire on May 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology Used in this Document . . . . . . 5 2. Conventions and Terminology Used in this Document . . . . . . 5
3. Compatibility Considerations . . . . . . . . . . . . . . . . . 5 3. Compatibility Considerations . . . . . . . . . . . . . . . . . 6
4. Hybrid Proxy Operation . . . . . . . . . . . . . . . . . . . . 6 4. Hybrid Proxy Operation . . . . . . . . . . . . . . . . . . . . 6
4.1. Delegated Subdomain for Service Discovery Records . . . . 7 4.1. Delegated Subdomain for Service Discovery Records . . . . 7
4.2. Domain Enumeration . . . . . . . . . . . . . . . . . . . . 8 4.2. Domain Enumeration . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Domain Enumeration via Unicast Queries . . . . . . . . 8 4.2.1. Domain Enumeration via Unicast Queries . . . . . . . . 8
4.2.2. Domain Enumeration via Multicast Queries . . . . . . . 9 4.2.2. Domain Enumeration via Multicast Queries . . . . . . . 9
4.3. Delegated Subdomain for LDH Host Names . . . . . . . . . . 10 4.3. Delegated Subdomain for LDH Host Names . . . . . . . . . . 10
4.4. Delegated Subdomain for Reverse Mapping . . . . . . . . . 12 4.4. Delegated Subdomain for Reverse Mapping . . . . . . . . . 12
4.5. Data Translation . . . . . . . . . . . . . . . . . . . . . 13 4.5. Data Translation . . . . . . . . . . . . . . . . . . . . . 13
4.5.1. DNS TTL limiting . . . . . . . . . . . . . . . . . . . 13 4.5.1. DNS TTL limiting . . . . . . . . . . . . . . . . . . . 13
4.5.2. Suppressing Unusable Records . . . . . . . . . . . . . 14 4.5.2. Suppressing Unusable Records . . . . . . . . . . . . . 14
4.5.3. Application-Specific Data Translation . . . . . . . . 15 4.5.3. Text Encoding Translation . . . . . . . . . . . . . . 14
4.5.4. Application-Specific Data Translation . . . . . . . . 15
4.6. Answer Aggregation . . . . . . . . . . . . . . . . . . . . 16 4.6. Answer Aggregation . . . . . . . . . . . . . . . . . . . . 16
4.6.1. Discovery of LLQ and/or PUSH Notification Service . . 19 5. DNS SOA (Start of Authority) Record . . . . . . . . . . . . . 19
5. DNS SOA (Start of Authority) Record . . . . . . . . . . . . . 20 6. DNSSEC Issues . . . . . . . . . . . . . . . . . . . . . . . . 20
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 6.1. On-line signing only . . . . . . . . . . . . . . . . . . . 20
6.1. Already Implemented and Deployed . . . . . . . . . . . . . 20 6.2. NSEC and NSEC3 Records . . . . . . . . . . . . . . . . . . 20
6.2. Already Implemented . . . . . . . . . . . . . . . . . . . 21 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
6.3. Partially Implemented . . . . . . . . . . . . . . . . . . 21 7.1. Already Implemented and Deployed . . . . . . . . . . . . . 21
6.4. Not Yet Implemented . . . . . . . . . . . . . . . . . . . 21 7.2. Already Implemented . . . . . . . . . . . . . . . . . . . 21
7. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 22 7.3. Partially Implemented . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7.4. Not Yet Implemented . . . . . . . . . . . . . . . . . . . 22
8.1. Authenticity . . . . . . . . . . . . . . . . . . . . . . . 22 8. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 23 9.1. Authenticity . . . . . . . . . . . . . . . . . . . . . . . 23
9. Intelectual Property Rights . . . . . . . . . . . . . . . . . 23 9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 10. Intelectual Property Rights . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . . 24 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Multicast DNS [RFC6762] and its companion technology DNS-based Multicast DNS [RFC6762] and its companion technology DNS-based
Service Discovery [RFC6763] were created to provide IP networking Service Discovery [RFC6763] were created to provide IP networking
with the ease-of-use and autoconfiguration for which AppleTalk was with the ease-of-use and autoconfiguration for which AppleTalk was
well known [RFC6760] [ZC]. well known [RFC6760] [ZC].
For a small network consisting of just a single link (or several For a small network consisting of just a single link (or several
physical links bridged together to appear as a single logical link to physical links bridged together to appear as a single logical link to
skipping to change at page 5, line 5 skipping to change at page 4, line 45
discusses various possible ways that a service's PTR, SRV, TXT and discusses various possible ways that a service's PTR, SRV, TXT and
address records can make their way into the Unicast DNS namespace, address records can make their way into the Unicast DNS namespace,
including manual zone file configuration [RFC1034] [RFC1035], including manual zone file configuration [RFC1034] [RFC1035],
DNS Update [RFC2136] [RFC3007] and proxies of various kinds. DNS Update [RFC2136] [RFC3007] and proxies of various kinds.
This document specifies a type of proxy called a Hybrid Proxy that This document specifies a type of proxy called a Hybrid Proxy that
uses Multicast DNS [RFC6762] to discover Multicast DNS records on its uses Multicast DNS [RFC6762] to discover Multicast DNS records on its
local link, and makes corresponding DNS records visible in the local link, and makes corresponding DNS records visible in the
Unicast DNS namespace. Unicast DNS namespace.
In simple terms, a descriptive DNS name is chosen for each physical
link in an organization. Using a DNS NS record, responsibility for
that DNS name is delegated to a Hybrid Proxy physically attached to
that link. Now, when a remote client issues a unicast query for a
name falling within the delegated subdomain, the normal DNS
delegation mechanism results in the unicast query arriving at the
Hybrid Proxy, since it has been declared authoritative for those
names. Now, instead of consulting a textual zone file on disk to
discover the answer to the query, as a traditional DNS server would,
a Hybrid Proxy consults its local link, using Multicast DNS, to find
the answer to the question.
Note that the Hybrid Proxy uses a "pull" model. The local link is
not queried using Multicast DNS until a remote client has requested
that data. In the idle state, in the absence of client requests, the
Hybrid Proxy sends no packets and imposes no burden on the network.
It operates purely "on demand".
An alternative proposal has been a proxy that performs DNS updates to
a remote DNS server on behalf of the Multicast DNS devices on the
local network. The difficulty of this is that the proxy would have
to be issuing all possible Multicast DNS queries all the time, to
discover all the answers it needed to push up to the remote DNS
server using DNS Update. It would thus generate very high load on
the network continuously, even when there were no clients with any
interest in that data.
Hence, having a model where the query comes to the Hybrid Proxy is
much more efficient than a model where the Hybrid Proxy pushes the
answers out to some other remote DNS server.
A client can send queries to the Hybrid Proxy in the form of
traditional DNS queries, or by making a DNS Push Notification
subscription [I-D.ietf-dnssd-push].
2. Conventions and Terminology Used in this Document 2. Conventions and Terminology Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
"Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
The Hybrid Proxy builds on Multicast DNS, which works between hosts The Hybrid Proxy builds on Multicast DNS, which works between hosts
on the same link. A set of hosts is considered to be "on the same on the same link. A set of hosts is considered to be "on the same
link" if: link" if:
skipping to change at page 14, line 37 skipping to change at page 14, line 37
about Long-Lived Queries, and its newer replacement, DNS Push about Long-Lived Queries, and its newer replacement, DNS Push
Notifications, see Section 4.6. Notifications, see Section 4.6.
4.5.2. Suppressing Unusable Records 4.5.2. Suppressing Unusable Records
A Hybrid Proxy SHOULD suppress Unicast DNS answers for records that A Hybrid Proxy SHOULD suppress Unicast DNS answers for records that
are not useful outside the local link. For example, DNS A and AAAA are not useful outside the local link. For example, DNS A and AAAA
records for IPv6 link-local addresses [RFC4862] and IPv4 link-local records for IPv6 link-local addresses [RFC4862] and IPv4 link-local
addresses [RFC3927] should be suppressed. Similarly, for sites that addresses [RFC3927] should be suppressed. Similarly, for sites that
have multiple private address realms [RFC1918], private addresses have multiple private address realms [RFC1918], private addresses
from one private address realm should not be communicated to clients from one private address realm SHOULD NOT be communicated to clients
in a different private address realm. in a different private address realm.
By the same logic, DNS SRV records that reference target host names By the same logic, DNS SRV records that reference target host names
that have no addresses usable by the requester should be suppressed, that have no addresses usable by the requester should be suppressed,
and likewise, DNS PTR records that point to unusable SRV records and likewise, DNS PTR records that point to unusable SRV records
should be similarly be suppressed. should be similarly be suppressed.
4.5.3. Application-Specific Data Translation 4.5.3. Text Encoding Translation
A Hybrid Proxy does no translation between text encodings.
Specifically, a Hybrid Proxy does no translation between Punycode and
UTF-8, either in the owner name of DNS records, or anywhere in the
RDATA of DNS records (such as the RDATA of PTR records, SRV records,
NS records, or other record types like TXT, where it is ambiguous
whether the RDATA may contain DNS names). All bytes are treated
as-is, with no attempt at text encoding translation. A client
implementing DNS-based Service Discovery [RFC6763] will use UTF-8
encoding for its service discovery queries, which the Hybrid Proxy
passes through without any text encoding translation to the Multicast
DNS subsystem. Responses from the Multicast DNS subsystem are
similarly returned, without any text encoding translation, back to
the requesting client.
4.5.4. Application-Specific Data Translation
There may be cases where Application-Specific Data Translation is There may be cases where Application-Specific Data Translation is
appropriate. appropriate.
For example, AirPrint printers tend to advertise fairly verbose For example, AirPrint printers tend to advertise fairly verbose
information about their capabilities in their DNS-SD TXT record. TXT information about their capabilities in their DNS-SD TXT record. TXT
record sizes in the range 500-1000 bytes are not uncommon. This record sizes in the range 500-1000 bytes are not uncommon. This
information is a legacy from LPR printing, because LPR does not have information is a legacy from LPR printing, because LPR does not have
in-band capability negotiation, so all of this information is in-band capability negotiation, so all of this information is
conveyed using the DNS-SD TXT record instead. IPP printing does have conveyed using the DNS-SD TXT record instead. IPP printing does have
skipping to change at page 17, line 26 skipping to change at page 17, line 34
of the device responding to the Multicast DNS query. If the of the device responding to the Multicast DNS query. If the
Multicast DNS device responds quickly, then the update message is Multicast DNS device responds quickly, then the update message is
delivered quickly. If the Multicast DNS device responds slowly, then delivered quickly. If the Multicast DNS device responds slowly, then
the update message is delivered slowly. The benefit of using update the update message is delivered slowly. The benefit of using update
messages is that the Hybrid Proxy can respond promptly because it messages is that the Hybrid Proxy can respond promptly because it
doesn't have to delay its unicast response to allow for the expected doesn't have to delay its unicast response to allow for the expected
worst-case delay for receiving all the Multicast DNS responses. Even worst-case delay for receiving all the Multicast DNS responses. Even
if a proxy were to try to provide reliability by assuming an if a proxy were to try to provide reliability by assuming an
excessively pessimistic worst-case time (thereby giving a very poor excessively pessimistic worst-case time (thereby giving a very poor
user experience) there would still be the risk of a slow Multicast user experience) there would still be the risk of a slow Multicast
DNS device taking even longer than that (e.g, a device that is not DNS device taking even longer than that (e.g., a device that is not
even powered on until ten seconds after the initial query is even powered on until ten seconds after the initial query is
received) resulting in incomplete responses. Using update message received) resulting in incomplete responses. Using update message
solves this dilemma: even very late responses are not lost; they are solves this dilemma: even very late responses are not lost; they are
delivered in subsequent update messages. delivered in subsequent update messages.
There are two factors that determine specifically how responses are There are two factors that determine specifically how responses are
generated: generated:
The first factor is whether the query from the client included an LLQ The first factor is whether the query from the client included an LLQ
or DNS Push Notification option (typical with long-lived service or DNS Push Notification option (typical with long-lived service
browsing PTR queries) or not (typical with one-shot operations like browsing PTR queries) or not (typical with one-shot operations like
SRV or address record queries). Note that queries containing the LLQ SRV or address record queries). Note that queries containing the LLQ
or PUSH option are received directly from the client (see or PUSH option are received directly from the client. Queries
Section 4.6.1). Queries containing no LLQ or PUSH option are containing no LLQ or PUSH option are generally received via the
generally received via the client's configured recursive (caching) client's configured recursive (caching) name server.
name server.
The second factor is whether the Hybrid Proxy already has at least The second factor is whether the Hybrid Proxy already has at least
one record in its cache that positively answers the question. one record in its cache that positively answers the question.
o No LLQ or PUSH option; no answer in cache: o No LLQ or PUSH option; no answer in cache:
Issue an mDNS query, exactly as a local client would issue an mDNS Issue an mDNS query, exactly as a local client would issue an mDNS
query on the local link for the desired record name, type and query on the local link for the desired record name, type and
class, including retransmissions, as appropriate, according to the class, including retransmissions, as appropriate, according to the
established mDNS retransmission schedule [RFC6762]. As soon as established mDNS retransmission schedule [RFC6762]. As soon as
any Multicast DNS response packet is received that contains one or any Multicast DNS response packet is received that contains one or
skipping to change at page 19, line 5 skipping to change at page 19, line 24
continues to remain accurate even as the network environment continues to remain accurate even as the network environment
changes.) changes.)
DNS TTLs in responses are returned unmodified. DNS TTLs in responses are returned unmodified.
Note that the "negative responses" referred to above are "no error no Note that the "negative responses" referred to above are "no error no
answer" negative responses, not NXDOMAIN. This is because the Hybrid answer" negative responses, not NXDOMAIN. This is because the Hybrid
Proxy cannot know all the Multicast DNS domain names that may exist 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 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. child names that do exist, making it an "empty nonterminal" name.
4.6.1. Discovery of LLQ and/or PUSH Notification Service
To issue LLQ or PUSH queries, clients need to communicate directly
with the authoritative Hybrid Proxy. The procedure by which the
client locates the authoritative Hybrid Proxy is described in the LLQ
specification [I-D.sekar-dns-llq] and the DNS Push Notifications
specification [I-D.ietf-dnssd-push].
Briefly, the procedure is as follows:
To discover the LLQ service for a given domain name, a client first
performs DNS zone apex discovery, and then, having discovered <apex>,
the client then issues a DNS query for the SRV record with the name
_dns-llq._udp.<apex> to find the target host and port for the LLQ
service for that zone. By default LLQ service runs on UDP port 5352,
but since SRV records are used, the LLQ service can be offered on any
port.
To discover the DNS Push Notification service for a given domain
name, a client first performs DNS zone apex discovery, and then,
having discovered <apex>, the client then issues a DNS query for the
SRV record with the name _dns-push-tls._tcp.<apex> to find the target
host and port for the DNS Push Notification service for that zone.
By default DNS Push Notification service runs on TCP port 5352, but
since SRV records are used, the DNS Push Notification service can be
offered on any port.
A client performs DNS zone apex discovery using the procedure below:
1. The client issues a DNS query for the SOA record with the given
domain name.
2. A conformant recursive (caching) name server will either send a
positive response, or a negative response containing the SOA
record of the zone apex in the Authority Section.
3. If the name server sends a negative response that does not
contain the SOA record of the zone apex, the client trims the
first label off the given domain name and returns to step 1 to
try again.
By this method, the client iterates until it learns the name of the
zone apex, or (in pathological failure cases) reaches the root and
gives up.
Normal DNS caching is used to avoid repetitive queries on the wire.
5. DNS SOA (Start of Authority) Record 5. DNS SOA (Start of Authority) Record
The MNAME field SHOULD contain the host name of the Hybrid Proxy The MNAME field SHOULD contain the host name of the Hybrid Proxy
device (i.e., the same domain name as the rdata of the NS record device (i.e., the same domain name as the rdata of the NS record
delegating the relevant zone(s) to this Hybrid Proxy device). delegating the relevant zone(s) to this Hybrid Proxy device).
The RNAME field SHOULD contain the mailbox of the person responsible The RNAME field SHOULD contain the mailbox of the person responsible
for administering this Hybrid Proxy device. for administering this Hybrid Proxy device.
The SERIAL field SHOULD contain a sequence number that increments The SERIAL field MUST be zero.
each time the Hybrid Proxy returns an SOA record to any client.
[Author's note: Or maybe it could just be zero?]
Since zone transfers are undefined for Hybrid Proxy zones, the Since zone transfers are undefined for Hybrid Proxy zones, the
REFRESH, RETRY and EXPIRE fields have no useful meaning for Hybrid REFRESH, RETRY and EXPIRE fields have no useful meaning for Hybrid
Proxy zones. These fields SHOULD contain reasonable default values. Proxy zones. These fields SHOULD contain reasonable default values.
The RECOMMENDED values are: REFRESH 7200, RETRY 3600, EXPIRE 86400. The RECOMMENDED values are: REFRESH 7200, RETRY 3600, EXPIRE 86400.
The MINIMUM field (used to control the lifetime of negative cache The MINIMUM field (used to control the lifetime of negative cache
entries) SHOULD contain the value 10. The value of ten seconds is entries) SHOULD contain the value 10. The value of ten seconds is
chosen based on user experience considerations (see Section 4.5.1). chosen based on user experience considerations (see Section 4.5.1).
[Author's note: Discussion of these recommendations is requested.] 6. DNSSEC Issues
6. Implementation Status 6.1. On-line signing only
Auth server must possess key, to generate signed data from mDNS
responses. Therefore off-line signing not applicable to Hybrid
Proxy.
6.2. NSEC and NSEC3 Records
In DNSSEC, NSEC and NSEC3 records are used to assert the nonexistence
of certain names, also described as "authenticated denial of
existence".
Since a Hybrid Proxy only knows what names exist on the local 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 exist
and which do not, a Hybrid Proxy cannot programatically synthesize
the traditional NSEC and NSEC3 records which assert the nonexistence
of a large range names. Instead, when generating a negative
response, a Hybrid Proxy programatically synthesizes a single NSEC
record assert the nonexistence of just the specific name queried, and
no others. Since the Hybrid Proxy has the zone signing key, it can
do this on demand. Since the NSEC record asserts the nonexistence of
only a single name, zone walking is not a concern, so NSEC3 is not
necessary. Note that this applies only to traditional immediate DNS
queries, which may return immediate negative answers when no
immediate positive answer is available. When used with a DNS Push
Notification subscription [I-D.ietf-dnssd-push] there are no negative
answers, merely the absence of answers so far, which may change in
the future if answers become available.
7. Implementation Status
Some aspects of the mechanism specified in this document already Some aspects of the mechanism specified in this document already
exist in deployed software. Some aspects are new. This section exist in deployed software. Some aspects are new. This section
outlines which aspects already exist and which are new. outlines which aspects already exist and which are new.
6.1. Already Implemented and Deployed 7.1. Already Implemented and Deployed
Domain enumeration by the client (the "b._dns-sd._udp" queries) is Domain enumeration by the client (the "b._dns-sd._udp" queries) is
already implemented and deployed. already implemented and deployed.
Unicast queries to the indicated discovery domain is already Unicast queries to the indicated discovery domain is already
implemented and deployed. implemented and deployed.
These are implemented and deployed in Mac OS X 10.4 and later These are implemented and deployed in Mac OS X 10.4 and later
(including all versions of Apple iOS, on all iPhone and iPads), in (including all versions of Apple iOS, on all iPhone and iPads), in
Bonjour for Windows, and in Android 4.1 "Jelly Bean" (API Level 16) Bonjour for Windows, and in Android 4.1 "Jelly Bean" (API Level 16)
and later. and later.
Domain enumeration and unicast querying have been used for several Domain enumeration and unicast querying have been used for several
years at IETF meetings to make Terminal Room printers discoverable years at IETF meetings to make Terminal Room printers discoverable
from outside the Terminal room. When you Press Cmd-P on your Mac, or from outside the Terminal room. When you Press Cmd-P on your Mac, or
select AirPrint on your iPad or iPhone, and the Terminal room select AirPrint on your iPad or iPhone, and the Terminal room
printers appear, that is because your client is sending unicast DNS printers appear, that is because your client is sending unicast DNS
queries to the IETF DNS servers. queries to the IETF DNS servers.
6.2. Already Implemented 7.2. Already Implemented
A minimal portable Hybrid Proxy implementation has been produced by A minimal portable Hybrid Proxy implementation has been produced by
Markus Stenberg and Steven Barth, which runs on OS X and several Markus Stenberg and Steven Barth, which runs on OS X and several
Linux variants including OpenWrt [ohp]. It was demonstrated at the Linux variants including OpenWrt [ohp]. It was demonstrated at the
Berlin IETF in July 2013. Berlin IETF in July 2013.
Tom Pusateri also has an implementation that runs on any Unix/Linux. Tom Pusateri also has an implementation that runs on any Unix/Linux.
It has a RESTful interface for management and an experimental demo It has a RESTful interface for management and an experimental demo
CLI and web interface. CLI and web interface.
6.3. Partially Implemented 7.3. Partially Implemented
The current APIs make multiple domains visible to client software, The current APIs make multiple domains visible to client software,
but most client UI today lumps all discovered services into a single but most client UI today lumps all discovered services into a single
flat list. This is largely a chicken-and-egg problem. Application flat list. This is largely a chicken-and-egg problem. Application
writers were naturally reluctant to spend time writing domain-aware writers were naturally reluctant to spend time writing domain-aware
UI code when few customers today would benefit from it. If Hybrid UI code when few customers today would benefit from it. If Hybrid
Proxy deployment becomes common, then application writers will have a Proxy deployment becomes common, then application writers will have a
reason to provide better UI. Existing applications will work with reason to provide better UI. Existing applications will work with
the Hybrid Proxy, but will show all services in a single flat list. the Hybrid Proxy, but will show all services in a single flat list.
Applications with improved UI will group services by domain. Applications with improved UI will group services by domain.
skipping to change at page 21, line 44 skipping to change at page 22, line 19
[I-D.ietf-dnssd-push]. The pragmatic short-term deployment approach [I-D.ietf-dnssd-push]. The pragmatic short-term deployment approach
is for vendors to produce Hybrid Proxies that implement both the is for vendors to produce Hybrid Proxies that implement both the
deployed Long-Lived Query mechanism [I-D.sekar-dns-llq] (for today's deployed Long-Lived Query mechanism [I-D.sekar-dns-llq] (for today's
clients) and the new DNS Push Notifications mechanism clients) and the new DNS Push Notifications mechanism
[I-D.ietf-dnssd-push] as the preferred long-term direction. [I-D.ietf-dnssd-push] as the preferred long-term direction.
The translating/filtering Hybrid Proxy specified in this document. The translating/filtering Hybrid Proxy specified in this document.
Implementations are under development, and operational experience Implementations are under development, and operational experience
with these implementations has guided updates to this document. with these implementations has guided updates to this document.
6.4. Not Yet Implemented 7.4. Not Yet Implemented
Client implementations of the new DNS Push Notifications mechanism Client implementations of the new DNS Push Notifications mechanism
[I-D.ietf-dnssd-push] are currently underway. [I-D.ietf-dnssd-push] are currently underway.
A mechanism to 'stitch' together multiple ".local." zones so that A mechanism to 'stitch' together multiple ".local." zones so that
they appear as one. Such a mechanism will be specified in a future they appear as one. Such a stitching mechanism will be specified in
companion document. a future companion document. This stitching mechanism addresses the
issue that if a printer is physically moved from one link to another,
then conceptually the old service has disappeared from the DNS
namespace, and a new service with a similar name has appeared. This
stitching mechanism will allow a service to change its point of
attachment without changing the name by which it can be found.
7. IPv6 Considerations 8. IPv6 Considerations
An IPv6-only host and an IPv4-only host behave as "ships that pass in An IPv6-only host and an IPv4-only host behave as "ships that pass in
the night". Even if they are on the same Ethernet, neither is aware the night". Even if they are on the same Ethernet, neither is aware
of the other's traffic. For this reason, each physical link may have of the other's traffic. For this reason, each physical link may have
*two* unrelated ".local." zones, one for IPv6 and one for IPv4. *two* unrelated ".local." zones, one for IPv6 and one for IPv4.
Since for practical purposes, a group of IPv6-only hosts and a group Since for practical purposes, a group of IPv6-only hosts and a group
of IPv4-only hosts on the same Ethernet act as if they were on two of IPv4-only hosts on the same Ethernet act as if they were on two
entirely separate Ethernet segments, it is unsurprising that their entirely separate Ethernet segments, it is unsurprising that their
use of the ".local." zone should occur exactly as it would if they use of the ".local." zone should occur exactly as it would if they
really were on two entirely separate Ethernet segments. really were on two entirely separate Ethernet segments.
It will be desirable to have a mechanism to 'stitch' together these It will be desirable to have a mechanism to 'stitch' together these
two unrelated ".local." zones so that they appear as one. Such two unrelated ".local." zones so that they appear as one. Such
mechanism will need to be able to differentiate between a dual-stack mechanism will need to be able to differentiate between a dual-stack
(v4/v6) host participating in both ".local." zones, and two different (v4/v6) host participating in both ".local." zones, and two different
hosts, one IPv6-only and the other IPv4-only, which are both trying hosts, one IPv6-only and the other IPv4-only, which are both trying
to use the same name(s). Such a mechanism will be specified in a to use the same name(s). Such a mechanism will be specified in a
future companion document. future companion document.
8. Security Considerations 9. Security Considerations
8.1. Authenticity 9.1. Authenticity
A service proves its presence on a link by its ability to answer A service proves its presence on a link by its ability to answer
link-local multicast queries on that link. If greater security is link-local multicast queries on that link. If greater security is
desired, then the Hybrid Proxy mechanism should not be used, and desired, then the Hybrid Proxy mechanism should not be used, and
something with stronger security should be used instead, such as something with stronger security should be used instead, such as
authenticated secure DNS Update [RFC2136] [RFC3007]. authenticated secure DNS Update [RFC2136] [RFC3007].
8.2. Privacy 9.2. Privacy
The Domain Name System is, generally speaking, a global public The Domain Name System is, generally speaking, a global public
database. Records that exist in the Domain Name System name database. Records that exist in the Domain Name System name
hierarchy can be queried by name from, in principle, anywhere in the hierarchy can be queried by name from, in principle, anywhere in the
world. If services on a mobile device (like a laptop computer) are world. If services on a mobile device (like a laptop computer) are
made visible via the Hybrid Proxy mechanism, then when those services made visible via the Hybrid Proxy mechanism, then when those services
become visibile in a domain such as "My House.example.com" that might become visible in a domain such as "My House.example.com" that might
indicate to (potentially hostile) observers that the mobile device is indicate to (potentially hostile) observers that the mobile device is
in my house. When those services disappear from in my house. When those services disappear from
"My House.example.com" that change could be used by observers to "My House.example.com" that change could be used by observers to
infer when the mobile device (and possibly its owner) may have left infer when the mobile device (and possibly its owner) may have left
the house. The privacy of this information may be protected using the house. The privacy of this information may be protected using
techniques like firewalls and split-view DNS, as are customarily used techniques like firewalls and split-view DNS, as are customarily used
today to protect the privacy of corporate DNS information. today to protect the privacy of corporate DNS information.
8.3. Denial of Service 9.3. Denial of Service
A remote attacker could use a rapid series of unique Unicast DNS A remote attacker could use a rapid series of unique Unicast DNS
queries to induce a Hybrid Proxy to generate a rapid series of queries to induce a Hybrid Proxy to generate a rapid series of
corresponding Multicast DNS queries on one or more of its local corresponding Multicast DNS queries on one or more of its local
links. Multicast traffic is expensive -- especially on Wi-Fi links links. Multicast traffic is expensive -- especially on Wi-Fi links
-- which makes this attack particularly serious. To limit the damage -- which makes this attack particularly serious. To limit the damage
that can be caused by such attacks, a Hybrid Proxy (or the underlying that can be caused by such attacks, a Hybrid Proxy (or the underlying
Multicast DNS subsystem which it utilizes) MUST implement Multicast Multicast DNS subsystem which it utilizes) MUST implement Multicast
DNS query rate limiting appropriate to the link technology in DNS query rate limiting appropriate to the link technology in
question. For Wi-Fi links the Multicast DNS subsystem SHOULD NOT question. For Wi-Fi links the Multicast DNS subsystem SHOULD NOT
issue more than 20 Multicast DNS query packets per second. On other issue more than 20 Multicast DNS query packets per second. On other
link technologies like Gigabit Ethernet higher limits may be link technologies like Gigabit Ethernet higher limits may be
appropriate. appropriate.
9. Intelectual Property Rights 10. Intelectual Property Rights
Apple has submitted an IPR disclosure concerning the technique Apple has submitted an IPR disclosure concerning the technique
proposed in this document. Details are available on the IETF IPR proposed in this document. Details are available on the IETF IPR
disclosure page [IPR2119]. disclosure page [IPR2119].
10. IANA Considerations 11. IANA Considerations
This document has no IANA Considerations. This document has no IANA Considerations.
11. Acknowledgments 12. Acknowledgments
Thanks to Markus Stenberg for helping develop the policy regarding Thanks to Markus Stenberg for helping develop the policy regarding
the four styles of unicast response according to what data is the four styles of unicast response according to what data is
immediately available in the cache. Thanks to Anders Brandt and immediately available in the cache. Thanks to Anders Brandt, Tim
Andrew Yourtchenko for their comments. [Partial list; more names to Chown, Ralph Droms, Ray Hunter, Ted Lemon, Tom Pusateri, Markus
be added.] Stenberg, Dave Thaler, and Andrew Yourtchenko for their comments.
[Partial list; more names to be added.]
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., J. de Groot, [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., J. de Groot,
skipping to change at page 24, line 44 skipping to change at page 25, line 30
December 2012. December 2012.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, December 2012. Discovery", RFC 6763, December 2012.
[I-D.ietf-dnssd-push] [I-D.ietf-dnssd-push]
Pusateri, T. and S. Cheshire, "DNS Push Notifications", Pusateri, T. and S. Cheshire, "DNS Push Notifications",
draft-ietf-dnssd-push-03 (work in progress), draft-ietf-dnssd-push-03 (work in progress),
November 2015. November 2015.
12.2. Informative References 13.2. Informative References
[HOME] Cheshire, S., "Special Use Top Level Domain 'home'", [HOME] Cheshire, S., "Special Use Top Level Domain 'home'",
draft-cheshire-homenet-dot-home (work in progress), draft-cheshire-homenet-dot-home (work in progress),
November 2015. November 2015.
[IPR2119] "Apple Inc.'s Statement about IPR related to Hybrid [IPR2119] "Apple Inc.'s Statement about IPR related to Hybrid
Unicast/Multicast DNS-Based Service Discovery", Unicast/Multicast DNS-Based Service Discovery",
<https://datatracker.ietf.org/ipr/2119/>. <https://datatracker.ietf.org/ipr/2119/>.
[ohp] "Hybrid Proxy implementation for OpenWrt", [ohp] "Hybrid Proxy implementation for OpenWrt",
 End of changes. 33 change blocks. 
105 lines changed or deleted 145 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/