1 Network Working Group                                            D. Barr   
    2 Request for Comments: 1912             The Pennsylvania State University   
    3 Obsoletes: 1537                                            February 1996   
    4 Category: Informational                                                    
    7             Common DNS Operational and Configuration Errors                
    9 Status of this Memo                                                        
   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.                                                 
   15 Abstract                                                                   
   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].                                
   24 1. Introduction                                                            
   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.                                       
   35 2. DNS Data                                                                
   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.                                           
   41 2.1 Inconsistent, Missing, or Bad Data                                     
   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.                                                  
   52 Barr                         Informational                      [Page 1]   

   53 RFC 1912                   Common DNS Errors               February 1996   
   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.                   
   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.                                                              
   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).                                                  
   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.                                                  
  107 Barr                         Informational                      [Page 2]   

  108 RFC 1912                   Common DNS Errors               February 1996   
  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  It is also rumored that there       
  115    exists some broken inet_ntoa() routines that treat an address like      
  116    x400 as an IP address.                                                  
  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.                                                         
  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.                                
  129 2.2 SOA records                                                            
  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.                                        
  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.                                           
  162 Barr                         Informational                      [Page 3]   

  163 RFC 1912                   Common DNS Errors               February 1996   
  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):            
  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).                                                   
  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.                                                        
  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.                                      
  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.          
  217 Barr                         Informational                      [Page 4]   

  218 RFC 1912                   Common DNS Errors               February 1996   
  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.                                                            
  232 2.3 Glue A Records                                                         
  234    Glue records are A records that are associated with NS records to       
  235    provide "bootstrapping" information to the nameserver.  For example:    
  237            podunk.xx.      in      ns      ns1.podunk.xx.                  
  238                            in      ns      ns2.podunk.xx.                  
  239            ns1.podunk.xx.  in      a                         
  240            ns2.podunk.xx.  in      a                         
  242    Here, the A records are referred to as "Glue records".                  
  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).     
  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.                             
  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.                                            
  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    
  272 Barr                         Informational                      [Page 5]   

  273 RFC 1912                   Common DNS Errors               February 1996   
  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).                        
  281 2.4 CNAME records                                                          

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!:                                                     
  290            podunk.xx.      IN      NS      ns1                             
  291                            IN      NS      ns2                             
  292                            IN      CNAME   mary                            
  293            mary            IN      A                         
  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!                      
  303    If you want to have your domain also be a host, do the following:       
  305            podunk.xx.      IN      NS      ns1                             
  306                            IN      NS      ns2                             
  307                            IN      A                         
  308            mary            IN      A                         
  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.                 
  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.                                                           
  327 Barr                         Informational                      [Page 6]   

  328 RFC 1912                   Common DNS Errors               February 1996   
  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:                                                   
  336            podunk.xx.      IN      MX      mailhost                        
  337            mailhost        IN      CNAME   mary                            
  338            mary            IN      A                         
  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.   
  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.                            
  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.                                                
  362 2.5 MX records                                                             
  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.                                               
  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       
  382 Barr                         Informational                      [Page 7]   

  383 RFC 1912                   Common DNS Errors               February 1996   
  386    until the mailer gives up trying to send it.                            
  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)                                     
  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.)                
  398 2.6 Other Resource Records                                                 
  400 2.6.1 WKS                                                                  
  402    WKS records are deprecated in [RFC 1123].  They serve no known useful   
  403    function, except internally among LISP machines.  Don't use them.       
  405 2.6.2 HINFO                                                                
  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.                                               
  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.                                                                
  420 2.6.3 TXT                                                                  
  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.                                                           
  427 2.6.4 RP                                                                   
  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].                                      
  437 Barr                         Informational                      [Page 8]   

  438 RFC 1912                   Common DNS Errors               February 1996   
  441 2.7 Wildcard records                                                       
  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.,                      
  448            podunk.xx.      IN      NS      ns1                             
  449                            IN      NS      ns2                             
  450            mary            IN      A                         
  451            *.podunk.xx.    IN      MX      5 sue                           
  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.             
  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".                                                   
  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.                                   
  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.      
  492 Barr                         Informational                      [Page 9]   

  493 RFC 1912                   Common DNS Errors               February 1996   
  496 2.8 Authority and Delegation Errors (NS records)                           
  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).       
  509    The "classic" lame delegation can be illustrated in this example:       
  511            podunk.xx.      IN      NS      ns1.podunk.xx.                  
  512                            IN      NS      ns0.widget.com.                 
  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.                                    
  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)                                                       
  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.                                                                
  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            
  547 Barr                         Informational                     [Page 10]   

  548 RFC 1912                   Common DNS Errors               February 1996   
  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.                                                           
  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.                                   
  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.            
  575 3. BIND operation                                                          
  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.                   
  582 3.1 Serial numbers                                                         
  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).   
  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.                                           
  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:                                                    
  602 Barr                         Informational                     [Page 11]   

  603 RFC 1912                   Common DNS Errors               February 1996   
  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.                                         
  611       Repeat above until the resulting serial number is less than the      
  612       target serial number.                                                
  614       Up the serial number to the target serial number.                    
  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.                                                            
  624 3.2 Zone file style guide                                                  
  626    Here are some useful tips in structuring your zone files.  Following    
  627    these will help you spot mistakes, and avoid making more.               
  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:                   
  632            mary            IN      A                         
  633            sue.podunk.xx.  IN      A                         
  635    or:                                                                     
  637            bobbi           IN      A                         
  638                            IN      MX      mary.podunk.xx.                 
  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.                                                             
  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.)                                                         
  657 Barr                         Informational                     [Page 12]   

  658 RFC 1912                   Common DNS Errors               February 1996   
  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.                                                                   
  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.                                         
  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.                         
  677 3.3 Verifying data                                                         
  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.                                                          
  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.                           
  693 4. Miscellaneous Topics                                                    
  695 4.1 Boot file setup                                                        
  697    Certain zones should always be present in nameserver configurations:    
  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                       
  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    
  712 Barr                         Informational                     [Page 13]   

  713 RFC 1912                   Common DNS Errors               February 1996   
  716    timers very long, since this data will never change.                    
  718    The "localhost" address is a "special" address which always refers to   
  719    the local host.  It should contain the following line:                  
  721            localhost.      IN      A                       
  723    The "127.0" file should contain the line:                               
  725            1    PTR     localhost.                                         
  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:                 
  731       "localhost" by itself is used and expected to work in some           
  732       systems.                                                             
  734       Translating 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".     
  738    The "255" and "0" files should not contain any additional data beyond   
  739    the NS and SOA records.                                                 
  741    Note that future BIND versions may include all or some of this data     
  742    automatically without additional configuration.                         
  744 4.2 Other Resolver and Server bugs                                         
  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.                                                         
  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.                     
  767 Barr                         Informational                     [Page 14]   

  768 RFC 1912                   Common DNS Errors               February 1996   
  771 4.3 Server issues                                                          
  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.                                       
  783 References                                                                 
  785    [RFC 974] Partridge, C., "Mail routing and the domain system", STD      
  786               14, RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.   
  788    [RFC 1033] Lottor, M, "Domain Administrators Operations Guide", RFC     
  789               1033, USC/Information Sciences Institute, November 1987.     
  791    [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",   
  792               STD 13, RFC 1034, USC/Information Sciences Institute,        
  793               November 1987.                                               
  795    [RFC 1035] Mockapetris, P., "Domain Names - Implementation and          
  796               Specification", STD 13, RFC 1035, USC/Information Sciences   
  797               Institute, November 1987.                                    
  799    [RFC 1123] Braden, R., "Requirements for Internet Hosts --              
  800               Application and Support", STD 3, RFC 1123, IETF, October     
  801               1989.                                                        
  803    [RFC 1178] Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC   
  804               1178, Integrated Systems Group/NIST, August 1990.            
  806    [RFC 1183] Ullman, R., Mockapetris, P., Mamakos, L, and C. Everhart,    
  807               "New DNS RR Definitions", RFC 1183, October 1990.            
  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.                                 
  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.                                                
  822 Barr                         Informational                     [Page 15]   

  823 RFC 1912                   Common DNS Errors               February 1996   
  826    [RFC 1537] Beertema, P., "Common DNS Data File Configuration Errors",   
  827               RFC 1537, CWI, October 1993.                                 
  829    [RFC 1713] A. Romao, "Tools for DNS debugging", RFC 1713, FCCN,         
  830               November 1994.                                               
  832    [BOG] Vixie, P, et. al., "Name Server Operations Guide for BIND",       
  833               Vixie Enterprises, July 1994.                                
  835 5. Security Considerations                                                 
  837    Security issues are not discussed in this memo.                         
  839 6. Author's Address                                                        
  841    David Barr                                                              
  842    The Pennsylvania State University                                       
  843    Department of Mathematics                                               
  844    334 Whitmore Building                                                   
  845    University Park, PA 16802                                               
  847    Voice: +1 814 863 7374                                                  
  848    Fax: +1 814 863-8311                                                    
  849    EMail: barr@math.psu.edu                                                
  877 Barr                         Informational                     [Page 16]   
line-283 Jonathan Teague(Editorial Erratum #5381) [Reported]
based on outdated version
   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.
It should say:
   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.

The .edu is a typo and should be corrected to .xx