diff options
Diffstat (limited to 'doc/draft/draft-ietf-dnsext-nsid-01.txt')
| -rw-r--r-- | doc/draft/draft-ietf-dnsext-nsid-01.txt | 840 |
1 files changed, 840 insertions, 0 deletions
diff --git a/doc/draft/draft-ietf-dnsext-nsid-01.txt b/doc/draft/draft-ietf-dnsext-nsid-01.txt new file mode 100644 index 0000000..90d1a06 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-nsid-01.txt @@ -0,0 +1,840 @@ + + + +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] + |