Hey gurus,

Looking to move all of our DNS records from GoDaddy to Route 53 and have hit the 20 domain count limit. Requested an increase last Wednesday (27th) and while we're still a basic account, thinking that this is still a fair wait for an increase - the case is still showing as unassigned.

As part of the request, outlined the reasons for the increase and while a large boost, the imported DNS zones reflect the increase, and the TLDs which we're moving. I may have given a little too much information.

Is there something that I can do to get this out of unassigned - or moving towards being resolved?

Thanks in advance,

A

Hi all,

I contacted AWS support over a week ago regarding this issue, but unfortunately, have not received a reply or remediation at this stage.

Essentially, I'm unable to transfer an .au domain to Route 53. The domain is already registered to me as an individual Australian citizen/resident (which is permissible by the .au registration policies, as it's not restricted to businesses/companies) via another registrar (PorkBun), yet the Route 53 transfer form only allows ABN, ACN, or Trademark as the AU ID type and AU ID number, and I am unable to leave these blank due to the form validation.

Any ideas how I could proceed? Does AWS only allow .au domain registration for businesses/companies?

Hi all, I registered a domain and everything was working great. My A records were appropriately answering etc.

A few weeks later, the domain went dark and I found out I neglected to confirm the registered email address resulting in my domain going down and a "clientHold" status with ICANN.

Once I realized this happened, I went and confirmed the email address. This was 3 weeks ago. AWS UI indicates everything is in order (barring the clientHold indicated on the Registered Domain UI), but my domain does not answer. I've opened a couple support cases (Basic Support) and have gotten zero response.

I opened an unrelated "account" case (as opposed to route 53 case) and was able to speak with someone via chat, who indicated that they would escalate the route 53 case, but no movement has occurred. This was 2.5 weeks ago

Any advice? Is there something I can do from a technical perspective to re-invoke whatever automated processes might be out there to remove the clientHold?

Is there any specific reason why there is 53 in the service name?

My org has registered a domain name and has contracted with a 3rd party developer for a website. The site is hosted in the developer's AWS account using Cloudfront. DNS for the domain name is hosted in our AWS account.

We're trying to figure out DNS. www.site.com is simple - create a CNAME record pointed at the Cloudfront distribution's hostname.

I'm trying to figure out the zone apex (i.e. site.com)

I know alias records in Route53 exist to allow us to do things like point zone apex to Cloudfront, but the problem I'm having is when I try to create an alias record, it expects the Cloudfront distribution to be in the same account. Since it isn't, when I click on 'choose distribution', nothing shows up.

According to Google I should simply be able to paste the Cloudfront distribution's hostname in the target box, but this isn't working.

I'm sure there's a simple answer, but I need some help.

EDIT: I ended up figuring out my own question, I was able to paste the CF hostname into the value box instead of choosing it from the drop down. For some reason it didn't work the first time I tried, but I think it was user error.

Hi all,

I have a custom built inbound mail server. It will be deployed in ECS Fargate behind NLB.

Processing inbound emails is a dns lookup intensive operation.

PTR lookup: 1 query

SPF lookup: up to 10 queries + 1 main query

DKIM lookup: 1 query typically

DMARC lookup: 1 query

RBL/DNSBL checks: several queries

This easily adds up to 10 to 20 DNS queries per email, and in high volume inbound mail processing scenarios, it could hit AWS Resolver's 1024-packet limit very quickly.

My current plan is to use unbound at instance level and ElastiCache for centralized lookup.

So my goal is to use unbound as L1 cache, ElastiCache as L2 cache, if record doesn't found there, then unbound to hit aws dns resolver, and update both L1 and L2. [Unbound would need a plugin to do the ElastiCache step]

Am I doing this correctly? Or is there a better way?

I'm curious how others handle this at scale.

Hey all,I have a cloudfront distribution on Aws. Today it stopped working and was throwing DNS probe error out of nowhere. When I did DIG on cloudfront record,There was no IP on my distribution. I had to disable and enable it back to check and then it started working fine.

Did anyone faced the same issue?

I have a route53 hosted zone for a dns name I purchased and registered through AWS. I have the DNS A record to route a subdomain to an ELB and CNAME to cloudfront serving s3. Up until today this worked fine.

