mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-31 14:35:26 +00:00
Code Issues Releases Wiki Activity

added more multicast DNS drafts

Browse Source
This commit is contained in:
Andreas Gustafsson
2000-12-13 18:15:16 +00:00
parent 3d509f54ac
commit cdb41f0dc3
3 changed files with 1420 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

480
doc/draft/draft-aboba-dnsext-mdns-01.txt Normal file
View File

@@ -0,0 +1,480 @@
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]

521
doc/draft/draft-ietf-dnsext-mdns-00.txt Normal file
View File

@@ -0,0 +1,521 @@
DNSEXT Working Group Levon Esibov
INTERNET-DRAFT Bernard Aboba
Category: Standards Track Dave Thaler
<draft-ietf-dnsext-mdns-00.txt> Microsoft
November 16, 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.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
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.
1. 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 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
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.
Esibov, Aboba & Thaler Standards Track [Page 1]
INTERNET-DRAFT Multicast DNS 16 November 2000
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.
Discovery of the services in general as well as discovery of the DNS
servers in particular using multicast DNS is left outside of the scope
of this document.
Name resolution over non-multicast capable media is left outside of the
scope of this document.
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [1].
2. 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 [2] for IPv4
and IPv6 (below in this text referred as LINKLOCAL address), which are
yet to be assigned by IANA. LINKLOCAL addresses are used to prevent
propagation of the multicast DNS traffic across the routers that may
cause network flooding. Propagation of the multicast DNS packets within
the boundaries is considered sufficient to enable DNS name resolution,
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.
2.1 Behavior of the sender and responder
For the purpose of this document a device that sends a multicast query
is called a "sender", while a device that listens to (but not
necessarily responds to) a multicast query is called "responder". A
device configured to be a "responder" may also be a "sender". A device
configured to not be a "responder" cannot be a "sender".
A sender sends multicast DNS query for any legal Type of resource record
(e.g. A, PTR, etc<74>) for a name within the ".local.arpa." domain to the
LINKLOCAL address. The RD (Recursion Desired) bit MUST NOT be set. If a
responder receives a query with the header containing RD set bit, the
responder MUST ignore the RD bit.
Esibov, Aboba & Thaler Standards Track [Page 2]
INTERNET-DRAFT Multicast DNS 16 November 2000
If the multicast query 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 a sender MAY repeat the transmission of a
query in order to assure themselves that the query has been received by
a host capable of responding to the query. Repetition MUST NOT be
attempted more than 5 times, and the repetition SHOULD NOT be repeated
more often than once per 0.1 seconds to reduce the unnecessary network
traffic. Retry intervals SHOULD be exponentially increased.
A responder listens on port 53 on the LINKLOCAL address. Responders MUST
respond to multicast queries to those and only those names for which
they are authoritative. As an example, computer
"host.example.com.local.arpa." is authoritative for the domain
"host.example.com.local.arpa.". When such host receives a multicast DNS
query for an A record for the name "host.example.com.local.arpa." it
responds with an A record(s) that contains its IP address(es) in the
RDATA of the record.
In conventional DNS terminology a DNS server authoritative for a zone is
authoritative for all the domain names under the zone root except for
the branches delegated into separate zones. Contrary to conventional DNS
terminology, a responder is authoritative only for the zone root. For
example the host "host.example.com.local.arpa." is not authoritative for
the name "child.host.example.com.local.arpa." unless the host is
configured with multiple names, including "host.example.com.local.arpa."
and "child.host.example.com.local.arpa.". The purpose of such limitation
of the name authority scope of a responder is to prevent complication
that could be caused by coexistence of two or more devices with the
names representing child and parent (or grandparents) nodes in the DNS
tree, for example, "host.example.com.local.arpa." and
"child.host.example.com.local.arpa.". In this example (unless this
limitation introduced) the multicast query for an A record for the name
"child.host.example.com.local.arpa." would cause two authoritative
responses: name error received from "host.example.com.local.arpa.", and
requested A record - from "child.host.example.com.local.arpa.". To
prevent such ambiguity, we could propose to implement multicast enabled
devices to perform a dynamic update of the parent (or grandparent) zone
with a delegation to a child zone, in this example a host
"child.host.example.com.local.arpa." would send a dynamic update for
the NS and glue A record to the "host.example.com.local.arpa.", but this
approach significantly complicates implementation of the multicast DNS
and would not be acceptable for a lightweight devices.
The response to the multicast query is composed in exactly the same
manner as in case of a response to the unicast DNS query as specified
in [4]. Responders MUST never respond using cached data, and the AA
(Authoritative Answer) bit MUST be set. The response is sent to the
sender via unicast. If a TC (truncation) bit is set in the response,
then the sender MAY use the response if it contains all necessary
information, or the sender MAY discard the response and resend the query
over TCP or using EDNS0 with larger window using unicast address of the
Esibov, Aboba & Thaler Standards Track [Page 3]
INTERNET-DRAFT Multicast DNS 16 November 2000
responder. The RA (Recursion Available) bit in the header of the
response MUST NOT be set. Even if the RA bit is set in the response
header, the sender MUST ignore it. The responder MUST set the Hop Limit
field in IPv6 header and TTL field in IPv4 header of all responses to
the multicast DNS query to 255. The sender MUST verify that the Hop
Limit field in IPv6 header and TTL field in IPv4 header of each response
to the multicast DNS query is set to 255. If it is not, then sender MUST
ignore such response.
The responder should use a pre-configured TTL [5] value in the records
returned in the multicast DNS query response. Due to the TTL
minimalization necessary when caching an RRset, all TTLs in an RRset
MUST be set to the same value.
The responder includes in the additional and authority section of the
response the same records, as a DNS server would insert in the response
to the unicast DNS query.
Sender MUST anticipate receiving no replies to some multicasted queries,
in the event that no responders 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 for a period that SHOULD NOT
exceed 5 seconds.
Sender MUST anticipate receiving multiple replies to the same
multicasted query, in the event that several multicast DNS enabled
computers receive the query and respond with valid answers. When this
occurs, the responses MAY first be concatenated, and then treated in the
same manner that multiple RRs received from the same DNS server would,
ordinarily.
3. Usage model
A device configured to be a "responder" may also be a "sender". A device
configured to not be a "responder" cannot be a "sender".
Multicast DNS usage is determined by the domain search configuration as
well as by special treatment of the ".local.arpa." namespace. Any
device whose domain search configuration contains ".local.arpa." domain
is configured to behave as "responder". A device configured to be a
"responder" may also be a "sender". A device cannot be configured to
behave as one (i.e. sender or responder), but not another. The sender
treats queries for ".local.arpa." as a special case. The domain search
list can be configured manually or automatically via a DHCP option.
Esibov, Aboba & Thaler Standards Track [Page 4]
INTERNET-DRAFT Multicast DNS 16 November 2000
A sender MUST NOT send a unicast query for names ending with the
".local.arpa." suffix except in the case when a sender repeats a query
over TCP after it received a response to the previous multicast query
with TC bit set or unless sender's cache contains NS resource record
that enables sender to send a query directly to the devices
authoritative for the name in query.
It is not expected that a device "host.example.com." will be manually
configured to have additional name "host.example.com.local.arpa." when
it is configured to use multicast DNS. Instead, a responder with a name
"host.example.com." configured with ".local.arpa." suffix in its domain
search configuration is authoritative for the name
"host.example.com.local.arpa.". I.e. when responder with the name
"host.example.com." receives an A type query for the name
"host.example.com.local.arpa." it authoritatively responds to the query.
If ".local.arpa" is not in the domain search list, then multicast DNS
MUST NOT be used by a device. This implies that the device will neither
listen on the DNS LINKLOCAL multicast address, nor will it send queries
to that address. An auto-configured host will typically have
".local.arpa" first in its search list so that it will be enabled to
use mDNS. Typically an enterprise host will not have ".local.arpa" in
its search list at all so that it will not use mDNS.
The same device may use multicast DNS queries for the name resolution of
the names ending with ".local.arpa.", and unicast DNS queries for name
resolution of all other names. When a DNS client is requested by a user
or application to perform a name resolution of a dot-terminated name
that contains a ".local.arpa" suffix, a query for such name MUST be
multicasted and such name should not be concatenated with any suffix.
If a DNS server is running on a device, the device MUST NOT listen for
the multicast DNS queries, to prevent a device from listening on port 53
and intercepting DNS queries directed to a DNS server. A DNS server may
listen and respond to the multicast queries. A DNS server by default
doesn't listen to the multicast DNS queries. Presence of the
".local.arpa." in the domain search list doesn't affect the
configuration on the DNS server.
4. Sequence of events
The sequence of events for usage of multicast DNS is as follows:
1. If a sender needs to resolve a query for a name
"host.example.com.local.arpa", then it sends a multicast query to the
LINKLOCAL multicast address.
2. A responder responds to this query only if it is authoritative
for the domain name "host.example.com.local.arpa". The responder sends
a response to the sender via unicast over UDP.
Esibov, Aboba & Thaler Standards Track [Page 5]
INTERNET-DRAFT Multicast DNS 16 November 2000
3. Upon the reception of the response the sender verifies that the Hop
Limit field in IPv6 header or TTL field in IPv4 header (depending on
used protocol) of the response is set to 255. If it is, then sender
uses and caches the returned response. If not, then the sender ignores
the response and continues waiting for the response.
5. 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 ".local.arpa.").
A gratuitous name resolution query SHOULD be done to check for a name
conflict. This is done by having the resolver send a multicast query for
a SOA type query for its own name (i.e. for the name it is authoritative
for). If the query is not positively resolved then host assumes
authority for the name. If the query is positively resolved, then the
host should verify that the computer name specified in the RDATA of the
SOA record in the answer section of the response is its own computer
name. If the host verifies it, then it assumes authority for its name.
If the host cannot match the returned computer name to its computer
name, then a conflict has been detected. In order to resolve name
conflict, the host will change the name.
A host that has detected a name conflict 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 sender receives more
than one response to its multicasted DNS query. Such sender sends using
unicast the first response that it received to all responders, except
the first one, that responded to this query. A host that receives a
response for a query for it's own name, even if it didn't send such
query, sends a multicast query for the SOA record for the name that it
is authoritative for. Based on the response the host detects the name
conflict and acts according to the description above.
6. IANA Considerations
Authors will contact IANA to reserve LINKLOCAL IPv4 and IPv6 addresses.
Esibov, Aboba & Thaler Standards Track [Page 6]
INTERNET-DRAFT Multicast DNS 16 November 2000
7. 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. Such attacks also
allow nodes to receive packets destined for other nodes. The protocol
reduces the exposure to such threats in the absence of authentication
by ignoring multicast DNS query response packets received from off-link
senders. The Hop Limit field in IPv6 and TTL field in IPv4 of all
received packets is verified to contain 255, the maximum legal value.
Because routers decrement the Hop Limit on all packets they forward,
received packets containing a Hop Limit of 255 must have originated
from a neighbor.
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.
The mechanism specified in this draft does not require use of the
DNSSEC, which means that the responses to the multicast DNS queries may
not be authenticated. If a network contains a "signed key distribution
center" for all (or at least some) of the DNS zones that the responders
are authoritative for, then those devices on such a network are
configured with the key for the top zone, "local.arpa." (hosted by
"signed keys distribution center") may use DNSSEC for the authentication
of the responders using DNSSEC.
8. Acknowledgements
The authors would like to thank Stuart Cheshire, Michael Patton, Erik
Guttman, Olafur Gudmundsson, Thomas Narten, Mark Andrews, Erik Nordmark,
Myrong Hattig, Bill Manning and James Gilroy for comments on this draft.
9. Authors' Addresses
Levon Esibov
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: levone@microsoft.com
Esibov, Aboba & Thaler Standards Track [Page 7]
INTERNET-DRAFT Multicast DNS 16 November 2000
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 (425) 936-6605
EMail: bernarda@microsoft.com
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 (425) 703-8835
EMail: dthaler@microsoft.com
10. 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] Mockapetris, P., "Domain Names - Implementation and Specification",
RFC 1035, November 1987.
[5] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, November 1987.
11. 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.
Esibov, Aboba & Thaler Standards Track [Page 8]
INTERNET-DRAFT Multicast DNS 16 November 2000
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.
12. 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 implementation 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
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."
13. Expiration Date
This memo is filed as <draft-ietf-dnsext-mdns-00.txt>, and expires
May 16, 2001.
Esibov, Aboba & Thaler Standards Track [Page 9]

