One document matched: draft-manning-multicast-dns-00.txt
Network Working Group B. Woodcock
INTERNET-DRAFTS Zocalo
Category: Experimental B. Manning
Expires in six months ISI
December 1998
Multicast Discovery of DNS Services
<draft-manning-multicast-dns-00.txt>
Status of this Memo
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.
This document is an Internet-Draft. 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 entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nic.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Copyright Notice
Copyright (C) The Internet Society (1998). 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, Benard Aboba, and Peter Ford. Thanks also
to Alex Hoppman for discussion of text-encoding methods.
3. Overview and rationale
Currently, no method exists within shipping implementations of the IP
protocol for unconfigured devices to find local DNS servers. 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.
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
Woodcock & Manning Experimental [Page 1]
RFC nnnn Multicast Discovery of DNS Services December 1998
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, 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 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.
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.
Woodcock & Manning Experimental [Page 2]
RFC nnnn Multicast Discovery of DNS Services December 1998
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.
Woodcock & Manning Experimental [Page 3]
RFC nnnn Multicast Discovery of DNS Services December 1998
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. Uniqueness checks at
service-registration time must be somewhat more strict, comparing
names which have already been mapped to the DNS-compliant equivalents
(names must contain only a-z, A-Z, 0-9, and the hyphen character, and
must start 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.
Woodcock & Manning Experimental [Page 4]
RFC nnnn Multicast Discovery of DNS Services December 1998
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 responding 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.
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
Woodcock & Manning Experimental [Page 5]
RFC nnnn Multicast Discovery of DNS Services December 1998
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.
Mark Handley, M., Thaler, D., "Multicast-Scope Zone Announcement
Protocol (MZAP)", MBoneD Internet Draft, October, 1998.
Security Considerations
The authors believe that this extension to DNS introduces no new
security problems to DNS or Multicast, nor does it encourage the
exploitation of any problems which may currently exist.
Woodcock & Manning Experimental [Page 6]
RFC nnnn Multicast Discovery of DNS Services December 1998
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
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.
Woodcock & Manning Experimental [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 04:04:45 |