On Sat, Mar 21, 2009 at 8:00 AM, <bmanning@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@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@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@j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs