draft-ietf-dnsext-nsid-01.txt
来自「非常好的dns解析软件」· 文本 代码 · 共 841 行 · 第 1/2 页
TXT
841 行
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 complicateAustein 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 20064. 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 20065. 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 20066. 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 20067. References7.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 2006Author's Address Rob Austein ISC 950 Charter Street Redwood City, CA 94063 USA Email: sra@isc.orgAustein Expires July 15, 2006 [Page 14] Internet-Draft DNS NSID January 2006Intellectual 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] ⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?