Internet DRAFT - draft-aboba-dnsext-mdns

draft-aboba-dnsext-mdns









DNSEXT Working Group                                        Levon Esibov
INTERNET-DRAFT                                             Bernard Aboba
Category: Standards Track                                    Dave Thaler
<draft-aboba-dnsext-mdns-01.txt>                               Microsoft
14 July 2000


                             Multicast DNS

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet- Drafts.

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."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

1.  Copyright Notice

Copyright (C) The Internet Society (2000).  All Rights Reserved.

2.  Abstract

Today, with the rise of home networking, there are an increasing number
of small networks operating without a DNS server. In order to allow DNS
name resolution in such environments, the use of a multicast DNS is
proposed.

3.  Introduction

Multicast DNS enables DNS name resolution in the scenarios when
conventional DNS name resolution is not possible. Namely, when there are
no DNS servers available on the network or available DNS servers do not
provide the name resolution for the names of the hosts on the local
network. The latter case, for example, corresponds to a scenario when a
home network that doesn't have a DNS server is connected to the Internet
through an ISP and the home network hosts are configured with the ISP's
DNS server for the name resolution. The ISP's DNS server provides the



Esibov, Aboba & Thaler       Standards Track                    [Page 1]





INTERNET-DRAFT               Multicast DNS                  14 July 2000


name resolution for the names registered on the Internet, but doesn't
provide name resolution for the names of the hosts on the home network.

This document discusses multicast DNS, an extension to the DNS protocol
which consists of a single change to the method of use, and no change to
the format of DNS packets.

4.  Terminology

In this document, the key words "MAY", "MUST,  "MUST  NOT", "optional",
"recommended",  "SHOULD",  and  "SHOULD  NOT",  are to be interpreted as
described in [1].

5.  Name resolution using Multicast DNS

This extension to the DNS protocol consists of a single change to the
method of use, and no change whatsoever to the current format of DNS
packets.  Namely, this extension allows multicast DNS queries to be sent
to and received on port 53 using the LINKLOCAL addresses for IPv4 and
IPv6, which are yet to be assigned by IANA. LINKLOCAL addresses are used
since the expectation is that if a network has a router, then this
router can function as a mini-DHCP server, as described in [3], and a
DNS proxy, possibly implementing dynamic DNS. Thus there is not expected
to be a need for use of multicast DNS in networks with multiple
segments.

Hosts actively using mDNS behave as DNS servers, and inherit all the
obligations of DNS servers, as described in [8], including the need to
increment the serial number in SOA records. It is suggested that the
serial number be taken from a monotonically increasing clock which
implies that the serial number will be monotonic across reboots.
However, this is not crucial if the DNS TTL is set to a low value.

In order to prevent a DNS server from recursive resolution of the
multicast DNS queries, the RD (Recursion Desired) bit in the Header
section of the query MUST be set to 0. If the RD bit is set to 1, then
it is ignored.

DNS resolvers configured to use multicast DNS for name resolution listen
on port 53 on the LINKLOCAL mDNS address. Responses SHOULD contain a AA
(Authoritative Answer) bit set to 0.

Issue: Handling of the AA bit was flagged as a subject for more
discussion.

If a query sent to the LINKLOCAL mDNS addresses is not positively
resolved  ("positively resolved" refers in this document to the response
with the RCODE set to 0) during a limited amount of time, then the



Esibov, Aboba & Thaler       Standards Track                    [Page 2]





INTERNET-DRAFT               Multicast DNS                  14 July 2000


resolver MAY repeat the transmission of a query in order to assure
themselves that the query has been received by any hosts capable of
answering the query.

Resolvers MUST anticipate receiving no replies to some multicasted
queries, in the event that no multicast-enabled clients are available
within the multicast scope, or in the event that no positive non-null
responses exist to the transmitted query.

If no positive response is received, a resolver treats it as a response
that no records of the specified type and class for the specified name
exist (NXRRSET), which should be cached according to RFC 2308 [15].

6.  Usage model

