Network Working Group Robert Elz
Internet Draft University of Melbourne
Expiration Date: August 1996
Randy Bush
RGnet, Inc.
February 1996
Selection of Secondary DNS Servers
draft-ietf-dnsind-2ndry-00.txt
1. Status of this Memo
This document is an Internet-Draft. 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."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
2. Abstract
This draft discusses the selection of secondary servers for DNS
zones.
3. Introduction
Poor choice of secondary servers for DNS zones seems to currently be
an endemic problem. This draft discusses some of the issues, and
attempts to give some guidance in the matter of the selection of the
required secondary DNS server(s).
kre/randy [Page 1]
Internet Draft draft-ietf-dnsind-2ndry-00.txt February 1996
4. Definitions
For the purposes of this document, and only this document, the
following definitions apply:
DNS The Domain Name System [RFC1034, RFC1035].
Zone A part of the DNS tree, that is treated as a
unit.
Server An implementation of the DNS protocols able to
provide answers to queries. Answers may be
from information known by the server, or
information obtained from another server.
Authoritative Server A server that knows the content of a DNS zone
from local knowledge, and thus can answer
queries about that zone without needing to
query other servers.
Listed Server An Authoritative Server for which there is an
"NS" resource record (RR) in the zone.
Primary Server An authoritative server for which the zone
information is locally configured. Sometimes
known as a Master server.
Secondary Server An authoritative server that obtains
information about a zone from a Primary Server
via a zone transfer mechanism. Sometimes
known as a Slave Server.
5. Secondary Servers
A prime purpose of secondary servers is to allow information from the
Domain Name System to be available widely and reliably to clients
throughout the Internet (that is, throughout the world), even when
the primary server is unavailable or unreachable. They can also
spread the name resolution load, that purpose is not treated further
here.
When selecting secondary servers, attention should be given to the
various likely failure modes, and servers should be placed so that it
is likely that at least one server will be available to all
significant parts of the Internet, for any likely failure.
Consequently, placing all servers at the local site, while easy to
arrange, and easy to manage, is not a good policy, as they are
kre/randy [Page 2]
Internet Draft draft-ietf-dnsind-2ndry-00.txt February 1996
susceptible, together, to being disconnected from the Internet due to
a single link failure, or a site (or sometimes, building or even
room) wide power failure.
Secondary servers should be placed at both topologically and
geographically dispersed locations on the Internet, to minimise the
likelihood of a single failure disabling all of them.
6. Unreachable servers
Similarly, listing as a server, or as the address of a server, a name
or value that cannot be reached from much of the network is
undesirable. Not only does such a server add no reliability at all,
it actually causes the network as a whole (the Internet) problems, as
the lack of reachability cannot be ascertained other than by
attempted use and the subsequent lack or response (or occasionally
ICMP error response). Further, even that is generally
indistinguishable from a simple packet loss, so the sequence must be
repeated, several times, to give any real evidence of an unreachable
server. Further, the whole thing needs to be repeated from time to
time to distinguish a permanently unreachable server from a
temporarily unreachable one. Worst of all, all this may potentially
be done by every other DNS server on the Internet.
To avoid this problem, NS records for a zone returned in any response
should list only servers that the client requesting the information,
and others to which it may forward the reply, are likely to be able
to reach. Additionally, addresses of the servers returned must all
be reachable. As the addresses of each server form a Resource Record
Set [KRE1996], all must be returned (or none), thus it is not
acceptable to elide addresses of servers that are unreachable, or to
return them with a low TTL (while returning others with a higher
TTL).
In particular, when some servers are behind a firewall, which
disallows DNS queries or responses, their names, or addresses, should
not be returned to clients outside the firewall. Similarly, servers
outside the firewall should not be made known to clients inside it,
if the clients would be unable to query those servers. Implementing
this usually requires dual DNS setups, one for internal use, the
other for external use. Such a setup often solves other problems
with environments like this.
When a server is at a firewall boundary, reachable from both sides,
but using different addresses, that server should be given two names,
each name associated with appropriate A records, such that each
appears to be reachable only on the appropriate side of the firewall.
This should then be treated just like two servers, one on each side
kre/randy [Page 3]
Internet Draft draft-ietf-dnsind-2ndry-00.txt February 1996
of the firewall. Special care will need to be taken to allow such a
server to return the correct responses to clients on each side.
A similar problem occurs with DNS servers located in parts of the net
that are often disconnected from the Internet as a whole, for
example, those which connect via an intermittent connection that is
often down. A similar solution may need to be adopted, though here
much of the zone information can often be replicated, with only NS
records being adjusted.
Servers in this environment often need special provision to give them
access to the root servers. Often this is accomplished via "fake
root" configurations. In such a case the servers should be kept well
isolated from the rest of the DNS, lest their unusual configuration
pollute others.
7. How many secondaries?
The DNS specification requires at least two servers for every zone.
That is, usually, the primary and one secondary. While two,
carefully placed, are usually sufficient, occasions where two are
insufficient are frequent enough that we advise the use of more than
two listed servers. Various problems can cause a server to be
unavailable for extended periods - during such a period, a zone with
only two listed servers is actually running with just one. Since any
server may occasionally be unavailable, for all kinds of reasons,
this zone is likely, at times, to have no functional servers at all.
On the other hand, having large numbers of servers adds little
benefit, while adding costs. At the simplest, more servers cause
packets to be larger, so requiring more bandwidth. This may seem,
and realistically is, trivial, however there is a limit to the size
of a DNS packet, and causing that limit to be reached has more
serious performance implications. It is wise to stay well clear of
it. More servers also increase both the likelihood that one server
will be misconfigured, or malfunction, without being detected.
Consequently, it is recommended for most forward zones, that three,
four, or five listed servers, depending on circumstances and
placement of the servers, be established. Reverse zones, that is,
sub-domains of .IN-ADDR.ARPA, tend to be less crucial, and less
servers, less distributed, will often suffice. Servers which are
authoritative for the zone, but not listed in NS records (also known
as "stealth" servers) are not included above - it can often be useful
for all servers at a site to be authoritative, but unlisted, for all
local zones.
kre/randy [Page 4]
Internet Draft draft-ietf-dnsind-2ndry-00.txt February 1996
8. Security Considerations
This document does not consider security.
The mention of firewalls in section 6 is purely because they are a
fact of life (and an impediment to orderly communications). It is
not intended to imply that a firewall is in any way useful for
security purposes.
It is not believed that anything in this document adds to any
security issues that may exist with the DNS, nor does it do anything
to lessen them.
9. References
[RFC1034] Domain Names - Concepts and Facilities,
P. Mockapetris, ISI, November 1987.
[RFC1035] Domain Names - Implementation and Specification,
P. Mockapetris, ISI, November 1987
[KRE1996] Clarifications to the DNS specification,
R. Elz, R. Bush,
Work In Progress (internet-draft), February 1996.
10. Acknowledgements
To be supplied.
kre/randy [Page 5]
