0
votes

I have a use case, in which I want to configure different hosted zones with same domain names(lets say abc.example.com) to manage different set of A records(which satisfy different personas as per our application). How to get them working, As per my understanding 2 hosted zones, would want me to update my DNS provider with total 8 name server records to route requests to(4 NS records per hosted zone). Which I think either is not possible(to have 8 NS records for one subdomain), or will be confusingly distributing requests(sometimes recieved by Duplicate Zone 1, sometimes Duplcates Zone 2).

Thanks in advance.

1
When someone requests abc.example.com to be resolved, what value shout be returned, from which of the two zones?Dusan Bajic

1 Answers

1
votes

If you are looking to have separate public DNS records for a single Route53 domain, it's simply not possible. Public DNS records are propagated across the internet and unless those users are using an internal set of private DNS records that override these ones they are all going to the same place, DNS (basically) works like this:

  • A user makes a DNS request
  • The DNS request reaches out to the locally configured DNS server (whether this is your ISP, or an internal DNS server of your own). This DNS server is usually configured to be recursive meaning it knows which other DNS servers to reach out to to complete the request.
  • The recursive request is going to ask a root server, such as the root server for .com top level domains. The root server will tell the requester which name server (the ones set in your NS record) the requested domain belongs to.
  • The request is then forwarded to this name server that returns the information requested.

So, unless that local DNS server holds different records that will resolve for those local hosts (kind of like Route53 private hosted zones do for servers in a specific VPC), all the requests go to the same nameservers. However, there are some ways to control where traffic goes with Route53 if these customers are geographically spread. You should review Choosing a Routing Policy and see if any of these options work for you:

Geolocation Routing:

Geolocation routing lets you choose the resources that serve your traffic based on the geographic location of your users, meaning the location that DNS queries originate from. For example, you might want all queries from Europe to be routed to an ELB load balancer in the Frankfurt region.

Geoproximity Routing (Traffic Flow Only)

Geoproximity routing lets Amazon Route 53 route traffic to your resources based on the geographic location of your users and your resources. You can also optionally choose to route more traffic or less to a given resource by specifying a value, known as a bias, that expands or shrinks the size of the geographic region from which traffic is routed to a resource.

Latency-based Routing

If your application is hosted in multiple Amazon EC2 regions, you can improve performance for your users by serving their requests from the Amazon EC2 region that provides the lowest latency.

If your customers are not able to fit nicely in one of these options you will need to consider something outside Route53