Multicast DNS usage is determined by the domain search configuration as
well as by special treatment of the ".lcl.arpa" namespace.  The resolver
treat queries for ".lcl.arpa" as a special case, thus avoiding the need
to formally allocate a new top level domain.  The domain search list can
be configured manually or automatically via a DHCP option. There is
therefore no need for another mDNS configuration mechanism.

The resolver will always do a multicast query for names in the
".lcl.arpa" namespace if there is no NS record corresponding to the
name. mDNS is only used to resolve unqualified names. This means, for
example, that queries for "www.microsoft.com" will never be resolved via
mDNS.

If ".lcl.arpa" is not in the domain search list, then mDNS MUST NOT be
used by that host. An auto-configured host will typically have
".lcl.arpa" first in its search list so that it will be enabled to use
mDNS. Typically an enterprise host will not have ".lcl.arpa" in its
searchlist at all so that it will not use mDNS.

6.1.  Sequence of events

The sequence of events for usage of multicast DNS is as follows:

1. A host multicasts a query for ANY record for a name within
   the ".lcl.arpa" domain. The query is sent to the LINKLOCAL
   multicast address. The response is multicast to the LINKLOCAL
   address, and uses DNS TTL=0, with the exception of NS, which
   uses a default TTL, with a value TBD.

2. Hosts only respond to queries if they are the name server for
   the domain (e.g. they are foo.lcl.arpa). Hosts never
   respond based on cached information. The responding host
   responds with SOA and NS records.



Esibov, Aboba & Thaler       Standards Track                    [Page 3]





INTERNET-DRAFT               Multicast DNS                  14 July 2000


3. Now that the querying host has discovered the name server for the
   domain, subsequent queries are sent unicast to the discovered
   name server.

Note that this implies that multicast DNS cannot be used for discovering
services (e.g. trying to query for all printers on the segument via a
"*._lpr._udp" SRV [4] query).  While this is not an objective of the
current specification, this functionality may be added in a subsequent
extension.

Since mDNS queries are sent on to a LINKLOCAL multicast address, mDNS
cannot even be used to discover the location of DNS servers off the
local segment. As a result, mDNS is not useful for IPv6 or IPv4 DNS
server discovery.

7.  Name conflicts

It is required to verify the uniqueness of the host DNS name when a host
boots, when its name is changed, or when it is configured to use
multicast DNS (such as when the domain search option is changed to
include ".lcl.arpa").

A gratuitious name resolution query SHOULD be done to check for a name
conflict. This is done by having the resolver send a multicast ANY type
query for its own name. If the query is not positively resolved then
host starts using its name. If the query is positively resolved, then
the host should verify that the IP addresses specified in the response
are its own IP addresses, possibly from another adapter.  If the host
verifies it, then it starts using its name. If the host cannot match the
returned A records to its IP addresses, then a conflict has been
detected. In order to resolve ownership conflicts, if the host has a
lower IP address it will keep the name, else if the device has a higher
IP  address it will change names.

A host that has detected a name conflict and has loses the name election
MUST NOT use the name. This means that the host MUST NOT respond to
multicast queries for that name and MUST NOT respond to other multicast
queries with the records that contain in RDATA name in conflict (for
example, PTR record).

Note that this name conflict detection mechanism doesn't prevent name
conflicts when previously separate networks are connected by a bridge.
Name conflict in such situation is detected when a host receives an
multicast response to a query for its name or when a client receives
more than one response to a multicast query that it sent. A host that
receives a response for a query for it's own name, even if it didn't
send such query, behaves as if it sent this query.




Esibov, Aboba & Thaler       Standards Track                    [Page 4]





INTERNET-DRAFT               Multicast DNS                  14 July 2000


In order to prevent denial of service attacks, it is recommended that
"lcl.arpa" be placed last in the domain searchlist. As long as this is
the case, there should be no way for a server with a FQDN to encounter
name conflict problems which would cause it to become unreachable.

8.  IANA Considerations

Authors will contact IANA to reserve LINKLOCAL IPv4 and IPv6 addresses.

9.  Security Considerations

