contrib/bind9/doc/rfc/rfc1537.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                        P. Beertema
   8 Request for Comments: 1537                                           CWI
   9 Category: Informational                                     October 1993
  10
  11
  12                Common DNS Data File Configuration Errors
  13
  14 Status of this Memo
  15
  16    This memo provides information for the Internet community.  It does
  17    not specify an Internet standard.  Distribution of this memo is
  18    unlimited.
  19
  20 Abstract
  21
  22    This memo describes errors often found in DNS data files. It points
  23    out common mistakes system administrators tend to make and why they
  24    often go unnoticed for long periods of time.
  25
  26 Introduction
  27
  28    Due to the lack of extensive documentation and automated tools, DNS
  29    zone files have mostly been configured by system administrators, by
  30    hand. Some of the rules for writing the data files are rather subtle
  31    and a few common mistakes are seen in domains worldwide.
  32
  33    This document is an attempt to list "surprises" that administrators
  34    might find hidden in their zone files. It describes the symptoms of
  35    the malady and prescribes medicine to cure that. It also gives some
  36    general recommendations and advice on specific nameserver and zone
  37    file issues and on the (proper) use of the Domain Name System.
  38
  39 1. SOA records
  40
  41    A problem I've found in quite some nameservers is that the various
  42    timers have been set (far) too low. Especially for top level domain
  43    nameservers this causes unnecessary traffic over international and
  44    intercontinental links.
  45
  46    Unfortunately the examples given in the BIND manual, in RFC's and in
  47    some expert documents give those very short timer values, and that's
  48    most likely what people have modeled their SOA records after.
  49
  50    First of all a short explanation of the timers used in the SOA
  51    record:
  52
  53
  54
  55
  56
  57
  58 Beertema                                                        [Page 1]
  59 \f
  60 RFC 1537       Common DNS Data File Configuration Errors    October 1993
  61
  62
  63         - Refresh: The SOA record of the primary server is checked
  64                    every "refresh" time by the secondary servers;
  65                    if it has changed, a zone transfer is done.
  66
  67         - Retry: If a secondary server cannot reach the primary
  68                  server, it tries it again every "retry" time.
  69
  70         - Expire: If for "expire" time the primary server cannot
  71                   be reached, all information about the zone is
  72                   invalidated on the secondary servers (i.e., they
  73                   are no longer authoritative for that zone).
  74
  75         - Minimum TTL: The default TTL value for all records in the
  76                        zone file; a different TTL value may be given
  77                        explicitly in a record when necessary.
  78                        (This timer is named "Minimum", and that's
  79                        what it's function should be according to
  80                        STD 13, RFC 1035, but most (all?)
  81                        implementations take it as the default value
  82                        exported with records without an explicit TTL
  83                        value).
  84
  85    For top level domain servers I would recommend the following values:
  86
  87           86400 ; Refresh     24 hours
  88            7200 ; Retry        2 hours
  89         2592000 ; Expire      30 days
  90          345600 ; Minimum TTL  4 days
  91
  92    For other servers I would suggest:
  93
  94           28800 ; Refresh     8 hours
  95            7200 ; Retry       2 hours
  96          604800 ; Expire      7 days
  97           86400 ; Minimum TTL 1 day
  98
  99    but here the frequency of changes, the required speed of propagation,
 100    the reachability of the primary server etc. play a role in optimizing
 101    the timer values.
 102
 103 2. Glue records
 104
 105    Quite often, people put unnecessary glue (A) records in their zone
 106    files. Even worse is that I've even seen *wrong* glue records for an
 107    external host in a primary zone file! Glue records need only be in a
 108    zone file if the server host is within the zone and there is no A
 109    record for that host elsewhere in the zone file.
 110
 111
 112
 113
 114 Beertema                                                        [Page 2]
 115 \f
 116 RFC 1537       Common DNS Data File Configuration Errors    October 1993
 117
 118
 119    Old BIND versions ("native" 4.8.3 and older versions) showed the
 120    problem that wrong glue records could enter secondary servers in a
 121    zone transfer.
 122
 123 3. "Secondary server surprise"
 124
 125    I've seen it happen on various occasions that hosts got bombarded by
 126    nameserver requests without knowing why. On investigation it turned
 127    out then that such a host was supposed to (i.e., the information was
 128    in the root servers) run secondary for some domain (or reverse (in-
 129    addr.arpa)) domain, without that host's nameserver manager having
 130    been asked or even been told so!
 131
 132    Newer BIND versions (4.9 and later) solved this problem.  At the same
 133    time though the fix has the disadvantage that it's far less easy to
 134    spot this problem.
 135
 136    Practice has shown that most domain registrars accept registrations
 137    of nameservers without checking if primary (!) and secondary servers
 138    have been set up, informed, or even asked.  It should also be noted
 139    that a combination of long-lasting unreachability of primary
 140    nameservers, (therefore) expiration of zone information, plus static
 141    IP routing, can lead to massive network traffic that can fill up
 142    lines completely.
 143
 144 4. "MX records surprise"
 145
 146    In a sense similar to point 3. Sometimes nameserver managers enter MX
 147    records in their zone files that point to external hosts, without
 148    first asking or even informing the systems managers of those external
 149    hosts.  This has to be fought out between the nameserver manager and
 150    the systems managers involved. Only as a last resort, if really
 151    nothing helps to get the offending records removed, can the systems
 152    manager turn to the naming authority of the domain above the
 153    offending domain to get the problem sorted out.
 154
 155 5. "Name extension surprise"
 156
 157    Sometimes one encounters weird names, which appear to be an external
 158    name extended with a local domain. This is caused by forgetting to
 159    terminate a name with a dot: names in zone files that don't end with
 160    a dot are always expanded with the name of the current zone (the
 161    domain that the zone file stands for or the last $ORIGIN).
 162
 163    Example: zone file for foo.xx:
 164
 165    pqr          MX 100  relay.yy.
 166    xyz          MX 100  relay.yy           (no trailing dot!)
 167
 168
 169
 170 Beertema                                                        [Page 3]
 171 \f
 172 RFC 1537       Common DNS Data File Configuration Errors    October 1993
 173
 174
 175    When fully written out this stands for:
 176
 177       pqr.foo.xx.  MX 100  relay.yy.
 178       xyz.foo.xx.  MX 100  relay.yy.foo.xx.   (name extension!)
 179
 180 6. Missing secondary servers
 181
 182    It is required that there be a least 2 nameservers for a domain. For
 183    obvious reasons the nameservers for top level domains need to be very
 184    well reachable from all over the Internet. This implies that there
 185    must be more than just 2 of them; besides, most of the (secondary)
 186    servers should be placed at "strategic" locations, e.g., close to a
 187    point where international and/or intercontinental lines come
 188    together.  To keep things manageable, there shouldn't be too many
 189    servers for a domain either.
 190
 191    Important aspects in selecting the location of primary and secondary
 192    servers are reliability (network, host) and expedient contacts: in
 193    case of problems, changes/fixes must be carried out quickly.  It
 194    should be considered logical that primary servers for European top
 195    level domains should run on a host in Europe, preferably (if
 196    possible) in the country itself. For each top level domain there
 197    should be 2 secondary servers in Europe and 2 in the USA, but there
 198    may of course be more on either side.  An excessive number of
 199    nameservers is not a good idea though; a recommended maximum is 7
 200    nameservers.  In Europe, EUnet has offered to run secondary server
 201    for each European top level domain.
 202
 203 7. Wildcard MX records
 204
 205    Wildcard MX records should be avoided where possible. They often
 206    cause confusion and errors: especially beginning nameserver managers
 207    tend to overlook the fact that a host/domain listed with ANY type of
 208    record in a zone file is NOT covered by an overall wildcard MX record
 209    in that zone; this goes not only for simple domain/host names, but
 210    also for names that cover one or more domains. Take the following
 211    example in zone foo.bar:
 212
 213          *            MX 100  mailhost
 214          pqr          MX 100  mailhost
 215          abc.def      MX 100  mailhost
 216
 217    This makes pqr.foo.bar, def.foo.bar and abd.def.foo.bar valid
 218    domains, but the wildcard MX record covers NONE of them, nor anything
 219    below them.  To cover everything by MX records, the required entries
 220    are:
 221
 222
 223
 224
 225
 226 Beertema                                                        [Page 4]
 227 \f
 228 RFC 1537       Common DNS Data File Configuration Errors    October 1993
 229
 230
 231          *            MX 100  mailhost
 232          pqr          MX 100  mailhost
 233          *.pqr        MX 100  mailhost
 234          abc.def      MX 100  mailhost
 235          *.def        MX 100  mailhost
 236          *.abc.def    MX 100  mailhost
 237
 238    An overall wildcard MX record is almost never useful.
 239
 240    In particular the zone file of a top level domain should NEVER
 241    contain only an overall wildcard MX record (*.XX). The effect of such
 242    a wildcard MX record can be that mail is unnecessarily sent across
 243    possibly expensive links, only to fail at the destination or gateway
 244    that the record points to. Top level domain zone files should
 245    explicitly list at least all the officially registered primary
 246    subdomains.
 247
 248    Whereas overall wildcard MX records should be avoided, wildcard MX
 249    records are acceptable as an explicit part of subdomain entries,
 250    provided they are allowed under a given subdomain (to be determined
 251    by the naming authority for that domain).
 252
 253    Example:
 254
 255          foo.xx.      MX 100  gateway.xx.
 256                       MX 200  fallback.yy.
 257          *.foo.xx.    MX 100  gateway.xx.
 258                       MX 200  fallback.yy.
 259 8. Hostnames
 260
 261    People appear to sometimes look only at STD 11, RFC 822 to determine
 262    whether a particular hostname is correct or not. Hostnames should
 263    strictly conform to the syntax given in STD 13, RFC 1034 (page 11),
 264    with *addresses* in addition conforming to RFC 822. As an example
 265    take "c&w.blues" which is perfectly legal according to RFC 822, but
 266    which can have quite surprising effects on particular systems, e.g.,
 267    "telnet c&w.blues" on a Unix system.
 268
 269 9. HINFO records
 270
 271    There appears to be a common misunderstanding that one of the data
 272    fields (usually the second field) in HINFO records is optional. A
 273    recent scan of all reachable nameservers in only one country revealed
 274    some 300 incomplete HINFO records. Specifying two data fields in a
 275    HINFO record is mandatory (RFC 1033), but note that this does *not*
 276    mean that HINFO records themselves are mandatory.
 277
 278
 279
 280
 281
 282 Beertema                                                        [Page 5]
 283 \f
 284 RFC 1537       Common DNS Data File Configuration Errors    October 1993
 285
 286
 287 10. Safety measures and specialties
 288
 289    Nameservers and resolvers aren't flawless. Bogus queries should be
 290    kept from being forwarded to the root servers, since they'll only
 291    lead to unnecessary intercontinental traffic. Known bogus queries
 292    that can easily be dealt with locally are queries for 0 and broadcast
 293    addresses.  To catch such queries, every nameserver should run
 294    primary for the 0.in-addr.arpa and 255.in-addr.arpa zones; the zone
 295    files need only contain a SOA and an NS record.
 296
 297    Also each nameserver should run primary for 0.0.127.in-addr.arpa;
 298    that zone file should contain a SOA and NS record and an entry:
 299
 300          1    PTR     localhost.
 301
 302    There has been extensive discussion about whether or not to append
 303    the local domain to it. The conclusion was that "localhost." would be
 304    the best solution; reasons given were:
 305
 306    - "localhost" itself is used and expected to work on some systems.
 307
 308    - translating 127.0.0.1 into "localhost.my_domain" can cause some
 309      software to connect to itself using the loopback interface when
 310      it didn't want to.
 311
 312    Note that all domains that contain hosts should have a "localhost" A
 313    record in them.
 314
 315    People maintaining zone files with the Serial number given in dotted
 316    decimal notation (e.g., when SCCS is used to maintain the files)
 317    should beware of a bug in all BIND versions: if the serial number is
 318    in Release.Version (dotted decimal) notation, then it is virtually
 319    impossible to change to a higher release: because of the wrong way
 320    that notation is turned into an integer, it results in a serial
 321    number that is LOWER than that of the former release.
 322
 323    For this reason and because the Serial is an (unsigned) integer
 324    according to STD 13, RFC 1035, it is recommended not to use the
 325    dotted decimal notation. A recommended notation is to use the date
 326    (yyyymmdd), if necessary with an extra digit (yyyymmddn) if there is
 327    or can be more than one change per day in a zone file.
 328
 329    Very old versions of DNS resolver code have a bug that causes queries
 330    for A records with domain names like "192.16.184.3" to go out. This
 331    happens when users type in IP addresses and the resolver code does
 332    not catch this case before sending out a DNS query. This problem has
 333    been fixed in all resolver implementations known to us but if it
 334    still pops up it is very serious because all those queries will go to
 335
 336
 337
 338 Beertema                                                        [Page 6]
 339 \f
 340 RFC 1537       Common DNS Data File Configuration Errors    October 1993
 341
 342
 343    the root servers looking for top level domains like "3" etc. It is
 344    strongly recommended to install the latest (publicly) available BIND
 345    version plus all available patches to get rid of these and other
 346    problems.
 347
 348    Running secondary nameserver off another secondary nameserver is
 349    possible, but not recommended unless really necessary: there are
 350    known cases where it has led to problems like bogus TTL values. This
 351    can be caused by older or flawed implementations, but secondary
 352    nameservers in principle should always transfer their zones from the
 353    official primary nameserver.
 354
 355 11. Some general points
 356
 357    The Domain Name System and nameserver are purely technical tools, not
 358    meant in any way to exert control or impose politics. The function of
 359    a naming authority is that of a clearing house. Anyone registering a
 360    subdomain under a particular (top level) domain becomes naming
 361    authority and therewith the sole responsible for that subdomain.
 362    Requests to enter MX or NS records concerning such a subdomain
 363    therefore always MUST be honored by the registrar of the next higher
 364    domain.
 365
 366    Examples of practices that are not allowed are:
 367
 368       - imposing specific mail routing (MX records) when registering
 369         a subdomain.
 370
 371       - making registration of a subdomain dependent on to the use of
 372         certain networks or services.
 373
 374       - using TXT records as a means of (free) commercial advertising.
 375
 376    In the latter case a network service provider could decide to cut off
 377    a particular site until the offending TXT records have been removed
 378    from the site's zone file.
 379
 380    Of course there are obvious cases where a naming authority can refuse
 381    to register a particular subdomain and can require a proposed name to
 382    be changed in order to get it registered (think of DEC trying to
 383    register a domain IBM.XX).
 384
 385    There are also cases were one has to probe the authority of the
 386    person: sending in the application - not every systems manager should
 387    be able to register a domain name for a whole university.  The naming
 388    authority can impose certain extra rules as long as they don't
 389    violate or conflict with the rights and interest of the registrars of
 390    subdomains; a top level domain registrar may e.g., require that there
 391
 392
 393
 394 Beertema                                                        [Page 7]
 395 \f
 396 RFC 1537       Common DNS Data File Configuration Errors    October 1993
 397
 398
 399    be primary subdomain "ac" and "co" only and that subdomains be
 400    registered under those primary subdomains.
 401
 402    The naming authority can also interfere in exceptional cases like the
 403    one mentioned in point 4, e.g., by temporarily removing a domain's
 404    entry from the nameserver zone files; this of course should be done
 405    only with extreme care and only as a last resort.
 406
 407    When adding NS records for subdomains, top level domain nameserver
 408    managers should realize that the people setting up the nameserver for
 409    a subdomain often are rather inexperienced and can make mistakes that
 410    can easily lead to the subdomain becoming completely unreachable or
 411    that can cause unnecessary DNS traffic (see point 1). It is therefore
 412    highly recommended that, prior to entering such an NS record, the
 413    (top level) nameserver manager does a couple of sanity checks on the
 414    new nameserver (SOA record and timers OK?, MX records present where
 415    needed? No obvious errors made? Listed secondary servers
 416    operational?). Things that cannot be caught though by such checks
 417    are:
 418
 419       - resolvers set up to use external hosts as nameservers
 420
 421       - nameservers set up to use external hosts as forwarders
 422         without permission from those hosts.
 423
 424    Care should also be taken when registering 2-letter subdomains.
 425    Although this is allowed, an implication is that abbreviated
 426    addressing (see STD 11, RFC 822, paragraph 6.2.2) is not possible in
 427    and under that subdomain.  When requested to register such a domain,
 428    one should always notify the people of this consequence. As an
 429    example take the name "cs", which is commonly used for Computer
 430    Science departments: it is also the name of the top level domain for
 431    Czecho-Slovakia, so within the domain cs.foo.bar the user@host.cs is
 432    ambiguous in that in can denote both a user on the host
 433    host.cs.foo.bar and a user on the host "host" in Czecho-Slovakia.
 434    (This example does not take into account the recent political changes
 435    in the mentioned country).
 436
 437 References
 438
 439    [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
 440        RFC 1034, USC/Information Sciences Institute, November 1987.
 441
 442    [2] Mockapetris, P., "Domain Names Implementation and Specification",
 443        STD 13, RFC 1035, USC/Information Sciences Institute, November
 444        1987.
 445
 446
 447
 448
 449
 450 Beertema                                                        [Page 8]
 451 \f
 452 RFC 1537       Common DNS Data File Configuration Errors    October 1993
 453
 454
 455    [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
 456        974, CSNET CIC BBN, January 1986.
 457
 458    [4] Gavron, E., "A Security Problem and Proposed Correction With
 459        Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
 460        October 1993.
 461
 462    [5] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
 463        "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
 464        USC/Information Sciences Institute, USC, October 1993.
 465
 466 Security Considerations
 467
 468    Security issues are not discussed in this memo.
 469
 470 Author's Address
 471
 472    Piet Beertema
 473    CWI
 474    Kruislaan 413
 475    NL-1098 SJ Amsterdam
 476    The Netherlands
 477
 478    Phone: +31 20 592 4112
 479    FAX:   +31 20 592 4199
 480    EMail: Piet.Beertema@cwi.nl
 481
 482
 483 Editor's Address
 484
 485    Anant Kumar
 486    USC Information Sciences Institute
 487    4676 Admiralty Way
 488    Marina Del Rey CA 90292-6695
 489
 490    Phone:(310) 822-1511
 491    FAX:  (310) 823-6741
 492    EMail: anant@isi.edu
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506 Beertema                                                        [Page 9]
 507 \f