diff --git a/doc/draft/draft-ietf-dnsop-serverid-04.txt b/doc/draft/draft-ietf-dnsop-serverid-04.txt deleted file mode 100644 index 242aa9ea62..0000000000 --- a/doc/draft/draft-ietf-dnsop-serverid-04.txt +++ /dev/null @@ -1,616 +0,0 @@ - - -Network Working Group S. Woolf -Internet-Draft Internet Systems Consortium, Inc. -Expires: September 14, 2005 D. Conrad - Nominum, Inc. - March 13, 2005 - - - Identifying an Authoritative Name Server - draft-ietf-dnsop-serverid-04 - -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 September 14, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -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 - - - -Woolf & Conrad Expires September 14, 2005 [Page 1] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - - query would be useful, particularly as a diagnostic aid. Existing ad - 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 disadvantages, and to - characterize an improved mechanism. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 14, 2005 [Page 2] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - -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 September 14, 2005 [Page 3] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - -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, and - some changes in management practices as the public Internet has - evolved, 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 (such as those - generated by tools such as "traceroute"), etc., can end up going to a - different server than that which receives the DNS queries. - - There is a well-known and frequently-used technique for determining - an identity for a nameserver more specific than the - possibly-non-unique "server that answered my query". 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 September 14, 2005 [Page 4] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - -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 - defined string which defaults to the version of the server - responding. This is, however, not generally implemented by other - vendors. - -3.1 Advantages - - There are several valuable attributes to this mechanism, which - account for its usefulness. - 1. The "hostname.bind" query response 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. Since the identity information is requested and returned within - the DNS protocol, it doesn't require allowing any other query - mechanism to the server, such as holes in firewalls for - otherwise-unallowed ICMP Echo requests. Thus it does not require - any special exceptions to site security policy. - 3. It is simple to configure. An administrator can easily turn on - this feature and control the results of the relevant query. - 4. 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. - - - - -Woolf & Conrad Expires September 14, 2005 [Page 5] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - - 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 - 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. 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 September 14, 2005 [Page 6] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - -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. In particular, it should not - propagate the existing drawback of requiring support for a CLASS - and top level domain in the authoritative server (or the querying - tool) to be useful. - 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 September 14, 2005 [Page 7] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - -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 September 14, 2005 [Page 8] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - -6. Security Considerations - - Providing identifying information as to which server is responding to - a particular query from a particular location in the Internet 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 September 14, 2005 [Page 9] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - -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 version - 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 September 14, 2005 [Page 10] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - -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 (2005). 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 September 14, 2005 [Page 11] - - diff --git a/doc/draft/draft-ietf-dnsop-serverid-06.txt b/doc/draft/draft-ietf-dnsop-serverid-06.txt new file mode 100644 index 0000000000..c6ec7e42a5 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-serverid-06.txt @@ -0,0 +1,618 @@ + + + + +Network Working Group S. Woolf +Internet-Draft Internet Systems Consortium, Inc. +Expires: September 6, 2006 D. Conrad + Nominum, Inc. + March 5, 2006 + + + Requirements for a Mechanism Identifying a Name Server Instance + draft-ietf-dnsop-serverid-06 + +Status of this Memo + + 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 becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + 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 September 6, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +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 for + administrators. Existing ad hoc mechanisms for addressing this need + + + +Woolf & Conrad Expires September 6, 2006 [Page 1] + +Internet-Draft Serverid March 2006 + + + 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 + some widely deployed implementations of the DNS protocol, including + advantages and disadvantages, and discusses some attributes of an + improved mechanism. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 6, 2006 [Page 2] + +Internet-Draft Serverid March 2006 + + +1. Introduction and Rationale + + Identifying which name server is responding to queries is often + useful, particularly in attempting to diagnose name server + difficulties. This is most obviously useful for authoritative + nameservers in the attempt to diagnose the source or prevalence of + inaccurate data, but can also conceivably be useful for caching + resolvers in similar and other situations. Furthermore, the ability + to identify which server is responding to a query has become more + useful as DNS has become more critical to more Internet users, and as + network and server deployment topologies have become more complex. + + The traditional means for determining which of several possible + servers is answering a query has traditionally been based on the use + of the server's IP address as a unique identifier. However, the + modern Internet has seen the deployment of various load balancing, + fault-tolerance, or attack-resistance schemes such as shared use of + unicast IP addresses as documented in [RFC3258]. An unfortunate side + effect of these schemes has been to make the use of IP addresses as + identifiers somewhat problematic. Specifically, a dedicated DNS + query may not go to the same server as answered a previous query, + even though sent to the same IP address. Non-DNS methods such as + ICMP ping, TCP connections, or non-DNS UDP packets (such as those + generated by tools like "traceroute"), etc., may well be even less + certain to reach the same server as the one which receives the DNS + queries. + + There is a well-known and frequently-used technique for determining + an identity for a nameserver more specific than the possibly-non- + unique "server that answered the query I sent to IP address XXX". + 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 September 6, 2006 [Page 3] + +Internet-Draft Serverid March 2006 + + +2. Existing Conventions + + For some time, the commonly deployed Berkeley Internet Name Domain + implementation of the DNS protocol suite from the Internet Systems + Consortium [BIND] has supported a way of identifying a particular + server via the use of a standards-compliant, if somewhat unusual, DNS + query. Specifically, a query to a recent 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. (The value defaults to the result 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. + + A refinement to the BIND-based mechanism, which dropped the + implementation-specific string, replaces ".BIND" with ".SERVER". + Thus the query string to learn the unique name of a server may be + queried as "ID.SERVER". + + (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 CHAOS TXT RR for this name will return an + administratively defined string which defaults to the version of the + server responding. This is, however, not generally implemented by + other vendors.) + +2.1. Advantages + + There are several valuable attributes to this mechanism, which + account for its usefulness. + + 1. The "HOSTNAME.BIND" or "ID.SERVER" query response 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 system as a + "normal" DNS query. + + 2. Since the identity information is requested and returned within + the DNS protocol, it doesn't require allowing any other query + mechanism to the server, such as holes in firewalls for + otherwise-unallowed ICMP Echo requests. Thus it is likely to + reach the same server over a path subject to the same routing, + resource, and security policy as the query, without any special + exceptions to site security policy. + + + + + +Woolf & Conrad Expires September 6, 2006 [Page 4] + +Internet-Draft Serverid March 2006 + + + 3. It is simple to configure. An administrator can easily turn on + this feature and control the results of the relevant query. + + 4. 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. + + 5. Hypothetically, since it's an ordinary DNS record and the + relevant DNSSEC RRs are class independent, the id.server response + RR could be signed, which has the advantages described in + [RFC4033]. + +2.2. Disadvantages + + At the same time, there are some serious drawbacks to the CHAOS/TXT + query 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 + purpose is a good use of the namespace or of implementation + effort. + + 3. The initial and still common form, using .BIND, is implementation + specific. BIND is one DNS implementation. At the time of this + writing, it is probably the most prevalent for authoritative + servers. This does not justify standardizing on its ad hoc + solution to a problem shared across many operators and + implementors. Meanwhile, the proposed refinement changes the + string but preserves the ad hoc CHAOS/TXT mechanism. + + 4. There is no convention or shared understanding of what + information an answer to such a query for a server identity could + or should include, including a possible encoding or + authentication mechanism. + + The first of the listed disadvantages may be 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 September 6, 2006 [Page 5] + +Internet-Draft Serverid March 2006 + + +2.3. 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. But it should preserve the ability of + the CHAOS/TXT query-based mechanism to work through firewalls and + in other situations where only DNS can be relied upon to reach + the server of interest. + + 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. In particular, it should not + propagate the existing drawback of requiring support for a CLASS + and top level domain in the authoritative server (or the querying + tool) to be useful. + + 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. It should be possible to authenticate the received data by some + mechanism analogous to those provided by DNSSEC. In this + context, the need could be met by including encryption options in + the specification of a new mechanism. + + 6. The identification mechanism should not be implementation- + specific. + + + + + + + + + + +Woolf & Conrad Expires September 6, 2006 [Page 6] + +Internet-Draft Serverid March 2006 + + +3. 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. A proposed extension, specified and adopted by normal IETF + process, is described in [NSID], including relevant IANA action. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 6, 2006 [Page 7] + +Internet-Draft Serverid March 2006 + + +4. Security Considerations + + Providing identifying information as to which server is responding to + a particular query from a particular location in the Internet 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. + + Both authentication and confidentiality of serverid data are + potentially of interest to administrators-- that is, operators may + wish to make serverid data available and reliable to themselves and + their chosen associates only. This would imply both an ability to + authenticate it to themselves and keep it private from arbitrary + other parties. This led to Characteristics 4 and 5 of an improved + solution. + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 6, 2006 [Page 8] + +Internet-Draft Serverid March 2006 + + +5. 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 version + 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. + +6. References + + [1] Mockapetris, P., "Domain Names - Concepts and Facilities", + RFC 1034, STD 0013, November 1987. + + [2] Mockapetris, P., "Domain Names - Implementation and + Specification", RFC 1035, STD 0013, November 1987. + + [3] Hardie, T., "Distributing Authoritative Name Servers via Shared + Unicast Addresses", RFC 3258, April 2002. + + [4] ISC, "BIND 9 Configuration Reference". + + [5] Austein, S., "DNS Name Server Identifier Option (NSID)", + Internet Drafts http://www.ietf.org/internet-drafts/ + draft-ietf-dnsext-nsid-01.txt, January 2006. + + [6] Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 6, 2006 [Page 9] + +Internet-Draft Serverid March 2006 + + +Authors' Addresses + + Suzanne Woolf + Internet Systems Consortium, Inc. + 950 Charter Street + Redwood City, CA 94063 + US + + Phone: +1 650 423-1333 + Email: woolf@isc.org + URI: http://www.isc.org/ + + + David Conrad + Nominum, Inc. + 2385 Bay Road + Redwood City, CA 94063 + US + + Phone: +1 1 650 381 6003 + Email: david.conrad@nominum.com + URI: http://www.nominum.com/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 6, 2006 [Page 10] + +Internet-Draft Serverid March 2006 + + +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 (2006). 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 September 6, 2006 [Page 11] + +