DNS/RFC/1713 - moin.dnsq.info

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

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!