Craig Sanders wrote:
BTW, note that the smallest net block that a .in-addr.arpa domain
can be delegated for is a /24.
if he has less than a /24 then there are ugly tricks that can be done
with CNAMEs, but they are complicated and a PITA and easy to screw up,
so he's extremely unlikely to ever get his upstream to bother. really,
it just isn't going to happen. he may, however, be able to get his
upstream to accept a regular text file listing his PTR records which
they can use to update the zonefile on their NS. i wouldn't hold my
breath waiting for this.
if he has more than a /24 or multiple /24s then he needs multiple
.in-addr.arpa domains delegated to his NS - one for each /24.
there's no way he'll have a /16 or a /8, which are the next sizes up
that can be delegated in one go. it goes like this:
x.in-addr.arpa /8 e.g. 192.in-addr.arpa
whoever owns that can delegate .in-addr.arpa
domains for the /16s & /24s within it.
x.x.in-addr.arpa /16 e.g. 168.192.in-addr.arpa
whoever owns that can delegate .in-addr.arpa
domains for the /24s within it.
x.x.x.in-addr.arpa /24 e.g. 0.168.192.in-addr.arpa
Craig's information is correct, but the "ugly tricks" comment isn't fair. Those "ugly tricks" aren't that bad, and they've been WELL documented since 1998 in RFC 2317!
Any DNS admin who hasn't read and implemented that RFC before, shouldn't be working at an ISP DNS admin level.
Any upstream who can't do it, should be avoided.Problem is, as Craig mentions, upstreams are ULTRA lazy and typically DNS gets delegated (no pun intented) to junior folks who hate it as much as the last guy who's now senior... and instead of learning the best practices and KNOWING how what they do for a living actually WORKS, they ignore customers.
I think the only job worse than DNS admin (in the heads of many router jocks) is getting SWIP information correct. But they KNOW they have to do that, or they can't play with their IP's.
"DNS? That's the application/server people's job, not infrastructure!", they complain.
Once you know RFC 2317 by heart, it's so easy to do it's not an issue at all. If you want pretty graphics, you'll have problems, but that's a personal problem.
ISP's and upstreams need to grow up and learn to manage reverse DNS properly. Especially for something that's been documented and works since 1998.
(There are days where I miss being an ISP "DNS guy" so I can rant at a peer level with the idiots who won't read and understand this RFC document at *my* upstreams. They sucked back then too. As a customer, Craig's right -- you often get nowhere when you call. Threatening to switch upstreams helps, but is a sad, stupid tactic that too-often has to be employed because the ISP and their upstream can't get their shit together on reverse DNS.)
DNS is easy. Too many people make it out like it's rocket science. I used to get a chuckle out of customers doing multi-month planning for moving servers from one site to another and then realizing (far too late, after how many meetings about EVERYTHING else related to the move EXCEPT talking to the DNS guy...) that they forgot to lower their DNS TTL and that after the move, it was likely that nothing was going to resolve to the new IP's out on the Internet for weeks.
You don't have working DNS, you don't have squat. That's how the Internet goes... reverse DNS isn't as bad, but it's still broken behavior to ignore it, whether you're the local ISP, the "upstream", the "backbone" -- whoever.
I'm always amazed at how often DNS is treated as an afterthought by the large service providers and not managed well.
Nate