diff options
Diffstat (limited to 'doc/draft/draft-dnsext-opcode-discover-02.txt')
| -rw-r--r-- | doc/draft/draft-dnsext-opcode-discover-02.txt | 241 |
1 files changed, 241 insertions, 0 deletions
diff --git a/doc/draft/draft-dnsext-opcode-discover-02.txt b/doc/draft/draft-dnsext-opcode-discover-02.txt new file mode 100644 index 0000000..7b5e8cc --- /dev/null +++ b/doc/draft/draft-dnsext-opcode-discover-02.txt @@ -0,0 +1,241 @@ + +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. + +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. 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. + + 3. if QDCOUNT equals 0 then only servers willing to do recursion should + answer. Other servers must silently discard the DISCOVER request. + + 4. if QDCOUNT is not equal to 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 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. + 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 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----------------------- + |