diff options
Diffstat (limited to 'contrib/bind9/doc/draft/draft-ietf-dnsext-nsid-01.txt')
| -rw-r--r-- | contrib/bind9/doc/draft/draft-ietf-dnsext-nsid-01.txt | 840 |
1 files changed, 0 insertions, 840 deletions
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsid-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-nsid-01.txt deleted file mode 100644 index 90d1a06..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsid-01.txt +++ /dev/null @@ -1,840 +0,0 @@ - - - -Network Working Group R. Austein -Internet-Draft ISC -Expires: July 15, 2006 January 11, 2006 - - - DNS Name Server Identifier Option (NSID) - draft-ietf-dnsext-nsid-01 - -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 July 15, 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. While existing ad-hoc - mechanism 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 which 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 Expires July 15, 2006 [Page 1] - -Internet-Draft DNS NSID January 2006 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 4 - 2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 4 - 2.3. The NSID Option . . . . . . . . . . . . . . . . . . . . . 4 - 2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 5 - 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 6 - 3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 8 - 3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 8 - 3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 - Intellectual Property and Copyright Statements . . . . . . . . . . 15 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 2] - -Internet-Draft DNS NSID January 2006 - - -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 which 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. - -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]. - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 3] - -Internet-Draft DNS NSID January 2006 - - -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 which 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. - - 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 [TBD]. - - - -Austein Expires July 15, 2006 [Page 4] - -Internet-Draft DNS NSID January 2006 - - - 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 content 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 5] - -Internet-Draft DNS NSID January 2006 - - -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 is - deliberately left outside the scope of this specification. This - section describe 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 choosing a simple opaque byte string. - - 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 probabilisticly 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 dynamicly 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. - - - - -Austein Expires July 15, 2006 [Page 6] - -Internet-Draft DNS NSID January 2006 - - - 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 - 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 Probabilisticly unique identifiers have similar properties 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 probabilisticly unique identifier - across reboots, but this does not appear to be a serious - restriction, since authoritative nameservers almost always have - some form of nonvolatile storage in any case, and 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 just - generates a new identifier every time it reboots. - - o Using an arbitrary octet string gives name server operators yet - another thing 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. - - 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 up to the implementor and name server operator. The following - guidelines may be useful to implementors and server operators: - - - - -Austein Expires July 15, 2006 [Page 7] - -Internet-Draft DNS NSID January 2006 - - - o Operators for whom divulging the unicast address is an issue could - use the raw binary representation of a probabilisticly 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, - 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 - - - -Austein Expires July 15, 2006 [Page 8] - -Internet-Draft DNS NSID January 2006 - - - 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 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. - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 9] - -Internet-Draft DNS NSID January 2006 - - -4. IANA Considerations - - This mechanism requires allocation of one ENDS option code for the - NSID option (Section 2.3). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 10] - -Internet-Draft DNS NSID January 2006 - - -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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 11] - -Internet-Draft DNS NSID January 2006 - - -6. Acknowledgements - - Joe Abley, Harald Alvestrand, Mark Andrews, Roy Arends, Steve - Bellovin, Randy Bush, David Conrad, Johan Ihren, Daniel Karrenberg, - Peter Koch, Mike Patton, Mike StJohns, Paul Vixie, Sam Weiler, and - Suzanne Woolf. Apologies to anyone inadvertently omitted from the - above list. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 12] - -Internet-Draft DNS NSID January 2006 - - -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. - - [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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 13] - -Internet-Draft DNS NSID January 2006 - - -Author's Address - - Rob Austein - ISC - 950 Charter Street - Redwood City, CA 94063 - USA - - Email: sra@isc.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 14] - -Internet-Draft DNS NSID January 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. - - - - -Austein Expires July 15, 2006 [Page 15] - |
