IETF DNSEXT WG Bill Manning
draft-dnsext-opcode-discover-02.txt ep.net
Paul Vixie
ISC
13 Oct 2003
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 generate replies from multiple responders. So DISCOVER is defined to deal with replies from multiple responders.
As such, this document extends 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 during the TBDS project (1999-2000), funded under DARPA grant F30602-99-1-0523.
- 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."
- Method:
DISCOVER works like QUERY except:
- it can be sent to a broadcast or multicast destination. QUERY isn't defined for non-unicast, and arguably shouldn't be.
- the Question section, if present, has <QNAME=zonename,QTYPE=SOA> tuples. TBDS 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.
- if QDCOUNT equals 0 then only servers willing to do recursion should answer. Other servers must silently discard the DISCOVER request.
- if QDCOUNT is not equal to 0 then only servers who are authoritative for the zones named by some QNAME should answer.
- responses may echo the request's Question section or leave it blank, just like QUERY.
- responses have standard 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. We expect that
there will be a single response per responder.
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. This structure can be populated by values returned from a request as follows:
s_name The name of the service, "service" without the
preceding underscore.
saliases 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 authoritative servers.
Usage for disconnected networks with no authoritative 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. Compute NS as the host's FQDN. Compute the
glue as 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 exactly match QNAME's, not with zone names which
are owned by QNAME's.
The main 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 any 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. Updated by discussion in September/October 2003. David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock, Erik Guttman, Bill Manning and Paul Vixie 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>
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
----------------------------EOL-----------------------