draft-ietf-dnsop-serverid-08.txt		rfc4892.txt
	Network Working Group S. Woolf		Network Working Group S. Woolf
	Internet-Draft Internet Systems Consortium, Inc.		Request for Comments: 4892 Internet Systems Consortium, Inc.
	Intended Status: Informational D. Conrad		Category: Informational D. Conrad
	Expires: July 26, 2007 ICANN		ICANN
	January 22, 2007
	Requirements for a Mechanism Identifying a Name Server Instance		Requirements for a Mechanism Identifying a Name Server Instance
	draft-ietf-dnsop-serverid-08
	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		Status of This Memo
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on July 26, 2007.		This memo provides information for the Internet community. It does
			not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	With the increased use of DNS anycast, load balancing, and other		With the increased use of DNS anycast, load balancing, and other
	mechanisms allowing more than one DNS name server to share a single		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		IP address, it is sometimes difficult to tell which of a pool of name
	skipping to change at page 3, line 17		skipping to change at page 2, line 5
	Identifying which name server is responding to queries is often		Identifying which name server is responding to queries is often
	useful, particularly in attempting to diagnose name server		useful, particularly in attempting to diagnose name server
	difficulties. This is most obviously useful for authoritative		difficulties. This is most obviously useful for authoritative
	nameservers in the attempt to diagnose the source or prevalence of		nameservers in the attempt to diagnose the source or prevalence of
	inaccurate data, but can also conceivably be useful for caching		inaccurate data, but can also conceivably be useful for caching
	resolvers in similar and other situations. Furthermore, the ability		resolvers in similar and other situations. Furthermore, the ability
	to identify which server is responding to a query has become more		to identify which server is responding to a query has become more
	useful as DNS has become more critical to more Internet users, and as		useful as DNS has become more critical to more Internet users, and as
	network and server deployment topologies have become more complex.		network and server deployment topologies have become more complex.
	The traditional means for determining which of several possible		The conventional means for determining which of several possible
	servers is answering a query has traditionally been based on the use		servers is answering a query has traditionally been based on the use
	of the server's IP address as a unique identifier. However, the		of the server's IP address as a unique identifier. However, the
	modern Internet has seen the deployment of various load balancing,		modern Internet has seen the deployment of various load balancing,
	fault-tolerance, or attack-resistance schemes such as shared use of		fault-tolerance, or attack-resistance schemes such as shared use of
	unicast IP addresses as documented in [RFC3258]. An unfortunate side		unicast IP addresses as documented in [RFC3258]. An unfortunate side
	effect of these schemes has been to make the use of IP addresses as		effect of these schemes has been to make the use of IP addresses as
	identifiers associated with DNS (or any other) service somewhat		identifiers associated with DNS (or any other) service somewhat
	problematic. Specifically, multiple dedicated DNS queries may not go		problematic. Specifically, multiple dedicated DNS queries may not go
	to the same server even though sent to the same IP address. Non-DNS		to the same server even though sent to the same IP address. Non-DNS
	methods such as ICMP ping, TCP connections, or non-DNS UDP packets		methods such as ICMP ping, TCP connections, or non-DNS UDP packets
	skipping to change at page 4, line 8		skipping to change at page 2, line 32
	unique "server that answered the query I sent to IP address A.B.C.D".		unique "server that answered the query I sent to IP address A.B.C.D".
	The widespread use of the existing convention suggests a need for a		The widespread use of the existing convention suggests a need for a
	documented, interoperable means of querying the identity of a		documented, interoperable means of querying the identity of a
	nameserver that may be part of an anycast or load-balancing cluster.		nameserver that may be part of an anycast or load-balancing cluster.
	At the same time, however, it also has some drawbacks that argue		At the same time, however, it also has some drawbacks that argue
	against standardizing it as it's been practiced so far.		against standardizing it as it's been practiced so far.
	2. Existing Conventions		2. Existing Conventions
	For some time, the commonly deployed Berkeley Internet Name Domain		For some time, the commonly deployed Berkeley Internet Name Domain
	implementation of the DNS protocol suite from the Internet Systems		(BIND) implementation of the DNS protocol suite from the Internet
	Consortium [BIND] has supported a way of identifying a particular		Systems Consortium [BIND] has supported a way of identifying a
	server via the use of a standards-compliant, if somewhat unusual, DNS		particular server via the use of a standards-compliant, if somewhat
	query. Specifically, a query to a recent BIND server for a TXT		unusual, DNS query. Specifically, a query to a recent BIND server
	resource record in class 3 (CHAOS) for the domain name		for a TXT resource record in class 3 (CHAOS) for the domain name
	"HOSTNAME.BIND." will return a string that can be configured by the		"HOSTNAME.BIND." will return a string that can be configured by the
	name server administrator to provide a unique identifier for the		name server administrator to provide a unique identifier for the
	responding server. (The value defaults to the result of a		responding server. (The value defaults to the result of a
	gethostname() call). This mechanism, which is an extension of the		gethostname() call). This mechanism, which is an extension of the
	BIND convention of using CHAOS class TXT RR queries to sub-domains of		BIND convention of using CHAOS class TXT RR queries to sub-domains of
	the "BIND." domain for version information, has been copied by		the "BIND." domain for version information, has been copied by
	several name server vendors.		several name server vendors.
	A refinement to the BIND-based mechanism, which dropped the		A refinement to the BIND-based mechanism, which dropped the
	implementation-specific label, replaces "BIND." with "SERVER.". Thus		implementation-specific label, replaces "BIND." with "SERVER.". Thus
	skipping to change at page 5, line 32		skipping to change at page 4, line 7
	situations in which this simply isn't reliable.		situations in which this simply isn't reliable.
	2. It reserves an entire class in the DNS (CHAOS) for what amounts		2. It reserves an entire class in the DNS (CHAOS) for what amounts
	to one zone. While CHAOS class is defined in [RFC1034] and		to one zone. While CHAOS class is defined in [RFC1034] and
	[RFC1035], it's not clear that supporting it solely for this		[RFC1035], it's not clear that supporting it solely for this
	purpose is a good use of the namespace or of implementation		purpose is a good use of the namespace or of implementation
	effort.		effort.
	3. The initial and still common form, using "BIND.", is		3. The initial and still common form, using "BIND.", is
	implementation specific. BIND is one DNS implementation. At the		implementation specific. BIND is one DNS implementation. At the
	time of this writing, it is probably the most prevalent for		time of this writing, it is probably most prevalent for
	authoritative servers. This does not justify standardizing on		authoritative servers. This does not justify standardizing on
	its ad hoc solution to a problem shared across many operators and		its ad hoc solution to a problem shared across many operators and
	implementors. Meanwhile, the aforementioned refinement changes		implementors. Meanwhile, the aforementioned refinement changes
	the query label but preserves the ad hoc CHAOS/TXT mechanism.		the query label but preserves the ad hoc CHAOS/TXT mechanism.
	4. There is no convention or shared understanding of what		4. There is no convention or shared understanding of what
	information an answer to such a query for a server identity could		information an answer to such a query for a server identity could
	or should contain, including a possible encoding or		or should contain, including a possible encoding or
	authentication mechanism.		authentication mechanism.
	5. Hypothetically, since DNSSEC has been defined to cover all DNS		5. Hypothetically, since DNSSEC has been defined to cover all DNS
	classes, the TXT RRs returned in response to the "ID.SERVER."		classes, the TXT RRs returned in response to the "ID.SERVER."
	query could be signed, which has the advantages described in		query could be signed, which has the advantages described in
	[RFC4033]. However, since DNSSEC deployment for the CHAOS class		[RFC4033]. However, since DNSSEC deployment for the CHAOS class
	is neither existent nor foreseeable, and since the "ID.SERVER."		is neither existent nor foreseeable, and since the "ID.SERVER."
	TXT RR is expected to be unique per server, this would be		TXT RR is expected to be unique per server, this would be
	impossible in practice.		impossible in practice.
	The first of the listed disadvantages may be technically the most		The first of the listed disadvantages may be technically the most
	serious. It argues for an attempt to design a good answer to the		serious. It argues for an attempt to design a good answer to the
	problem that "I need to know what nameserver is answering my		problem, "I need to know what nameserver is answering my queries",
	queries", not simply a convenient one.		not simply a convenient one.
	3. Characteristics of an Implementation Neutral Convention		3. Characteristics of an Implementation Neutral Convention
	The discussion above of advantages and disadvantages to the		The discussion above of advantages and disadvantages to the
	"HOSTNAME.BIND." mechanism suggest some requirements for a better		"HOSTNAME.BIND." mechanism suggest some requirements for a better
	solution to the server identification problem. These are summarized		solution to the server identification problem. These are summarized
	here as guidelines for any effort to provide appropriate protocol		here as guidelines for any effort to provide appropriate protocol
	extensions:		extensions:
	1. The mechanism adopted must be in-band for the DNS protocol. That		1. The mechanism adopted must be in-band for the DNS protocol. That
	is, it needs to allow the query for the server's identifying		is, it needs to allow the query for the server's identifying
	information to be part of a normal, operational query. It should		information to be part of a normal, operational query. It should
	also permit a separate, dedicated query for the server's		also permit a separate, dedicated query for the server's
	identifying information. But it should preserve the ability of		identifying information. But it should preserve the ability of
	the CHAOS/TXT query-based mechanism to work through firewalls and		the CHAOS/TXT query-based mechanism to work through firewalls and
	in other situations where only DNS can be relied upon to reach		in other situations where only DNS can be relied upon to reach
	the server of interest.		the server of interest.
	2. The new mechanism should not require dedicated namespaces or		2. The new mechanism should not require dedicated namespaces or
	other reserved values outside of the existing protocol mechanisms		other reserved values outside of the existing protocol mechanisms
	for these, i.e. the OPT pseudo-RR. In particular, it should not		for these, i.e., the OPT pseudo-RR. In particular, it should not
	propagate the existing drawback of requiring support for a CLASS		propagate the existing drawback of requiring support for a CLASS
	and top level domain in the authoritative server (or the querying		and top level domain in the authoritative server (or the querying
	tool) to be useful.		tool) to be useful.
	3. Support for the identification functionality should be easy to		3. Support for the identification functionality should be easy to
	implement and easy to enable. It must be easy to disable and		implement and easy to enable. It must be easy to disable and
	should lend itself to access controls on who can query for it.		should lend itself to access controls on who can query for it.
	4. It should be possible to return a unique identifier for a server		4. It should be possible to return a unique identifier for a server
	without requiring the exposure of information that may be non-		without requiring the exposure of information that may be non-
	skipping to change at page 10, line 10		skipping to change at page 6, line 18
	their chosen associates only. This constraint would imply both an		their chosen associates only. This constraint would imply both an
	ability to authenticate it to themselves and to keep it private from		ability to authenticate it to themselves and to keep it private from
	arbitrary other parties, which leads to characteristics 4 and 5 of an		arbitrary other parties, which leads to characteristics 4 and 5 of an
	improved solution.		improved solution.
	6. Acknowledgements		6. Acknowledgements
	The technique for host identification documented here was initially		The technique for host identification documented here was initially
	implemented by Paul Vixie of the Internet Software Consortium in the		implemented by Paul Vixie of the Internet Software Consortium in the
	Berkeley Internet Name Daemon package. Comments and questions on		Berkeley Internet Name Daemon package. Comments and questions on
	earlier drafts were provided by Bob Halley, Brian Wellington, Andreas		earlier versions were provided by Bob Halley, Brian Wellington,
	Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the		Andreas Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and
	ICANN Root Server System Advisory Committee. The newest version		members of the ICANN Root Server System Advisory Committee. The
	takes a significantly different direction from previous versions,		newest version takes a significantly different direction from
	owing to discussion among contributors to the DNSOP working group and		previous versions, owing to discussion among contributors to the
	others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam		DNSOP working group and others, particularly Olafur Gudmundsson, Ed
	Weiler, and Rob Austein.		Lewis, Bill Manning, Sam Weiler, and Rob Austein.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",		[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
	RFC 1034, STD 0013, November 1987.		STD 13, RFC 1034, November 1987.
	[RFC1035] Mockapetris, P., "Domain Names - Implementation and		[RFC1035] Mockapetris, P., "Domain Names - Implementation and
	Specification", RFC 1035, STD 0013, November 1987.		Specification", STD 13, RFC 1035, November 1987.
	[RFC3258] Hardie, T., "Distributing Authoritative Name Servers via		[RFC3258] Hardie, T., "Distributing Authoritative Name Servers via
	Shared Unicast Addresses", RFC 3258, April 2002.		Shared Unicast Addresses", RFC 3258, April 2002.
	7.2. Informative References		7.2. Informative References
	[BIND] ISC, "BIND 9 Configuration Reference".		[BIND] ISC, "BIND 9 Configuration Reference".
	[NSID] Austein, S., "DNS Name Server Identifier Option (NSID)",		[NSID] Austein, R., "DNS Name Server Identifier Option (NSID)",
	Internet Drafts http://www.ietf.org/internet-drafts/		Work in Progress, June 2006.
	draft-ietf-dnsext-nsid-02.txt, June 2006.
	[RFC4033] Arends, R., Austein, S., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements", RFC 4033,		Rose, "DNS Security Introduction and Requirements", RFC
	March 2005.		4033, March 2005.
	Authors' Addresses		Authors' Addresses
	Suzanne Woolf		Suzanne Woolf
	Internet Systems Consortium, Inc.		Internet Systems Consortium, Inc.
	950 Charter Street		950 Charter Street
	Redwood City, CA 94063		Redwood City, CA 94063
	US		US
	Phone: +1 650 423-1333		Phone: +1 650 423-1333
	Email: woolf@isc.org		EMail: woolf@isc.org
	URI: http://www.isc.org/		URI: http://www.isc.org/
	David Conrad		David Conrad
	ICANN		ICANN
	4676 Admiralty Way		4676 Admiralty Way
	Marina del Rey, CA 90292		Marina del Rey, CA 90292
	US		US
	Phone: +1 310 823 9358		Phone: +1 310 823 9358
	Email: david.conrad@icann.org		EMail: david.conrad@icann.org
	URI: http://www.iana.org/		URI: http://www.iana.org/
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	skipping to change at page 13, line 45		skipping to change at page 8, line 45
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment		Acknowledgement
	Funding for the RFC Editor function is provided by the IETF		Funding for the RFC Editor function is currently provided by the
	Administrative Support Activity (IASA).		Internet Society.
End of changes. 18 change blocks.
	57 lines changed or deleted		34 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/