idnits 2.17.1 draft-ietf-dnsind-2ndry-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1997) is 9774 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1631 (Obsoleted by RFC 3022) -- Possible downref: Non-RFC (?) normative reference: ref. 'KRE1996' Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Robert Elz 2 Internet Draft University of Melbourne 3 Expiration Date: January 1998 4 Randy Bush 5 RGnet, Inc. 7 Scott Bradner 8 Harvard University 10 Michael A. Patton 11 Consultant 13 July 1997 15 Selection and Operation of Secondary DNS Servers 17 draft-ietf-dnsind-2ndry-06.txt 19 Status of this Memo 21 This document is an Internet-Draft. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 To learn the current status of any Internet-Draft, please check the 32 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 33 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 34 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 35 ftp.isi.edu (US West Coast). 37 Abstract 39 The Domain Name System requires that multiple servers exist for every 40 delegated domain (zone). This document discusses the selection of 41 secondary servers for DNS zones. Both the physical and topological 42 location of each server are material considerations when selecting 43 secondary servers. The number of servers appropriate for a zone is 44 also discussed, and some general secondary server maintenance issues 45 considered. 47 Contents 49 Status of this Memo ........................................ 1 50 Abstract ................................................... 1 51 1 Introduction ............................................... 2 52 2 Definitions ................................................ 2 53 3 Secondary Servers .......................................... 3 54 4 Unreachable servers ........................................ 5 55 5 How many secondaries? ...................................... 7 56 6 Finding Suitable Secondary Servers ......................... 8 57 7 Serial Number Maintenance .................................. 9 58 Security Considerations .................................... 11 59 References ................................................. 11 60 Acknowledgements ........................................... 11 61 Authors' Addresses ......................................... 11 63 1. Introduction 65 A number of problems in DNS operations today are attributable to poor 66 choices of secondary servers for DNS zones. The geographic placement 67 as well as the diversity of network connectivity exhibited by the set 68 of DNS servers for a zone can increase the reliability of that zone 69 as well as improve overall network performance and access 70 characteristics. Other considerations in server choice can 71 unexpectedly lower reliability or impose extra demands on the 72 network. 74 This document discusses many of the issues that should be considered 75 when selecting secondary servers for a zone. It offers guidance in 76 how to best choose servers to serve a given zone. 78 2. Definitions 80 For the purposes of this document, and only this document, the 81 following definitions apply: 83 DNS The Domain Name System [RFC1034, RFC1035]. 85 Zone A part of the DNS tree, that is treated as a 86 unit. 88 Forward Zone A zone containing data mapping names to host 89 addresses, mail exchange targets, etc. 91 Reverse Zone A zone containing data used to map addresses 92 to names. 94 Server An implementation of the DNS protocols able to 95 provide answers to queries. Answers may be 96 from information known by the server, or 97 information obtained from another server. 99 Authoritative Server A server that knows the content of a DNS zone 100 from local knowledge, and thus can answer 101 queries about that zone without needing to 102 query other servers. 104 Listed Server An Authoritative Server for which there is an 105 "NS" resource record (RR) in the zone. 107 Primary Server An authoritative server for which the zone 108 information is locally configured. Sometimes 109 known as a Master server. 111 Secondary Server An authoritative server that obtains 112 information about a zone from a Primary Server 113 via a zone transfer mechanism. Sometimes 114 known as a Slave Server. 116 Stealth Server An authoritative server, usually secondary, 117 which is not a Listed Server. 119 Resolver A client of the DNS which seeks information 120 contained in a zone using the DNS protocols. 122 3. Secondary Servers 124 A major reason for having multiple servers for each zone is to allow 125 information from the zone to be available widely and reliably to 126 clients throughout the Internet, that is, throughout the world, even 127 when one server is unavailable or unreachable. 129 Multiple servers also spread the name resolution load, and improve 130 the overall efficiency of the system by placing servers nearer to the 131 resolvers. Those purposes are not treated further here. 133 With multiple servers, usually one server will be the primary server, 134 and others will be secondary servers. Note that while some unusual 135 configurations use multiple primary servers, that can result in data 136 inconsistencies, and is not advisable. 138 The distinction between primary and secondary servers is relevant 139 only to the servers for the zone concerned, to the rest of the DNS 140 there are simply multiple servers. All are treated equally at first 141 instance, even by the parent server that delegates the zone. 142 Resolvers often measure the performance of the various servers, 143 choose the "best", for some definition of best, and prefer that one 144 for most queries. That is automatic, and not considered here. 146 The primary server holds the master copy of the zone file. That is, 147 the server where the data is entered into the DNS from some source 148 outside the DNS. Secondary servers obtain data for the zone using 149 DNS protocol mechanisms to obtain the zone from the primary server. 151 3.1. Selecting Secondary Servers 153 When selecting secondary servers, attention should be given to the 154 various likely failure modes. Servers should be placed so that it is 155 likely that at least one server will be available to all significant 156 parts of the Internet, for any likely failure. 158 Consequently, placing all servers at the local site, while easy to 159 arrange, and easy to manage, is not a good policy. Should a single 160 link fail, or there be a site, or perhaps even building, or room, 161 power failure, such a configuration can lead to all servers being 162 disconnected from the Internet. 164 Secondary servers must be placed at both topologically and 165 geographically dispersed locations on the Internet, to minimise the 166 likelihood of a single failure disabling all of them. 168 That is, secondary servers should be at geographically distant 169 locations, so it is unlikely that events like power loss, etc, will 170 disrupt all of them simultaneously. They should also be connected to 171 the net via quite diverse paths. This means that the failure of any 172 one link, or of routing within some segment of the network (such as a 173 service provider) will not make all of the servers unreachable. 175 3.2. Unsuitable Configurations 177 While it is unfortunately quite common, servers for a zone should 178 certainly not all be placed on the same LAN segment in the same room 179 of the same building - or any of those. Such a configuration almost 180 defeats the requirement, and utility, of having multiple servers. 181 The only redundancy usually provided in that configuration is for the 182 case when one server is down, whereas there are many other possible 183 failure modes, such as power failures, including lengthy ones, to 184 consider. 186 3.3. A Myth Exploded 188 An argument is occasionally made that there is no need for the domain 189 name servers for a domain to be accessible if the hosts in the domain 190 are unreachable. This argument is fallacious. 192 + Clients react differently to inability to resolve than inability 193 to connect, and reactions to the former are not always as 194 desirable. 195 + If the zone is resolvable yet the particular name is not, then a 196 client can discard the transaction rather than retrying and 197 creating undesirable load on the network. 198 + While positive DNS results are usually cached, the lack of a 199 result is not cached. Thus, unnecessary inability to resolve 200 creates an undesirable load on the net. 201 + All names in the zone may not resolve to addresses within the 202 detached network. This becomes more likely over time. Thus a 203 basic assumption of the myth often becomes untrue. 205 It is important that there be nameservers able to be queried, 206 available always, for all forward zones. 208 4. Unreachable servers 210 Another class of problems is caused by listing servers that cannot be 211 reached from large parts of the network. This could be listing the 212 name of a machine that is completely isolated behind a firewall, or 213 just a secondary address on a dual homed machine which is not 214 accessible from outside. The names of servers listed in NS records 215 should resolve to addresses which are reachable from the region to 216 which the NS records are being returned. Including addresses which 217 most of the network cannot reach does not add any reliability, and 218 causes several problems, which may, in the end, lower the reliability 219 of the zone. 221 First, the only way the resolvers can determine that these addresses 222 are, in fact, unreachable, is to try them. They then need to wait on 223 a lack of response timeout (or occasionally an ICMP error response) 224 to know that the address cannot be used. Further, even that is 225 generally indistinguishable from a simple packet loss, so the 226 sequence must be repeated, several times, to give any real evidence 227 of an unreachable server. All of this probing and timeout may take 228 sufficiently long that the original client program or user will 229 decide that no answer is available, leading to an apparent failure of 230 the zone. Additionally, the whole thing needs to be repeated from 231 time to time to distinguish a permanently unreachable server from a 232 temporarily unreachable one. 234 And finally, all these steps will potentially need to be done by 235 resolvers all over the network. This will increase the traffic, and 236 probably the load on the filters at whatever firewall is blocking 237 this access. All of this additional load does no more than 238 effectively lower the reliability of the service. 240 4.1. Servers behind intermittent connections 242 A similar problem occurs with DNS servers located in parts of the net 243 that are often disconnected from the Internet as a whole. For 244 example, those which connect via an intermittent connection that is 245 often down. Such servers should usually be treated as if they were 246 behind a firewall, and unreachable to the network at any time. 248 4.2. Other problem cases 250 Similar problems occur when a Network Address Translator (NAT) 251 [RFC1631] exists between a resolver and server. Despite what 252 [RFC1631] suggests, NATs in practice do not translate addresses 253 embedded in packets, only those in the headers. As [RFC1631] 254 suggests, this is somewhat of a problem for the DNS. This can 255 sometimes be overcome if the NAT is accompanied by, or replaced with, 256 an Application Layer Gateway (ALG). Such a device would understand 257 the DNS protocol and translate all the addresses as appropriate as 258 packets pass through. Even with such a device, it is likely to be 259 better in any of these cases to adopt the solution described in the 260 following section. 262 4.3. A Solution 264 To avoid these problems, NS records for a zone returned in any 265 response should list only servers that the resolver requesting the 266 information, is likely to be able to reach. Some resolvers are 267 simultaneously servers performing lookups on behalf of other 268 resolvers. The NS records returned should be reachable not only by 269 the resolver that requested the information, but any other resolver 270 that may be forwarded the information. All the addresses of all the 271 servers returned must be reachable. As the addresses of each server 272 form a Resource Record Set [KRE1996], all must be returned (or none), 273 thus it is not acceptable to elide addresses of servers that are 274 unreachable, or to return them with a low TTL (while returning others 275 with a higher TTL). 277 In particular, when some servers are behind a firewall, intermittent 278 connection, or NAT, which disallows, or has problems with, DNS 279 queries or responses, their names, or addresses, should not be 280 returned to clients outside the firewall. Similarly, servers outside 281 the firewall should not be made known to clients inside it, if the 282 clients would be unable to query those servers. Implementing this 283 usually requires dual DNS setups, one for internal use, the other for 284 external use. Such a setup often solves other problems with 285 environments like this. 287 When a server is at a firewall boundary, reachable from both sides, 288 but using different addresses, that server should be given two names, 289 each name associated with appropriate A records, such that each 290 appears to be reachable only on the appropriate side of the firewall. 291 This should then be treated just like two servers, one on each side 292 of the firewall. A server implemented in an ALG will usually be such 293 a case. Special care will need to be taken to allow such a server to 294 return the correct responses to clients on each side. That is, 295 return only information about hosts reachable from that side and the 296 correct IP address(es) for the host when viewed from that side. 298 Servers in this environment often need special provision to give them 299 access to the root servers. Often this is accomplished via "fake 300 root" configurations. In such a case the servers should be kept well 301 isolated from the rest of the DNS, lest their unusual configuration 302 pollute others. 304 5. How many secondaries? 306 The DNS specification and domain name registration rules require at 307 least two servers for every zone. That is, usually, the primary and 308 one secondary. While two, carefully placed, are often sufficient, 309 occasions where two are insufficient are frequent enough that we 310 advise the use of more than two listed servers. Various problems can 311 cause a server to be unavailable for extended periods - during such a 312 period, a zone with only two listed servers is actually running with 313 just one. Since any server may occasionally be unavailable, for all 314 kinds of reasons, this zone is likely, at times, to have no 315 functional servers at all. 317 On the other hand, having large numbers of servers adds little 318 benefit, while adding costs. At the simplest, more servers cause 319 packets to be larger, so requiring more bandwidth. This may seem, 320 and realistically is, trivial. However there is a limit to the size 321 of a DNS packet, and causing that limit to be reached has more 322 serious performance implications. It is wise to stay well clear of 323 it. More servers also increase the likelihood that one server will 324 be misconfigured, or malfunction, without being detected. 326 It is recommended that three servers be provided for most 327 organisation level zones, with at least one which must be well 328 removed from the others. For zones where even higher reliability is 329 required, four, or even five, servers may be desirable. Two, or 330 occasionally three of five, would be at the local site, with the 331 others not geographically or topologically close to the site, or each 332 other. 334 Reverse zones, that is, sub-domains of .IN-ADDR.ARPA, tend to be less 335 crucial, and less servers, less distributed, will often suffice. 336 This is because address to name translations are typically needed 337 only when packets are being received from the address in question, 338 and only by resolvers at or near the destination of the packets. 339 This gives some assurances that servers located at or near the packet 340 source, for example, on the the same network, will be reachable from 341 the resolvers that need to perform the lookups. Thus some of the 342 failure modes that need to be considered when planning servers for 343 forward zones may be less relevant when reverse zones are being 344 planned. 346 5.1. Stealth Servers 348 Servers which are authoritative for the zone, but not listed in NS 349 records (also known as "stealth" servers) are not included in the 350 count of servers. 352 It can often be useful for all servers at a site to be authoritative 353 (secondary), but only one or two be listed servers, the rest being 354 unlisted servers for all local zones, that is, to be stealth servers. 356 This allows those servers to provide answers to local queries 357 directly, without needing to consult another server. If it were 358 necessary to consult another server, it would usually be necessary 359 for the root servers to be consulted, in order to follow the 360 delegation tree - that the zone is local would not be known. This 361 would mean that some local queries may not be able to be answered if 362 external communications were disrupted. 364 Listing all such servers in NS records, if more than one or two, 365 would cause the rest of the Internet to spend unnecessary effort 366 attempting to contact all servers at the site when the whole site is 367 inaccessible due to link or routing failures. 369 6. Finding Suitable Secondary Servers 371 Operating a secondary server is usually an almost automatic task. 372 Once established, the server generally runs itself, based upon the 373 actions of the primary server. Because of this, large numbers of 374 organisations are willing to provide a secondary server, if 375 requested. The best approach is usually to find an organisation of 376 similar size, and agree to swap secondary zones - each organisation 377 agrees to provide a server to act as a secondary server for the other 378 organisation's zones. Note that there is no loss of confidential 379 data here, the data set exchanged would be available publically 380 whatever the servers are. 382 7. Serial Number Maintenance 384 Secondary servers use the serial number in the SOA record of the zone 385 to determine when it is necessary to update their local copy of the 386 zone. Serial numbers are basically just 32 bit unsigned integers 387 that wrap around from the biggest possible value to zero again. See 388 [RFC1982] for a more rigorous definition of the serial number. 390 The serial number must be incremented every time a change, or group 391 of changes, is made to the zone on the primary server. This informs 392 secondary servers they need update their copies of the zone. Note 393 that it is not possible to decrement a serial number, increments are 394 the only defined modification. 396 Occasionally due to editing errors, or other factors, it may be 397 necessary to cause a serial number to become smaller. Never simply 398 decrease the serial number. Secondary servers will ignore that 399 change, and further, will ignore any later increments until the 400 earlier large value is exceeded. 402 Instead, given that serial numbers wrap from large to small, in 403 absolute terms, increment the serial number, several times, until it 404 has reached the value desired. At each step, wait until all 405 secondary servers have updated to the new value before proceeding. 407 For example, assume that the serial number of a zone was 10, but has 408 accidentally been set to 1000, and it is desired to set it back to 409 11. Do not simply change the value from 1000 to 11. A secondary 410 server that has seen the 1000 value (and in practice, there is always 411 at least one) will ignore this change, and continue to use the 412 version of the zone with serial number 1000, until the primary 413 server's serial number exceeds that value. This may be a long time - 414 in fact, the secondary often expires its copy of the zone before the 415 zone is ever updated again. 417 Instead, for this example, set the primary's serial number to 418 2000000000, and wait for the secondary servers to update to that 419 zone. The value 2000000000 is chosen as a value a lot bigger than 420 the current value, but less that 2^31 bigger (2^31 is 2147483648). 421 This is then an increment of the serial number [RFC1982]. 423 Next, after all servers needing updating have the zone with that 424 serial number, the serial number can be set to 4000000000. 425 4000000000 is 2000000000 more than 2000000000 (fairly clearly), and 426 is thus another increment (the value added is less than 2^31). 428 Once this copy of the zone file exists at all servers, the serial 429 number can simply be set to 11. In serial number arithmetic, a 430 change from 4000000000 to 11 is an increment. Serial numbers wrap at 431 2^32 (4294967296), so 11 is identical to 4294967307 432 (4294967296 + 11). 4294967307 is just 294967307 greater than 433 4000000000, and 294967307 is well under 2^31, this is therefore an 434 increment. 436 When following this procedure, it is essential to verify that all 437 relevant servers have been updated at each step, never assume 438 anything. Failing to do this can result in a worse mess than existed 439 before the attempted correction. Also beware that it is the 440 relationship between the values of the various serial numbers that is 441 important, not the absolute values. The values used above are 442 correct for that one example only. 444 It is possible in essentially all cases to correct the serial number 445 in two steps by being more aggressive in the choices of the serial 446 numbers. This however causes the numbers used to be less "nice", and 447 requires considerably more care. 449 Also, note that not all nameserver implementations correctly 450 implement serial number operations. With such servers as secondaries 451 there is typically no way to cause the serial number to become 452 smaller, other than contacting the administrator of the server and 453 requesting that all existing data for the zone be purged. Then that 454 the secondary be loaded again from the primary, as if for the first 455 time. 457 It remains safe to carry out the above procedure, as the 458 malfunctioning servers will need manual attention in any case. After 459 the sequence of serial number changes described above, conforming 460 secondary servers will have been reset. Then when the primary server 461 has the correct (desired) serial number, contact the remaining 462 secondary servers and request their understanding of the correct 463 serial number be manually corrected. Perhaps also suggest that they 464 upgrade their software to a standards conforming implementation. 466 A server which does not implement this algorithm is defective, and 467 may be detected as follows. At some stage, usually when the absolute 468 integral value of the serial number becomes smaller, a server with 469 this particular defect will ignore the change. Servers with this 470 type of defect can be detected by waiting for at least the time 471 specified in the SOA refresh field and then sending a query for the 472 SOA. Servers with this defect will still have the old serial number. 473 We are not aware of other means to detect this defect. 475 Security Considerations 477 It is not believed that anything in this document adds to any 478 security issues that may exist with the DNS, nor does it do anything 479 to lessen them. 481 Administrators should be aware, however, that compromise of a server 482 for a domain can, in some situations, compromise the security of 483 hosts in the domain. Care should be taken in choosing secondary 484 servers so that this threat is minimised. 486 References 488 [RFC1034] Domain Names - Concepts and Facilities, 489 P. Mockapetris, STD 13, ISI, November 1987. 491 [RFC1035] Domain Names - Implementation and Specification, 492 P. Mockapetris, STD 13, ISI, November 1987 494 [RFC1631] The IP Network Address Translator (NAT), 495 K. Egevang, Cray Communications, P. Francis, NTT, May 1994 497 [RFC1982] Serial Number Arithmetic, 498 R. Elz, University of Melbourne, R. Bush, RGnet Inc, 499 August 1996. 501 [KRE1996] Clarifications to the DNS specification, 502 R. Elz, R. Bush, 503 Work In Progress (internet-draft), May 1996. 505 Acknowledgements 507 Brian Carpenter and Yakov Rekhter suggested mentioning NATs and ALGs 508 as a companion to the firewall text. Dave Crocker suggested 509 explicitly exploding the myth. 511 Authors' Addresses 513 Robert Elz 514 Computer Science 515 University of Melbourne 516 Parkville, Vic, 3052 517 Australia. 519 EMail: kre@munnari.OZ.AU 520 Randy Bush 521 RGnet, Inc. 522 5147 Crystal Springs Drive NE 523 Bainbridge Island, Washington, 98110 524 United States. 526 EMail: randy@psg.com 528 Scott Bradner 529 Harvard University 530 1350 Mass Ave 531 Cambridge, MA, 02138 532 United States. 534 EMail: sob@harvard.edu 536 Michael A. Patton 537 33 Blanchard Road 538 Cambridge, MA, 02138 539 United States. 541 EMail: MAP@POBOX.COM