/24 in-addr.arpa Delegation Problem

[Jim Reid]

>>>>> "Ethan" == Ethan Banks <ebanks at vitts.com> writes:

    Ethan> I've delegated 49.64.216.in-addr.arpa. to
    Ethan> oldman.state.nh.us and whitemtns.state.nh.us by putting NS
    Ethan> records in the zone file living on ns1.vitts.com and
    Ethan> ns2.vitts.com.

Maybe, but it looks as though you've left zone{} statements for this
zone on your name servers. If that's the case, you've not done the
delegation correctly.

    Ethan> If I nslookup against either oldman or
    Ethan> whitemtns, I get answers for PTR queries in this domain.
    Ethan> However, if I attempt a reverse lookup from anywhere else,
    Ethan> the query fails.

Correct. The name servers for the parent zone, .arpa, say that
ns1.vitts.net and ns2.vitts.net are the name servers for
49.64.216.in-addr.arpa. This means that you've not delegated the zone
properly. You'll need to get ARIN to fix the NS records for this zone
so that they point at whitemtns.state.nh.us and oldman.state.nh.us
instead of your name servers. Your servers are telling lies about
49.64.216.in-addr.arpa. Well, they give different answers for zone
from the servers you've supposedly delegated the zone to.

    Ethan> What's broken?  My delegation, the authoritative name
    Ethan> servers, or something in the middle?  Here's my zone file
    Ethan> for 49.64.216.in-addr.arpa:

What are you doing with zone files for 49.64.216.in-addr.arpa if
you've delegated this zone? Once it's delegated, you have no control
over the zone's contents and you should not be filling your name
servers with data for this zone from a local zone file that you
maintain.

Your name servers still have old copies of this zone and they are
providing authoritative but wrong answers for it. So when you do a
reverse lookup of 216.64.49.4 to one of your name servers, it replies
with an NXDOMAIN error and supplies your version of the SOA record for
this zone in the Authority Section of the reply. But if someone uses
another name server, they might follow the NS records in your bogus
"delegation" and reach the real name servers for this zone where they
can get the correct answer instead of the lies from your name
servers. In fact ns[12].vitts.com are giving authoritative answers for
49.64.216.in-addr.arpa's SOA record. But this SOA record is not the
same as the one on the real name servers for this zone. So your
servers appear to be falsely claiming ownership of the zone that
you've "delegated".

BTW, you might like to tell whoever you delegated the
49.64.216.in-addr.arpa zone to that they've screwed up the zone's SOA
record. The MNAME and RNAME fields are bust. Not that this matters for
the problem you describe.