[Maintain] How to do reverse dns

Greg Connor gconnor at sgi.com
Mon Apr 11 11:13:16 PDT 2005


On Mon, 11 Apr 2005, Brandon Philips wrote:

> Greg,
>
> Sorry for the long delay, I started writing the email last week, but
> forgot to send.


Thanks for the reply.  Here's a quick followup...

> > I haven't seen a good explanation of how to set up in-addr.arpa zones.  Do I
> > just create the appropriate in-addr.arpas, and then when hosts get defined,
> > they will automatically associate themselves with the right reverse zones?

> For hosts the in-addr.arpas should not be necessary, tinydns
> automagically creates the reverse pointer record.
>
> http://tinyurl.com/3td8a


OK, sounds good.  I found out that the PTR records were being automatically
generated, but I created the in-addr.arpa domains in the Domain: Create
section because I wanted them to have SOA records as well.  (SOAs are needed
in order to transfer the zones to a BIND server.)


> > Speaking of reverses, does maintain support CNAME-type reverses, like you
> > would use to split up reverse dns into chunks that are not /16 or /24?
> >
> > How would I tell Maintain that the data should be placed into
> > d.0.c.b.a.in-addr.arpa instead of the standard
> > d.c.b.a.in-addr.arpa?
>
> I am familiar with this type of setup.  Could you explain it a bit more?
> Or maybe point me to a website that shows a use case?
>

Here's some more information on the "classless
in-addr.arpa scheme".  (It is described in
more detail here: <http://www.ietf.org/rfc/rfc2317.txt>)

More clarification on my previous example.  Let's say someone else (like SBC)
owns the full class C or class B.  They would maintain the records for
c.b.a.in-addr.arpa, and they will need to serve multiple clients out of that
range (anyone on a.b.c.* IP range).  Their records look like this.

# Create sub-zone called "216/28" and delegate it to customer (216-231)
$ORIGIN 172.225.69.in-addr.arpa.
> 216/28  IN   NS      ns2.nekodojo.org.
> 216/28  IN   NS      ns1.nekodojo.org.

# Create CNAMES to point 216-231 to the customer's slice
$ORIGIN 172.225.69.in-addr.arpa.
> 216     IN   CNAME   216.216/28
> 217     IN   CNAME   217.216/28
> 218     IN   CNAME   218.216/28
...
> 231     IN   CNAME   231.216/28


Therefore, my in-addr-arpa zone which would normally be:
      c.b.a.in-addr.arpa
now needs to be relocated to:
  x/y.c.b.a.in-addr.arpa

And, all PTR records that I produce would change from something like this:
         218.172.225.69.in-addr.arpa. 21600 IN PTR   neko-base.nekodojo.org.
to something like this:
  218.216/28.172.225.69.in-addr.arpa. 21600 IN PTR   neko-base.nekodojo.org.

(In my home network which I rent from SBC, they used "216" as the name of the
sub-zone, not 216/28, but I changed the example to use 216/28 to match the
example in the RFC/BCP document.)

In a perfect world, we would all own class C /24 networks (or /16's :) but
in today's world there are some vendor/client relationships that still need to
use the CNAME/NS trick.  This would mean the clients would need to relocate
their PTR records.  (The RFC also mentions that you can CNAME the PTR records
into "in-addr.mydomain.com" instead of a subtree of "in-addr.arpa" - but I
think the creation/delegation of a small slice of in-addr.arpa is probably
more common)

What this means for maintain?  Probably it means tweaking things so that hosts
in subnet a.b.c.d/m would generate their PTR records in some other zone, where
"d.c.b.a.in-addr.arpa" is probably hard-coded right now.  So, that would be
another field for each subnet, or perhaps each block, to alter behavior to
make it different from the default.  Or, it could also be accomplished with a
script that searches for records like d.c.b.a.in-addr.arpa and changes them
into d.x/m.c.b.a.in-addr.arpa (perl or even sed could probably do this).

Personally I don't think I have an immediate need for this... there are a lot
of these type of arrangements inside our company, but our maintain rollout
shouldn't be affected by them at first.  In the longer term, I want maintain
to take over the whole shooting match, and not just have little bits and
pieces delegated to it.  So, it's not a high priority for me... I just mostly
wanted to know if it's been thought about or if there are plans to add this to
the current in-addr.arpa support...

--
Greg Connor <gconnor at sgi.com>
Netops Services Group



More information about the Maintain mailing list