--- 1/draft-ietf-dnsop-serverid-06.txt 2006-06-29 01:12:33.000000000 +0200 +++ 2/draft-ietf-dnsop-serverid-07.txt 2006-06-29 01:12:33.000000000 +0200 @@ -1,19 +1,20 @@ Network Working Group S. Woolf Internet-Draft Internet Systems Consortium, Inc. -Expires: September 6, 2006 D. Conrad - Nominum, Inc. - March 5, 2006 +Expires: December 28, 2006 D. Conrad + Internet Corporation for Assigned + Names and Numbers + June 26, 2006 Requirements for a Mechanism Identifying a Name Server Instance - draft-ietf-dnsop-serverid-06 + draft-ietf-dnsop-serverid-07 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 @@ -24,21 +25,21 @@ 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 September 6, 2006. + This Internet-Draft will expire on December 28, 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 @@ -140,21 +141,24 @@ 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. 5. Hypothetically, since it's an ordinary DNS record and the relevant DNSSEC RRs are class independent, the id.server response RR could be signed, which has the advantages described in - [RFC4033]. + [RFC4033]. However, since zone integrity of ".server." isn't + maintained from one server to another (otherwise, the RR returned + for "id.server." couldn't be unique per server), this would be + difficult or impossible in practice. 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 @@ -268,60 +272,64 @@ earlier drafts 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. 6. References - [1] Mockapetris, P., "Domain Names - Concepts and Facilities", +6.1 Normative References + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, STD 0013, November 1987. - [2] Mockapetris, P., "Domain Names - Implementation and + [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, STD 0013, November 1987. - [3] Hardie, T., "Distributing Authoritative Name Servers via Shared + [RFC3258] Hardie, T., "Distributing Authoritative Name Servers via Shared Unicast Addresses", RFC 3258, April 2002. - [4] ISC, "BIND 9 Configuration Reference". +6.2 Informative References - [5] Austein, S., "DNS Name Server Identifier Option (NSID)", + [BIND] ISC, "BIND 9 Configuration Reference". + + [NSID] Austein, S., "DNS Name Server Identifier Option (NSID)", Internet Drafts http://www.ietf.org/internet-drafts/ - draft-ietf-dnsext-nsid-01.txt, January 2006. + draft-ietf-dnsext-nsid-04.txt, December 2006. - [6] Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose, + [RFC4033] Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. 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 - Nominum, Inc. - 2385 Bay Road - Redwood City, CA 94063 + Internet Corporation for Assigned Names and Numbers + 4676 Admiralty Way, Suite 300 + Marina del Rey, CA 90292 US - Phone: +1 1 650 381 6003 - Email: david.conrad@nominum.com - URI: http://www.nominum.com/ + Phone: +1 310 823 9358 + Email: david.conrad@icann.org + URI: http://www.iana.org/ 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