1 Answer
- Newest
- Most votes
- Most comments
1
You can still just create a rule for 10.0.0.0/8 and forward to on prem still. You only need the one rule for 10.in-addr.arpa which will cover any PTR zone in the /8.
Your on prem DNS Servers will still correctly respond..
Would that be an issue for you?
Relevant content
- Accepted Answer
asked 2 years ago 
AWS OFFICIALUpdated 2 years ago- AWS OFFICIALUpdated 3 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
Hi Gary, that would would for On-Prem servers. For Reverse DNS INSIDE AWS I would need 16 PHZ then, correct? 1) 200.10.in-addr.arpa., 2) 201.10.in-addr.arpa., 3) 202.10.in-addr.arpa. etc. That would be Option A of my description. Is this best practice? Then for each A record in AWS I would need to find the right PHZ to implement the PTR record.
Im pretty sure a single rule would work.. In route 53 create a rule just for 10.in-addr.arpa and forward to on prem
You mean to say best practice would be Option A of my initial description? That means: 1 FORWARD Rule to On-Prem, AND 16 Private Hosted Zones to allow Reverse DNS inside AWS environment (10.200.0.0/12).
Im saying 1 rule and 1 PHZ for 10.in-addr.arpa You dont need to have a different PHZ for every subnet your creating. You have all your PTR records in the one 10.in-addr.arpa as its a CLASS A
Hi Gary, You are describing OPTION B of my initial post then. Indeed this is the way we have implemented the setup right now. Challenge with OPTION B is that we need to have 240 * FORWARD rules due to our setup. Context: You can only delegate on octet borders. Having a /12 for our AWS environment means we need to implement a FORWARD rule for all /16 in the 10. range (=240* /16), except for our /12 (=16* /16). Thanks for sharing your view!