DNS Resolution in AWS — Route 53 Resolver vs Private Hosted Zones
In most AWS deployments it is common to encounter a scenario where you may need name resolution across VPCs or between on-prem and VPCs.
This article highlights the nuances of using a few patterns for certain use cases.
Before we begin, in case you are not familiar, any DNS query from any of the instances within a VPC would go via the +2 address in that VPC subnet. For example if the subnet range was 10.2.0.0/24 then the DNS queries will go via 10.2.0.2 by default.
There is a DHCPOptionSet setting available which can change this behaviour to route queries to a different DNS server. This overrides the default behaviour.
The way a query flows is important. Each VPC has a default Route 53 resolver. So all your queries to resolve addresses for Private Hosted Zones or Public Hosted Zones are routed via the default resolver. You can alter the flow for any domain query by adding rules to the resolver.
In the above config you will also need to add Outbound Endpoints as the resolver actually creates an endpoint inside the subnet. It is visible in the Outbound Endpoint dropdown once you create it.
Hope all of the above makes sense.
With all the above ammunition lets look at the scenarios you may need to tackle.
1. Resolve Private and Public Hosted Zones in AWS.
By default you need not do anything. The Resolver by default will route queries to the hosted zones for resolution.
You can see the default resolver record in your Route 53 Resolver
2. Resolve on prem or other AD hosted domains in your VPC
a. Use of DHCPOptionSet
If you wanted to just use an AD or other DNS server you could create a DHCP Option set and set the DNS ips in there. There is a downside to this approach. It bypasses the Resolver which means it cannot resolve hosted zones, especially private hosted zones without additional external config. It will only be able to resolve what the AD or your DNS server resolves.
b. Use of Route 53 Resolver
This option lets you create rules to use different DNS servers for specific domains without affecting your local private zone domain resolution. Also it is a very clean solution and works really well. The only issue is it is actually expensive. I am not entirely sure why it is so expensive considering it only amounts to a rule and couple of ENIs in your subnet.
3. Share resources from one VPC to another.
Now lets say you have multiple VPCs and a shared VPC which hosts all your common resources which are accessed your other accounts. There may also be services in one app domain which is required by another for example.
There are various ways you could solve it. For example you could create a VPC Endpoint for this and go via the VPCE. But that could get very complicated and in some cases may not be feasible at all.
Lets say you have test.app.internal, dev.app.internal and shared.app.internal. Both the dev and test need the Jenkins servers running in shared.app.internal. There is a way you could create a PHZ in the shared.app.internal and share it with dev and test.
What this will do is from the dev VPC you will be able to easily resolve say jenkins.shared.app.internal which points to the Jenkins server.
With the above setup you will be able to resolve jenkins.shared.app.internal in the dev and test VPC accounts to 10.0.0.25. Remember you will still need peering between networks and routes set correctly.
Here is how you share Private Hosted Zone across VPCs.
https://aws.amazon.com/premiumsupport/knowledge-center/private-hosted-zone-different-account/
4. Share an AWS Microsoft AD across accounts.
a. Use of Route 53 Resolver
This is super easy. Let’s say your AD is in another VPC and let’s say it hosts a domain called “abc.com”. All you need to do in the corresponding VPC is a Route 53 Resolver rule that points to the AD IP and set up network peering directly or via a Transit Gateway.
For simplicity we will just show VPC peering rather than Transit Gateway in the example below.
So in the above set up what you get is all *.abc.com will be resolved by the shared account AD. The other domains will be resolved by the default resolver. So for example *.dev.local will be resolvable by the EC2.
b. Use of PHZ ( unconfirmed) to do conditional forwarding.
This is apparently an option but I haven’t tested it yet. I will update the blog once I have.
5. Use an AD in your account with hosted zones
a. Use of Route 53 Resolver
This is same as the one with AD hosted in another VPC. So you can refer to 4a. The only difference is the AD sits in the same VPC.
b. Use of AD conditional forwarding
You can also add a Conditional Forwarder in the Active Directory itself to resolve other domains including the Private Hosted Zone. So if you set your DHCP Option set to point to the local AD and your AD does the DNS forward lookup.
The conditional forwarder works something like this.
This one is interesting. *.ad.dev.internal will be resolved by AD itself. That is the hosted zone in AD.
*.dev.local which is hosted in a PHZ will be forwarded by the AD. The *.abc.com resolutions will be forwarded to an external DNS as configured.
This solution gets around the issue in just using the DHCP OptionSet in 2a or 5a.
6. Share main AD and subdomains across all accounts with each other
Check this article out. I have tried this but one of the things that was mentioned by AWS support was that the child accounts also needed ADs which is not great. So needs further investigation. Again will update the post when I find out more.