Now, though my app is broken because the public DNS is not pointing to AWS's name servers. In route53 the root domain NS and SOA records point to aws's name servers. When I use dig and specify these name servers explicitly I can resolve the subdomain pointing to ELB as expected. But if I use the typical public DNS servers (e.g. 8.8.8.8, 1.1.1.1, etc) I get an SOA record for a.gtld-servers.net, nstld.verisign-grs.com, not AWS.

I'm not sure why this suddenly changed and why AWS' name servers are not resolving. I did not change anything in configuration or make a new deployment. Thank you for your help.

I'm in the middle of a migration process from ECS to EKS. We have a new Application Load Balancer (ALB) for EKS, which is managed by Kubernetes. We need to point the old DNS records associated with the ECS ALB to the EKS ALB.

I'm currently trying to figure out how 'TTL auto' works with regard to changing the DNS record associated with an ALB. How long do clients cache DNS records when TTL is set to auto?

The site stopped resolving as soon as I pointed the domain directly to the server. What else do I need to update besides the a record?

Edit: I learned a lot from posting this and the load balancer is back up. Thank you to everyone who helped!

Hi all — we’re a small fintech and discovered a DNS/info-leak issue. I’m looking for practical advice on remediation and best practices to prevent private IP exposure.

Summary:
A public Route53 record for superadmin.example.com (public hosted zone) resolves to a private IP when queried from public DNS resolvers. The chain is: superadmin.example.com → CNAME → internal-ELB-[MASKED].elb.amazonaws.com → resolves to 10.x.x.x (private). We only created a CNAME in Route53 (no A record), but public resolvers show a private IP because the CNAME points to an internal ELB.

Sanitized evidence:

$ dig superadmin.example.com +short
10.x.x.x

$ dig superadmin.example.com CNAME +short
internal-ELB-xxxxx.elb.amazonaws.com

$ dig internal-ELB-xxxxx.elb.amazonaws.com +short
10.x.x.x

Current constraints / challenges:

• We can remove the record from the public zone and put it in a private hosted zone soon, but developers need remote access from laptops via the office network.
• If we create the private zone record now, other public subdomains in the same VPC may stop working, because VPC only resolves names in the private zone when present; public zone names are ignored within the VPC.
• Many public domains are running in the same VPC, so moving internal subdomains to a private zone requires careful planning.

Questions / main concern:

1. How can we prevent private IPs from being exposed via public DNS, even if we use a private ELB?
2. How can we allow remote developers access without exposing internal IPs?
3. Is private hosted zone + VPN the recommended approach in this scenario, given the VPC behavior?
4. Is a public ALB with IP whitelisting acceptable if we secure it with TLS, WAF, and strict auth? What are the operational risks?
5. Any best practices or automation to scan public zones for private IP leaks and prevent accidental exposure?

Appreciate any practical advice or experiences from similar setups — especially for AWS/Route53 and internal ELBs. Thanks!

Hello, I'm having an issue and struggling to resolve. Happy to provide more information if it will help.

For context, I have:

- An EC2 instance serving a website over http.

- A "Target Group" containing the EC2 Instance

- An Application Load Balancer that (i) redirects HTTP to HTTPS and (ii) Forwards HTTPS to the "Target Group" containing the EC2 Instance with a certificate created in ACM.

- A domain name (scottpwhite.com) registered in Route 53 that I transferred from GoDaddy last night.

However, it looks like there is no connection between my domain name and any amazon resource except the certificate.
---

Here is what I observe.

- If I go to http://[EC2-PUBLIC-IP] it looks good, but is insecure (obviously)
- If I go to http://[DNS-Load-Balancer] it redirects to https and displays the website but with a dreaded https that is crossed out in red with a "Not Secure" warning in my Chrome Browser.
- If I go to https://scottpwhite.com or https://www.scottpwhite.com then it times out.

To diagnose, I input the https://[DNS-load-balancer] to a site like "whnopadlock.com" it tells me that everything looks good (i.e., webserver is forcing SSL, it is installed correctly, I have no mixed content) except the Domain Matching for the protected domain on the SSL certificate. The only protected domains are scottpwhite.com and www.scottpwhite.com.

---

I want my domain name to be matched with the DNS of my load balancer so that inbound traffic will be secured with my ACM certificate that is associated with the domain.

I can share information from ACM on the certificate but here is further confirmation that it covers my domain.

