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, 0 insertions, 241 deletions
diff --git a/doc/draft/draft-dnsext-opcode-discover-02.txt b/doc/draft/draft-dnsext-opcode-discover-02.txt deleted file mode 100644 index 7b5e8cc4455b..000000000000 --- a/doc/draft/draft-dnsext-opcode-discover-02.txt +++ /dev/null @@ -1,241 +0,0 @@ - -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----------------------- - |