idnits 2.17.1 draft-barr-dns-errors-03.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-25) 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. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 782 lines 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. ** The abstract seems to contain references ([RFC1537]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 12 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 13 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1035' on line 90 == Missing Reference: 'RFC 822' is mentioned on line 101, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Unused Reference: 'RFC 974' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'RFC 1178' is defined on line 702, but no explicit reference was found in the text == Unused Reference: 'RFC 1713' is defined on line 715, but no explicit reference was found in the text == Unused Reference: 'BOG' is defined on line 718, but no explicit reference was found in the text ** Obsolete normative reference: RFC 974 (Obsoleted by RFC 2821) ** Downref: Normative reference to an Unknown state RFC: RFC 1033 ** Downref: Normative reference to an Informational RFC: RFC 1178 ** Downref: Normative reference to an Experimental RFC: RFC 1183 ** Downref: Normative reference to an Informational RFC: RFC 1535 ** Obsolete normative reference: RFC 1537 (Obsoleted by RFC 1912) ** Downref: Normative reference to an Informational RFC: RFC 1713 -- Possible downref: Non-RFC (?) normative reference: ref. 'BOG' Summary: 17 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft D. Barr, The Pennsylvania State University 2 Expires in six months 4 Common DNS Operational and Configuration Errors 6 Status of this Memo 8 This document is an Internet-Draft. Internet-Drafts are working 9 documents of the Internet Engineering Task Force (IETF), its areas, 10 and its working groups. Note that other groups may also distribute 11 working documents as Internet-Drafts. 13 Internet-Drafts are draft documents valid for a maximum of six months 14 and may be updated, replaced, or obsoleted by other documents at any 15 time. It is inappropriate to use Internet-Drafts as reference 16 material or to cite them other than as "work in progress." 18 To learn the current status of any Internet Draft, please check the 19 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 20 Directories on ds.internic.net (US East Coast), nic.nordu.net 21 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 22 Rim). 24 Comments on this document should be sent to the author and the 25 namedroppers mailing list, namedroppers@internic.net. 27 Abstract 29 This memo describes errors often found in both the operation of 30 Domain Name System (DNS) servers, and in the data that these DNS 31 servers contain. This memo tries to summarize current Internet 32 requirements as well as common practice in the operation and 33 configuration of the DNS. This memo also tries to summarize or 34 expand upon issues raised in [RFC 1537]. 36 1. Introduction 38 Running a nameserver is not a trivial task. There are many things 39 that can go wrong, and many decisions have to be made about what data 40 to put in the DNS and how to set up servers. This memo attempts to 41 address many of the common mistakes and pitfalls that are made in DNS 42 data as well as in the operation of nameservers. Discussions are 43 also made regarding some other relevant issues such as server or 44 resolver bugs, and a few political issues with respect to the 45 operation of DNS on the Internet. 47 2. DNS Data 49 This section discusses problems people typically have with the DNS 50 data in their nameserver, as found in the zone data files that the 51 nameserver loads into memory. 53 2.1 Inconsistent, Missing, or Bad Data 55 Every Internet-reachable host should have a name. The consequences 56 of this are becoming more and more obvious. Many services available 57 on the Internet will not talk to you if you aren't correctly 58 registered in the DNS. 60 Make sure your PTR and A records match. For every IP address, there 61 should be a matching PTR record in the in-addr.arpa domain. If a 62 host is multi-homed, (more than one IP address) make sure that all IP 63 addresses have a corresponding PTR record (not just the first one). 64 Failure to have matching PTR and A records can cause loss of Internet 65 services similar to not being registered in the DNS at all. Also, 66 PTR records must point back to a valid A record, not a alias defined 67 by a CNAME. It is highly recommended that you use some software 68 which automates this checking, or generate your DNS data from a 69 database which automatically creates consistent data. 71 DNS domain names consist of ``labels'' separated by single dots. The 72 DNS is very liberal in its rules for the allowable characters in a 73 domain name. However, if a domain name is used to name a host, it 74 should follow rules restricting host names. Further if a name is 75 used for mail, it must follow the naming rules for names in mail 76 addresses. 78 Allowable characters in a label for a host name are only ASCII 79 letters, digits, and the `-' character. Labels may not be all 80 numbers, but may have a leading digit (e.g. 3com.com). Labels must 81 end and begin only with a letter or digit. See [RFC 1035] and [RFC 82 1123]. (Labels were initially restricted in [RFC 1035] to start with 83 a letter, and some older hosts still reportedly have problems with 84 the relaxation in [RFC 1123].) Note there are some Internet 85 hostnames which violate this rule (411.org, 1776.com). The presence 86 of underscores in a label is allowed in [RFC 1033], except [RFC 1033] 87 is informational only and was not defining a standard. There is at 88 least one popular TCP/IP implementation which currently refuses to 89 talk to hosts named with underscores in them. It must be noted that 90 the language in [1035] is such that these rules are voluntary -- they 91 are there for those who wish to minimize problems. Note that the 92 rules for Internet host names also apply to hosts and addresses used 93 in SMTP (See RFC 821). 95 If a domain name is to be used for mail (not involving SMTP), it must 96 follow the rules for mail in [RFC 822], which is actually more 97 liberal than the above rules. Labels for mail can be any ASCII 98 character except ``specials'', control characters, and whitespace 99 characters. ``Specials'' are specific symbols used in the parsing of 100 addresses. They are the characters ``()<>@,;:\".[]''. (The ``!'' 101 character wasn't in [RFC 822], however it also shouldn't be used due 102 to the conflict with UUCP mail as defined in RFC 976) However, since 103 today almost all names which are used for mail on the Internet are 104 also names used for hostnames, one rarely sees addresses using these 105 relaxed standard, but mail software should be made liberal and robust 106 enough to accept them. 108 You should also be careful to not have addresses which are valid 109 alternate syntaxes to the inet_ntoa() library call. For example 0xe 110 is a valid name, but if you were to type ``telnet 0xe'', it would try 111 to connect to IP address 0.0.0.14. It is also rumored that there 112 exists some broken inet_ntoa() routines that treat an address like 113 x400 as an IP address. 115 Certain operating systems have limitations on the length of their own 116 hostname. While not strictly of issue to the DNS, you should be 117 aware of your operating system's length limits before choosing the 118 name of a host. 120 Remember that many resource records (abbreviated RR) take on more 121 than one argument. HINFO requires two arguments, as does RP. If you 122 don't supply enough arguments, servers sometime return garbage for 123 the missing fields. If you need to include whitespace within any 124 data, you must put the string in quotes. 126 2.2 SOA records 128 In the SOA record of every zone, remember to fill in the e-mail 129 address that will get to the person who maintains the DNS at your 130 site (commonly referred to as ``hostmaster''). The `@' in the e-mail 131 must be replaced by a `.' first. Do not try to put an `@' sign in 132 this address. If the local part of the address already contains a 133 `.' (e.g. John.Smith@widget.xx), then you need to quote the `.' by 134 preceding it with `\' character. (e.g. to become 135 John\.Smith.widget.xx) Alternately (and preferred), you can just use 136 the generic name `hostmaster', and use a mail alias to redirect it to 137 the appropriate persons. There exists software which uses this field 138 to automatically generate the e-mail address for the zone contact. 139 This software will break if this field is improperly formatted. It 140 is imperative that this address get to one or more real persons, 141 because it is often used for everything from reporting bad DNS data 142 to reporting security incidents. 144 Even though some BIND versions allow you to use a decimal in a serial 145 number, don't. A decimal serial number is converted to an unsigned 146 32-bit integer internally anyway. The formula for a n.m serial 147 number is n*10^(3+int(0.9+log10(m))) + m which translates to 148 something rather unexpected. For example it's routinely possible 149 with a decimal serial number (perhaps automatically generated by 150 SCCS) to be incremented such that it is numerically larger, but after 151 the above conversion yield a serial number which is LOWER than 152 before. Decimal serial numbers have been officially deprecated in 153 recent BIND versions. The recommended syntax is YYYYMMDDnn 154 (YYYY=year, MM=month, DD=day, nn=revision number. This won't 155 overflow until the year 4294. 157 Choose logical values for the timer values in the SOA record (note 158 values below must be expressed as seconds in the zone data): 160 Refresh: How often a secondary will poll the primary server to see 161 if the serial number for the zone has increased (so it knows 162 to request a new copy of the data for the zone). Set this to 163 how long your secondaries can comfortably contain out-of-date 164 data. You can keep it short (20 mins to 2 hours) if you 165 aren't worried about a small increase in bandwidth used, or 166 longer (2-12 hours) if your Internet connection is slow or is 167 started on demand. Recent BIND versions (4.9.3) have optional 168 code to automatically notify secondaries that data has 169 changed, allowing you to set this TTL to a long value (one 170 day, or more). 172 Retry: If a secondary was unable to contact the primary at the 173 last refresh, wait the retry value before trying again. This 174 value isn't as important as others, unless the secondary is on 175 a distant network from the primary or the primary is more 176 prone to outages. It's typically some fraction of the refresh 177 interval. 179 Expire: How long a secondary will still treat its copy of the zone 180 data as valid if it can't contact the primary. This value 181 should be greater than how long a major outage would typically 182 last, and must be greater than the minimum and retry 183 intervals, to avoid having a secondary expire the data before 184 it gets a chance to get a new copy. After a zone is expired a 185 secondary will still continue to try to contact the primary, 186 but it will no longer provide nameservice for the zone. 2-4 187 weeks are suggested values. 189 Minimum: The default TTL (time-to-live) for resource records -- 190 how long data will remain in other nameservers' cache. ([RFC 191 1035] defines this to be the minimum value, but servers seem 192 to always implement this as the default value) This is by far 193 the most important timer. Set this as large as is comfortable 194 given how often you update your nameserver. If you plan to 195 make major changes, it's a good idea to turn this value down 196 temporarily beforehand. Then wait the previous minimum value, 197 make your changes, verify their correctness, and turn this 198 value back up. 1-5 days are typical values. Remember this 199 value can be overridden on individual resource records. 201 As you can see, the typical values above for the timers vary widely. 202 Popular documentation like [RFC 1033] recommended a day for the 203 minimum TTL, which is now considered too low except for zones with 204 data that vary regularly. Once a DNS stabilizes, values on the order 205 of 3 or more days are recommended. It is also recommended that you 206 individually override the TTL on certain RRs which are often 207 referenced and don't often change to have very large values (1-2 208 weeks). Good examples of this are the MX, A, and PTR records of your 209 mail host(s), the NS records of your zone, and the A records of your 210 nameservers. 212 2.3 Glue A Records 214 Glue records are A records that are associated with NS records to 215 provide ``bootstrapping'' information to the nameserver. For 216 example: 218 podunk.xx. in ns ns1.podunk.xx. 219 in ns ns2.podunk.xx. 220 ns1.podunk.xx. in a 1.2.3.4 221 ns2.podunk.xx. in a 1.2.3.5 223 Here, the A records are referred to as ``Glue records''. 225 Glue records are required only in forward zone files for nameservers 226 that are located in the subdomain of the current zone that is being 227 delegated. You shouldn't have any A records in an in-addr.arpa zone 228 file (unless you're using RFC 1101-style encoding of subnet masks). 230 If your nameserver is multi-homed (has more than one IP address), you 231 must list all of its addresses in the glue to avoid cache 232 inconsistency due to differing TTL values, causing some lookups to 233 not find all addresses for your nameserver. 235 Some people get in the bad habit of putting in a glue record whenever 236 they add an NS record ``just to make sure''. Having duplicate glue 237 records in your zone files just makes it harder when a nameserver 238 moves to a new IP address, or is removed. You'll spend hours trying 239 to figure out why random people still see the old IP address for some 240 host, because someone forgot to change or remove a glue record in 241 some other file. Newer BIND versions will ignore these extra glue 242 records in local zone files. 244 Older BIND versions (4.8.3 and previous) have a problem where it 245 inserts these extra glue records in the zone transfer data to 246 secondaries. If one of these glues is wrong, the error can be 247 propagated to other nameservers. If two nameservers are secondaries 248 for other zones of each other, it's possible for one to continually 249 pass old glue records back to the other. The only way to get rid of 250 the old data is to kill both of them, remove the saved backup files, 251 and restart them. Combined with that those same versions also tend 252 to become infected more easily with bogus data found in other non- 253 secondary nameservers (like the root zone data). 255 2.4 CNAME records 257 A CNAME record is not allowed to coexist with any other data. In 258 other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you 259 can't also have an MX record for suzy.podunk.edu, or an A record, or 260 even a TXT record. Especially do not try to combine CNAMEs and NS 261 records like this!: 263 podunk.xx. IN NS ns1 264 IN NS ns2 265 IN CNAME mary 266 mary IN A 1.2.3.4 268 This is often attempted by inexperienced administrators as an obvious 269 way to allow your domain name to also be a host. However, DNS 270 servers like BIND will see the CNAME and refuse to add any other 271 resources for that name. Since no other records are allowed to 272 coexist with a CNAME, the NS entries are ignored. Therefore all the 273 hosts in the podunk.xx domain are ignored as well! 275 If you want to have your domain also be a host, do the following: 277 podunk.xx. IN NS ns1 278 IN NS ns2 279 IN A 1.2.3.4 280 mary IN A 1.2.3.4 282 Don't go overboard with CNAMEs. Use them when renaming hosts, but 283 plan to get rid of them (and inform your users). However CNAMEs are 284 useful (and encouraged) for generalized names for servers -- `ftp' 285 for your ftp server, `www' for your Web server, `gopher' for your 286 Gopher server, `news' for your Usenet news server, etc. 288 Don't forget to delete the CNAMEs associated with a host if you 289 delete the host it is an alias for. Such ``stale CNAMEs'' are a 290 waste of resources. 292 Don't use CNAMEs in combination with RRs which point to other names 293 like MX, CNAME, PTR and NS. (PTR is an exception if you want to 294 implement classless in-addr delegation.) For example, this is 295 strongly discouraged: 297 podunk.xx. IN MX mailhost 298 mailhost IN CNAME mary 299 mary IN A 1.2.3.4 301 [RFC 1034] in section 3.6.2 says this should not be done, and [RFC 302 974] explicitly states that MX records shall not point to an alias 303 defined by a CNAME. This results in unnecessary indirection in 304 accessing the data, and DNS resolvers and servers need to work more 305 to get the answer. If you really want to do this, you can accomplish 306 the same thing by using a preprocessor such as m4 on your host files. 308 Also, having chained records such as CNAMEs pointing to CNAMEs may 309 make administration issues easier, but is known to tickle bugs in 310 some resolvers that fail to check loops correctly. As a result some 311 hosts may not be able to resolve such names. 313 Having NS records pointing to a CNAME is bad and may conflict badly 314 with current BIND servers. In fact, current BIND implementations 315 will ignore such records, possibly leading to a lame delegation. 316 There is a certain amount of security checking done in BIND to 317 prevent spoofing DNS NS records. Also, older BIND servers reportedly 318 will get caught in an infinite query loop trying to figure out the 319 address for the aliased nameserver, causing a continuous stream of 320 DNS requests to be sent. 322 2.5 MX records 324 It is a good idea to give every host an MX record, even if it points 325 to itself! Some mailers will cache MX records, but will always need 326 to check for an MX before sending mail. If a site does not have an 327 MX, then every piece of mail may result in one more resolver query, 328 since the answer to the MX query often also contains the IP addresses 329 of the MX hosts. Internet SMTP mailers are required by [RFC 1123] to 330 support the MX mechanism. 332 Put MX records even on hosts that aren't intended to send or receive 333 e-mail. If there is a security problem involving one of these hosts, 334 some people will mistakenly send mail to postmaster or root at the 335 site without checking first to see if it is a ``real'' host or just a 336 terminal or personal computer that's not set up to accept e-mail. If 337 you give it an MX record, then the e-mail can be redirected to a real 338 person. Otherwise mail can just sit in a queue for hours or days 339 until the mailer gives up trying to send it. 341 Don't forget that whenever you add an MX record, you need to inform 342 the target mailer if it is to treat the first host as "local". (The 343 ``Cw'' flag in sendmail, for example) 345 If you add an MX record which points to an external host (e.g. for 346 the purposes of backup mail routing) be sure to ask permission from 347 that site first. Otherwise that site could get rather upset and take 348 action (like throw your mail away, or appeal to higher authorities 349 like your parent DNS administrator or network provider.) 351 2.6 Other Resource Records 353 2.6.1 WKS 355 WKS records are deprecated in [RFC 1123]. They serve no known useful 356 function, except internally among LISP machines. Don't use them. 358 2.6.2 HINFO 360 On the issue HINFO records, some will argue that these is a security 361 problem (by broadcasting what vendor hardware and operating system 362 you so people can run systematic attacks on known vendor security 363 holes). If you do use them, you should keep up to date with known 364 vendor security problems. However, they serve a useful purpose. 365 Don't forget that HINFO requires two arguments, the hardware type, 366 and the operating system. 368 HINFO is sometimes abused to provide other information. The record 369 is meant to provide specific information about the machine itself. 370 If you need to express other information about the host in the DNS, 371 use TXT. 373 2.6.3 TXT 375 TXT records have no specific definition. You can put most anything 376 in them. Some use it for a generic description of the host, some put 377 specific information like its location, primary user, or maybe even a 378 phone number. 380 2.6.4 RP 382 RP records are relatively new. They are used to specify an e-mail 383 address (see first paragraph of section 2.2) of the ``Responsible 384 Person'' of the host, and the name of a TXT record where you can get 385 more information. See [RFC 1183]. 387 2.7 Wildcard records 389 Wildcard MXs are useful mostly for non IP-connected sites. A common 390 mistake is thinking that a wildcard MX for a zone will apply to all 391 hosts in the zone. A wildcard MX will apply only to names in the 392 zone which aren't listed in the DNS at all. e.g. 394 podunk.xx. IN NS ns1 395 IN NS ns2 396 mary IN A 1.2.3.4 397 *.podunk.xx. IN MX 5 sue 399 Mail for mary.podunk.xx will be sent to itself for delivery. Only 400 mail for jane.podunk.xx or any hosts you don't see above will be sent 401 to the MX. For most Internet sites, wildcard MX records are not 402 useful. You need to put explicit MX records on every host. 404 Wildcard MXs can be bad, because they make some operations succeed 405 when they should fail instead. Consider the case where someone in 406 the domain ``widget.com'' tries to send mail to ``joe@larry''. If 407 the host ``larry'' doesn't actually exist, the mail should in fact 408 bounce immediately. But because of domain searching the address gets 409 resolved to ``larry.widget.com'', and because of the wildcard MX this 410 is a valid address according to DNS. Or perhaps someone simply made 411 a typo in the hostname portion of the address. The mail message then 412 gets routed to the mail host, which then rejects the mail with 413 strange error messages like ``I refuse to talk to myself'' or ``Local 414 configuration error''. 416 Wildcard MX records are good for when you have a large number of 417 hosts which are not directly Internet-connected (for example, behind 418 a firewall) and for administrative or political reasons it is too 419 difficult to have individual MX records for every host, or to force 420 all e-mail addresses to be ``hidden'' behind one or more domain 421 names. In that case, you must divide your DNS into two parts, an 422 internal DNS, and an external DNS. The external DNS will have only a 423 few hosts and explicit MX records, and one or more wildcard MXs for 424 each internal domain. Internally the DNS will be complete, with all 425 explicit MX records and no wildcards. 427 Wildcard As and CNAMEs are possible too, and are really confusing to 428 users, and a potential nightmare if used without thinking first. It 429 could result (due again to domain searching) in any telnet/ftp 430 attempts from within the domain to unknown hosts to be directed to 431 one address. One such wildcard CNAME (in *.edu.com) caused 432 Internet-wide loss of services and potential security nightmares due 433 to unexpected interactions with domain searching. It resulted in 434 swift fixes, and even an RFC ([RFC 1535]) documenting the problem. 436 2.8 Authority and Delegation Errors (NS records) 438 You are required to have at least two nameservers for every domain, 439 though more is preferred. Have secondaries outside your network. If 440 the secondary isn't under your control, periodically check up on them 441 and make sure they're getting current zone data from you. Queries to 442 their nameserver about your hosts should always result in an 443 ``authoritative'' response. If not, this is called a ``lame 444 delegation''. A lame delegations exists when a nameserver is 445 delegated responsibility for providing nameservice for a zone (via NS 446 records) but is not performing nameservice for that zone (usually 447 because it is not set up as a primary or secondary for the zone). 449 The ``classic'' lame delegation can be illustrated in this example: 451 podunk.xx. IN NS ns1.podunk.xx. 452 IN NS ns0.widget.com. 454 ``podunk.xx'' is a new domain which has recently been created, and 455 ``ns1.podunk.xx'' has been set up to perform nameservice for the 456 zone. They haven't quite finished everything yet and haven't made 457 sure that the hostmaster at ``ns0.widget.com'' has set up to be a 458 proper secondary, and thus has no information about the podunk.xx 459 domain, even though the DNS says it is supposed to. Various things 460 can happen depending on which nameserver is used. At best, extra DNS 461 traffic will result from a lame delegation. At worst, you can get 462 unresolved hosts and bounced e-mail. 464 Also, sometimes a nameserver is moved to another host or removed from 465 the list of secondaries. Unfortunately due to caching of NS records, 466 many sites will still think that a host is a secondary after that 467 host has stopped providing nameservice. In order to prevent lame 468 delegations while the cache is being aged, continue to provide 469 nameservice on the old nameserver for the length of the maximum of 470 the minimum plus refresh times for the zone and the parent zone. 471 (See section 2.2) 473 Whenever a primary or secondary is removed or changed, it takes a 474 fair amount of human coordination among the parties involved. (The 475 site itself, it's parent, and the site hosting the secondary) When a 476 primary moves, make sure all secondaries have their named.boot files 477 updated and their servers reloaded. When a secondary moves, make 478 sure the address records at both the primary and parent level are 479 changed. 481 It's also been reported that some distant sites like to pick popular 482 nameservers like ``ns.uu.net'' and just add it to their list of NS 483 records in hopes that they will magically perform additional 484 nameservice for them. This is an even worse form of lame delegation, 485 since this adds traffic to an already busy nameserver. Please 486 contact the hostmasters of sites which have lame delegations. 487 Various tools can be used to detect or actively find lame 488 delegations. See the list of contributed software in the BIND 489 distribution. 491 Make sure your parent domain has the same NS records for your zone as 492 you do. (Don't forget your in-addr.arpa zones too!). Do not list 493 too many (7 is the recommended maximum), as this just makes things 494 harder to manage and is only really necessary for very popular top- 495 level or root zones. You also run the risk of overflowing the 512- 496 byte limit of a UDP packet in the response to an NS query. If this 497 happens, resolvers will ``fall back'' to using TCP requests, 498 resulting in increased load on your nameserver. 500 It's important when picking geographic locations for secondary 501 nameservers to minimize latency as well as increase reliability. 502 Keep in mind network topologies. For example if your site is on the 503 other end of a slow local or international link, consider a secondary 504 on the other side of the link to decrease average latency. Contact 505 your Internet service provider or parent domain contact for more 506 information about secondaries which may be available to you. 508 3. BIND operation 510 This section discusses common problems people have in the actual 511 operation of the nameserver (specifically, BIND). Not only must the 512 data be correct as explained above, but the nameserver must be 513 operated correctly for the data to be made available. 515 3.1 Serial numbers 517 Each zone has a serial number associated with it. Its use is for 518 keeping track of who has the most current data. If and only if the 519 primary's serial number of the zone is greater will the secondary ask 520 the primary for a copy of the new zone data (see special case below). 522 Don't forget to change the serial number when you change data! If 523 you don't, your secondaries will not transfer the new zone 524 information. Automating the incrementing of the serial number with 525 software is also a good idea. 527 If you make a mistake and increment the serial number too high, and 528 you want to reset the serial number to a lower value, use the 529 following procedure: 531 Take the `incorrect' serial number and add 2147483647 to it. If 532 the number exceeds 4294967296, subtract 4294967296. Load the 533 resulting number. Then wait 2 refresh periods to allow the zone 534 to propagate to all servers. 536 Repeat above until the resulting serial number is less than the 537 target serial number. 539 Up the serial number to the target serial number. 541 This procedure won't work if one of your secondaries is running an 542 old version of BIND (4.8.3 or earlier). In this case you'll have to 543 contact the hostmaster for that secondary and have them kill the 544 secondary servers, remove the saved backup file, and restart the 545 server. Be careful when editing the serial number -- DNS admins 546 don't like to kill and restart nameservers because you lose all that 547 cached data. 549 3.2 Zone file style guide 551 Here are some useful tips in structuring your zone files. Following 552 these will help you spot mistakes, and avoid making more. 554 Be consistent with the style of entries in your DNS files. If your 555 $ORIGIN is podunk.xx., try not to write entries like: 557 mary IN A 1.2.3.1 558 sue.podunk.xx. IN A 1.2.3.2 560 or: 562 bobbi IN A 1.2.3.2 563 IN MX mary.podunk.xx. 565 Either use all FQDNs (Fully Qualified Domain Names) everywhere or 566 used unqualified names everywhere. Or have FQDNs all on the right- 567 hand side but unqualified names on the left. Above all, be 568 consistent. 570 Use tabs between fields, and try to keep columns lined up. It makes 571 it easier to spot missing fields (note some fields such as ``IN'' are 572 inherited from the previous record and may be left out in certain 573 circumstances.) 575 Remember you don't need to repeat the name of the host when you are 576 defining multiple records for one host. Be sure also to keep all 577 records associated with a host together in the file. It will make 578 things more straightforward when it comes time to remove or rename a 579 host. 581 Always remember your $ORIGIN. If you don't put a `.' at the end of 582 an FQDN, it's not recognized as an FQDN. If it is not an FQDN, then 583 the nameserver will append $ORIGIN to the name. Double check, triple 584 check, those trailing dots, especially in in-addr.arpa zone files, 585 where they are needed the most. 587 Be careful with the syntax of the SOA and WKS records (the records 588 which use parentheses). BIND is not very flexible in how it parses 589 these records. See the documentation for BIND. 591 3.3 Verifying data 593 Verify the data you just entered or changed by querying the resolver 594 with dig (or your favorite DNS tool, many are included in the BIND 595 distribution) after a change. A few seconds spent double checking 596 can save hours of trouble, lost mail, and general headaches. Also be 597 sure to check syslog output when you reload the nameserver. If you 598 have grievous errors in your DNS data or boot file, named will report 599 it via syslog. 601 It is also highly recommended that you automate this checking, either 602 with software which runs sanity checks on the data files before they 603 are loaded into the nameserver, or with software which checks the 604 data already loaded in the nameserver. Some contributed software to 605 do this is included in the BIND distribution. 607 4. Miscellaneous Topics 609 4.1 Boot file setup 611 Certain zones should always be present in nameserver configurations: 613 primary localhost localhost 614 primary 0.0.127.in-addr.arpa 127.0 615 primary 255.in-addr.arpa 255 616 primary 0.in-addr.arpa 0 618 These are set up to either provide nameservice for ``special'' 619 addresses, or to help eliminate accidental queries for broadcast or 620 local address to be sent off to the root nameservers. All of these 621 files will contain NS and SOA records just like the other zone files 622 you maintain, the exception being that you can probably make the SOA 623 timers very long, since this data will never change. 625 The ``localhost'' address is a ``special'' address which always 626 refers to the local host. It should contain the following line: 628 localhost. IN A 127.0.0.1 630 The ``127.0'' file should contain the line: 632 1 PTR localhost. 634 There has been some extensive discussion about whether or not to 635 append the local domain to it. The conclusion is that ``localhost.'' 636 would be the best solution. The reasons given include: 638 ``localhost'' by itself is used and expected to work in some 639 systems. 641 Translating 127.0.0.1 into ``localhost.dom.ain'' can cause some 642 software to connect back to the loopback interface when it didn't 643 want to because ``localhost'' is not equal to 644 ``localhost.dom.ain''. 646 The ``255'' and ``0'' files should not contain any additional data 647 beyond the NS and SOA records. 649 Note that future BIND versions may include all or some of this data 650 automatically without additional configuration. 652 4.2 Other Resolver and Server bugs 654 Very old versions of the DNS resolver have a bug that cause queries 655 for names that look like IP addresses to go out, because the user 656 supplied an IP address and the software didn't realize that it didn't 657 need to be resolved. This has been fixed but occasionally it still 658 pops up. It's important because this bug means that these queries 659 will be sent directly to the root nameservers, adding to an already 660 heavy DNS load. 662 While running a secondary nameserver off another secondary nameserver 663 is possible, it is not recommended unless necessary due to network 664 topologies. There are known cases where it has led to problems like 665 bogus TTL values. While this may be caused by older or flawed DNS 666 implementations, you should not chain secondaries off of one another 667 since this builds up additional reliability dependencies as well as 668 adds additional delays in updates of new zone data. 670 4.3 Server issues 672 DNS operates primarily via UDP (User Datagram Protocol) messages. 673 Some UNIX operating systems, in an effort to save CPU cycles, run 674 with UDP checksums turned off. The relative merits of this have long 675 been debated. However, with the increase in CPU speeds, the 676 performance considerations become less and less important. It is 677 strongly encouraged that you turn on UDP checksumming to avoid 678 corrupted data not only with DNS but with other services that use UDP 679 (like NFS). Check with your operating system documentation to verify 680 that UDP checksumming is enabled. 682 References 684 [RFC 974] Partridge, C., "Mail routing and the domain system", STD 685 14, RFC 974, CSNET CIC BBN Laboratories Inc, January 1986. 687 [RFC 1033] Lottor, M, "Domain Administrators Operations Guide", RFC 688 1033, USC/Information Sciences Institute, November 1987. 690 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 691 STD 13, RFC 1034, USC/Information Sciences Institute, 692 November 1987. 694 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and 695 Specification", STD 13, RFC 1035, USC/Information Sciences 696 Institute, November 1987. 698 [RFC 1123] Braden, R., "Requirements for Internet Hosts -- 699 Application and Support", STD 3, RFC 1123, IETF, October 700 1989. 702 [RFC 1178] Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC 703 1178, Integrated Systems Group/NIST, August 1990. 705 [RFC 1183] R. Ullman, P. Mockapetris, L. Mamakos, C. Everhart, "New 706 DNS RR Definitions", RFC 1183, October 1990. 708 [RFC 1535] Gavron, E., "A Security Problem and Proposed Correction 709 With Widely Deployed DNS Software", RFC 1535, ACES 710 Research Inc., October 1993. 712 [RFC 1537] Beertema, P., "Common DNS Data File Configuration Errors", 713 RFC 1537, CWI, October 1993. 715 [RFC 1713] A. Romao, "Tools for DNS debugging", RFC 1713, FCCN, 716 November 1994. 718 [BOG] Vixie, P, et. al., "Name Server Operations Guide for BIND", 719 Vixie Enterprises, July 1994. 721 5. Security Considerations 723 Security considerations are not discussed in this memo. 725 6. Author's Address 727 David Barr 728 The Pennsylvania State University 729 Department of Mathematics 730 334 Whitmore Building 731 University Park, PA 16802 733 Voice: +1 814 863 7374 734 Fax: +1 814 863-8311 735 Email: barr@math.psu.edu