REVERSE DNS Practices.

Sat Mar 21 15:15:50 UTC 2009

On Sat, Mar 21, 2009 at 8:00 AM, <bmanning at vacation.karoshi.com> wrote:

>     the 20th or 21st century answer?

>     if you really don't care about the actual node, then you should map
the
>     numbers to topologically significant names - after all, the reverse
map
>     follows topology, not some goofball - layer 9 - ego trip thing.

>>> For routing / backbone devices/interfaces/loopbacks, absolutely. <<<

There are security implications [sort of] with being verbose about
infrastructure naming, but obscurity in DNS never stopped a crawler from
walking the ipv4 space looking for vulnerabilities...

I'm going to guess tho that your question pertains to user ips.

>>> For end-user (dsl/dial/cable/eyeball) ips on a small or large scale,
simpler is better. <<<

There's no need to put "-slip" or 'ppp' or isdn or dial or poolXXX or city
names in an in-addr.
Nobody needs to know, nobody will probably care, and eventually, it'll
change somehow.

There is a quite elegant, database-friendly, probably-easy-to-generate/code
sans textfiles method - a  rather clever nomenclature for its insanely
ginormous [yes, thats the technical term] user ip pools.  AOL uses it in
their user pools.

    * each octet is converted to a to byte hex value, and concatenated.
example: 172.137.220.58 = AC89DC3A.ipt.aol.com.
      o It's short, simple, and not geographically tying or revealing (your
noc should know where your dial blocks sit) ;) etc etc.
      o Being hex, It's also not language-specific ..
      o Win factor?  With a different SLD or subdomain (e.g. /ipt/.aol.com)
, queries can be offloaded to less critical nameservers

The problem eventually, as bill hints to, is that hostnames (esp. in-addr)
*will* change.  A certain phone co out here (cant tell you their name, but
their initials are sbc) is annoyingly famous for this.
Tens of thousands of in-addrs resolve to hostnames with locations in other
states, other time zones, because, pools get shuffled around.. and really,
nobody likes to sit and manage DNS all day.  Even noc monkies.

Using the hex method solves this.

>      or - the more modern approach is to let the node (w/ proper
authorization) do a secure dynamic update of the revserse map - so the
forward and reverse delegations match. ... a -VERY- useful technique.

Lots of administration in this one, too, tho..  keys, manual definitions ..
i suppose it could be automated, but you still have client configs,
interoperability issues, and worst case / improperly configured dns update
controls, namespace collisions.

A lot of this of course is about context.
What are the IPs purposed to?  Infrastructure? Users?
Everyone's mileage will vary, but, I've yet to come across any serious
issues with dotted quads to hex...

-jamie

    On Sat, Mar 21, 2009 at 01:38:55PM +0300, bruce at yoafrica.com wrote:
    > Slighty related...
    >
    > Can people please post their recommended reverse dns naming
conventions for a small ISP with growth and scalability in mind.
    > I already have one drawn up, but I would like to contrast and compare
:D
    >
    > Thanks
    >
    > On 21 Mar 2009 10:32:30 -0000, John Levine <johnl at iecc.com> wrote:
    > >> I want to ask some folks out there that maintain reverse DNS
queries
    > >>of their respective IP blocks. I want to know if there is a need for
    > >>me to contact my upstream provider. I am in charge of 2 /24's under
    > >>LACNIC. I've already registered my DNS servers on LACNIC. but for
some
    > >>weird reason it's not owning reverse resolves. any tips would be
    > >>gladly appreciated.
    > >
    > > The RIRs don't maintain rDNS for you.  You'll have to trace the
    > > delegations downward from in-addr.arpa, find out who's handling your
    > > /24's, and contact them to get them to delegate your chunks to you.
    > >
    > > R's,
    > > John
    >

-- 
Jamie Rishaw // .com.arpa at j <- reverse it. ish.
[Impressive C-level Title Here], arpa / arpa labs