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/