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]
projects / FreeBSD / releng / 7.2.git / blob