diff --git a/doc/draft/draft-ietf-dnsop-respsize-01.txt b/doc/draft/draft-ietf-dnsop-respsize-01.txt new file mode 100644 index 0000000000..f6ece88210 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-respsize-01.txt @@ -0,0 +1,485 @@ + DNSOP Working Group Paul Vixie, ISC (Ed.) + INTERNET-DRAFT Akira Kato, WIDE + July, 2004 + + + DNS Response Size Issues + + + Status of this Memo + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which we are aware have been or will be disclosed, and any of which + we become aware will be disclosed, in accordance with RFC 3668. + + + 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. + + + Copyright Notice + + + Copyright (C) The Internet Society (2003-2004). All Rights Reserved. + + + + + + Abstract + + + With a mandated default minimum maximum message size of 512 octets, + the DNS protocol presents some special problems for zones wishing to + expose a moderate or high number of authority servers (NS RRs). This + document explains the operational issues caused by, or related to + this response size limit. + + + + + + + Expires December 2004 [Page 1] + INTERNET-DRAFT June 2003 RESPSIZE + + + + 1 - Introduction and Overview + + + 1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512 + octets. Even though this limitation was due to the required minimum UDP + reassembly limit for IPv4, it is a hard DNS protocol limit and is not + implicitly relaxed by changes in transport, for example to IPv6. + + + 1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger + responses by mutual agreement of the requestor and responder. However, + deployment of EDNS0 cannot be expected to reach every Internet resolver + in the short or medium term. The 512 octet message size limit remains + in practical effect at this time. + + + 1.3. Since DNS responses include a copy of the request, the space + available for response data is somewhat less than the full 512 octets. + For negative responses, there is rarely a space constraint. For + positive and delegation responses, though, every octet must be carefully + and sparingly allocated. This document specifically addresses + delegation response sizes. + + + 2 - Delegation Details + + + 2.1. A delegation response will include the following elements: + + + Header Section: fixed length (12 octets) + Question Section: original query (name, class, type) + Answer Section: (empty) + Authority Section: NS RRset (nameserver names) + Additional Section: A and AAAA RRsets (nameserver addresses) + + + 2.2. If the total response size would exceed 512 octets, and if the data + that would not fit was in the question, answer, or authority section, + then the TC bit will be set (indicating truncation) which may cause the + requestor to retry using TCP, depending on what information was present + and what was omitted. If a retry using TCP is needed, the total cost of + the transaction is much higher. + + + 2.3. RRsets are never sent partially, so if truncation occurs, entire + RRsets are omitted. Note that the authority section consists of a + single RRset. It is absolutely essential that truncation not occur in + the authority section. + + + + + + + + + Expires December 2004 [Page 2] + INTERNET-DRAFT June 2003 RESPSIZE + + + + 2.4. DNS label compression allows a domain name to be instantiated only + once per DNS message, and then referenced with a two-octet "pointer" + from other locations in that same DNS message. If all nameserver names + in a message are similar (for example, all ending in ".ROOT- + SERVERS.NET"), then more space will be available for uncompressable data + (such as nameserver addresses). + + + 2.5. The query name can be as long as 255 characters of presentation + data, which can be up to 256 octets of network data. In this worst case + scenario, the question section will be 260 octets in size, which would + leave only 240 octets for the authority and additional sections (after + deducting 12 octets for the fixed length header.) + + + 2.6. Average and maximum question section sizes can be predicted by the + zone owner, since they will know what names actually exist, and can + measure which ones are queried for most often. For cost and performance + reasons, the majority of requests should be satisfied without truncation + or TCP retry. + + + 2.7. Requestors who deliberately send large queries to force truncation + are only increasing their own costs, and cannot effectively attack the + resources of an authority server since the requestor would have to retry + using TCP to complete the attack. An attack that always used TCP would + have a lower cost. + + + 2.8. The minimum useful number of address records is two, since with + only one address, the probability that it would refer to an unreachable + server is too high. Truncation which occurs after two address records + have been added to the additional data section is therefore less + operationally significant than truncation which occurs earlier. + + + 2.9. The best case is no truncation. (This is because many requestors + will retry using TCP by reflex, without considering whether the omitted + data was actually necessary.) + + + + + + + + + + + + + + + + Expires December 2004 [Page 3] + INTERNET-DRAFT June 2003 RESPSIZE + + + + 3 - Analysis + + + 3.1. An instrumented protocol trace of a best case delegation response + follows. Note that 13 servers are named, and 13 addresses are given. + This query was artificially designed to exactly reach the 512 octet + limit. + + + ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13 + ;; QUERY SECTION: + ;; [23456789.123456789.123456789.\ + 123456789.123456789.123456789.com A IN] ;; @80 + + + ;; AUTHORITY SECTION: + com. 86400 NS E.GTLD-SERVERS.NET. ;; @112 + com. 86400 NS F.GTLD-SERVERS.NET. ;; @128 + com. 86400 NS G.GTLD-SERVERS.NET. ;; @144 + com. 86400 NS H.GTLD-SERVERS.NET. ;; @160 + com. 86400 NS I.GTLD-SERVERS.NET. ;; @176 + com. 86400 NS J.GTLD-SERVERS.NET. ;; @192 + com. 86400 NS K.GTLD-SERVERS.NET. ;; @208 + com. 86400 NS L.GTLD-SERVERS.NET. ;; @224 + com. 86400 NS M.GTLD-SERVERS.NET. ;; @240 + com. 86400 NS A.GTLD-SERVERS.NET. ;; @256 + com. 86400 NS B.GTLD-SERVERS.NET. ;; @272 + com. 86400 NS C.GTLD-SERVERS.NET. ;; @288 + com. 86400 NS D.GTLD-SERVERS.NET. ;; @304 + + + ;; ADDITIONAL SECTION: + A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320 + B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336 + C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352 + D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368 + E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384 + F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400 + G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416 + H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432 + I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448 + J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464 + K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480 + L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496 + M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512 + + + ;; MSG SIZE sent: 80 rcvd: 512 + + + + + + + Expires December 2004 [Page 4] + INTERNET-DRAFT June 2003 RESPSIZE + + + + 3.2. For longer query names, the number of address records supplied will + be lower. Furthermore, it is only by using a common parent name (which + is GTLD-SERVERS.NET in this example) that all 13 addresses are able to + fit. The following output from a response simulator demonstrates these + properties: + + + % perl respsize.pl 13 13 0 + common name, average case: msg:303 nsaddr#13 (green) + common name, worst case: msg:495 nsaddr# 1 (red) + uncommon name, average case: msg:457 nsaddr# 3 (orange) + uncommon name, worst case: msg:649(*) nsaddr# 0 (red) + % perl respsize.pl 13 13 2 + common name, average case: msg:303 nsaddr#11 (orange) + common name, worst case: msg:495 nsaddr# 1 (red) + uncommon name, average case: msg:457 nsaddr# 2 (orange) + uncommon name, worst case: msg:649(*) nsaddr# 0 (red) + + + (Note: The response simulator program is shown in Section 5.) + + + Here we use the term "green" if all address records could fit, or + "orange" if two or more could fit, or "red" if fewer than two could fit. + It's clear that without a common parent for nameserver names, much space + would be lost. + + + We're assuming an average query name size of 64 since that is the + typical average maximum size seen in trace data at the time of this + writing. If Internationalized Domain Name (IDN) or any other technology + which results in larger query names be deployed significantly in advance + of EDNS, then more new measurements and new estimates will have to be + made. + + + 4 - Conclusions + + + 4.1. The current practice of giving all nameserver names a common parent + (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS + responses and allows for more nameservers to be enumerated than would + otherwise be possible. (Note that in this case it is wise to serve the + common parent domain's zone from the same servers that are named within + it, in order to limit external dependencies when all your eggs are in a + single basket.) + + + 4.2. Thirteen (13) seems to be the effective maximum number of + nameserver names usable traditional (non-extended) DNS, assuming a + common parent domain name, and assuming that additional-data truncation + is undesirable in the average case. + + + + + Expires December 2004 [Page 5] + INTERNET-DRAFT June 2003 RESPSIZE + + + + 4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a + prototypical delegation that currently contains thirteen (13) IPv4 + nameserver addresses (A RRs) for thirteen (13) nameserver names under a + common parent, would not have a significant negative operational impact + on the domain name system. + + + 5 - Source Code + + + #!/usr/bin/perl -w + + + $asize = 2+2+2+4+2+4; + $aaaasize = 2+2+2+4+2+16; + ($nns, $na, $naaaa) = @ARGV; + test("common", "average", common_name_average($nns), + $na, $naaaa); + test("common", "worst", common_name_worst($nns), + $na, $naaaa); + test("uncommon", "average", uncommon_name_average($nns), + $na, $naaaa); + test("uncommon", "worst", uncommon_name_worst($nns), + $na, $naaaa); + exit 0; + + + sub test { my ($namekind, $casekind, $msg, $na, $naaaa) = @_; + my $nglue = numglue($msg, $na, $naaaa); + printf "%8s name, %7s case: msg:%3d%s nsaddr#%2d (%s)\n", + $namekind, $casekind, + $msg, ($msg > 512) ? "(*)" : " ", + $nglue, ($nglue == $na + $naaaa) ? "green" + : ($nglue >= 2) ? "orange" + : "red"; + } + + + sub pnum { my ($num, $tot) = @_; + return sprintf "%3d%s", + } + + + sub numglue { my ($msg, $na, $naaaa) = @_; + my $space = ($msg > 512) ? 0 : (512 - $msg); + my $num = 0; + + + while ($space && ($na || $naaaa )) { + if ($na) { + if ($space >= $asize) { + $space -= $asize; + + + + + Expires December 2004 [Page 6] + INTERNET-DRAFT June 2003 RESPSIZE + + + + $num++; + } + $na--; + } + if ($naaaa) { + if ($space >= $aaaasize) { + $space -= $aaaasize; + $num++; + } + $naaaa--; + } + } + return $num; + } + + + sub msgsize { my ($qname, $nns, $nsns) = @_; + return 12 + # header + $qname+2+2 + # query + 0 + # answer + $nns * (4+2+2+4+2+$nsns); # authority + } + + + sub average_case { my ($nns, $nsns) = @_; + return msgsize(64, $nns, $nsns); + } + + + sub worst_case { my ($nns, $nsns) = @_; + return msgsize(256, $nns, $nsns); + } + + + sub common_name_average { my ($nns) = @_; + return 15 + average_case($nns, 2); + } + + + sub common_name_worst { my ($nns) = @_; + return 15 + worst_case($nns, 2); + } + + + sub uncommon_name_average { my ($nns) = @_; + return average_case($nns, 15); + } + + + sub uncommon_name_worst { my ($nns) = @_; + return worst_case($nns, 15); + } + + + + + Expires December 2004 [Page 7] + INTERNET-DRAFT June 2003 RESPSIZE + + + + Security Considerations + + + The recommendations contained in this document have no known security + implications. + + + IANA Considerations + + + This document does not call for changes or additions to any IANA + registry. + + + IPR Statement + + + Copyright (C) The Internet Society (2003-2004). This document is + subject to the rights, licenses and restrictions contained in BCP 78, + and except as set forth therein, the authors retain all their rights. + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR + IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + + + Authors' Addresses + + + Paul Vixie + 950 Charter Street + Redwood City, CA 94063 + +1 650 423 1301 + vixie@isc.org + + + Akira Kato + University of Tokyo, Information Technology Center + 2-11-16 Yayoi Bunkyo + Tokyo 113-8658, JAPAN + +81 3 5841 2750 + kato@wide.ad.jp + + + + + + + + + + + Expires December 2004 [Page 8] \ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsop-serverid-02.txt b/doc/draft/draft-ietf-dnsop-serverid-02.txt new file mode 100644 index 0000000000..b593c57179 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-serverid-02.txt @@ -0,0 +1,617 @@ + + +Network Working Group S. Woolf +Internet-Draft Internet Systems Consortium, Inc. +Expires: January 16, 2005 D. Conrad + Nominum, Inc. + July 18, 2004 + + + Identifying an Authoritative Name `Server + draft-ietf-dnsop-serverid-02 + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + 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. + + This Internet-Draft will expire on January 16, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + With the increased use of DNS anycast, load balancing, and other + mechanisms allowing more than one DNS name server to share a single + IP address, it is sometimes difficult to tell which of a pool of name + servers has answered a particular query. A standardized mechanism to + determine the identity of a name server responding to a particular + query would be useful, particularly as a diagnostic aid. Existing ad + + + +Woolf & Conrad Expires January 16, 2005 [Page 1] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + + hoc mechanisms for addressing this concern are not adequate. This + document attempts to describe the common ad hoc solution to this + problem, including its advantages and disadvantasges, and to + characterize an improved mechanism. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires January 16, 2005 [Page 2] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + +1. Introduction + + With the increased use of DNS anycast, load balancing, and other + mechanisms allowing more than one DNS name server to share a single + IP address, it is sometimes difficult to tell which of a pool of name + servers has answered a particular query. A standardized mechanism to + determine the identity of a name server responding to a particular + query would be useful, particularly as a diagnostic aid. + + Unfortunately, existing ad-hoc mechanisms for providing such + identification have some shortcomings, not the least of which is the + lack of prior analysis of exactly how such a mechanism should be + designed and deployed. This document describes the existing + convention used in one widely deployed implementation of the DNS + protocol and discusses requirements for an improved solution to the + problem. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires January 16, 2005 [Page 3] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + +2. Rationale + + Identifying which name server is responding to queries is often + useful, particularly in attempting to diagnose name server + difficulties. However, relying on the IP address of the name server + has become more problematic due the deployment of various load + balancing solutions, including the use of shared unicast addresses as + documented in [RFC3258]. + + An unfortunate side effect of these load balancing solutions is that + traditional methods of determining which server is responding can be + unreliable. Specifically, non-DNS methods such as ICMP ping, TCP + connections, or non-DNS UDP packets (e.g., as generated by tools such + as "traceroute"), etc., can end up going to a different server than + that which receives the DNS queries. + + The widespread use of the existing convention suggests a need for a + documented, interoperable means of querying the identity of a + nameserver that may be part of an anycast or load-balancing cluster. + At the same time, however, it also has some drawbacks that argue + against standardizing it as it's been practiced so far. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires January 16, 2005 [Page 4] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + +3. Existing Conventions + + Recent versions of the commonly deployed Berkeley Internet Name + Domain implementation of the DNS protocol suite from the Internet + Software Consortium [BIND] support a way of identifying a particular + server via the use of a standard, if somewhat unusual, DNS query. + Specifically, a query to a late model BIND server for a TXT resource + record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will + return a string that can be configured by the name server + administrator to provide a unique identifier for the responding + server (defaulting to the value of a gethostname() call). This + mechanism, which is an extension of the BIND convention of using + CHAOS class TXT RR queries to sub-domains of the "BIND." domain for + version information, has been copied by several name server vendors. + + For reference, the other well-known name used by recent versions of + BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A + query for a TXT RR for this name will return an administratively re- + definable string which defaults to the version of the server + responding. + +3.1 Advantages + + There are several valuable attributes to this mechanism, which + account for its usefulness. + 1. This mechanism is within the DNS protocol itself. An + identification mechanism that relies on the DNS protocol is more + likely to be successful (although not guaranteed) in going to the + same machine as a "normal" DNS query. + 2. It is simple to configure. An administrator can easily turn on + this feature and control the results of the relevant query. + 3. It allows the administrator complete control of what information + is given out in the response, minimizing passive leakage of + implementation or configuration details. Such details are often + considered sensitive by infrastructure operators. + +3.2 Disadvantages + + At the same time, there are some forbidding drawbacks to the + VERSION.BIND mechanism that argue against standardizing it as it + currently operates. + 1. It requires an additional query to correlate between the answer + to a DNS query under normal conditions and the supposed identity + of the server receiving the query. There are a number of + situations in which this simply isn't reliable. + 2. It reserves an entire class in the DNS (CHAOS) for what amounts + to one zone. While CHAOS class is defined in [RFC1034] and + [RFC1035], it's not clear that supporting it solely for this + + + +Woolf & Conrad Expires January 16, 2005 [Page 5] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + + purpose is a good use of the namespace or of implementation + effort. + 3. It is implementation specific. BIND is one DNS implementation. + At the time of this writing, it is probably the most prevalent, + for authoritative servers anyway. This does not justify + standardizing on its ad hoc solution to a problem shared across + many operators and implementors. + + The first of the listed disadvantages is technically the most + serious. It argues for an attempt to design a good answer to the + problem that "I need to know what nameserver is answering my + queries", not simply a convenient one. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires January 16, 2005 [Page 6] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + +4. Characteristics of an Implementation Neutral Convention + + The discussion above of advantages and disadvantages to the + HOSTNAME.BIND mechanism suggest some requirements for a better + solution to the server identification problem. These are summarized + here as guidelines for any effort to provide appropriate protocol + extensions: + 1. The mechanism adopted MUST be in-band for the DNS protocol. That + is, it needs to allow the query for the server's identifying + information to be part of a normal, operational query. It SHOULD + also permit a separate, dedicated query for the server's + identifying information. + 2. The new mechanism should not require dedicated namespaces or + other reserved values outside of the existing protocol mechanisms + for these, i.e. the OPT pseudo-RR. + 3. Support for the identification functionality SHOULD be easy to + implement and easy to enable. It MUST be easy to disable and + SHOULD lend itself to access controls on who can query for it. + 4. It should be possible to return a unique identifier for a server + without requiring the exposure of information that may be + non-public and considered sensitive by the operator, such as a + hostname or unicast IP address maintained for administrative + purposes. + 5. The identification mechanism SHOULD NOT be + implementation-specific. + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires January 16, 2005 [Page 7] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + +5. IANA Considerations + + This document proposes no specific IANA action. Protocol extensions, + if any, to meet the requirements described are out of scope for this + document. Should such extensions be specified and adopted by normal + IETF process, the specification will include appropriate guidance to + IANA. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires January 16, 2005 [Page 8] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + +6. Security Considerations + + Providing identifying information as to which server is responding + can be seen as information leakage and thus a security risk. This + motivates the suggestion above that a new mechanism for server + identification allow the administrator to disable the functionality + altogether or partially restrict availability of the data. It also + suggests that the serverid data should not be readily correlated with + a hostname or unicast IP address that may be considered private to + the nameserver operator's management infrastructure. + + Propagation of protocol or service meta-data can sometimes expose the + application to denial of service or other attack. As DNS is a + critically important infrastructure service for the production + Internet, extra care needs to be taken against this risk for + designers, implementors, and operators of a new mechanism for server + identification. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires January 16, 2005 [Page 9] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + +7. Acknowledgements + + The technique for host identification documented here was initially + implemented by Paul Vixie of the Internet Software Consortium in the + Berkeley Internet Name Daemon package. Comments and questions on + earlier drafts were provided by Bob Halley, Brian Wellington, Andreas + Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the + ICANN Root Server System Advisory Committee. The newest draft takes + a significantly different direction from previous versions, owing to + discussion among contributors to the DNSOP working group and others, + particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam Weiler, + and Rob Austein. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires January 16, 2005 [Page 10] + +Internet-Draft Identifying an Authoritative Name `Server July 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Woolf & Conrad Expires January 16, 2005 [Page 11] + +