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