I'm setting up a PTR zone in Route 53 and I'm running into issues with the naming conventions. Previously, we've used Bind9, and our PTR zone for our 64 IPs was named 0/26.X.X.50.in-addr.arpa. I tried creating this same zone name in Route 53, but I'm getting an error saying the record can't be found, likely because of the slash ("/"). After some experimenting, I created a zone called 0-26.X.X.50.in-addr.arpa, which seemed to work for testing the records. However, after my ISP added the new AWS nameservers to their delegation list and I turned off Bind9 for testing, reverse lookups aren't functioning. It appears turning Bind9 back on resolves the lookups again. So, I'm trying to figure out the right naming convention for a /26 zone. Since each setup gives a different group of nameservers, I can't constantly switch back without opening a support ticket to change them again.
4 Answers
You mentioned creating another zone using a dash, which aligns with RFC 4183. That's a good move since the slash ('/') isn’t accepted universally in DNS servers. Route 53 states they support slashes, but since you're having problems, the dash might be your safer bet. You could also format it as subnet0.X.X.50.in-addr.arpa if everyone involved agrees on it.
Can you share your named.conf snippet? It might help to see how you've configured your old nameservers versus the new Route 53 settings.
Make sure the delegation was set up correctly by your provider. If you're still querying your old nameservers, that could be a sign the transition wasn't fully completed. Double check with Comcast about the changes and ensure the TTL expired before shutting down the old nameservers to avoid issues. Also, check out AWS's documentation on reusable delegation sets for a smoother process.
Did you bring your own IP range into AWS? If not, that could be affecting your setup since Comcast still controls your IP block and forwards lookups. Though it sounds like your Bind9 setup works fine with this configuration, the AWS nameservers may not be fully resolving yet as Comcast may not have set them up correctly.
No, they haven't done that yet. They've added the nameservers to the delegation but I'm still having trouble actually getting things to resolve properly.
That’s a good point. I suspect there could be an issue with how Comcast handled the delegation. I’ll follow up with them but wanted to confirm my zone naming internally first.