DNS/RFC/1713について、ここに記述してください。

https://tools.ietf.org/rfc/rfc1713.txt

2.3. Lamers

A lame delegation is a serious error in DNS configurations, yet a
   (too) common one.  It happens when a name server is listed in the NS
   records for some domain and in fact it is not a server for that
   domain.  Queries are thus sent to the wrong servers, who don't know
   nothing (at least not as expected) about the queried domain.
   Furthermore, sometimes these hosts (if they exist!) don't even run
   name servers.  As a result, queries are timed out and resent, only to
   fail, thus creating (more) unnecessary traffic.

It's easy to create a lame delegation: the most common case happens
   when an administrator changes the NS list for his domain, dropping
   one or more servers from that list, without informing his parent
   domain administration, who delegated him authority over the domain.
   From now on the parent name server announces one or more servers for
   the domain, which will receive queries for something they don't know
   about.  (On the other hand, servers may be added to the list without
   the parent's servers knowing, thus hiding valuable information from
   them - this is not a lame delegation, but shouldn't happen either.)
   Other examples are the inclusion of a name in an NS list without
   telling the administrator of that host, or when a server suddenly
   stops providing name service for a domain.

To detect and warn DNS administrators all over the world about this
   kind of problem, Bryan Beecher from University of Michigan wrote
   lamers, a program to analyze named (the well-known BIND name server)
   logging information [2].  To produce useful logs, named was applied a
   patch to detect and log lame delegations (this patch was originally
   written by Don Lewis from Silicon Systems and is now part of the
   latest release of BIND thanks to Bryan Beecher, so it is expected to
   be widely available in the near future).  Lamers is a small shell
   script that simply scans these logs and reports the lame delegations
   found.  This reporting is done by sending mail to the hostmasters of
   the affected domains, as stated in the SOA record for each of them.
   If this is not possible, the message is sent to the affected name
   servers' postmasters instead.  Manual processing is needed in case of
   bounces, caused by careless setup of those records or invalid
   postmaster addresses.  A report of the errors found by the U-M
   servers is also posted twice a month on the USENET newsgroup
   comp.protocols.tcp-ip.domains.

If you ever receive such a report, you should study it carefully in
   order to find and correct problems in your domain, or see if your
   servers are being affected by the spreading of erroneous information.
   Better yet, lamers could be run on your servers to detect more lame
   delegations (U-M can't see them all!).  Also, if you receive mail
   reporting a lame delegation affecting your domain or some of your
   hosts, please don't just ignore it or flame the senders.  They're
   really trying to help!

You can get lamers from ftp://terminator.cc.umich.edu/dns/lame-delegations.