classless in-addr.arpa delegation

[Kevin Darcy]

rhalper at my-deja.com wrote:

> Hello,
>   I appreciate the help supplied to me by those who responded to my last
> post.  Your assistance helped me greatly, though I'm still trying to
> track down my reverse lookup problems.  My problems are complicated by
> the ridiculouos DNS setup of my upstream provider.  The provider who is
> delegating a range of IP addresses to me (209.97.92.96-127 &
> 209.97.93.1-31) has their primary server (ns1.eliasconsulting.com)
> running on an NT box with BIND 4.  The secondary nameserver
> (ns2.eliasconsulting.com) is a running FreeBSD & BIND 8.  Here's where
> it gets wierd.  Because it's a pain to edit files on the NT box, the
> secondary nameserver (ns2) is replicating to the primary nameserver
> (ns1).  I have determined that the delegation is setup properly on the
> secondary nameserver using classless in-addr.arpa delegation.  However,
> I'm not sure if it the delegation is setup properly on the NT box
> running NT 4.  I have a couple questions about the setup in the
> named.boot file.
>
> secondary 92.97.209.in-addr.arpa 209.97.92.3 db.209.97.92
> secondary 96-126.92.97.209.in-addr.arpa 209.227.44.2 db.209.97.92.96-126
> secondary 93.97.209.in-addr.arpa 209.227.92.3 db.209.97.93
> secondary 1-30.93.97.209.in-addr.arpa 209.227.44.2 db.209.97.93.1-30
>
> As you can see the 209.227.44.2 is my master nameserver & 209.97.92.3 is
> my upstream provider's secondary namserver (for all intents and purposes
> the primary since it is replicating to the master.)  Does BIND 4 support
> the classless in-addr.arpa delegation?  Considering the bizarre setup of
> my upstream provider should I have primary listed in the named.boot file
> for the delegation areas instead of secondary (see above).  This would
> certainly be easier if my upstream provider had a more intuitive setup.
>
> Thanks in advance for your help.

A number of problems observed here:

1) The only servers which are answering authoritatively for the
92.97.209.in-addr.arpa zone are the IngressNet servers in the delegation
records. But the NS records reported by the delegated servers are not a
superset of the delegation records. They report only 1 NS record --
ns1.eliasconsulting.com.
2) ns1.eliasconsulting.com is lame for the zone, and appears to have no
knowledge of its contents other than what it can learn from IngressNet.
3) ns2.eliasconsulting.com (another nameserver you mentioned) also answers
non-authoritatively, and may or may not have independent knowledge of the
zone: it's hard to tell since the TTLs in the answer and authority sections
of its responses seem to always be 0 (???)

I'd recommend getting the existing /24 zone and/or its servers and/or
delegations fixed up before attempting classless delegations from it.


- Kevin