Internet Engineering Task Force K. Lynn Internet-Draft Consultant Intended status: Experimental D. Sturek Expires: September 15, 2011 Pacific Gas & Electric March 14, 2011 Extended Multicast DNS draft-lynn-dnsext-site-mdns-01 Abstract Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional unicast DNS server. Extended mDNS (xmDNS) extends the specification of mDNS to site-local scope in order to support multi-hop LANs that forward multicast packets but do not provide a unicast DNS service. Like mDNS, xmDNS designates a portion of the DNS namespace to apply to the site-local network and specifies rules for its use. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 15, 2011. Copyright Notice Copyright (c) 2011 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 carefully, as they describe your rights and restrictions with respect Lynn & Sturek Expires September 15, 2011 [Page 1] Internet-Draft Extended Multicast DNS March 2011 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology Used in this Document . . . . . . 3 3. Extended Multicast DNS Names . . . . . . . . . . . . . . . . . 4 4. Reverse Address Mapping . . . . . . . . . . . . . . . . . . . 4 5. Querying . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Responding . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Traffic Reduction . . . . . . . . . . . . . . . . . . . . . . 5 8. Probing and Announcing on Startup . . . . . . . . . . . . . . 5 9. Conflict Resolution . . . . . . . . . . . . . . . . . . . . . 5 10. Resource Record TTL Values and Cache Coherency . . . . . . . . 5 11. Source Address Check . . . . . . . . . . . . . . . . . . . . . 5 12. Special Characteristics of Extended Multicast DNS Domains . . 6 13. Enabling and Disabling Multicast DNS . . . . . . . . . . . . . 6 14. Considerations for Multiple Interfaces . . . . . . . . . . . . 6 15. Considerations for Multiple Responders on the Same Machine . . 6 16. Multicast DNS Character Set . . . . . . . . . . . . . . . . . 6 17. Multicast DNS Message Size . . . . . . . . . . . . . . . . . . 6 18. Multicast DNS Message Format . . . . . . . . . . . . . . . . . 6 19. Summary of Differences Between Multicast DNS and Unicast DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 20. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 6 21. Security Considerations . . . . . . . . . . . . . . . . . . . 7 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 23. Domain Name Reservation Considerations . . . . . . . . . . . . 8 24. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 25. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 25.1. Normative References . . . . . . . . . . . . . . . . . . 10 25.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Lynn & Sturek Expires September 15, 2011 [Page 2] Internet-Draft Extended Multicast DNS March 2011 1. Introduction Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional unicast DNS server. Extended mDNS (xmDNS) extends the specification of mDNS to site-local scope in order to support multi-hop LANs that forward multicast packets but do not provide a unicast DNS service. Like mDNS, xmDNS designates a portion of the DNS namespace to apply to the site-local network and specifies rules for its use. Extended mDNS implementations MUST support all of the features of Multicast DNS [I-D.cheshire-dnsext-multicastdns] in addition to the changes specified in this document. The organization of this document is identical to mDNS, with changes specified by section below. It is important to note that xmDNS is not intended to replace DNS-SD [I-D.cheshire-dnsext-dns-sd], but rather to fill a gap between the link-local scope of mDNS and the highly scalable DNS-SD. In particular, the design target anticipates multi-subnet residential LANs such as ethernet to wireless mesh. 2. Conventions and Terminology Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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" [RFC2119]. When this document uses the term "Multicast DNS", it should be taken to mean: "Clients performing DNS-like queries for DNS-like resource records by sending DNS-like UDP query and response packets on the local link over IP Multicast to UDP port 5353." This document uses the term "Extended Multicast DNS" to indicate the distribution of mDNS queries and responses to all links that comprise the site-local area network. Exceptions to normal mDNS operation are specified in subsequent sections. This document uses the term "host name" in the strict sense to mean a fully-qualified domain name that has an IPv4 or IPv6 address record. It does not use the term "host name" in the commonly used but incorrect sense to mean just the first DNS label of a host's fully qualified domain name. A DNS (or mDNS) packet contains an IP TTL in the IP header, which is effectively a hop-count limit for the packet, to guard against routing loops. Each Resource Record also contains a TTL, which is Lynn & Sturek Expires September 15, 2011 [Page 3] Internet-Draft Extended Multicast DNS March 2011 the number of seconds for which the Resource Record may be cached. This document uses the term "IP TTL" to refer to the IP header TTL (hop limit), and the term "RR TTL" or just "TTL" to refer to the Resource Record TTL (cache lifetime). 3. Extended Multicast DNS Names Extended Multicast DNS specifies that the DNS top-level domain ".site." is a special domain with special semantics, namely that any fully-qualified domain name ending in ".site." is site-local, and names within this domain are meaningful only on the site-local area network where they originate. This is analogous to Unique Local IPv6 Unicast Address [RFC4291] prefixes, which are site-local and meaningful only on the site where they are defined. Any DNS query for a name ending with ".site." MUST be sent to the xmDNS multicast address (239.255.TBD.TBD or its IPv6 equivalent FF05::FB). Future versions of this document may specify a method for creating zones under the ".site." top-level domain and mapping these to alternate IPv6 multicast addresses but this is currently out of scope. Note that the ".site." and ".local." domains are functionally disjoint, both from a name space and address space perspective. Hosts wishing to register or discover names in both domains must do so individually. 4. Reverse Address Mapping [RFC4193] recommends that queries for D.F.IPV6.ARPA be handled locally. [I-D.ietf-dnsop-default-local-zones] extends the recommendation to cover other well known IN-ADDR.ARPA and IP6.ARPA zones for which queries should not appear on the public Internet. In the absence of a unicast DNS server in the LAN, any DNS query for a name within the reverse mapping domain ("d.f.ip6.arpa.") for Unique Local IPv6 Unicast addresses [RFC4193] SHOULD be sent to the IPv6 xmDNS link-local multicast address FF05::FB or the IPv4 xmDNS multicast address 239.255.TBD.TBD. [Other prefixes TBD] 5. Querying In cases where the desired scope of a query is the local link, Lynn & Sturek Expires September 15, 2011 [Page 4] Internet-Draft Extended Multicast DNS March 2011 Extended Multicast DNS queries MAY be sent with a link-local [RFC4291] source address to FF05::FB. Otherwise, Extended Multicast DNS queries SHOULD be sent with a Unique Local IPv6 Unicast [RFC4193] source address. Extended Multicast DNS queries MUST NOT be sent with a Global IPv6 Unicast [RFC4291] source address. The Source Address Check rules in Section 11 will not be able to determine whether the query was from an on-site host. 6. Responding All Extended Multicast DNS responses (including responses sent via unicast) SHOULD be sent with IP TTL set to 255. Extended Multicast DNS Responses MUST return all available AAAA records. 7. Traffic Reduction [TBD] 8. Probing and Announcing on Startup [TBD] 9. Conflict Resolution [TBD] 10. Resource Record TTL Values and Cache Coherency [TBD] 11. Source Address Check Source address check must ensure that queries originate from on-site prefixes. All other queries must be silently dropped. Lynn & Sturek Expires September 15, 2011 [Page 5] Internet-Draft Extended Multicast DNS March 2011 12. Special Characteristics of Extended Multicast DNS Domains [TBD] 13. Enabling and Disabling Multicast DNS [TBD] 14. Considerations for Multiple Interfaces [TBD] 15. Considerations for Multiple Responders on the Same Machine [TBD] 16. Multicast DNS Character Set [Same as mDNS] 17. Multicast DNS Message Size [Same as mDNS] 18. Multicast DNS Message Format [Same as mDNS] 19. Summary of Differences Between Multicast DNS and Unicast DNS [Same as mDNS] 20. IPv6 Considerations An IPv4-only host and an IPv6-only host behave as "ships that pass in 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 *two* unrelated ".site." zones, one for IPv4 and one for IPv6. Since for practical purposes, a group of IPv4-only hosts and a group of IPv6-only hosts on the same Ethernet act as if they were on two Lynn & Sturek Expires September 15, 2011 [Page 6] Internet-Draft Extended Multicast DNS March 2011 entirely separate Ethernet segments, it is unsurprising that their use of the ".site." zone should occur exactly as it would if they really were on two entirely separate Ethernet segments. A dual-stack (v4/v6) host can participate in both ".site." zones, and should register its name(s) and perform its lookups both using IPv4 and IPv6. This enables it to reach, and be reached by, both IPv4- only and IPv6-only hosts. In effect this acts like a multi- homed host, with one connection to the logical "IPv4 Ethernet segment", and a connection to the logical "IPv6 Ethernet segment". When such a host generates NSEC records, if it is using the same host name for its IPv4 addresses and its IPv6 addresses on that network interface, its NSEC records should indicate that the host name has both A and AAAA records. 21. Security Considerations [TBD] 22. IANA Considerations IANA has allocated the IPv6 multicast address set FF0X::FB for Multicast DNS [mcast6]. The use of FF02::FB (Link-Local Scope) is described in [I-D.cheshire-dnsext-multicastdns] and the use of address FF05::FB (Site-Local Scope) is defined in this document. When this document is published, IANA should designate a list of domains which are deemed to have only site-local significance, as described in Section 12 of this document ("Special Characteristics of Extended Multicast DNS Domains") [I-D.cheshire-dnsext-special-names]. Specifically, the designated site-local domains are: site. d.f.ip6.arpa. [TBD] This proposal will also likely request an IPv4 multicast address in the site-local range (239.255.0.0/16) [RFC2365] in order to differentiate xmDNS queries from normal mDNS queries, and to allow for modified xmDNS source address check rules. Lynn & Sturek Expires September 15, 2011 [Page 7] Internet-Draft Extended Multicast DNS March 2011 23. Domain Name Reservation Considerations The two domains listed in Section 22 above and any names falling within those domains (e.g. "MyServer.site.", "b.a.9.8.7.6.5.0.0. 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.d.f.ip6.arpa.", "www._http._tcp.site.") are special DNS names [I-D.cheshire-dnsext-special-names] in the following ways: 1. Users may use these names as they would other DNS names, entering them anywhere that they would otherwise enter a conventional DNS name, or a dotted decimal IPv4 address, or a literal IPv6 address. Since there is no central authority responsible for assigning dot-site names, and all devices on the site-local network are equally entitled to claim any dot-site name, users SHOULD be aware of this and SHOULD exercise appropriate caution. In an untrusted or unfamiliar network environment, users SHOULD be aware that using a name like "www.site" may not actually connect them to the web site they expected, and could easily connect them to a different web page, or even a fake or spoof of their intended web site, designed to trick them into revealing confidential information. As always with networking, end-to-end cryptographic security can be a useful tool. For example, when connecting with ssh, the ssh host key verification process will inform the user if it detects that the identity of the entity they are communicating with has changed since the last time they connected to that name. 2. Application software may use these names as they would other similar DNS names, and is not required to recognize the names and treat them specially. Due to the relative ease of spoofing dot- site names, end-to-end cryptographic security remains important when communicating across a local network, just as it is when communicating across the global Internet. 3. Name resolution APIs and libraries SHOULD recognize these names as special and SHOULD NOT send queries for these names to their configured (unicast) caching DNS server(s). This is to avoid unnecessary load on the root name servers and other name servers, caused by queries for which those name servers do not have useful non-negative answers to give, and will not ever have useful nonnegative answers to give. 4. Caching DNS servers SHOULD recognize these names as special and SHOULD NOT attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve these names. Instead, caching DNS servers SHOULD generate immediate Lynn & Sturek Expires September 15, 2011 [Page 8] Internet-Draft Extended Multicast DNS March 2011 NXDOMAIN responses for all such queries they may receive (from misbehaving name resolver libraries). This is to avoid unnecessary load on the root name servers and other name servers. 5. Authoritative DNS servers SHOULD NOT by default be configurable tp answer queries for these names, and, like caching DNS servers, SHOULD generate immediate NXDOMAIN responses for all such queries they may receive. DNS server software MAY provide a configuration option to override this default, for testing purposes or other specialized uses. 6. DNS server operators SHOULD NOT attempt to configure authoritative DNS servers to act as authoritative for any of these names. Configuring an authoritative DNS server to act as authoritative for any of these names may not, in many cases, yield the expected result, since name resolver libraries and caching DNS servers SHOULD NOT send queries for those names (see 3 and 4 above), so such queries SHOULD be suppressed before they even reach the authoritative DNS server in question, and consequently it will not even get an opportunity to answer them. 7. DNS Registrars MUST NOT allow any of these names to be registered in the normal way to any person or entity. These names are reserved protocol identifiers with special meaning and fall outside the set of names available for allocation by registrars. Attempting to allocate one of these names as if it were a normal DNS domain name will probably not work as desired, for reasons 3, 4, and 6 above. 24. Acknowledgments We wish to thank the authors of [I-D.cheshire-dnsext-multicastdns] on whose work this document is heavily based. Reviews and comments were provided by Tom Herbst and Ralph Droms. Lynn & Sturek Expires September 15, 2011 [Page 9] Internet-Draft Extended Multicast DNS March 2011 25. References 25.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [mcast6] "IPv6 Multicast Address Space Registry", . 25.2. Informative References [I-D.cheshire-dnsext-dns-sd] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", draft-cheshire-dnsext-dns-sd-10 (work in progress), February 2011. [I-D.cheshire-dnsext-multicastdns] Cheshire, S. and M. Krochmal, "Multicast DNS", draft-cheshire-dnsext-multicastdns-14 (work in progress), February 2011. [I-D.cheshire-dnsext-special-names] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", draft-cheshire-dnsext-special-names-01 (work in progress), January 2011. [I-D.ietf-dnsop-default-local-zones] Andrews, M., "Locally-served DNS Zones", draft-ietf-dnsop-default-local-zones-15 (work in progress), March 2011. Lynn & Sturek Expires September 15, 2011 [Page 10] Internet-Draft Extended Multicast DNS March 2011 Authors' Addresses Kerry Lynn Consultant Phone: +1 978-460-4253 Email: kerlyn@ieee.org Don Sturek Pacific Gas & Electric 77 Beale Street San Francisco, CA USA Phone: +1 619-504-3615 Email: d.sturek@att.net Lynn & Sturek Expires September 15, 2011 [Page 11]