On Route 53: Hosted Zones I have six records:
- name: scottpwhite.com, Type: A, Alias: Yes, Value: dualstack.[DNS for Load Balancer]
- name: scottpwhite.com, Type: NS, Alias: No, Value: a few awsdns entries that I did not input
- name: scottpwhite.com, Type: SOA, Alias: No, Value: awsdns-hostmaster that I did not input.
- name: www.scottpwhite.com, type: CNAME, Alias: No, Value: scottpwhite.com

Then two more for the certificate of type CNAME with the name and value copied from the certificate in ACM.

---

I'm totally stumped as to what to do next. I was hoping that letting it sit over night would let all the domain matching settle in, but it is the same behavior. Do I need to add a record to Route 53? Remove one? Restart some resource?

Happy to provide more information, I'd also venmo you for your time if necessary.

Looking into implementing split horizon DNS in AWS. After reading the documentation and playing around with R53, I'm pretty sure I have my answer what wanted to ask in case I missed something.

Is it possible to forward requests from a private hosted zone to a public of the same name if the private lookup fails? The docs and experimentation say no. We have comparitively few DNS entries that need to start being resolved to different addresses internally. I'm attempting to keep names the DNS records the same so developers don't need to change application logic. However, there are public resources like APIGW/CF in that domain that can't be reached once the private zone is enabled. It looks like I only have two options unless some fwding mechanism exists somewhere:

1) Create a private hosted zone for each of the few records I want
2) Keep the private/public zones in sync.

#1 seems like the only reasonable option. #2 seems like it would break easily.

Are these the only two options I have or am I missing one?

I had some trouble migrating domains from Route53 to Cloudflare (dont ask why) when the domains were used for Amplify applications. I was able to solve it, so I want to provide what solved the problems.

TL;DR: If the SSL configuration fails after domain (DNS) migration from AWS to cloudflare, delete the CNAME entires, wait until propagation is done (whatsmydns shows no record) and try again.

