Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

AWS Route53 - different AWS accounts with same hosting zone name

I'd like to understand better what would happen in the following scenarios:

  1. If there are 2 AWS accounts and both of them have example.com hosting zone each, account one has prod.example.com and account two has dev.example.com, will they resolve correcly?
  2. If aws account one and two have example.com hosting zone, I delete record good.example.com and than create same record in account two but good.example.com pointing to a different endpoint (i.e. different Load Balancer), will this resolve correctly?
  3. If I have existing example.com hosting zone, will creating example.com in another aws account screw up the first one?
  4. If I have existing example.com public hosting zone, will creating private example.com in another aws account screw up the first one? Is it even possible? In this case, I'd like to have domains like internal.example.com in private one.
  5. Will having public and private hosted zone with same name work in same AWS account?

I wish I could test these scenarios but I don't want to bomb production:) Thank you.

like image 629
Anton Kim Avatar asked Sep 14 '26 20:09

Anton Kim


2 Answers

Only one AWS account can have a working example.com public hosted zone in Route53. Only one Route53 public hosted zone can be configured as the authoritative DNS server with the domain registrar. Please see how DNS works. A DNS record lookup is going to go only to the authoritative DNS server for that domain. None of the other DNS servers (Route53 public hosted zones) you have configured will ever get the DNS lookup request.

If you need other accounts to control subdomains of the main domain, like prod.example.com and dev.example.com, then you would have to setup DNS delegation. In that setup you would still only have one account with a working example.com Route53 public hosted zone, but for any requests for prod.example.com or *.prod.example.com DNS records, that Route53 hosted zone would delegate the DNS lookup to the public hosted zone in the other account.


If I have existing example.com public hosting zone, will creating private example.com in another aws account screw up the first one? Is it even possible? In this case, I'd like to have domains like internal.example.com in private one.

Private hosted zones are different. Private hosted zones must be attached to a VPC (or multiple VPCs). Private hosted zones are never configured with your domain registrar, and are not resolvable on the public Internet. The DNS lookups for private hosted zones only work inside the VPCs they are attached to. Creating private hosted zones does not interfere with the public hosted zone at all. It will not "screw up" the public DNS resolution of the domain in any way.

Will having public and private hosted zone with same name work in same AWS account?

Yes absolutely. The public hosted zone will be the only one configured with your domain registrar. As far as public DNS queries on the Internet are concerned, the public hosted zone is the only DNS server for your domain. Only your software performing DNS lookups inside your private VPCs will be able to see the private hosted zone records.

Note that private hosted zones don't even have to be for domain names that you own. They can be completely made-up domain names, like internal.mydomain. They don't even need to have a valid Internet TLD (Top Level Domain) because they are not "on the Internet".

like image 179
Mark B Avatar answered Sep 16 '26 11:09

Mark B


I agree with the most of the accepted answer posted by @mark-b except one part. I am posting it here as an answer to show how one can create and use the same DNS hosted zone in multiple AWS accounts and get benefited.

The solution I am posting here I implemented at my work place a few years ago. Doing so, I eliminated the need of a complex solution of creating cross-account DNS records using CloudFormation custom-resource (Lambda).

Here is how I did this:

Assume, I have two AWS accounts for the same application: Account-A for production and Account-B for non-production. I created the same example.com hosted zone on these two AWS accounts' Route 53. Their NS records are showing similar to the ones below:

example.com NS Record in Account-A:

ns-001.awsdns-01.co.uk.
ns-002.awsdns-02.com.
ns-003.awsdns-03.net.
ns-004.awsdns-04.org.

example.com NS Record in Account-B:

ns-0001.awsdns-001.co.uk.
ns-0002.awsdns-002.com.
ns-0003.awsdns-003.net.
ns-0004.awsdns-004.org.

Now, to manage production related DNS records, I use Route 53 of Account-A and to manage non-production (e.g. dev, uat, qa) DNS records, I use Route 53 of Account-B.

For that, I needed to create these non-production DNS records as NS records in Route 53 of Account-A manually. For example, I need to manage dev.example.com DNS record with dynamic a value (that can change with any deployment) in Account-B. I created the following NS record in Account-A manually with the values of the NS record for the same zone name in Account-B like below:

In Account-A (manually):

Record Name: dev.example.com
Type: NS
Value/Route traffic to:
ns-0001.awsdns-001.co.uk.
ns-0002.awsdns-002.com.
ns-0003.awsdns-003.net.
ns-0004.awsdns-004.org.

In Route 53 of Account-B, create the following record with the actual target value like below:

In Account-B (dynamically):

Record Name: dev.example.com
Type: A
Value/Route traffic to: 10.10.10.15

Here, you can create any type of DNS records with the name dev.example.com you manually created an NS record for, in the Route 53 of Account-B.

Please note that for every record you want to manage (dynamically) in non-prod accounts (e.g. Account-B, you need to create a corresponding NS record in the prod account (e.g. Account-A.

Benefits:

  1. Easily create and manage DNS records with dynamic values using different automations you use (e.g. CloudFormation, Terraform or whichever you use) in multiple AWS accounts for the same DNS zone name.
  2. Eliminate the need of a complex cross-account DNS record creation with automations, which requires conditions, custom-resource and cross-account IAM permissions in assumed role used by the automations.

Limitations/Disadvantages:

  1. Need to create a corresponding DNS record manually in AWS Account-A (once for the lifetime per DNS record).
  2. If you create ACM certificates in the non-production accounts (Account-B, in this case), the verification CNAME record has to be created in Route 53 of the AWS Account-A (once for the lifetime per ACM certificate).
like image 20
Rafiq Avatar answered Sep 16 '26 10:09

Rafiq



Donate For Us

If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!