+++ /dev/null
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-
--- /dev/null
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+
projects / thirdparty / bind9.git / commitdiff
