RFC 1537 (rfc1537) - Page 3 of 9

Common DNS Data File Configuration Errors

RFC 1537       Common DNS Data File Configuration Errors    October 1993


   Old BIND versions ("native" 4.8.3 and older versions) showed the
   problem that wrong glue records could enter secondary servers in a
   zone transfer.

3. "Secondary server surprise"

   I've seen it happen on various occasions that hosts got bombarded by
   nameserver requests without knowing why. On investigation it turned
   out then that such a host was supposed to (i.e., the information was
   in the root servers) run secondary for some domain (or reverse (in-
   addr.arpa)) domain, without that host's nameserver manager having
   been asked or even been told so!

   Newer BIND versions (4.9 and later) solved this problem.  At the same
   time though the fix has the disadvantage that it's far less easy to
   spot this problem.

   Practice has shown that most domain registrars accept registrations
   of nameservers without checking if primary (!) and secondary servers
   have been set up, informed, or even asked.  It should also be noted
   that a combination of long-lasting unreachability of primary
   nameservers, (therefore) expiration of zone information, plus static
   IP routing, can lead to massive network traffic that can fill up
   lines completely.

4. "MX records surprise"

   In a sense similar to point 3. Sometimes nameserver managers enter MX
   records in their zone files that point to external hosts, without
   first asking or even informing the systems managers of those external
   hosts.  This has to be fought out between the nameserver manager and
   the systems managers involved. Only as a last resort, if really
   nothing helps to get the offending records removed, can the systems
   manager turn to the naming authority of the domain above the
   offending domain to get the problem sorted out.

5. "Name extension surprise"

   Sometimes one encounters weird names, which appear to be an external
   name extended with a local domain. This is caused by forgetting to
   terminate a name with a dot: names in zone files that don't end with
   a dot are always expanded with the name of the current zone (the
   domain that the zone file stands for or the last $ORIGIN).

   Example: zone file for foo.xx:

   pqr          MX 100  relay.yy.
   xyz          MX 100  relay.yy           (no trailing dot!)



Beertema