Reverse DNS issue.

[Barry Margolin]

In article <9oe4t8$5bd at pub3.rc.vix.com>,
Ed Bravo <crypog*takethis*@yahoo.com> wrote:
>Hi there....
>I have a REVERSE DNS problem and I'm lost...
>
>Situation:
>I have been assigned the following subnetwork from a COMPANY X :
>
>209.189.109.128/26
>
>We've setup the reverse DNS but is not working properly.
>If we query COMPANY X DNS server, it resolves fine, but if we query any
>other server it doesn' resolve.
>
>The funny thing is that COMPANY X has been assigned from ISP Y, the whole
>class C that they later leased to us a /26.
>
>The part that COMPANY X is managing reverse dns, resolves fine, even on the
>"world" BUT the segment they assigned me doesn't unless I query their
>server....
>
>Where could be the problem ?

The problem is that you seem to be trying to use the technique in RFC 2317,
but it's not applicable in your case.

The problem starts with the fact that Verio (ISP Y) doesn't own all of
209.189.0.0/16, they just own 209.189.0.0/17.  This means that the
189.209.in-addr.arpa zone can't be delegated to their servers.  Instead,
there are 128 class C reverse domains delegated to them from ARIN; this
includes the 109.189.209.in-addr.arpa reverse domain.

Since you can't redelegate a whole domain, they couldn't simply point this
whole class C to bhwy.net's servers.  So instead, Verio created NS records
for each IP address in this class C:

0.109.189.209.in-addr.arpa.  4H IN NS  underdog.bhwy.net.
0.109.189.209.in-addr.arpa.  4H IN NS  chillywilly.bhwy.net.
1.109.189.209.in-addr.arpa.  4H IN NS  underdog.bhwy.net.
1.109.189.209.in-addr.arpa.  4H IN NS  chillywilly.bhwy.net.
and so on.

This means that bhwy.net should have a separate zone for each IP address.
But instead, they put it all in a single reverse zone.  Then they tried
doing RFC 2317 delegation from this zone.

Here's why this doesn't work.  When a client wants to look up
129.109.189.209.in-addr.arpa, it starts by asking a root server.  The root
server will refer it to an ARIN server for the 209.in-addr.arpa zone.  This
ARIN server will refer it to a Verio server; it will send back the
following referral:

129.109.189.209.in-addr.arpa.  4H IN NS  underdog.bhwy.net.
129.109.189.209.in-addr.arpa.  4H IN NS  chillywilly.bhwy.net.

The client will then ask one of these servers for the PTR record, and it
will send back:

129.109.189.209.in-addr.arpa.  1h50m IN CNAME  129.128/26.109.189.209.in-addr.arpa.

Now the client has to start all over, trying to look up
129.128/26.109.189.209.in-addr.arpa.  It already has the NS record for
109.189.209.in-addr.arpa in its cache, pointing to the Verio servers.  So
it asks that server for this PTR record.  The problem is that the Verio
servers don't know about the 128/26.109.189.209.in-addr.arpa subdomain, so
they reply that the record doesn't exist.

There are three solutions that I can think of:

1) bhwy.net could ask Verio to install RFC 2317 reverse delegation of your
   address block onto their servers, instead of going through the bhwy.net
   servers.

2) You can configure your server as the master for 64 zones,
   128.109.189.209.in-addr.arpa through 191.109.189.209.in-addr.arpa, and
   bhwy.net can configure their servers as slaves for these zones.  They
   also need to remove the bogus 109.189.209.in-addr.arpa zone from their
   servers, and make themselves master or slave for the other 192
   x.109.189.209.in-addr.arpa zones.

3) Instead of delegating each IP address from the Verio servers to the
   bhwy.net servers, Verio could configure their servers as slaves for the
   109.189.209.in-addr.arpa zone.

Solution 3 is probably the simplest.  It's the technique we use when we
need to redelegate a /24 and the /16 isn't all delegated to us.

-- 
Barry Margolin, barmar at genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.