This draft does not prescribe a means of securing the multicast DNS
mechanism. It is possible that hosts will allocate conflicting names for
a period of time, or that non-conforming hosts will attempt to deny
service to other hosts by allocating the same name.

These threats are most serious in wireless networks such as 802.11,
since attackers on a wired network will require physical access to the
home network, while wireless attackers may reside outside the home. In
order to provide for privacy equivalent to a wired network, the 802.11
specification provides for RC4-based encryption. This is known as the
"Wired Equivalency Privacy" (WEP) specification. Where WEP is
implemented, an attacker will need to obtain the WEP key prior to
gaining access to the home network.

10.  Acknowledgements

The authors would like to thank Stuart Cheshire, Michael Patton, Erik
Guttman, Olafur Gudmundsson, Thomas Narten, Mark Andrews, Erik Nordmark,
Myrong Hattig and Bill Manning for comments on this draft, provided at
the mDNS lunch in Adelaide, Australia on 3/29/00.

11.  Authors' Addresses

Levon Esibov
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

EMail: levone@microsoft.com

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: +1 (425) 936-6605
EMail: bernarda@microsoft.com



Esibov, Aboba & Thaler       Standards Track                    [Page 5]





INTERNET-DRAFT               Multicast DNS                  14 July 2000


Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: +1 (425) 703-8835
EMail: dthaler@microsoft.com


12.  References

[1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997.

[2]  Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
     2365, July 1998.

[3]  Aboba, B., "The Mini-DHCP Server", Internet draft (work in
     progress), draft-aboba-dhc-mini-01.txt, April 2000.

[4]  Gulbrandsen, A., Vixie, P., Esibov, L. "A DNS RR for specifying the
     location of services (DNS SRV)", RFC 2782, February 2000.

[5]  Braden, R., "Requirements for Internet Hosts -- Application and
     Support", RFC 1123, October 1989.

[6]  Hanna, S., Patel, B., and Shah, M., "Multicast Address Dynamic
     Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.

[7]  Gulbrandsen, A., "A DNS RR for encoding DHCP information", Internet
     draft (work in progress), draft-ietf-dnsind-dhcp-rr-00.txt, October
     1999.

[8]  Mockapetris, P., "Domain Names - Implementation and Specification",
     RFC 1035, November 1987.

[9]  IANA, "Single-source IP Multicast Address Range",
     http://www.isi.edu/in-notes/iana/assignments/single-source-
     multicast, October 1998.

[10] Handley, M., Thaler, D., and Kermode, R., "Multicast-Scope Zone
     Announcement Protocol (MZAP)", Work in progress, draft-ietf-mboned-
     mzap-06.txt, December, 1999.

[11] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., Lear,
     E., "Address Allocation for Private Internets", RFC 1918, February,
     1996.




Esibov, Aboba & Thaler       Standards Track                    [Page 6]





INTERNET-DRAFT               Multicast DNS                  14 July 2000


[12] Stapp, M., Rekhter, Y., "Interaction between DHCP and DNS",
     Internet draft (work in progress), draft-ietf-dhc-dhcp-dns-11.txt,
     October 1999.

[13] Vixie, P., et. al., "Dynamic Updates in the Domain Name System (DNS
     UPDATE)", RFC 2136, April, 1997.

[14] Troll,  R.,  "DHCP  Option  to  Disable  Stateless Auto-
     Configuration  in  IPv4  Clients", RFC 2563, May 1999.

[15] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
     2308, March 1998.

[16] Auerbach, K., "PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP
     TRANSPORT: CONCEPTS AND METHODS", RFC 1001, March, 1987.

13.  Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to  pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights.  Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11.  Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard.  Please address the information to the IETF Executive
Director.

14.  Full Copyright Statement

Copyright (C) The Internet Society (2000).  All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice



Esibov, Aboba & Thaler       Standards Track                    [Page 7]





INTERNET-DRAFT               Multicast DNS                  14 July 2000


or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.  The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns.  This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

15.  Expiration Date

This memo is filed as <draft-aboba-dnsext-mdns-01.txt>,  and  expires
February 1, 20001.


































Esibov, Aboba & Thaler       Standards Track                    [Page 8]