< draft-ietf-dnssd-hybrid-08.txt   draft-ietf-dnssd-hybrid-09.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 March 18, 2018 Intended status: Standards Track March 11, 2019
Expires: September 19, 2018 Expires: September 12, 2019
Discovery Proxy for Multicast DNS-Based Service Discovery Discovery Proxy for Multicast DNS-Based Service Discovery
draft-ietf-dnssd-hybrid-08 draft-ietf-dnssd-hybrid-09
Abstract Abstract
This document specifies a network proxy that uses Multicast DNS to This document specifies a network proxy that uses Multicast DNS to
automatically populate the wide-area unicast Domain Name System automatically populate the wide-area unicast Domain Name System
namespace with records describing devices and services found on the namespace with records describing devices and services found on the
local link. local link.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 September 19, 2018. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 10, line 17 skipping to change at page 10, line 17
(e.g., "_printer._tcp.Building 1.example.com. PTR ?") the normal DNS (e.g., "_printer._tcp.Building 1.example.com. PTR ?") the normal DNS
delegation mechanism results in that query being forwarded until it delegation mechanism results in that query being forwarded until it
reaches the delegated authoritative name server for that subdomain, reaches the delegated authoritative name server for that subdomain,
namely the Discovery Proxy on the link in question. Like a namely the Discovery Proxy on the link in question. Like a
conventional Unicast DNS server, a Discovery Proxy implements the conventional Unicast DNS server, a Discovery Proxy implements the
usual Unicast DNS protocol [RFC1034] [RFC1035] over UDP and TCP. usual Unicast DNS protocol [RFC1034] [RFC1035] over UDP and TCP.
However, unlike a conventional Unicast DNS server that generates However, unlike a conventional Unicast DNS server that generates
answers from the data in its manually-configured zone file, a answers from the data in its manually-configured zone file, a
Discovery Proxy generates answers using Multicast DNS. A Discovery Discovery Proxy generates answers using Multicast DNS. A Discovery
Proxy does this by consulting its Multicast DNS cache and/or issuing Proxy does this by consulting its Multicast DNS cache and/or issuing
Multicast DNS queries for the corresponding Multicast DNS name, type Multicast DNS queries, as appropriate, according to the usual
and class, (e.g., in this case, "_printer._tcp.local. PTR ?"). Then, protocol rules of Multicast DNS [RFC6762], for the corresponding
from the received Multicast DNS data, the Discovery Proxy synthesizes Multicast DNS name, type and class, (e.g., in this case,
the appropriate Unicast DNS response. How long the Discovery Proxy "_printer._tcp.local. PTR ?"). Then, from the received Multicast DNS
should wait to accumulate Multicast DNS responses is described below data, the Discovery Proxy synthesizes the appropriate Unicast DNS
in Section 5.6. response. How long the Discovery Proxy should wait to accumulate
Multicast DNS responses is described below in Section 5.6.
The existing Multicast DNS caching mechanism is used to minimize The existing Multicast DNS caching mechanism is used to minimize
unnecessary Multicast DNS queries on the wire. The Discovery Proxy unnecessary Multicast DNS queries on the wire. The Discovery Proxy
is acting as a client of the underlying Multicast DNS subsystem, and is acting as a client of the underlying Multicast DNS subsystem, and
benefits from the same caching and efficiency measures as any other benefits from the same caching and efficiency measures as any other
client using that subsystem. client using that subsystem.
5.2. Domain Enumeration 5.2. Domain Enumeration
A DNS-SD client performs Domain Enumeration [RFC6763] via certain PTR A DNS-SD client performs Domain Enumeration [RFC6763] via certain PTR
skipping to change at page 27, line 19 skipping to change at page 27, line 19
with glue records giving the names and addresses of all the Discovery with glue records giving the names and addresses of all the Discovery
Proxy devices on the link. Proxy devices on the link.
Each Discovery Proxy device MUST be configured with its own NS Each Discovery Proxy device MUST be configured with its own NS
record, and with the NS records of its fellow Discovery Proxy devices 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 on the same link, so that it can return the correct answers for NS
queries. queries.
6.3. DNS SRV Records 6.3. DNS SRV Records
In the event that a Discovery Proxy implements Long-Lived Queries There are certain special DNS records that logically fall within the
[DNS-LLQ] and/or DNS Push Notifications [Push] (as most SHOULD) they delegated unicast DNS subdomain, but rather than mapping to their
MUST generate answers for the appropriate corresponding corresponding ".local" namesakes, they actually contain metadata
_dns-llq._udp.<zone> and/or _dns-push-tls._tcp.<zone> SRV record pertaining to the operation of the delegated unicast DNS subdomain
queries. These records are conceptually inserted into the namespace itself. They do not exist in the corresponding ".local" namespace of
of the relevant zones. They do not exist in the corresponding the local link. For these queries a Discovery Proxy MUST generate
".local" namespace of the local link. 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
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.<zone> SRV" queries,
"_dns-llq._tcp.<zone> SRV" queries, and "_dns-llq-tls._tcp.<zone>
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.<zone>" 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.<zone> SRV" queries, "_dns-update._tcp.<zone> SRV"
queries, and "_dns-update-tls._tcp.<zone> SRV" queries, since using
DNS Update [RFC2136] to change zones generated dynamically from local
Multicast DNS data is not possible.
7. DNSSEC Considerations 7. DNSSEC Considerations
7.1. On-line signing only 7.1. On-line signing only
The Discovery Proxy acts as the authoritative name server for The Discovery Proxy acts as the authoritative name server for
designated subdomains, and if DNSSEC is to be used, the Discovery designated subdomains, and if DNSSEC is to be used, the Discovery
Proxy needs to possess a copy of the signing keys, in order to Proxy needs to possess a copy of the signing keys, in order to
generate authoritative signed data from the local Multicast DNS generate authoritative signed data from the local Multicast DNS
responses it receives. Off-line signing is not applicable to responses it receives. Off-line signing is not applicable to
skipping to change at page 33, line 42 skipping to change at page 33, line 42
March 2018. March 2018.
12.2. Informative References 12.2. Informative References
[I-D.ietf-homenet-dot] [I-D.ietf-homenet-dot]
Pfister, P. and T. Lemon, "Special Use Domain Pfister, P. and T. Lemon, "Special Use Domain
'home.arpa.'", draft-ietf-homenet-dot-14 (work in 'home.arpa.'", draft-ietf-homenet-dot-14 (work in
progress), September 2017. progress), September 2017.
[Roadmap] Cheshire, S., "Service Discovery Road Map", draft- [Roadmap] Cheshire, S., "Service Discovery Road Map", draft-
cheshire-dnssd-roadmap-01 (work in progress), March 2018. cheshire-dnssd-roadmap-03 (work in progress), October
2018.
[DNS-UL] Sekar, K., "Dynamic DNS Update Leases", draft-sekar-dns- [DNS-UL] Sekar, K., "Dynamic DNS Update Leases", draft-sekar-dns-
ul-01 (work in progress), August 2006. ul-01 (work in progress), August 2006.
[DNS-LLQ] Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns- [DNS-LLQ] Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns-
llq-01 (work in progress), August 2006. llq-01 (work in progress), August 2006.
[RegProt] Cheshire, S. and T. Lemon, "Service Registration Protocol [RegProt] Cheshire, S. and T. Lemon, "Service Registration Protocol
for DNS-Based Service Discovery", draft-sctl-service- for DNS-Based Service Discovery", draft-sctl-service-
registration-00 (work in progress), July 2017. registration-00 (work in progress), July 2017.
skipping to change at page 37, line 31 skipping to change at page 37, line 31
A.4. Not Yet Implemented A.4. Not Yet Implemented
Client implementations of the new DNS Push Notifications mechanism Client implementations of the new DNS Push Notifications mechanism
[Push] are currently underway. [Push] are currently underway.
Author's Address Author's Address
Stuart Cheshire Stuart Cheshire
Apple Inc. Apple Inc.
1 Infinite Loop One Apple Park Way
Cupertino, California 95014 Cupertino, California 95014
USA USA
Phone: +1 408 974 3207 Phone: +1 (408) 996-1010
Email: cheshire@apple.com Email: cheshire@apple.com
 End of changes. 9 change blocks. 
21 lines changed or deleted 45 lines changed or added

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