Lame server error

Roy Arends Roy.Arends at nominum.com
Tue Mar 27 14:29:08 UTC 2001


On Tue, 27 Mar 2001, Julian W H Osborne wrote:

> Hi All,
> 
> Our ISP has set up their DNS to forward requests for our allocated block
> of IP address so we can control reverse lookup.
> 
> The Block is 195.102.186.160/27
> 
> If a reverse lookup is tried the following error message occurs:
> 
> Mar 27 13:00:21 buckk named[32449]: Lame server on
> '165.186.102.195.in-addr.arpa' (in '165.186.102.195.IN-ADDR.ARPA'?):
> [195.102.186.163].53 'ns2.imsgrp.net'
> 
> The following is my setup:
> 
> named.conf
> 
> zone "160-191.186.102.195.in-addr.arpa" {
>         type master;
>         file "db.160-191.186.102.195.in-addr.arpa";
> };
> 
> db.160-191.186.102.195.in-addr.arpa
> 
> @       IN      SOA ns2.imsgrp.net. hostmaster.imsmaxims.com.
> 
>         (
>                 2000080901
>                 10800
>                 3600
>                 604800
>                 86400
>         )
> 
> @       IN      NS      ns2.imsgrp.net.
> @       IN      NS      ns.imsgrp.net.
> 
> 163     IN      PTR     mx0.uk.imsgrp.net.
> 174     IN      PTR     workstations.uk.imsgrp.net.
> 
> 
> If anyone can help I'd appreciate it.

The problem is that the ns0.u-net.net and ns1.u-net.net servers
(authoritative for 186.102.195.in-addr.arpa.) tell resolvers that for
anything in the 161-191 range, the ns2.imsgrp.net. is authoritative. They
define the whole 161-191 as zone delegations (NS records). You can see
that here:

At ns[01].u-net.net. the delegations for the 182.102.195.in-addr.arpa.
lists:

$ORIGIN 186.102.195.in-addr.arpa.

161                     1D IN NS        ns2.imsgrp.net.
162                     1D IN NS        ns2.imsgrp.net.
...
190                     1D IN NS        ns2.imsgrp.net.
191                     1D IN NS        ns2.imsgrp.net.

Resolvers will ask ns2.imsgrp.net. for an answer to the query
"165.186.102.195.in-addr.arpa.". The ns2.imsgrp.net machine doesn't have a
clue what the question is about. They are not authoritative for the zone
"165.186.102.195.in-addr.arpa." They are responsible for the zone
"160-191.186.102.195.in-addr.arpa." which is in theory totally something
else, and therefore a lame-delegation.

The way this should be fixed:

Tell the ns[01].u-net.net. to change their records in the zone
"186.102.195.in-addr.arpa." (specified above, starting with $origin) to
the following:

160         1D IN CNAME 160.160-191
161         1D IN CNAME 161.160-191
...               
190         1D IN CNAME 190.160-191
191         1D IN CNAME 191.160-191

160-191  1D IN NS ns2.imsgrp.net.
160-191  1D IN NS ns.imsgrp.net.

Now you should be fine.

Note: for readability and understanding, it might be better to use 160/27
instead of 160-191.

This is standardised in RFC 2317: Classless IN-ADDR.ARPA delegation.

Regards,

Roy Arends
Nominum

PS. Comments on this scheme are greatly appreciated, since this is not
    straightforward. 



More information about the bind-users mailing list