draft-ietf-dnsop-serverid-00.txt		draft-ietf-dnsop-serverid-01.txt
	INTERNET-DRAFT David Conrad		INTERNET-DRAFT David Conrad
	draft-ietf-dnsop-serverid-00.txt Nominum, Inc.		draft-ietf-dnsop-serverid-01.txt Nominum, Inc.
	May, 2002		November, 2002
	Identifying an Authoritative Name Server		Identifying an Authoritative Name Server
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 3, line 4		skipping to change at page 3, line 4
	For reference, the other well-known name used by recent versions of		For reference, the other well-known name used by recent versions of
	BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A		BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A
	query for a TXT RR for this name will return an administratively re-		query for a TXT RR for this name will return an administratively re-
	definable string which defaults to the version of the server		definable string which defaults to the version of the server
	responding.		responding.
	4. An Implementation Neutral Convention		4. An Implementation Neutral Convention
	The previously described use of the CHAOS class "BIND." domain has		The previously described use of the CHAOS class "BIND." domain has
	rightly been viewed by many implementors as not being standardized		(rightly) been viewed by many implementors as not being standardized
	nor being implementation neutral. As such, a standard mechanism to		nor being implementation neutral. As such, a standard mechanism to
	identify a particular machine among a shared unicast set of machines		identify a particular machine among a shared unicast set of machines
	serving the same DNS data does not currently exist.		serving the same DNS data does not currently exist.
	Since a name server conforming to [RFC1034] and [RFC1035] should		Since a name server conforming to [RFC1034] and [RFC1035] should
	support the CHAOS class and the use of TXT resource record queries in		support the CHAOS class and the use of TXT resource record queries in
	the CHAOS class to derive information about a name server has been		the CHAOS class to derive information about a name server has been
	used in several independent name server implementations, the quickest		used in several independent name server implementations, the quickest
	way of supporting the identification of a particular name server out		way of supporting the identification of a particular name server out
	of a set of name servers all sharing the same unicast prefix would		of a set of name servers all sharing the same unicast prefix would
	skipping to change at page 3, line 29		skipping to change at page 3, line 29
	domain to be "SERVER." instead of "BIND.". Since using the actual		domain to be "SERVER." instead of "BIND.". Since using the actual
	hostname may be considered an information leakage security risk, the		hostname may be considered an information leakage security risk, the
	use of the actual hostname of the server is discouraged and instead a		use of the actual hostname of the server is discouraged and instead a
	unique per-server identifier should be used. As the BIND convention		unique per-server identifier should be used. As the BIND convention
	of "HOSTNAME" implies the use of a hostname, the domain name		of "HOSTNAME" implies the use of a hostname, the domain name
	"ID.SERVER" is proposed. That is, a TXT RR query for "ID.SERVER." in		"ID.SERVER" is proposed. That is, a TXT RR query for "ID.SERVER." in
	the CHAOS class will return an administratively defined string that		the CHAOS class will return an administratively defined string that
	can be used to differentiate among multiple servers.		can be used to differentiate among multiple servers.
	To make this convention useful, DNS operators wishing to identify		To make this convention useful, DNS operators wishing to identify
	their servers MUST put a unique string for the RDATA of the TXT		their servers uniquely MUST, for EACH server, put a unique string for
	record associated with the "ID.SERVER." domain in class CHAOS.		the RDATA of the TXT record associated with the "ID.SERVER." domain
	Implementors MUST provide a way to disable returning identifying		in class CHAOS. For example, given two machines "a.example.com" and
			"b.example.com" that receive DNS queries at the same IP address, the
			name server administrator could include
			$ORIGIN SERVER.
			ID CH TXT "a"
			in the appropriate zone file on machine "a.example.com" and
			$ORIGIN SERVER.
			ID CH TXT "b"
			in the appropriate zone file on machine "b.example.com".
			Queries for TXT RRs of "id.server" in class CHAOS to the IP address
			serving both "a.example.com" and "b.example.com" should return "a" or
			"b" depending on which machine the query was routed.
			Implementors MUST provide a way to disable returning this identifying
	information. Implementors SHOULD provide a way to limit who can		information. Implementors SHOULD provide a way to limit who can
	query for the identifying information.		query for the identifying information.
	The use of other names in the CHAOS class "SERVER." domain are beyond		The use of other names in the CHAOS class "SERVER." domain are beyond
	the scope of this document.		the scope of this document.
	IANA Considerations		IANA Considerations
	The "SERVER." domain in the CHAOS class should be reserved by IANA		The "SERVER." domain in the CHAOS class should be reserved by IANA
	and a registry should be created that reserves the "ID" name. In the		and a registry should be created that reserves the "ID" name. In the
	future, requests may be submitted for other sub-domains of "SERVER.",		future, requests may be submitted for other sub-domains of "SERVER.",
	e.g., "VERSION.SERVER." and the IANA should take appropriate action.		e.g., "VERSION.SERVER." and the IANA should take appropriate action.
	Security Considerations		Security Considerations
	Providing identifying information as to which server is responding		Providing identifying information as to which server is responding
	can be seen as information leakage and thus a security risk. It may		can be seen as information leakage and thus a security risk. It may
	be appropriate to restrict who can query for the "ID.SERVER."		be appropriate to restrict who can query for the "ID.SERVER." domain.
	domain. Filtering on source address would be one way in which		Filtering on source address would be one way in which restrictions
	restrictions can be applied.		can be applied.
	The identifer returned via an "ID.SERVER." query SHOULD NOT contain		The identifer returned via an "ID.SERVER." query SHOULD NOT contain
	the hostname or other information that could be considered sensitive.		the hostname or other information that could be considered sensitive.
	Acknowledgements		Acknowledgements
	The technique for host identification documented here derive from		The technique for host identification documented here derive from
	practices implemented by Paul Vixie of the Internet Software		practices implemented by Paul Vixie of the Internet Software
	Consortium in the Berkeley Internet Name Domain package. Useful		Consortium in the Berkeley Internet Name Domain package. Useful
	comments on earlier drafts were provided by Bob Halley, Brian		comments on earlier drafts were provided by Bob Halley, Brian
	Wellington, Andreas Gustafsson, Ted Hardie, Chris Yarnell, and		Wellington, Andreas Gustafsson, Ted Hardie, Chris Yarnell, and
	members of the ICANN Root Server System Advisory Council.		members of the ICANN Root Server System Advisory Council. Additional
			explanatory information provided due to questions received from Randy
			Bush.
	References		References
	[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",		[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
	RFC 1034, November 1987.		RFC 1034, November 1987.
	[RFC1035] Mockapetris, P., "Domain Names - Implementation and		[RFC1035] Mockapetris, P., "Domain Names - Implementation and
	Specifications", RFC 1035, November 1987.		Specifications", RFC 1035, November 1987.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/