NS Record discrepancy after buying domain in Route 53

0

I have a domain that I purchased in Route 53 that I was trying to host a static website on via Cloudfront and S3. I configured all routing and endpoints but could not get the URL to route back to the Cloudfront distribution. After mirroring the configs on a different URL I got the website working for proof of concept and decided to look at the AWS configured records (SOA and NS). The NS records differed between the purchased domain listed name servers and the name servers on the actual record so I copied the name servers from the domain page into the NS record but the URL is still not working. Has anyone run into problems with the preconfigured NS records on Route53 that AWS sets up when you buy a domain?

1 Answer
0

If you purchased the domain in Route53 and also want to host it in Route53, this should all have been done for you automatically. If you edited the NS records in Route53, there should have been a big warning message come up:

When you create a hosted zone, Amazon Route 53 allocates a delegation set (a set of four name servers) to serve your hosted zone. Route 53 then creates a name server (NS) record inside the zone, with the same name as your hosted zone, that lists the four allocated name servers.

If you change this NS record, it doesn't change the name servers that Route 53 allocated. There are use cases when you might change the NS record, such as configuring branded name servers. However, be aware that making incorrect changes to the NS record can cause your domain to become unavailable on the internet

If you still have a record of what the previous values were for the NS record, you should re-instate those. Then update the Glue records to match them. If you didn't make a note of what the previous values were, you can retrieve them from Cloudtrail.

AWS
EXPERT
Paul_L
answered 2 months ago
profile picture
EXPERT
Steve_M
reviewed 2 months ago
  • Thank you so much for your time and the prompt response. I purchased the domain through Route53 and that was my concern. Hopefully it is not some kind of coding bug internally to Route53 when configuring the NS record based on where the domain was previously housed in terms of name servers. I thought there could have been a previous owner internal to AWS and when the NS records transferred there may have been a lapse between the NS updates of where it used to be located internally and where it is now located internally. Just a thought if this is the case

  • The discrepancy between NS records was on the actual record UI and then the domain UI within Route53. The domain UI (accessed on the LHS nav pane) showed a different set of name servers than the configured NS record in the record set UI for hosted zones

  • Yes, the problem is that you've tried to resolve the discrepancy the wrong way around. You needed to update the Glue records (in the Domain UI) with the values from the NS record in the hosted zone.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions