doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc4892.txt b/doc/rfc/rfc4892.txt
new file mode 100644
index 0000000..a89d3fb
--- /dev/null
+++ b/doc/rfc/rfc4892.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                           S. Woolf
+Request for Comments: 4892             Internet Systems Consortium, Inc.
+Category: Informational                                        D. Conrad
+                                                                   ICANN
+                                                               June 2007
+
+
+    Requirements for a Mechanism Identifying a Name Server Instance
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+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
+   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.
+
+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.
+
+
+
+
+
+Woolf & Conrad               Informational                      [Page 1]
+
+RFC 4892                        Serverid                       June 2007
+
+
+   The conventional 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 associated with DNS (or any other) service somewhat
+   problematic.  Specifically, multiple dedicated DNS queries may not go
+   to the same server 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 A.B.C.D".
+   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.
+
+2.  Existing Conventions
+
+   For some time, the commonly deployed Berkeley Internet Name Domain
+   (BIND) 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 label, replaces "BIND." with "SERVER.".  Thus
+   the query label to learn the unique name of a server may appear 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
+
+
+
+Woolf & Conrad               Informational                      [Page 2]
+
+RFC 4892                        Serverid                       June 2007
+
+
+   administratively defined string which defaults to the software
+   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.
+
+   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.
+
+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.
+
+
+
+
+Woolf & Conrad               Informational                      [Page 3]
+
+RFC 4892                        Serverid                       June 2007
+
+
+   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 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 aforementioned refinement changes
+       the query label 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 contain, including a possible encoding or
+       authentication mechanism.
+
+   5.  Hypothetically, since DNSSEC has been defined to cover all DNS
+       classes, the TXT RRs returned in response to the "ID.SERVER."
+       query could be signed, which has the advantages described in
+       [RFC4033].  However, since DNSSEC deployment for the CHAOS class
+       is neither existent nor foreseeable, and since the "ID.SERVER."
+       TXT RR is expected to be unique per server, this would be
+       impossible in practice.
+
+   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, "I need to know what nameserver is answering my queries",
+   not simply a convenient one.
+
+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
+
+
+
+
+Woolf & Conrad               Informational                      [Page 4]
+
+RFC 4892                        Serverid                       June 2007
+
+
+       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.
+
+4.  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.
+
+5.  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 server identification 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 the 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               Informational                      [Page 5]
+
+RFC 4892                        Serverid                       June 2007
+
+
+   Both authentication and confidentiality of server identification data
+   are potentially of interest to administrators -- that is, operators
+   may wish to make such data available and reliable to themselves and
+   their chosen associates only.  This constraint would imply both an
+   ability to authenticate it to themselves and to keep it private from
+   arbitrary other parties, which leads to characteristics 4 and 5 of an
+   improved solution.
+
+6.  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 versions 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.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC3258]  Hardie, T., "Distributing Authoritative Name Servers via
+              Shared Unicast Addresses", RFC 3258, April 2002.
+
+7.2.  Informative References
+
+   [BIND]     ISC, "BIND 9 Configuration Reference".
+
+   [NSID]     Austein, R., "DNS Name Server Identifier Option (NSID)",
+              Work in Progress, June 2006.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements", RFC
+              4033, March 2005.
+
+
+
+
+
+
+
+Woolf & Conrad               Informational                      [Page 6]
+
+RFC 4892                        Serverid                       June 2007
+
+
+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
+   ICANN
+   4676 Admiralty Way
+   Marina del Rey, CA  90292
+   US
+
+   Phone: +1 310 823 9358
+   EMail: david.conrad@icann.org
+   URI:   http://www.iana.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad               Informational                      [Page 7]
+
+RFC 4892                        Serverid                       June 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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, THE IETF TRUST 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.
+
+Intellectual Property
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Woolf & Conrad               Informational                      [Page 8]
+