Answered Mon, 10 Feb 1997 19:03:58 Reverse mapping with less than a full Class C, or Classless in-addr.arpa is your friend

>i m having problem in setting up a DNS for my sub-class C address given
>by my ISP. the address range is 203.127.125.129-254, with a netmask of
>255.255.255.128 and network address of 203.127.125.128. the ISP itself
>is the zone master for the 125.127.203.in-addr.arpa. zone
>
>my ISP told me to insert the statement
>"primary 128.125.127.203.in-addr.arpa named.rev" into my named.boot
>file. they also requested me to use this in the named.rev
>
>$ORIGIN 125.127.203.in-addr.arpa.
>128 SOA <RR info>
>
>   NS <DNS server>
>
>$ORIGIN 128.125.127.203.in-addr.arpa.
>129 PTR <host1>
>130 PTR <host2>
>
>etc...
>
>now, the problem is named under Linux works fine if i m given the entire
>125.127.203.in-addr.arpa zone. but once i start adding in a subnet, the
>named will load but nslookup will always hang and time out with an
>error.
>
>my ISP insist that the example they gave is correct and coulnd help me
>as they claim they dont support Linux. can u offer any help?

The problem you have is becoming more common as ISPs give out sub-Class C chunks of IP address space. Until very recently, only four levels of the in-addr.arpa portion of the name space were used--one level per octet of an IP address. Although it's not possible to delegate narrower than the fourth (least significant) octet, some clever folks have found a way around the problem and published an Internet-Draft:

[Ed. This is now at BCP at http://www.ietf.org/rfc/rfc2317.txt ]

The summary of it is this: the owner of the Class C (in this case, your ISP) inserts CNAME records instead of PTR records. These CNAME records point to PTR records in a zone that you manage. Your ISP might be doing this, but Mr. DNS can't tell what they're doing--he can't find any DNS information for the Class C 203.127.125.0 in your ISP's name servers.

If what your ISP has told you is correct, they have records like these at their level:

129.125.127.203.in-addr.arpa. IN CNAME 129.128.125.127.203.in-addr.arpa.
130.125.127.203.in-addr.arpa. IN CNAME 130.128.125.127.203.in-addr.arpa.
(etc)

These records point to the PTR records that they asked you to put in your name server:

129.128.125.127.203.in-addr.arpa. IN PTR <host1>
130.128.125.127.203.in-addr.arpa. IN PTR <host2>
(etc)

Of course, these pairs of records (one in your ISP's zone, one in your zone) are repeated for every host in your address range.

If your ISP is implementing "Classless in-addr.arpa", they're not following the nomenclature suggested in the Internet-Draft referenced above. Your ISP's method is more confusing to read, Mr. DNS thinks.

Mr. DNS recommends you check out the draft and ask your ISP if they're following it.

As far as your Linux name server problems, it's hard to troubleshoot without more information. Have you checked /var/log/messages for any errors from named? Does "nslookup -q=ptr 129.128.125.127.203.in-addr.arpa." return host1? Just doing "nslookup 203.127.125.129" is going to send your name server on a hunt for the PTR record for 129.125.127.203.in-addr.arpa., which is a CNAME in your ISP's name server. If your ISP hasn't set everything up correctly, you'll have problems. nslookup shouldn't just hang. Is it timing out?

Regards,
Mr. DNS