You create a Route 53 public hosted zone and add an A record for blog.example.com. The record appears in the console, but the browser still cannot connect. Before editing the record again, ask whether public DNS queries reach that hosted zone at all.
Why might an existing A record not answer?
Assume the domain was bought from another registrar and DNS is being moved to Route 53. The new example.com public hosted zone contains blog.example.com → 192.0.2.10, while the old DNS provider has no blog record. The address is documentation-only, not a live server.
The diagram follows delegation. When registrar NS remains at the old provider, public queries do not reach Route 53. After delegation changes, resolvers can query the hosted zone, subject to caching.
A hosted zone says how its names should be answered. The registrar's name-server setting says which DNS service should be asked for the domain. If they point to different services, a perfectly valid A record in Route 53 may never participate in an ordinary public lookup.
| Checkpoint | Example state | Consequence |
|---|---|---|
| Route 53 public hosted zone | A record for blog.example.com exists | Its name servers can answer direct queries |
| Registrar NS setting | Still points to the prior DNS provider | Ordinary resolvers follow the prior provider |
Creating a public hosted zone produces NS and SOA records there. It does not automatically change the registrar setting for a domain bought elsewhere. Route 53 can make that connection automatically when the domain is registered through Route 53. AWS explains the two setup paths.
Compare Route 53 and registrar name servers
Open the exact public hosted zone containing the A record and copy its four assigned name servers. It is possible to create multiple zones with the same name, so verify the zone you edited.
Then compare those servers with the names configured at the domain registrar. Changing the NS record inside the hosted zone is not a substitute for changing the parent delegation at the registrar.
For a real domain, these commands help inspect the live path:
dig +short NS example.com
dig +trace example.com NS
dig +short A blog.example.comCompare the dig results with both the registrar and Route 53 zone. A direct query to one of Route 53's assigned name servers can answer correctly while an ordinary resolver still follows the old delegation or a cached result. The console record and the public answer are distinct evidence.
Will changing NS fix it immediately?
Changing a production domain's name servers redirects the entire DNS service path, not just one website. Before changing them, copy and verify required MX, TXT, and other records in the new zone; otherwise email or verification may break while the website starts working.
Recursive resolvers can retain prior NS or A answers until their TTLs expire. If a changed delegation still appears ineffective, determine which name server answered and whether its data is old. Editing the wrong duplicate hosted zone also leaves the result unchanged. AWS's DNS troubleshooting guide covers these separate causes.
For a live domain, keep the previous DNS service available until the new delegation and important web and mail paths are verified.
Key takeaways
The Route 53 A record is an answer; registrar NS delegation directs queries to the service holding that answer. Check hosted-zone record → assigned NS → registrar NS → public DNS response. If delegation still points elsewhere, editing only the A record cannot repair the path.
