[Maintain] How to do reverse dns

[Brandon Philips]

Greg,

I finally got around to reading the RFC.  All I can say is yes it would
be possible to setup such a scheme with Maintain and I could help you
get it working, but there are no plans to develop the feature.


-Brandon

On 11:13 Mon 11 Apr     , Greg Connor wrote:
> 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
> 

-- 
Brandon Philips
brandon at osuosl.org
"Open minds. Open doors. Open source." - osuosl.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osuosl.org/pipermail/maintain/attachments/20050425/d98c099d/attachment.pgp