419
doc/draft/draft-manning-multicast-dns-02.txt Normal file
View File

@@ -0,0 +1,419 @@
Network Working Group B. Woodcock
Request for Comments: nnnn Zocalo
Category: Experimental B. Manning
ISI
August 2000
Multicast Discovery of DNS Services
draft-manning-multicast-dns-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026 except that the right
to produce derivative works is not granted. 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."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
1. Introduction
This document describes a minimal extension to the method of a DNS
query which allows unconfigured hosts to locate a local DNS server,
or in the absence of a DNS server to nonetheless identify some
local network services.
2. Acknowledgments
Vital contributions to this document were made by Paul Vixie, Dave
Meyer, Stuart Cheshire, Richard Ford, Tony McGregor, Erik Guttman,
Benard Aboba, and Peter Ford. Thanks also to Alex Hoppman for
discussion of text-encoding methods.
3. Overview and rationale
This experimental extension to DNS is intended to provide a bootstrap
mechanism whereby unconfigured devices may find a local DNS server
and begin using it to perform the usual name resolution and service
lookup functions. This need is particularly acute in the absence of
a DHCP server.
Secondarily, it is anticipated that device vendors may implement the
server (query-receiving) portion of this extension, in order to
render unconfigured devices which may lack an out-of-band
configuration interface such as a screen or keyboard discoverable on
the local network. For example, if a newly-purchased laser printer
or router were connected to a network, this extension would allow a
system administrator to use the DNS to discover the IP address which
the device had selected or been DHCP-assigned, and begin
communicating with it through the network.
A tertiary objective of this extension is to make possible the
deprecation of the AppleTalk protocol, which has been prolonged as a
means of providing support for "network browsing."
4. Discussion
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. Specifically, this extension allows UDP DNS queries, as
documented in RFC 1035, sections 4.1.1, 4.1.2 and 4.2.1, to be
addressed to port 53 of statically-assigned relative offset -2 within
the range of multicast addresses defined as "administratively scoped"
by RFC 2365, section 9. Within the full /8 of administratively
scoped addresses, this corresponds to the destination address
239.255.255.253. Until MZAP or a similar protocol is implemented to
allow hosts to discover the extent of the local multicast scopes
which enclose them, it is anticipated that implementations will
simply utilize the destination address 239.255.255.253.
In order to receive multicasted queries, DNS server implementations
MUST listen on the -2 offset to their local scope (as above, in the
absence of a method of determining the scope, this will be assumed to
be relative to the full /8 allocated for administratively-scoped
multicast use, or 239.255.255.253), and respond via ordinary unicast
UDP to ONLY those queries for which they have or can find a positive
non-null answer. Multicast-enabled DNS servers MUST answer
multicasted queries non-authoritatively. That is, when responding to
a query which was received via multicast, they MAY NOT include an NS
record which contains data which resolves back to their own IP
address.
Resolvers SHOULD be liberal in their acceptance of wildcard queries.
That is, resolvers should anticipate receiving queries which will
contain the asterisk character in any position within the query's
data field. For example, a query for SRV RRs with data
"afp.tcp.*.domain.com." would match "afp.tcp.server.domain.com." but
not match "afp.tcp.". A query for "afp.tcp.*" would match both,
since the asterisk should be interpreted as matching zero or more
characters within the RR data.
Resolvers MUST anticipate receiving no replies to some multicasted
queries, in the event that no multicast-enabled DNS server
implementations are active within the local scope, or in the event
that no positive non-null responses exist to the transmitted query.
That is, a query for the MX record for host.domain.com would go
unanswered if no local server was able to resolve that request, if no
MX record exists for host.domain.com, or if no local servers were
capable of receiving multicast queries. The resolver which initiated
the query MUST treat such non-response as a non-cacheable negative
response. Since this multicast transmission does not provide
reliable delivery, resolvers MAY repeat the transmission of a query
in order to assure themselves that is has been reveived by any hosts
capable of answering, however any resolvers which repeat a query MUST
increase the interval between such repetitions exponentially over
time.
Resolvers MUST also anticipate receiving multiple replies to the same
multicasted query, in the event that several multicast-enabled DNS
servers receive the query and respond with valid answers. When this
occurs, the responses MAY first be concatenated, and then treated in
the same manner that multiple RRs received from the same server
would, ordinarily.
5. Implementation Notes Appendix
It is anticipated that a major use of this extension to DNS will be
for the replacement of the AppleTalk Name Binding Protocol (NBP)
"distributed database," and the implementation of a similar service
within other operating systems and on other platforms. Such use
implies the existence of "stub DNS servers" on each participating
host, each containing only local information in its served zones, but
not to the exclusion of data which other servers may assert within
the same zones.
The following rather complex example shows the format by which an
implementor could assert the local information possessed by any
Macintosh in zones served by a stub DNS server on that host:
$ORIGIN .
@ SOA . . 1998082701 0 0 0 0
0 IN NS dns.udp.
Jasons-Mac 0 IN A 169.254.101.218
0 IN HINFO Macintosh-G3-400 MacOS-8.6
0 IN LOC 37 52 N 122 20 W
0 IN RP . owner-name.Jasons-Mac.
Jasons-Hard-Disk 0 IN A 169.254.101.218
0 IN TXT "UTF8-encoded service-name"
Print-Spooler 0 IN A 169.254.101.218
0 IN TXT "UTF8-encoded service-name"
dns.udp 0 IN SRV 0 0 53 Jasons-Mac.
afp.tcp 0 IN SRV 0 0 548 Jasons-Hard-Disk.
lpr.tcp 0 IN SRV 0 0 515 Print-Spooler.
http.tcp 0 IN SRV 0 0 80 www.jasonco.com.
https.tcp 0 IN SRV 0 0 443 secure.jasonco.com.
$ORIGIN jasonco.com.
www 0 IN A 169.254.101.218
0 IN TXT "UTF8-encoded service-name"
secure 0 IN A 169.254.101.218
0 IN TXT "UTF8-encoded service-name"
$ORIGIN Jasons-Mac.
dns.udp 0 IN SRV 0 0 53 Jasons-Mac.
owner-name 0 IN TXT "Jason A. Luser"
* 0 IN PTR afp.tcp.Jasons-Mac.
0 IN PTR lpr.tcp.Jasons-Mac.
0 IN PTR http.tcp.Jasons-Mac.
afp.tcp 0 IN SRV 0 0 548 Jasons-Hard-Disk.
lpr.tcp 0 IN SRV 0 0 515 Print-Spooler.
http.tcp 0 IN SRV 0 0 80 www.jasonco.com.
$ORIGIN 101.254.169.in-addr.arpa.
218 0 IN PTR Jasons-Mac.
Windows and Unix hosts are possessed of many of the same, or
analogous, types of local information, and similar examples could be
constructed around hypothetical hosts of those types. A much
simpler example featuring a laser printer follows, in section 6 of
this document.
Note that in translating service and device names from high-bit-depth
character sets such as Unicode to DNS-compliant hostnames, a
character-mapping must occur, whereby spaces are mapped to hyphens,
punctuation other than periods is removed, and plain characters are
substituted for their accented equivalents. Implementors MUST perform
a uniqueness check, in order to guarantee that no other device within
the local multicast scope has already asserted a claim to the DNS
name which their device wishes to employ. Uniqueness checks at
service-registration time must be somewhat more strict than their
historical AppleTalk equivalents, comparing names which have already
been converted to their DNS-compliant state (containing only a-z,
A-Z, 0-9, and the hyphen character, and starting with a letter rather
than a hyphen or number), and must treat upper and lower-case as
equivalent. Note that periods in device and service names shall be
preserved and used to establish subdomains within the stub DNS
server's dataset. The high-bit-depth names are made available to
queriants in the form of UTF8-encoded RDATA in TXT RRs included as
Additional Information (as described in RFC 1035, sections 4.1
through 4.1.3) appended to any A RR response.
Implementors of multicast-enabled resolvers may expect the following
results of the following query-types:
Data Type Result
*.in-addr.arpa PTR All hostnames in the local scope
*.host.domain.com SRV All services on host.domain.com
lpr.tcp. SRV All printers/spoolers in the local scope
Duplicate identical records received in different responses to a
query may be treated as a single record in the concatenation of
responses. It is beyond the scope of this document to suggest
disposition of different responses which contain disagreeing pairs of
name NAME and RDATA.
Implementors should note that "virtual hosts" (that is, the support
of multiple IP addresses on a single host, and the binding of
different services to different addresses) are easily supported in
responses to multicast queries, but should also note that one of the
benefits afforded by the use of SRV RR-types is a reduction in the
need for virtual hosts, since multiple named services may be bound to
different (non-well-known) ports of the same IP address, and still be
individually identified and differentiated. For example, a single
host might support one HTTP server on port 80, a second on port 8001,
and an HTTPS server on port 443, and each could be reached via
different name.
Another major use of this extension to DNS is to allow bootstrapping
machines to find local DNS servers. It is anticipated that larger
enterprises may in the future possess one or more fully-featured DNS
servers which are also multicast-enabled. Once a bootstrapping host
has located such a server, that host need no longer use multicast at
all. That host may instead employ ordinary unicast DNS exactly as
any other host would, to query those DNS servers. The servers, in
turn, might well employ multicast queries to glean information about
the services contained within their local scope, which information
they might then use to respond to unicast queries (proxying, in
effect), and cache against future need. Note also that the ability
to answer multicast queries would prove particularly useful to a DNS
server which was resident on the same host as a NAT at the border of
an enterprise which employed 10.0.0.0/8 or 169.254.0.0/16 unicast
addresses internally.
Implementors MAY choose to employ an optimization whereby the
deleterious impact of large numbers of unconfigured hosts
simultaneously attempting to locate DNS servers during the bootstrap
process might be mitigated, and the process be made more efficient.
Specifically, high- and low-water marks are defined for frequency of
multicasted lookups for SRV RRs of "dns.udp.". When a
multicast-enabled DNS server observes the frequency of such lookups
exceeding a high-water mark (five queries per minute, perhaps), the
server MAY begin interspersing responses transmitted via multicast,
rather than unicast, until such time as the frequency of such lookups
falls below a low-water mark (one query per five minutes, perhaps).
In order for this to work, multicast-enabled resolvers would also
need to listen on the multicast address for responses, and cache them
briefly. Both the server and resolver portions of this optimized
behavior are optional, and it should be stressed that this
optimization need not be considered by implementors of stub servers
in devices such as printers, which do not provide generalized DNS
services. If DNS server implementors choose to employ multicast
responses, they MUST interleave multicast responses with unicast
responses in such a way that the multicast responses decrease over
time, rather than flooding the network, in order that servers not be
used to propagate denial-of-service attacks. In other words, a
reasonable approach might be while above the high-water mark to make
the first, second, fourth, eighth, sixteenth et cetera responses for
each RR multicast, while all inbetween would be unicast. Note that
this not only protects against multicast "storms," it also protects
against the mis-match condition which occurs in the case that a
non-optimized resolver is the presence only of optimized servers, all
of which are temporarily in multicast-response mode.
Implementors SHOULD also employ DNS Sec, or its equivalent, as soon
as such technology is standardized, in order to minimize the
possiblity of "spoofing" of information by nodes responding to
multicast queries.
6. Use & Administration Notes Appendix
Administrators of networks employing this protocol are advised to
employ fully-qualified domain names (FQDNs) as their host names where
possible, such that the dots separating portions of the name shall be
interpreted by the stub-server implementations as subdomain
delimiters, and shall thus serve to remove the host from the local
view of the root domain to its correct and appropriate
globally-unique subdomain.
Administrators of service-providing devices, such as already-deployed
printers, which are not capable of receiving multicast DNS queries,
may wish to inject DNS records into a local multicast-enabled DNS
server on behalf of those devices. For example, an administrator
might wish to create records of the following nature in order to make
a non-multicast-capable laser printer visible to both multicast and
unicast queriants:
$ORIGIN .
lpr.tcp 0 IN SRV 0 0 515 laser2.sales.domain.com.
$ORIGIN sales.domain.com.
laser2 0 IN A 169.254.5.28
0 IN TXT "Old Sales Dep't Laser Printer"
$ORIGIN laser2.sales.domain.com.
* 0 IN PTR lpr.tcp.laser2.sales.domain.com.
lpr.tcp 0 IN SRV 0 0 515 laser2.sales.domain.com.
$ORIGIN 5.254.169.in-addr.arpa.
28 0 IN PTR laser2.sales.domain.com.
Administrators of networks which contain either multicast-capable
resolvers or multicast-capable DNS servers MUST employ filters
defining a contiguous border around their enterprises and prohibiting
passage of data to and from the 239.0.0.0/8 address space, as well as
routing information relating to the 239.0.0.0/8 prefix or any subnet
of it. This is the mechanism by which RFC 2365 administrative
scoping is enacted. The sole exception to this rule would be any
explicitly-configured interconnections with other specific
enterprises between which all involved administrators wish to share a
single browsable network space. This is anticipated to be a very
infrequent occurrence within the current regime of network security
policies.
References
RFC 1035: Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November, 1987.
RFC 2052: Gulbrandsen, A., Vixie, P., "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October, 1996.
RFC 2365: Meyer, D., "Administratively Scoped IP Multicast",
RFC 2365, July, 1998.
Handley, M., Thaler, D., "Multicast-Scope Zone Announcement
Protocol (MZAP)", MBoneD Internet Draft, October, 1998.
Sidhu, G.S., Andrews, R.F., and Oppenheimer, A., "Inside AppleTalk,
Second Edition", Addison-Wesley, 1990.
Security Considerations
While this extension to DNS introduces no new security problems to
DNS or Multicast, it should be emphasized that distributed
directories, common to other networking protocols, have not hitherto
been widely used in the IP networking community. Distributed
directories do require that users and system administrators assume
some conscious balance between the level of trust which they accord
to the responding entities on their network, and the degree of
credence which they pay to the responses they receive. The level of
trust traditionally assumed in distributed directory environments
does not necessarily mix well with clear-text password transmission
such as is still found on some IP networks, for example.
Authors' Addresses
Bill Woodcock
Zocalo
2355 Virginia Street
Berkeley, CA 94709-1315
USA
Phone: +1 510 540 8000
EMail: woody@zocalo.net
Bill Manning
USC/ISI
4676 Admiralty Way, #1001
Marina del Rey, CA. 90292
USA
Phone: +1 310 822 1511
EMail: bmanning@isi.edu
Full Copyright Statement
Copyright (C) The Internet Society (1998). 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 implementation 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 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
......
--------------1F985EC911030AB70E0CD7B9--
--
--bill