247 lines
10 KiB
Plaintext
247 lines
10 KiB
Plaintext
|
|
IETF DNSEXT WG Bill Manning
|
|
draft-dnsext-opcode-discover-01.txt ISI
|
|
Paul Vixie
|
|
ISC
|
|
Erik Guttman
|
|
SUN
|
|
21 Dec 2002
|
|
|
|
|
|
The DISCOVER opcode
|
|
|
|
This document is an Internet-Draft and is subject to all provisions of
|
|
Section 10 of RFC2026.
|
|
|
|
Comments may be submitted to the group mailing list at "mdns@zocalo.net"
|
|
or the authors.
|
|
|
|
Distribution of this memo is unlimited.
|
|
|
|
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.
|
|
|
|
The capitalized keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|
document are to be interpreted as described in RFC 2119
|
|
|
|
0. Abstract:
|
|
|
|
The QUERY opcode in the DNS is designed for unicast. With the
|
|
development of multicast capabilities in the DNS, it is desireable
|
|
to have a more robust opcode for server interactions since a single
|
|
request may result in replies from multiple responders. So DISCOVER
|
|
is defined to deal with replies from multiple responders.
|
|
|
|
As such, this document extend the core DNS specifications to allow
|
|
clients to have a method for coping with replies from multiple
|
|
responders. Use of this new opcode may facilitate DNS operations in
|
|
modern networking topologies. A prototype of the DISCOVER opcode
|
|
was developed as part of the TBDS project, funded under DARPA grant
|
|
F30602-99-1-0523.
|
|
|
|
1. Introduction:
|
|
|
|
This document describes an experimental extension to the DNS to receive
|
|
multiple responses which is the likely result when using DNS that has
|
|
enabled multicast queries. This approach was developed as part of the
|
|
TBDS research project, funded under DARPA grant F30602-99-1-0523. The
|
|
full processing rules used by TBDS are documented here for possible
|
|
incorporation in a future revision of the DNS specification."
|
|
|
|
2. Method:
|
|
|
|
DISCOVER works like QUERY except:
|
|
|
|
1. it can be sent to a broadcast or multicast destination QUERY
|
|
isn't defined for non-unicast, and arguably shouldn't be.
|
|
|
|
2. the Question section, if present, has <QNAME=zonename,QTYPE=SOA>
|
|
tuples. Our testing tried to augment this structure as follows:
|
|
<QNAME=service,QTYPE=SRV>. While this worked for our purposes in
|
|
TBDS, it is cleaner to place the SRV question in a separate pass.
|
|
|
|
3. if QDCOUNT==0 then only servers willing to do recursion should
|
|
answer. Other servers must silently discard the DISCOVER request.
|
|
|
|
4. if QDCOUNT!=0 then only servers who are authoritative for the
|
|
zones named by some QNAME should answer.
|
|
|
|
5. responses may echo the request's Question section or leave it blank,
|
|
just like QUERY.
|
|
|
|
6. responses have "normal" Answer, Authority, and Additional sections.
|
|
e.g. the response is the same as that to a QUERY. It is desireable
|
|
that zero content answers not be sent to avoid badly formed or
|
|
unfulfilled requests. Responses should be sent to the unicast
|
|
address of the requester and the source address should reflect
|
|
the unicast address of the responder.
|
|
|
|
Example usage for gethostby{name,addr}-style requestors:
|
|
|
|
Compute the zone name of the enclosing in-addr.arpa, ip6.int, or
|
|
ip6.arpa domain.
|
|
|
|
DISCOVER whether anyone in-scope is authoritative for this zone.
|
|
|
|
If so, query these authoritative servers for local
|
|
in-addr/ip6 names.
|
|
|
|
If not, DISCOVER whether there are recursive servers available.
|
|
|
|
If so, query these recursive servers for local
|
|
in-addr/ip6 names.
|
|
|
|
So, a node will issue a multicast request with the DISCOVER opcode at
|
|
some particular multicast scope. Then determine, from the replies,
|
|
whether there are any DNS servers which are authoritative (or support
|
|
recursion) for the zone. Replies to DISCOVER requests MUST set the
|
|
Recursion Available (RA) flag in the DNS message header.
|
|
|
|
It is important to recognize that a requester must be prepared to
|
|
receive multiple replies from multiple responders.
|
|
|
|
Once one learns a host's FQDN by the above means, repeat the process
|
|
for discovering the closest enclosing authoritative server of such
|
|
local name.
|
|
|
|
Cache all NS and A data learned in this process, respecting TTL's.
|
|
|
|
TBDS usage for SRV requestors:
|
|
|
|
Do the gethostbyaddr() and gethostbyname() on one's own link-local
|
|
address, using the above process.
|
|
|
|
Assume that the closest enclosing zone for which an authority server
|
|
answers an in-scope DISCOVER packet is "this host's parent domain".
|
|
|
|
Compute the SRV name as _service._transport.*.parentdomain.
|
|
|
|
This is a change to the definition as defined in RFC 1034.
|
|
A wildcard label ("*") in the QNAME used in a DNS message with
|
|
opcode DISCOVER SHOULD be evaluated with special rules. The
|
|
wildcard matches any label for which the DNS server data is
|
|
authoritative. For example 'x.*.example.com.' would match
|
|
'x.y.example.com.' and 'x.yy.example.com.' provided that the
|
|
server was authoritative for 'example.com.' In this particular
|
|
case, we suggest the follwing considerations be made:
|
|
|
|
getservbyname() can be satisfied by issuing a request with
|
|
this computed SRV name. The servent structure can be
|
|
populated by values returned from a request as follows:
|
|
|
|
s_name The name of the service, "_service" without the
|
|
preceding underscore.
|
|
s_aliases The names returned in the SRV RRs in replies
|
|
to the query.
|
|
s_port The port number in the SRV RRs replies to the
|
|
query. If these port numbers disagree - one
|
|
of the port numbers is chosen, and only those
|
|
names which correspond are returned.
|
|
s_proto The transport protocol from named by the
|
|
"_transport" label, without the preceding
|
|
underscore.
|
|
|
|
Send SRV query for this name to discovered local authority servers.
|
|
|
|
Usage for disconnected networks with no authority servers:
|
|
|
|
Hosts should run a "stub server" which acts as though its FQDN is a
|
|
zone name. Computed SOA gives the host's FQDN as MNAME, "." as the
|
|
ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE
|
|
and the other timers. Computed NS gives the host's FQDN. Computed
|
|
glue gives the host's link-local address. Or Hosts may run a
|
|
"DNS stub server" which acts as though its FQDN is a zone name. The
|
|
rules governing the behavior of this stub server are given elsewhere
|
|
[1] [2].
|
|
|
|
Such stub servers should answer DISCOVER packets for its zone, and
|
|
will be found by the iterative "discover closest enclosing authority
|
|
server" by DISCOVER clients, either in the gethostbyname() or SRV
|
|
cases described above. Note that stub servers only answer with
|
|
zone names which match QNAME's, not with zone names which are owned
|
|
by QNAME's.
|
|
|
|
The only deviation from the DNS[3][4] model is that a host (like, say, a
|
|
printer offering LPD services) has a DNS server which answers authoritatively
|
|
for something which hasn't been delegated to it. However, the only way that
|
|
such DNS servers can be discovered is with a new opcode, DISCOVER, which
|
|
is explicitly defined to discover undelegated zones for tightly scoped
|
|
purposes. Therefore this isn't officially a violation of DNS's coherency
|
|
principles. In some cases, a responder to DISCOVER, may not be traditional
|
|
DNS software, it could be special purpose software.
|
|
|
|
3. IANA Considerations
|
|
|
|
As a new opcode, the IANA will need to assign a numeric value
|
|
for the memnonic. The last OPCODE assigned was "5", for UPDATE.
|
|
Test implementations have used OPCODE "6".
|
|
|
|
4. Security Considerations
|
|
|
|
No new security considerations are known to be introduced with a new
|
|
opcode, however using multicast for service discovery has the potential
|
|
for denial of service, primarly from flooding attacks. It may also be
|
|
possible to enable deliberate misconfiguration of clients simply by
|
|
running a malicious DNS resolver that claims to be authoritative for
|
|
things that it is not. One possible way to mitigate this effect is by
|
|
use of credentials, such as CERT resource records within an RR set.
|
|
The TBDS project took this approach.
|
|
|
|
5. Attribution:
|
|
|
|
This material was generated in discussions on the mdns mailing list
|
|
hosted by Zocalo in March 2000. Paul Vixie, Stuart Cheshire, Bill Woodcock,
|
|
Erik Guttman and Bill Manning were active contributors.
|
|
|
|
6. Author's Address
|
|
|
|
Bill Manning
|
|
PO 12317
|
|
Marina del Rey, CA. 90295
|
|
+1.310.322.8102
|
|
bmanning@karoshi.com
|
|
|
|
Paul Vixie
|
|
Internet Software Consortium
|
|
950 Charter Street
|
|
Redwood City, CA 94063
|
|
+1 650 779 7001
|
|
<vixie@isc.org>
|
|
|
|
Erik Guttman
|
|
Sun Microsystems
|
|
Eichh\367lzelstr. 7
|
|
74915 Waibstadt Germany
|
|
+49 6227 356 202
|
|
erik.guttman@sun.com
|
|
|
|
7. References
|
|
|
|
Informational References:
|
|
|
|
[1] Esibov, L., Aboba, B., Thaler, D., "Multicast DNS",
|
|
draft-ietf-dnsext-mdns-00.txt, November 2000. Expired
|
|
|
|
[2] Woodcock, B., Manning, B., "Multicast Domain Name Service",
|
|
draft-manning-dnsext-mdns-00.txt, August 2000. Expired.
|
|
|
|
Normative References:
|
|
[3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
|
|
RFC 1034, November 1987.
|
|
[4] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
|
|
RFC 1035, November 1987
|
|
|