As per Relevance of the word selection, we have this rfc below:
Network Working Group R.
Request for Comments: 2182 University of
BCP: 16 R.
Category: Best Current Practice RGnet, Inc
S.
Harvard
M.
July 1997
Selection and Operation of Secondary DNS
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
The Domain Name System requires that multiple servers exist for
delegated domain (zone). This document discusses the selection
secondary servers for DNS zones. Both the physical and
location of each server are material considerations when
secondary servers. The number of servers appropriate for a zone
also discussed, and some general secondary server maintenance
considered
Elz, et al. Best Current Practice [Page 1]
RFC 2182 Selection and Operation of Secondary DNS Servers July 1997
Abstract ................................................... 1
1 Introduction ............................................... 2
2 Definitions ................................................ 2
3 Secondary Servers .......................................... 3
4 Unreachable servers ........................................ 5
5 How many secondaries? ...................................... 7
6 Finding Suitable Secondary Servers ......................... 8
7 Serial Number Maintenance .................................. 9
Security Considerations .................................... 11
References ................................................. 11
Acknowledgements ........................................... 11
Authors' Addresses ......................................... 11
1.
A number of problems in DNS operations today are attributable to
choices of secondary servers for DNS zones. The geographic
as well as the diversity of network connectivity exhibited by the
of DNS servers for a zone can increase the reliability of that
as well as improve overall network performance and
characteristics. Other considerations in server choice
unexpectedly lower reliability or impose extra demands on
network
This document discusses many of the issues that should be
when selecting secondary servers for a zone. It offers guidance
how to best choose servers to serve a given zone
2.
For the purposes of this document, and only this document,
following definitions apply
DNS The Domain Name System [RFC1034, RFC1035].
Zone A part of the DNS tree, that is treated as
unit
Forward Zone A zone containing data mapping names to
addresses, mail exchange targets, etc
Elz, et al. Best Current Practice [Page 2]
RFC 2182 Selection and Operation of Secondary DNS Servers July 1997
Reverse Zone A zone containing data used to map
to names
Server An implementation of the DNS protocols able
provide answers to queries. Answers may
from information known by the server,
information obtained from another server
Authoritative Server A server that knows the content of a DNS
from local knowledge, and thus can
queries about that zone without needing
query other servers
Listed Server An Authoritative Server for which there is
"NS" resource record (RR) in the zone
Primary Server An authoritative server for which the
information is locally configured.
known as a Master server
Secondary Server An authoritative server that
information about a zone from a Primary
via a zone transfer mechanism.
known as a Slave Server
Stealth Server An authoritative server, usually secondary
which is not a Listed Server
Resolver A client of the DNS which seeks
contained in a zone using the DNS protocols
3. Secondary
A major reason for having multiple servers for each zone is to
information from the zone to be available widely and reliably
clients throughout the Internet, that is, throughout the world,
when one server is unavailable or unreachable
Multiple servers also spread the name resolution load, and
the overall efficiency of the system by placing servers nearer to
resolvers. Those purposes are not treated further here
With multiple servers, usually one server will be the primary server
and others will be secondary servers. Note that while some
configurations use multiple primary servers, that can result in
inconsistencies, and is not advisable
Elz, et al. Best Current Practice [Page 3]
RFC 2182 Selection and Operation of Secondary DNS Servers July 1997
The distinction between primary and secondary servers is
only to the servers for the zone concerned, to the rest of the
there are simply multiple servers. All are treated equally at
instance, even by the parent server that delegates the zone
Resolvers often measure the performance of the various servers
choose the "best", for some definition of best, and prefer that
for most queries. That is automatic, and not considered here
The primary server holds the master copy of the zone file. That is
the server where the data is entered into the DNS from some
outside the DNS. Secondary servers obtain data for the zone
DNS protocol mechanisms to obtain the zone from the primary server
3.1. Selecting Secondary
When selecting secondary servers, attention should be given to
various likely failure modes. Servers should be placed so that it
likely that at least one server will be available to all
parts of the Internet, for any likely failure
Consequently, placing all servers at the local site, while easy
arrange, and easy to manage, is not a good policy. Should a
link fail, or there be a site, or perhaps even building, or room
power failure, such a configuration can lead to all servers
disconnected from the Internet
Secondary servers must be placed at both topologically
geographically dispersed locations on the Internet, to minimise
likelihood of a single failure disabling all of them
That is, secondary servers should be at geographically
locations, so it is unlikely that events like power loss, etc,
disrupt all of them simultaneously. They should also be connected
the net via quite diverse paths. This means that the failure of
one link, or of routing within some segment of the network (such as
service provider) will not make all of the servers unreachable
3.2. Unsuitable
While it is unfortunately quite common, servers for a zone
certainly not all be placed on the same LAN segment in the same
of the same building - or any of those. Such a configuration
defeats the requirement, and utility, of having multiple servers
The only redundancy usually provided in that configuration is for
case when one server is down, whereas there are many other
failure modes, such as power failures, including lengthy ones,
consider
Elz, et al. Best Current Practice [Page 4]
RFC 2182 Selection and Operation of Secondary DNS Servers July 1997
3.3. A Myth
An argument is occasionally made that there is no need for the
name servers for a domain to be accessible if the hosts in the
are unreachable. This argument is fallacious
+ Clients react differently to inability to resolve than
to connect, and reactions to the former are not always
desirable
+ If the zone is resolvable yet the particular name is not, then
client can discard the transaction rather than retrying
creating undesirable load on the network
+ While positive DNS results are usually cached, the lack of
result is not cached. Thus, unnecessary inability to
creates an undesirable load on the net
+ All names in the zone may not resolve to addresses within
detached network. This becomes more likely over time. Thus
basic assumption of the myth often becomes untrue
It is important that there be nameservers able to be queried
available always, for all forward zones
4. Unreachable
Another class of problems is caused by listing servers that cannot
reached from large parts of the network. This could be listing
name of a machine that is completely isolated behind a firewall,
just a secondary address on a dual homed machine which is
accessible from outside. The names of servers listed in NS
should resolve to addresses which are reachable from the region
which the NS records are being returned. Including addresses
most of the network cannot reach does not add any reliability,
causes several problems, which may, in the end, lower the
of the zone
First, the only way the resolvers can determine that these
are, in fact, unreachable, is to try them. They then need to wait
a lack of response timeout (or occasionally an ICMP error response
to know that the address cannot be used. Further, even that
generally indistinguishable from a simple packet loss, so
sequence must be repeated, several times, to give any real
of an unreachable server. All of this probing and timeout may
sufficiently long that the original client program or user
decide that no answer is available, leading to an apparent failure
the zone. Additionally, the whole thing needs to be repeated
time to time to distinguish a permanently unreachable server from
temporarily unreachable one
Elz, et al. Best Current Practice [Page 5]
RFC 2182 Selection and Operation of Secondary DNS Servers July 1997
And finally, all these steps will potentially need to be done
resolvers all over the network. This will increase the traffic,
probably the load on the filters at whatever firewall is
this access. All of this additional load does no more
effectively lower the reliability of the service
4.1. Servers behind intermittent
A similar problem occurs with DNS servers located in parts of the
that are often disconnected from the Internet as a whole.
example, those which connect via an intermittent connection that
often down. Such servers should usually be treated as if they
behind a firewall, and unreachable to the network at any time
4.2. Other problem
Similar problems occur when a Network Address Translator (NAT
[RFC1631] exists between a resolver and server. Despite
[RFC1631] suggests, NATs in practice do not translate
embedded in packets, only those in the headers. As [RFC1631]
suggests, this is somewhat of a problem for the DNS. This
sometimes be overcome if the NAT is accompanied by, or replaced with
an Application Layer Gateway (ALG). Such a device would
the DNS protocol and translate all the addresses as appropriate
packets pass through. Even with such a device, it is likely to
better in any of these cases to adopt the solution described in
following section
4.3. A
To avoid these problems, NS records for a zone returned in
response should list only servers that the resolver requesting
information, is likely to be able to reach. Some resolvers
simultaneously servers performing lookups on behalf of
resolvers. The NS records returned should be reachable not only
the resolver that requested the information, but any other
that may be forwarded the information. All the addresses of all
servers returned must be reachable. As the addresses of each
form a Resource Record Set [RFC2181], all must be returned (or none),
thus it is not acceptable to elide addresses of servers that
unreachable, or to return them with a low TTL (while returning
with a higher TTL).
In particular, when some servers are behind a firewall,
connection, or NAT, which disallows, or has problems with,
queries or responses, their names, or addresses, should not
returned to clients outside the firewall. Similarly, servers
the firewall should not be made known to clients inside it, if
Elz, et al. Best Current Practice [Page 6]
RFC 2182 Selection and Operation of Secondary DNS Servers July 1997
clients would be unable to query those servers. Implementing
usually requires dual DNS setups, one for internal use, the other
external use. Such a setup often solves other problems
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
appears to be reachable only on the appropriate side of the firewall
This should then be treated just like two servers, one on each
of the firewall. A server implemented in an ALG will usually be
a case. Special care will need to be taken to allow such a server
return the correct responses to clients on each side. That is
return only information about hosts reachable from that side and
correct IP address(es) for the host when viewed from that side
Servers in this environment often need special provision to give
access to the root servers. Often this is accomplished via "
root" configurations. In such a case the servers should be kept
isolated from the rest of the DNS, lest their unusual
pollute others
5. How many secondaries
The DNS specification and domain name registration rules require
least two servers for every zone. That is, usually, the primary
one secondary. While two, carefully placed, are often sufficient
occasions where two are insufficient are frequent enough that
advise the use of more than two listed servers. Various problems
cause a server to be unavailable for extended periods - during such
period, a zone with only two listed servers is actually running
just one. Since any server may occasionally be unavailable, for
kinds of reasons, this zone is likely, at times, to have
functional servers at all
On the other hand, having large numbers of servers adds
benefit, while adding costs. At the simplest, more servers
packets to be larger, so requiring more bandwidth. This may seem
and realistically is, trivial. However there is a limit to the
of a DNS packet, and causing that limit to be reached has
serious performance implications. It is wise to stay well clear
it. More servers also increase the likelihood that one server
be misconfigured, or malfunction, without being detected
It is recommended that three servers be provided for
organisation level zones, with at least one which must be
removed from the others. For zones where even higher reliability
required, four, or even five, servers may be desirable. Two,
Elz, et al. Best Current Practice [Page 7]
RFC 2182 Selection and Operation of Secondary DNS Servers July 1997
occasionally three of five, would be at the local site, with
others not geographically or topologically close to the site, or
other
Reverse zones, that is, sub-domains of .IN-ADDR.ARPA, tend to be
crucial, and less servers, less distributed, will often suffice
This is because address to name translations are typically
only when packets are being received from the address in question
and only by resolvers at or near the destination of the packets
This gives some assurances that servers located at or near the
source, for example, on the the same network, will be reachable
the resolvers that need to perform the lookups. Thus some of
failure modes that need to be considered when planning servers
forward zones may be less relevant when reverse zones are
planned
5.1. Stealth
Servers which are authoritative for the zone, but not listed in
records (also known as "stealth" servers) are not included in
count of servers
It can often be useful for all servers at a site to be
(secondary), but only one or two be listed servers, the rest
unlisted servers for all local zones, that is, to be stealth servers
This allows those servers to provide answers to local
directly, without needing to consult another server. If it
necessary to consult another server, it would usually be
for the root servers to be consulted, in order to follow
delegation tree - that the zone is local would not be known.
would mean that some local queries may not be able to be answered
external communications were disrupted
Listing all such servers in NS records, if more than one or two
would cause the rest of the Internet to spend unnecessary
attempting to contact all servers at the site when the whole site
inaccessible due to link or routing failures
6. Finding Suitable Secondary
Operating a secondary server is usually an almost automatic task
Once established, the server generally runs itself, based upon
actions of the primary server. Because of this, large numbers
organisations are willing to provide a secondary server,
requested. The best approach is usually to find an organisation
similar size, and agree to swap secondary zones - each
agrees to provide a server to act as a secondary server for the
Elz, et al. Best Current Practice [Page 8]
RFC 2182 Selection and Operation of Secondary DNS Servers July 1997
organisation's zones. Note that there is no loss of
data here, the data set exchanged would be available
whatever the servers are
7. Serial Number
Secondary servers use the serial number in the SOA record of the
to determine when it is necessary to update their local copy of
zone. Serial numbers are basically just 32 bit unsigned
that wrap around from the biggest possible value to zero again.
[RFC1982] for a more rigorous definition of the serial number
The serial number must be incremented every time a change, or
of changes, is made to the zone on the primary server. This
secondary servers they need update their copies of the zone.
that it is not possible to decrement a serial number, increments
the only defined modification
Occasionally due to editing errors, or other factors, it may
necessary to cause a serial number to become smaller. Never
decrease the serial number. Secondary servers will ignore
change, and further, will ignore any later increments until
earlier large value is exceeded
Instead, given that serial numbers wrap from large to small,
absolute terms, increment the serial number, several times, until
has reached the value desired. At each step, wait until
secondary servers have updated to the new value before proceeding
For example, assume that the serial number of a zone was 10, but
accidentally been set to 1000, and it is desired to set it back
11. Do not simply change the value from 1000 to 11. A
server that has seen the 1000 value (and in practice, there is
at least one) will ignore this change, and continue to use
version of the zone with serial number 1000, until the
server's serial number exceeds that value. This may be a long time -
in fact, the secondary often expires its copy of the zone before
zone is ever updated again
Instead, for this example, set the primary's serial number
2000000000, and wait for the secondary servers to update to
zone. The value 2000000000 is chosen as a value a lot bigger
the current value, but less that 2^31 bigger (2^31 is 2147483648).
This is then an increment of the serial number [RFC1982].
Next, after all servers needing updating have the zone with
serial number, the serial number can be set to 4000000000.
4000000000 is 2000000000 more than 2000000000 (fairly clearly),
Elz, et al. Best Current Practice [Page 9]
RFC 2182 Selection and Operation of Secondary DNS Servers July 1997
is thus another increment (the value added is less than 2^31).
Once this copy of the zone file exists at all servers, the
number can simply be set to 11. In serial number arithmetic,
change from 4000000000 to 11 is an increment. Serial numbers wrap
2^32 (4294967296), so 11 is identical to 4294967307 (4294967296 +
11). 4294967307 is just 294967307 greater than 4000000000,
294967307 is well under 2^31, this is therefore an increment
When following this procedure, it is essential to verify that
relevant servers have been updated at each step, never
anything. Failing to do this can result in a worse mess than
before the attempted correction. Also beware that it is
relationship between the values of the various serial numbers that
important, not the absolute values. The values used above
correct for that one example only
It is possible in essentially all cases to correct the serial
in two steps by being more aggressive in the choices of the
numbers. This however causes the numbers used to be less "nice",
requires considerably more care
Also, note that not all nameserver implementations
implement serial number operations. With such servers as
there is typically no way to cause the serial number to
smaller, other than contacting the administrator of the server
requesting that all existing data for the zone be purged. Then
the secondary be loaded again from the primary, as if for the
time
It remains safe to carry out the above procedure, as
malfunctioning servers will need manual attention in any case.
the sequence of serial number changes described above,
secondary servers will have been reset. Then when the primary
has the correct (desired) serial number, contact the
secondary servers and request their understanding of the
serial number be manually corrected. Perhaps also suggest that
upgrade their software to a standards conforming implementation
A server which does not implement this algorithm is defective,
may be detected as follows. At some stage, usually when the
integral value of the serial number becomes smaller, a server
this particular defect will ignore the change. Servers with
type of defect can be detected by waiting for at least the
specified in the SOA refresh field and then sending a query for
SOA. Servers with this defect will still have the old serial number
We are not aware of other means to detect this defect
Elz, et al. Best Current Practice [Page 10]
RFC 2182 Selection and Operation of Secondary DNS Servers July 1997
Security
It is not believed that anything in this document adds to
security issues that may exist with the DNS, nor does it do
to lessen them
Administrators should be aware, however, that compromise of a
for a domain can, in some situations, compromise the security
hosts in the domain. Care should be taken in choosing
servers so that this threat is minimised
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation
Specification", STD 13, RFC 1035, November 1987
[RFC1631] Egevang, K., Francis, P., "The IP Network Address
(NAT)", RFC 1631, May 1994
[RFC1982] Elz, R., Bush, R., "Serial Number Arithmetic",
RFC 1982, August 1996.
[RFC2181] Elz, R., Bush, R., "Clarifications to the DNS specification",
RFC 2181, July 1997.
Brian Carpenter and Yakov Rekhter suggested mentioning NATs and
as a companion to the firewall text. Dave Crocker
explicitly exploding the myth
Authors'
Robert
Computer
University of
Parkville, Vic, 3052
Australia
EMail: kre@munnari.OZ.
Elz, et al. Best Current Practice [Page 11]
RFC 2182 Selection and Operation of Secondary DNS Servers July 1997
Randy
RGnet, Inc
5147 Crystal Springs Drive
Bainbridge Island, Washington, 98110
United States
EMail: randy@psg.
Scott
Harvard
1350 Mass
Cambridge, MA, 02138
United States
EMail: sob@harvard.
Michael A.
33 Blanchard
Cambridge, MA, 02138
United States
EMail: MAP@POBOX.
Elz, et al. Best Current Practice [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
