doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc5001.txt b/doc/rfc/rfc5001.txt
new file mode 100644
index 0000000..fe15339
--- /dev/null
+++ b/doc/rfc/rfc5001.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                         R. Austein
+Request for Comments: 5001                                           ISC
+Category: Standards Track                                    August 2007
+
+
+                DNS Name Server Identifier (NSID) Option
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  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.  While existing ad-hoc
+   mechanisms allow an operator to send follow-up queries when it is
+   necessary to debug such a configuration, the only completely reliable
+   way to obtain the identity of the name server that responded is to
+   have the name server include this information in the response itself.
+   This note defines a protocol extension to support this functionality.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                     Standards Track                     [Page 1]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+     1.1.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     2.1.  Resolver Behavior  . . . . . . . . . . . . . . . . . . . .  3
+     2.2.  Name Server Behavior . . . . . . . . . . . . . . . . . . .  3
+     2.3.  The NSID Option  . . . . . . . . . . . . . . . . . . . . .  4
+     2.4.  Presentation Format  . . . . . . . . . . . . . . . . . . .  4
+   3.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1.  The NSID Payload . . . . . . . . . . . . . . . . . . . . .  4
+     3.2.  NSID Is Not Transitive . . . . . . . . . . . . . . . . . .  7
+     3.3.  User Interface Issues  . . . . . . . . . . . . . . . . . .  7
+     3.4.  Truncation . . . . . . . . . . . . . . . . . . . . . . . .  8
+   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
+
+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.
+
+   Existing ad-hoc mechanisms allow an operator to send follow-up
+   queries when it is necessary to debug such a configuration, but there
+   are situations in which this is not a totally satisfactory solution,
+   since anycast routing may have changed, or the server pool in
+   question may be behind some kind of extremely dynamic load balancing
+   hardware.  Thus, while these ad-hoc mechanisms are certainly better
+   than nothing (and have the advantage of already being deployed), a
+   better solution seems desirable.
+
+   Given that a DNS query is an idempotent operation with no retained
+   state, it would appear that the only completely reliable way to
+   obtain the identity of the name server that responded to a particular
+   query is to have that name server include identifying information in
+   the response itself.  This note defines a protocol enhancement to
+   achieve this.
+
+
+
+
+
+
+
+
+Austein                     Standards Track                     [Page 2]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+1.1.  Reserved Words
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Protocol
+
+   This note uses an EDNS [RFC2671] option to signal the resolver's
+   desire for information identifying the name server and to hold the
+   name server's response, if any.
+
+2.1.  Resolver Behavior
+
+   A resolver signals its desire for information identifying a name
+   server by sending an empty NSID option (Section 2.3) in an EDNS OPT
+   pseudo-RR in the query message.
+
+   The resolver MUST NOT include any NSID payload data in the query
+   message.
+
+   The semantics of an NSID request are not transitive.  That is: the
+   presence of an NSID option in a query is a request that the name
+   server which receives the query identify itself.  If the name server
+   side of a recursive name server receives an NSID request, the client
+   is asking the recursive name server to identify itself; if the
+   resolver side of the recursive name server wishes to receive
+   identifying information, it is free to add NSID requests in its own
+   queries, but that is a separate matter.
+
+2.2.  Name Server Behavior
+
+   A name server that understands the NSID option and chooses to honor a
+   particular NSID request responds by including identifying information
+   in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR in the
+   response message.
+
+   The name server MUST ignore any NSID payload data that might be
+   present in the query message.
+
+   The NSID option is not transitive.  A name server MUST NOT send an
+   NSID option back to a resolver which did not request it.  In
+   particular, while a recursive name server may choose to add an NSID
+   option when sending a query, this has no effect on the presence or
+   absence of the NSID option in the recursive name server's response to
+   the original client.
+
+
+
+
+
+Austein                     Standards Track                     [Page 3]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+   As stated in Section 2.1, this mechanism is not restricted to
+   authoritative name servers; the semantics are intended to be equally
+   applicable to recursive name servers.
+
+2.3.  The NSID Option
+
+   The OPTION-CODE for the NSID option is 3.
+
+   The OPTION-DATA for the NSID option is an opaque byte string, the
+   semantics of which are deliberately left outside the protocol.  See
+   Section 3.1 for discussion.
+
+2.4.  Presentation Format
+
+   User interfaces MUST read and write the contents of the NSID option
+   as a sequence of hexadecimal digits, two digits per payload octet.
+
+   The NSID payload is binary data.  Any comparison between NSID
+   payloads MUST be a comparison of the raw binary data.  Copy
+   operations MUST NOT assume that the raw NSID payload is null-
+   terminated.  Any resemblance between raw NSID payload data and any
+   form of text is purely a convenience, and does not change the
+   underlying nature of the payload data.
+
+   See Section 3.3 for discussion.
+
+3.  Discussion
+
+   This section discusses certain aspects of the protocol and explains
+   considerations that led to the chosen design.
+
+3.1.  The NSID Payload
+
+   The syntax and semantics of the content of the NSID option are
+   deliberately left outside the scope of this specification.
+
+   Choosing the NSID content is a prerogative of the server
+   administrator.  The server administrator might choose to encode the
+   NSID content in such a way that the server operator (or clients
+   authorized by the server operator) can decode the NSID content to
+   obtain more information than other clients can.  Alternatively, the
+   server operator might choose unencoded NSID content that is equally
+   meaningful to any client.
+
+   This section describes some of the kinds of data that server
+   administrators might choose to provide as the content of the NSID
+   option, and explains the reasoning behind specifying a simple opaque
+   byte string in Section 2.3.
+
+
+
+Austein                     Standards Track                     [Page 4]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+   There are several possibilities for the payload of the NSID option:
+
+   o  It could be the "real" name of the specific name server within the
+      name server pool.
+
+   o  It could be the "real" IP address (IPv4 or IPv6) of the name
+      server within the name server pool.
+
+   o  It could be some sort of pseudo-random number generated in a
+      predictable fashion somehow using the server's IP address or name
+      as a seed value.
+
+   o  It could be some sort of probabilistically unique identifier
+      initially derived from some sort of random number generator then
+      preserved across reboots of the name server.
+
+   o  It could be some sort of dynamically generated identifier so that
+      only the name server operator could tell whether or not any two
+      queries had been answered by the same server.
+
+   o  It could be a blob of signed data, with a corresponding key which
+      might (or might not) be available via DNS lookups.
+
+   o  It could be a blob of encrypted data, the key for which could be
+      restricted to parties with a need to know (in the opinion of the
+      server operator).
+
+   o  It could be an arbitrary string of octets chosen at the discretion
+      of the name server operator.
+
+   Each of these options has advantages and disadvantages:
+
+   o  Using the "real" name is simple, but the name server may not have
+      a "real" name.
+
+   o  Using the "real" address is also simple, and the name server
+      almost certainly does have at least one non-anycast IP address for
+      maintenance operations, but the operator of the name server may
+      not be willing to divulge its non-anycast address.
+
+   o  Given that one common reason for using anycast DNS techniques is
+      an attempt to harden a critical name server against denial of
+      service attacks, some name server operators are likely to want an
+      identifier other than the "real" name or "real" address of the
+      name server instance.
+
+   o  Using a hash or pseudo-random number can provide a fixed length
+      value that the resolver can use to tell two name servers apart
+
+
+
+Austein                     Standards Track                     [Page 5]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+      without necessarily being able to tell where either one of them
+      "really" is, but makes debugging more difficult if one happens to
+      be in a friendly open environment.  Furthermore, hashing might not
+      add much value, since a hash based on an IPv4 address still only
+      involves a 32-bit search space, and DNS names used for servers
+      that operators might have to debug at 4am tend not to be very
+      random.
+
+   o  Probabilistically unique identifiers have properties similar to
+      hashed identifiers, but (given a sufficiently good random number
+      generator) are immune to the search space issues.  However, the
+      strength of this approach is also its weakness: there is no
+      algorithmic transformation by which even the server operator can
+      associate name server instances with identifiers while debugging,
+      which might be annoying.  This approach also requires the name
+      server instance to preserve the probabilistically unique
+      identifier across reboots, but this does not appear to be a
+      serious restriction, since authoritative nameservers almost always
+      have some form of non-volatile storage.  In the rare case of a
+      name server that does not have any way to store such an
+      identifier, nothing terrible will happen if the name server
+      generates a new identifier every time it reboots.
+
+   o  Using an arbitrary octet string gives name server operators yet
+      another setting to configure, or mis-configure, or forget to
+      configure.  Having all the nodes in an anycast name server
+      constellation identify themselves as "My Name Server" would not be
+      particularly useful.
+
+   o  A signed blob is not particularly useful as an NSID payload unless
+      the signed data is dynamic and includes some kind of replay
+      protection, such as a timestamp or some kind of data identifying
+      the requestor.  Signed blobs that meet these criteria could
+      conceivably be useful in some situations but would require
+      detailed security analysis beyond the scope of this document.
+
+   o  A static encrypted blob would not be particularly useful, as it
+      would be subject to replay attacks and would, in effect, just be a
+      random number to any party that does not possess the decryption
+      key.  Dynamic encrypted blobs could conceivably be useful in some
+      situations but, as with signed blobs, dynamic encrypted blobs
+      would require detailed security analysis beyond the scope of this
+      document.
+
+   Given all of the issues listed above, there does not appear to be a
+   single solution that will meet all needs.  Section 2.3 therefore
+   defines the NSID payload to be an opaque byte string and leaves the
+   choice of payload up to the implementor and name server operator.
+
+
+
+Austein                     Standards Track                     [Page 6]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+   The following guidelines may be useful to implementors and server
+   operators:
+
+   o  Operators for whom divulging the unicast address is an issue could
+      use the raw binary representation of a probabilistically unique
+      random number.  This should probably be the default implementation
+      behavior.
+
+   o  Operators for whom divulging the unicast address is not an issue
+      could just use the raw binary representation of a unicast address
+      for simplicity.  This should only be done via an explicit
+      configuration choice by the operator.
+
+   o  Operators who really need or want the ability to set the NSID
+      payload to an arbitrary value could do so, but this should only be
+      done via an explicit configuration choice by the operator.
+
+   This approach appears to provide enough information for useful
+   debugging without unintentionally leaking the maintenance addresses
+   of anycast name servers to nogoodniks, while also allowing name
+   server operators who do not find such leakage threatening to provide
+   more information at their own discretion.
+
+3.2.  NSID Is Not Transitive
+
+   As specified in Section 2.1 and Section 2.2, the NSID option is not
+   transitive.  This is strictly a hop-by-hop mechanism.
+
+   Most of the discussion of name server identification to date has
+   focused on identifying authoritative name servers, since the best
+   known cases of anycast name servers are a subset of the name servers
+   for the root zone.  However, given that anycast DNS techniques are
+   also applicable to recursive name servers, the mechanism may also be
+   useful with recursive name servers.  The hop-by-hop semantics support
+   this.
+
+   While there might be some utility in having a transitive variant of
+   this mechanism (so that, for example, a stub resolver could ask a
+   recursive server to tell it which authoritative name server provided
+   a particular answer to the recursive name server), the semantics of
+   such a variant would be more complicated, and are left for future
+   work.
+
+3.3.  User Interface Issues
+
+   Given the range of possible payload contents described in
+   Section 3.1, it is not possible to define a single presentation
+   format for the NSID payload that is efficient, convenient,
+
+
+
+Austein                     Standards Track                     [Page 7]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+   unambiguous, and aesthetically pleasing.  In particular, while it is
+   tempting to use a presentation format that uses some form of textual
+   strings, attempting to support this would significantly complicate
+   what's intended to be a very simple debugging mechanism.
+
+   In some cases the content of the NSID payload may be binary data
+   meaningful only to the name server operator, and may not be
+   meaningful to the user or application, but the user or application
+   must be able to capture the entire content anyway in order for it to
+   be useful.  Thus, the presentation format must support arbitrary
+   binary data.
+
+   In cases where the name server operator derives the NSID payload from
+   textual data, a textual form such as US-ASCII or UTF-8 strings might
+   at first glance seem easier for a user to deal with.  There are,
+   however, a number of complex issues involving internationalized text
+   which, if fully addressed here, would require a set of rules
+   significantly longer than the rest of this specification.  See
+   [RFC2277] for an overview of some of these issues.
+
+   It is much more important for the NSID payload data to be passed
+   unambiguously from server administrator to user and back again than
+   it is for the payload data to be pretty while in transit.  In
+   particular, it's critical that it be straightforward for a user to
+   cut and paste an exact copy of the NSID payload output by a debugging
+   tool into other formats such as email messages or web forms without
+   distortion.  Hexadecimal strings, while ugly, are also robust.
+
+3.4.  Truncation
+
+   In some cases, adding the NSID option to a response message may
+   trigger message truncation.  This specification does not change the
+   rules for DNS message truncation in any way, but implementors will
+   need to pay attention to this issue.
+
+   Including the NSID option in a response is always optional, so this
+   specification never requires name servers to truncate response
+   messages.
+
+   By definition, a resolver that requests NSID responses also supports
+   EDNS, so a resolver that requests NSID responses can also use the
+   "sender's UDP payload size" field of the OPT pseudo-RR to signal a
+   receive buffer size large enough to make truncation unlikely.
+
+4.  IANA Considerations
+
+   IANA has allocated EDNS option code 3 for the NSID option
+   (Section 2.3).
+
+
+
+Austein                     Standards Track                     [Page 8]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+5.  Security Considerations
+
+   This document describes a channel signaling mechanism intended
+   primarily for debugging.  Channel signaling mechanisms are outside
+   the scope of DNSSEC, per se.  Applications that require integrity
+   protection for the data being signaled will need to use a channel
+   security mechanism such as TSIG [RFC2845].
+
+   Section 3.1 discusses a number of different kinds of information that
+   a name server operator might choose to provide as the value of the
+   NSID option.  Some of these kinds of information are security
+   sensitive in some environments.  This specification deliberately
+   leaves the syntax and semantics of the NSID option content up to the
+   implementation and the name server operator.
+
+   Two of the possible kinds of payload data discussed in Section 3.1
+   involve a digital signature and encryption, respectively.  While this
+   specification discusses some of the pitfalls that might lurk for
+   careless users of these kinds of payload data, full analysis of the
+   issues that would be involved in these kinds of payload data would
+   require knowledge of the content to be signed or encrypted,
+   algorithms to be used, and so forth, which is beyond the scope of
+   this document.  Implementors should seek competent advice before
+   attempting to use these kinds of NSID payloads.
+
+6.  Acknowledgements
+
+   Thanks to: Joe Abley, Harald Alvestrand, Dean Anderson, Mark Andrews,
+   Roy Arends, Steve Bellovin, Alex Bligh, Randy Bush, David Conrad,
+   John Dickinson, Alfred Hoenes, Johan Ihren, Daniel Karrenberg, Peter
+   Koch, William Leibzon, Ed Lewis, Thomas Narten, Mike Patton, Geoffrey
+   Sisson, Andrew Sullivan, Mike StJohns, Tom Taylor, Paul Vixie, Sam
+   Weiler, and Suzanne Woolf, none of whom are responsible for what the
+   author did with their comments and suggestions.  Apologies to anyone
+   inadvertently omitted from the above list.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", RFC 2119, BCP 14, March 1997.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+
+
+
+
+
+Austein                     Standards Track                     [Page 9]
+
+RFC 5001                        DNS NSID                     August 2007
+
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+7.2.  Informative References
+
+   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
+              Languages", RFC 2277, BCP 18, January 1998.
+
+Author's Address
+
+   Rob Austein
+   ISC
+   950 Charter Street
+   Redwood City, CA  94063
+   USA
+
+   EMail: sra@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                     Standards Track                    [Page 10]
+
+RFC 5001                        DNS NSID                     August 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.
+
+
+
+
+
+
+
+Austein                     Standards Track                    [Page 11]
+