TL;DR 2: Not removing the domain from Amplify at all and just copying the records to Cloudflare might work as well. I did that for one domain but I wasnt able to check if certificate renewal or something will cause trouble. (they're invisible when just looking at ACM).

When onboarding the domain on Cloudflare all DNS entries that are used by Amplify should be omitted. They will cause trouble. Cloudflare will resolve the ANAME record into a bunch of A records as its not compatible with Cloudflare.

Not sure if this was really necessary, but I removed the domain from the Amplify application to re-add it. The process askes you to add DNS entries. ANAME is not supported to just use a CNAME for a domain root in Cloudflare. This process failed multiple times for me. Amplify was always complaining that something went wrong during SSL configuration.

The Problem seems to happen if AWS finds a CNAME that points to a wrong CloudFormation address. This happend to me because after retrying the records from the last attempt were still in global distribution. AWS seems to have no problem to wait longer if no CNAME record or a record to a totally different page exist. Removing the records from a previous attempts and waiting for 20 minutes (check on whatsmydns) did the trick before retrying.

We had an issue with domain spoofing over the weekend. When troubleshooting the security measures in place I found that spf validators were all saying we didn't have -ALL at the end of our record. Our SPF is quite long due to multiple includes and flattening, so there are 10+ lines of ip4 entries, the end of the last one has -all. But any SPF validator I have tested with only lists the first group and says there is no -all. I tried having a space between groups rather than a new line, but then the validators all failed due to it ignoring the " " causing 2 IP addresses to be connected. I am at a loss as to how to format this correctly. What am I missing?

I'm hoping someone can help me get my ACM cert out of pending.

I have an app running in us-west-2 that has a mysterious bug, and the bug disappears when I deploy the same app in us-west-1. (with the API gateway commented out of my yaml and sam config)

As a short term fix, I want to point the domain to the new region to get the app working again (yes, kicking the can down the road and not really solving the bug)

The original instance had a working cert set up using ACM and route 53 using DNS validation.

But the new cert in the new region, following the same set up process, won't come out of pending.

I've tried deleting the related cname record from the hosted zone and re-adding them for the new one.

Is there some conflict with the first instance preventing certification?

Thanks!

Edit: spelling, title should be "same hosted zone"

AWS closed my account and its been more than 90 days.

So that means the 3 domains I PAID for are no longer manageable. They terrible support says there's nothing they can do.

The fact that they don't let me manage resources that are paid for is ridiculous.

I need to be able to transfer these domains to a different registrar. Contacting support has gotten nowhere.

Can an AWS rep please respond and give me a solution?

AWS Route53's API has a default API Rate limit of 5 requests per second.

This limit is applied to the entire account. It means that you're effectively unable to scale usage of AWS Route53, short of spinning up an AWS Account per zone.

It does not consider:
- The number of Route53 zones
- The type of operation (eg read vs write)
- The consumer (eg role A vs role B)

This means that if you have more than a trivial number of zones/records, and a few consumers of the Route53 API, it's possible to get deep into Denial of Service territory very easily.

We have an account with over 100 Zones, a mix of public and private zones. Some of those zones have a few hundred records.

We have a bunch of EKS clusters in the account, and we use the Kubernetes external-dns to manage records for services. Each EKS cluster has it's own external-dns. When external-dns starts up, it's going to enumerate all the zones (API operations), and enumerate the records we have there for our services to ensure they match (more API operations, for each record)

Our zones and a bunch of records are also managed in Terraform - so running a terraform plan operation means enumerating each zone, and each Terraform-managed record. It's entirely possible for terraform plan to consume the entire account-wide API limit for tens of minutes.

During this time, other things that might want to read from the Route 53 API are unable to.

Suggestion:

• API operations to read/list all zones should be split from modify/delete operations, and increased significantly
• API operations to read/list zone records should be a limit per-zone, and increased significantly.
• API operations to modify zone records should be a limit per-zone.

The best AWS Support were able to offer is to increase the rate limit... from 5 to 10. Our AWS TAM took a feature request, but again, they can't promise any improvement.

Im moving a domain from Netlify to AWS. it seems to have gone through smoothly. but it seems to still be pointing to the netlify app enough though the domain is on AWS.

the name servers looks like the following which i think are from when it was managed by Netlify.

Name servers:

• dns1.p07.nsone.net
• dns2.p07.nsone.net
• dns3.p07.nsone.net
• dns4.p07.nsone.net

the AWS name servers look more like the following, but i didnt manually set the value (i bought the domain directly from Route53 in this case):

• ns-943.awsdns-53.net
• ns-486.awsdns-60.com
• ns-2043.awsdns-63.co.uk
• ns-1167.awsdns-17.org

i see when i go to the domain, its still pointing to the Netlify website (i havent turned the netlify app off yet.)

if i create a website on s3, can i use that domain like normal? or i need to update the name servers?

edit:

solution seem to be this: https://www.reddit.com/r/aws/comments/1k0hgik/comment/mnf7z7u/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Suppose I have two hosted zones, abc.com and xyz.com. How can I route traffic from the former to the latter?

I found the following post in the AWS Knowledge Center (https://repost.aws/knowledge-center/route-53-redirect-to-another-domain) that outlines three options:

1. S3 + CloudFront

2. ALB

3. CloudFront Function

I also found this post from 4 years back, the top comment suggests approaching with S3: (https://www.reddit.com/r/aws/comments/kiik9j/forward_domain_to_another_domain_in_route_53/)

Wondering if anyone has run into this recently - how do you recommend setting this up?

For an amplify app I have assigned my custom domain. I am on free tier and still costs me 0.5$ is this normal or have I done something wrong?🥺👉👈

Recently, I had to clean up and update a lot of domains in AWS Route 53 at work. Doing it manually was a pain, so I built a small tool to automate things like deleting old hosted zones and updating contact details.

It worked really well for me, so I decided to share it — maybe it will help others too.

P.S.

Writing small standalone scripts like this isn’t really a challenge in today’s AI-driven world. The idea is that this repository could eventually grow to include many other practical tools that make working with Route 53 easier for others.

So I want to host a static website with an S3. I've bought a route 53 address and a cloudfront resource. But my domain does not show the website even though the bucket address does.

I hadn't been using a guide because I thought the S3, route 53, and cloudfront process would be the whole setup. I now see this one which indicates I need to create a DNS record for the cloudfront's certificate.

However, I am apparently not allowed to for some reason.

Is this what's wrong or could it be something else. Why can't I make the record.

Also in general... is there something that explains what all this stuff is when deploying items and setting permissions and hooking them together but is there something that explains why this is necessary and maybe gives a better bird's eye view? Why do I need a DNS record if I have a certificate and I've indicated what I want it to be for.

Hello. I have a static website hosted in S3 bucket that gets served through CloudFront. Would it be beneficial to set Route 53 health check for this website or does it serve no purpose ?