Route53 Alias not resolving to cloud front distribution

It appears that you are following the correct process with respect to using Route 53 for DNS resolution of CloudFront distributions, and I would specifically highlight that using a Route 53 Alias record is the recommended path as it'll allow you to create an alias at the zone apex (root) level as well as for subdomains in Route 53.

It seems you have done due diligence with your configuration and I would recommend some additional testing (below) if not done already. Alternatively, if this solution is still not functional, I would recommend creating a ticket with AWS Support to investigate further.

1. Are you able to access the CloudFront distribution directly using the DNS name assigned to the distribution itself? Are you provided the correct certificate?
2. Have you confirmed that Route 53 is the authoritative name service for the domain you are configuring the alias record within?
3. Have you any configured health checks on the alias record that may be failing (and causing an issue with DNS resolution)?
4. After you created the Alias record in Route 53, what value is returned when you query (nslookup) against this domain name from your local computer?

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-cloudfront-distribution.html

It sounds like the "example.com" domain may be split, that is, internal (on-premises) DNS may be authoritative for the domain on your local network, while Route 53 may be authoritative for the domain on the public Internet. And if you're connected to your local on-premises network (either directly or via VPN), you may be picking up the DNS servers there. Assuming this domain is split between on-premises and Route 53, it would make sense to see SOA and NS records in both locations as neither are aware of the other.

I would recommend double-checking that your "example.com" is in fact being served by Route 53, and you can use a whois tool such as https://whois.domaintools.com/ to verify that. What you should see here is an SOA and NS records that point to AWS' authoritative name servers (https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/migrate-dns-domain-in-use.html). I would also point out that technically Route 53 doesn't need to have the "example.com" domain registered to be authoritative for this domain's DNS function, and it is possible to leave this domain at your current registrar while delegating DNS functionality to Route 53.

Hopefully this is helpful, and would be interested in feedback on what you discover in your testing!

We have the setup working finally. The following is what we did in addition to the previous steps.

1. We re-imported the certificate for the CNAME with the whole certificate chain root -> intermediate -> domain.
2. On the on-premise name servers, created a CNAME (ALIAS) pointing to the distribution followed by cloudfront-update.

The exact step that made this working seems to be the creation of CNAME record on the on-premises name servers. As Darren mentioned, it looks like the name servers residing on-premise are the authoritative ones for our domain and R53 is used for delegation purposes.

Darren, Thank you for your quick response.

1. Are you able to access the CloudFront distribution directly using the DNS name assigned to the distribution itself? Are you provided the correct certificate?

Yes. The distribution is directly accessible and my request is going to the origin. We are also suspecting certificate issue, so asking our internal team to give us a new CA

2. Have you confirmed that Route 53 is the authoritative name service for the domain you are configuring the alias record within?

This is the part we are digging deeper along with the SSL certificate. More on this below.

3. Have you any configured health checks on the alias record that may be failing (and causing an issue with DNS resolution)?

No. When I created the ALIAS manually, the health check is by default disabled.

4. After you created the Alias record in Route 53, what value is returned when you query (nslookup) against this domain name from your local computer?

The name resolution is not happening and dns queries using various options & tools - nslookup, dig, host, etc are giving me NXDOMAIN

Expanding #2, one thing I did notice is that the SOA & NS records for the domain "example.com" via nslookup resolves to few of our onprem servers and in R53 as well I see NS records for "example.com" (Not sure if an old team member did this) but nslookup on "example.com" never gives me the servers from AWS - .awsdns-xx.. As a next stop I was thinking of adding the ALIAS record in "onprem" name servers......I'll be damned if that works.

And if it works, my follow up question would be, is the above setup valid? How come someone have SOA & NS records in 2 places - onprem and in R53. How does that work? What am I missing here. If its about primary and secondary name servers and assuming onprem is the primary name server, why is it also not checking with the secondary name servers on R53.

Regards

This probably isn't it, but I'll mention it in case - you have to use ACM in us-east-1. I can't remember what happens if you don't.