7
Network Working Group T. Hardie
8
Request for Comments: 3258 Nominum, Inc.
9
Category: Informational April 2002
12
Distributing Authoritative Name Servers via Shared Unicast Addresses
16
This memo provides information for the Internet community. It does
17
not specify an Internet standard of any kind. Distribution of this
22
Copyright (C) The Internet Society (2002). All Rights Reserved.
26
This memo describes a set of practices intended to enable an
27
authoritative name server operator to provide access to a single
28
named server in multiple locations. The primary motivation for the
29
development and deployment of these practices is to increase the
30
distribution of Domain Name System (DNS) servers to previously
31
under-served areas of the network topology and to reduce the latency
32
for DNS query responses in those areas.
36
This memo describes a set of practices intended to enable an
37
authoritative name server operator to provide access to a single
38
named server in multiple locations. The primary motivation for the
39
development and deployment of these practices is to increase the
40
distribution of DNS servers to previously under-served areas of the
41
network topology and to reduce the latency for DNS query responses in
42
those areas. This document presumes a one-to-one mapping between
43
named authoritative servers and administrative entities (operators).
44
This document contains no guidelines or recommendations for caching
45
name servers. The shared unicast system described here is specific
46
to IPv4; applicability to IPv6 is an area for further study. It
47
should also be noted that the system described here is related to
48
that described in [ANYCAST], but it does not require dedicated
49
address space, routing changes, or the other elements of a full
50
anycast infrastructure which that document describes.
58
Hardie Informational [Page 1]
60
RFC 3258 Distributing Authoritative Name Servers April 2002
65
2.1 Server Requirements
67
Operators of authoritative name servers may wish to refer to
68
[SECONDARY] and [ROOT] for general guidance on appropriate practice
69
for authoritative name servers. In addition to proper configuration
70
as a standard authoritative name server, each of the hosts
71
participating in a shared-unicast system should be configured with
72
two network interfaces. These interfaces may be either two physical
73
interfaces or one physical interface mapped to two logical
74
interfaces. One of the network interfaces should use the IPv4 shared
75
unicast address associated with the authoritative name server. The
76
other interface, referred to as the administrative interface below,
77
should use a distinct IPv4 address specific to that host. The host
78
should respond to DNS queries only on the shared-unicast interface.
79
In order to provide the most consistent set of responses from the
80
mesh of anycast hosts, it is good practice to limit responses on that
81
interface to zones for which the host is authoritative.
83
2.2 Zone file delivery
85
In order to minimize the risk of man-in-the-middle attacks, zone
86
files should be delivered to the administrative interface of the
87
servers participating in the mesh. Secure file transfer methods and
88
strong authentication should be used for all transfers. If the hosts
89
in the mesh make their zones available for zone transfer, the
90
administrative interfaces should be used for those transfers as well,
91
in order to avoid the problems with potential routing changes for TCP
92
traffic noted in section 2.5 below.
96
Authoritative name servers may be loosely or tightly synchronized,
97
depending on the practices set by the operating organization. As
98
noted below in section 4.1.2, lack of synchronization among servers
99
using the same shared unicast address could create problems for some
100
users of this service. In order to minimize that risk, switch-overs
101
from one data set to another data set should be coordinated as much
102
as possible. The use of synchronized clocks on the participating
103
hosts and set times for switch-overs provides a basic level of
104
coordination. A more complete coordination process would involve:
106
a) receipt of zones at a distribution host
107
b) confirmation of the integrity of zones received
108
c) distribution of the zones to all of the servers in the mesh
109
d) confirmation of the integrity of the zones at each server
114
Hardie Informational [Page 2]
116
RFC 3258 Distributing Authoritative Name Servers April 2002
119
e) coordination of the switchover times for the servers in the
121
f) institution of a failure process to ensure that servers that
122
did not receive correct data or could not switchover to the new
123
data ceased to respond to incoming queries until the problem
126
Depending on the size of the mesh, the distribution host may also be
127
a participant; for authoritative servers, it may also be the host on
128
which zones are generated.
130
This document presumes that the usual DNS failover methods are the
131
only ones used to ensure reachability of the data for clients. It
132
does not advise that the routes be withdrawn in the case of failure;
133
it advises instead that the DNS process shutdown so that servers on
134
other addresses are queried. This recommendation reflects a choice
135
between performance and operational complexity. While it would be
136
possible to have some process withdraw the route for a specific
137
server instance when it is not available, there is considerable
138
operational complexity involved in ensuring that this occurs
139
reliably. Given the existing DNS failover methods, the marginal
140
improvement in performance will not be sufficient to justify the
141
additional complexity for most uses.
145
Though the geographic diversity of server placement helps reduce the
146
effects of service disruptions due to local problems, it is diversity
147
of placement in the network topology which is the driving force
148
behind these distribution practices. Server placement should
149
emphasize that diversity. Ideally, servers should be placed
150
topologically near the points at which the operator exchanges routes
151
and traffic with other networks.
155
The organization administering the mesh of servers sharing a unicast
156
address must have an autonomous system number and speak BGP to its
157
peers. To those peers, the organization announces a route to the
158
network containing the shared-unicast address of the name server.
159
The organization's border routers must then deliver the traffic
160
destined for the name server to the nearest instantiation. Routing
161
to the administrative interfaces for the servers can use the normal
162
routing methods for the administering organization.
164
One potential problem with using shared unicast addresses is that
165
routers forwarding traffic to them may have more than one available
166
route, and those routes may, in fact, reach different instances of
170
Hardie Informational [Page 3]
172
RFC 3258 Distributing Authoritative Name Servers April 2002
175
the shared unicast address. Applications like the DNS, whose
176
communication typically consists of independent request-response
177
messages each fitting in a single UDP packet present no problem.
178
Other applications, in which multiple packets must reach the same
179
endpoint (e.g., TCP) may fail or present unworkable performance
180
characteristics in some circumstances. Split-destination failures
181
may occur when a router does per-packet (or round-robin) load
182
sharing, a topology change occurs that changes the relative metrics
183
of two paths to the same anycast destination, etc.
185
Four things mitigate the severity of this problem. The first is that
186
UDP is a fairly high proportion of the query traffic to name servers.
187
The second is that the aim of this proposal is to diversify
188
topological placement; for most users, this means that the
189
coordination of placement will ensure that new instances of a name
190
server will be at a significantly different cost metric from existing
191
instances. Some set of users may end up in the middle, but that
192
should be relatively rare. The third is that per packet load sharing
193
is only one of the possible load sharing mechanisms, and other
194
mechanisms are increasing in popularity.
196
Lastly, in the case where the traffic is TCP, per packet load sharing
197
is used, and equal cost routes to different instances of a name
198
server are available, any DNS implementation which measures the
199
performance of servers to select a preferred server will quickly
200
prefer a server for which this problem does not occur. For the DNS
201
failover mechanisms to reliably avoid this problem, however, those
202
using shared unicast distribution mechanisms must take care that all
203
of the servers for a specific zone are not participants in the same
204
shared-unicast mesh. To guard even against the case where multiple
205
meshes have a set of users affected by per packet load sharing along
206
equal cost routes, organizations implementing these practices should
207
always provide at least one authoritative server which is not a
208
participant in any shared unicast mesh. Those deploying shared-
209
unicast meshes should note that any specific host may become
210
unreachable to a client should a server fail, a path fail, or the
211
route to that host be withdrawn. These error conditions are,
212
however, not specific to shared-unicast distributions, but would
213
occur for standard unicast hosts.
215
Since ICMP response packets might go to a different member of the
216
mesh than that sending a packet, packets sent with a shared unicast
217
source address should also avoid using path MTU discovery.
219
Appendix A. contains an ASCII diagram of an example of a simple
220
implementation of this system. In it, the odd numbered routers
221
deliver traffic to the shared-unicast interface network and filter
222
traffic from the administrative network; the even numbered routers
226
Hardie Informational [Page 4]
228
RFC 3258 Distributing Authoritative Name Servers April 2002
231
deliver traffic to the administrative network and filter traffic from
232
the shared-unicast network. These are depicted as separate routers
233
for the ease this gives in explanation, but they could easily be
234
separate interfaces on the same router. Similarly, a local NTP
235
source is depicted for synchronization, but the level of
236
synchronization needed would not require that source to be either
237
local or a stratum one NTP server.
241
3.1 Points of Contact
243
A single point of contact for reporting problems is crucial to the
244
correct administration of this system. If an external user of the
245
system needs to report a problem related to the service, there must
246
be no ambiguity about whom to contact. If internal monitoring does
247
not indicate a problem, the contact may, of course, need to work with
248
the external user to identify which server generated the error.
250
4. Security Considerations
252
As a core piece of Internet infrastructure, authoritative name
253
servers are common targets of attack. The practices outlined here
254
increase the risk of certain kinds of attacks and reduce the risk of
259
4.1.1 Increase in physical servers
261
The architecture outlined in this document increases the number of
262
physical servers, which could increase the possibility that a server
263
mis-configuration will occur which allows for a security breach. In
264
general, the entity administering a mesh should ensure that patches
265
and security mechanisms applied to a single member of the mesh are
266
appropriate for and applied to all of the members of a mesh.
267
"Genetic diversity" (code from different code bases) can be a useful
268
security measure in avoiding attacks based on vulnerabilities in a
269
specific code base; in order to ensure consistency of responses from
270
a single named server, however, that diversity should be applied to
271
different shared-unicast meshes or between a mesh and a related
272
unicast authoritative server.
274
4.1.2 Data synchronization problems
276
The level of systemic synchronization described above should be
277
augmented by synchronization of the data present at each of the
278
servers. While the DNS itself is a loosely coupled system, debugging
282
Hardie Informational [Page 5]
284
RFC 3258 Distributing Authoritative Name Servers April 2002
287
problems with data in specific zones would be far more difficult if
288
two different servers sharing a single unicast address might return
289
different responses to the same query. For example, if the data
290
associated with www.example.com has changed and the administrators of
291
the domain are testing for the changes at the example.com
292
authoritative name servers, they should not need to check each
293
instance of a named authoritative server. The use of NTP to provide
294
a synchronized time for switch-over eliminates some aspects of this
295
problem, but mechanisms to handle failure during the switchover are
296
required. In particular, a server which cannot make the switchover
297
must not roll-back to a previous version; it must cease to respond to
298
queries so that other servers are queried.
300
4.1.3 Distribution risks
302
If the mechanism used to distribute zone files among the servers is
303
not well secured, a man-in-the-middle attack could result in the
304
injection of false information. Digital signatures will alleviate
305
this risk, but encrypted transport and tight access lists are a
306
necessary adjunct to them. Since zone files will be distributed to
307
the administrative interfaces of meshed servers, the access control
308
list for distribution of the zone files should include the
309
administrative interface of the server or servers, rather than their
310
shared unicast addresses.
314
The increase in number of physical servers reduces the likelihood
315
that a denial-of-service attack will take out a significant portion
316
of the DNS infrastructure. The increase in servers also reduces the
317
effect of machine crashes, fiber cuts, and localized disasters by
318
reducing the number of users dependent on a specific machine.
322
Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak,
323
Mark Andrews, Robert Elz, Geoff Huston, Bill Norton, Akira Kato,
324
Suzanne Woolf, Bernard Aboba, Casey Ajalat, and Gunnar Lindberg all
325
provided input and commentary on this work. The editor wishes to
326
remember in particular the contribution of the late Scott Tucker,
327
whose extensive systems experience and plain common sense both
328
contributed greatly to the editor's own deployment experience and are
329
missed by all who knew him.
338
Hardie Informational [Page 6]
340
RFC 3258 Distributing Authoritative Name Servers April 2002
345
[SECONDARY] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection
346
and Operation of Secondary DNS Servers", BCP 16, RFC
349
[ROOT] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root
350
Name Server Operational Requirements", BCP 40, RFC 2870,
353
[ANYCAST] Patridge, C., Mendez, T. and W. Milliken, "Host
354
Anycasting Service", RFC 1546, November 1993.
394
Hardie Informational [Page 7]
396
RFC 3258 Distributing Authoritative Name Servers April 2002
405
Transit| | _________ _________
406
etc | |--|Router1|---|----|----------|Router2|---WAN-|
407
| | --------- | | --------- |
410
------------------ [NTP] [DNS] |
419
Transit| | _________ _________ |
420
etc | |--|Router3|---|----|----------|Router4|---WAN-|
421
| | --------- | | --------- |
424
------------------ [NTP] [DNS] |
433
Transit| | _________ _________ |
434
etc | |--|Router5|---|----|----------|Router6|---WAN-|
435
| | --------- | | --------- |
438
------------------ [NTP] [DNS] |
450
Hardie Informational [Page 8]
452
RFC 3258 Distributing Authoritative Name Servers April 2002
460
Transit| | _________ _________ |
461
etc | |--|Router7|---|----|----------|Router8|---WAN-|
462
| | --------- | | ---------
465
------------------ [NTP] [DNS]
506
Hardie Informational [Page 9]
508
RFC 3258 Distributing Authoritative Name Servers April 2002
516
Redwood City, CA 94063
518
Phone: 1.650.381.6226
519
EMail: Ted.Hardie@nominum.com
562
Hardie Informational [Page 10]
564
RFC 3258 Distributing Authoritative Name Servers April 2002
567
8. Full Copyright Statement
569
Copyright (C) The Internet Society (2002). All Rights Reserved.
571
This document and translations of it may be copied and furnished to
572
others, and derivative works that comment on or otherwise explain it
573
or assist in its implementation may be prepared, copied, published
574
and distributed, in whole or in part, without restriction of any
575
kind, provided that the above copyright notice and this paragraph are
576
included on all such copies and derivative works. However, this
577
document itself may not be modified in any way, such as by removing
578
the copyright notice or references to the Internet Society or other
579
Internet organizations, except as needed for the purpose of
580
developing Internet standards in which case the procedures for
581
copyrights defined in the Internet Standards process must be
582
followed, or as required to translate it into languages other than
585
The limited permissions granted above are perpetual and will not be
586
revoked by the Internet Society or its successors or assigns.
588
This document and the information contained herein is provided on an
589
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
590
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
591
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
592
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
593
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
597
Funding for the RFC Editor function is currently provided by the
618
Hardie Informational [Page 11]
added
removed
doc/rfc/rfc3258.txt
