• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 427
  • Last Modified:

Reverse DNS delegation from ATT

I already have this working, but I'm hoping someone can help me to understand why. One of the services my company provides to our clients is DNS hosting, including rDNS if they can get their IPs delegated to us.

In the past I've always set up our rDNS zones using a / instead of a - as I understood that was proper CIDR notation for classless subnets.

For example, if ATT delegated this block to us:  12.171.xxx.yyy/29
Then we would set up the zone on our DNS server like this: yyy/29.xxx.171.12.in-addr.arpa

For some reason this absolutely wouldn't work on the most recent delegation, so after banging my head on the wall for a while I replaced the slash with a dash and this started working:


We have dozens of other delegations from ATT that worked with the / so I have no idea why this one suddenly started needing a - instead.

If it matters, we're using SimpleDNS Plus 5.1.

Thanks for reading!
1 Solution
Did you do any packet captures or enable logging (if any) in SimpleDNS to see what was going on?

The way I'm reading the doc for SimpleDNS it implies that what you had should work and as you stated, you had this working before.

2 thoughts:
1. Are you absolutely certain that there wasn't a typo in the first one?
2. How exactly are you determining whether it works or not? Is the zone not loading? Is it possible that the client side is old and doesn't recognize the / formatting?
sfcandersonAuthor Commented:
1. I'm as certain as I can be that there weren't any typos. Another engineer created it first and I looked it over with him. We didn't see any problems, but we each deleted and recreated the zone three more times over a couple of days and confirmed we were entering it correctly.

2. We ended up testing with a LOT of different methods:

Dig and nslookup on our workstations.
mxtoolbox.com, simpledns.com, dnsstuff.com, and several other websites for testing externally.

Another thing that may or may not have been useful was that I tried creating a zone using only the single IP that we needed a PTR for. It ended up looking like this:


If I queried my nameservers directly for that IP then it would respond with the PTR, but if  we used the normal resolution methods going through root servers then it would not. This may have been by design as a DNS trace would show ATT handing off the CNAME yyy/29.xxx.171.12.in-addr.arpa to requests, but since we didn't have the full scope configured I think our DNS server was dropping them.
Like many things on the internet, DNS has had various 'official' standards and many interpretations of that standard.
While both of the options you have stated may have worked on some systems, the introduction of IPV6 & the new DNS standards (more TLDs, non-English characters etc) has necessitated some systems tightening up to meet more specific standards.

You may never find out why is stopped working, but you may also struggle to find anyone confirming it is should have worked in the first place, as it wasn't 'officially' accepted to use the slash in the first place I don't think.


sfcandersonAuthor Commented:
I'm going to go with "we'll never know why," but thanks for trying!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get 10% Off Your First Squarespace Website

Ready to showcase your work, publish content or promote your business online? With Squarespace’s award-winning templates and 24/7 customer service, getting started is simple. Head to Squarespace.com and use offer code ‘EXPERTS’ to get 10% off your first purchase.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now