Requirements for a Mechanism Identifying a Name Server Instance
RFC 4892
|
Document |
Type |
|
RFC - Informational
(June 2007; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 4892 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
David Kessens
|
|
Send notices to |
|
(None)
|
Network Working Group S. Woolf
Request for Comments: 4892 Internet Systems Consortium, Inc.
Category: Informational D. Conrad
ICANN
June 2007
Requirements for a Mechanism Identifying a Name Server Instance
Status of This Memo
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 (C) The IETF Trust (2007).
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
servers has answered a particular query. A standardized mechanism to
determine the identity of a name server responding to a particular
query would be useful, particularly as a diagnostic aid for
administrators. Existing ad hoc mechanisms for addressing this need
have some shortcomings, not the least of which is the lack of prior
analysis of exactly how such a mechanism should be designed and
deployed. This document describes the existing convention used in
some widely deployed implementations of the DNS protocol, including
advantages and disadvantages, and discusses some attributes of an
improved mechanism.
1. Introduction and Rationale
Identifying which name server is responding to queries is often
useful, particularly in attempting to diagnose name server
difficulties. This is most obviously useful for authoritative
nameservers in the attempt to diagnose the source or prevalence of
inaccurate data, but can also conceivably be useful for caching
resolvers in similar and other situations. Furthermore, the ability
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
network and server deployment topologies have become more complex.
Woolf & Conrad Informational [Page 1]
RFC 4892 Serverid June 2007
The conventional means for determining which of several possible
servers is answering a query has traditionally been based on the use
of the server's IP address as a unique identifier. However, the
modern Internet has seen the deployment of various load balancing,
fault-tolerance, or attack-resistance schemes such as shared use of
unicast IP addresses as documented in [RFC3258]. An unfortunate side
effect of these schemes has been to make the use of IP addresses as
identifiers associated with DNS (or any other) service somewhat
problematic. Specifically, multiple dedicated DNS queries may not go
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
(such as those generated by tools like "traceroute"), etc., may well
be even less certain to reach the same server as the one which
receives the DNS queries.
There is a well-known and frequently-used technique for determining
an identity for a nameserver more specific than the possibly-non-
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
documented, interoperable means of querying the identity of a
nameserver that may be part of an anycast or load-balancing cluster.
At the same time, however, it also has some drawbacks that argue
against standardizing it as it's been practiced so far.
2. Existing Conventions
For some time, the commonly deployed Berkeley Internet Name Domain
(BIND) implementation of the DNS protocol suite from the Internet
Systems Consortium [BIND] has supported a way of identifying a
particular server via the use of a standards-compliant, if somewhat
unusual, DNS query. Specifically, a query to a recent BIND server
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
name server administrator to provide a unique identifier for the
responding server. (The value defaults to the result of a
gethostname() call). This mechanism, which is an extension of the
BIND convention of using CHAOS class TXT RR queries to sub-domains of
the "BIND." domain for version information, has been copied by
several name server vendors.
A refinement to the BIND-based mechanism, which dropped the
implementation-specific label, replaces "BIND." with "SERVER.". Thus
the query label to learn the unique name of a server may appear as
"ID.SERVER.".
(For reference, the other well-known name used by recent versions of
Show full document text