Route 53 Domain Not Resolving: The NS Record Mistake and 6 Other Fixes

If your Route 53 hosted zone was created, records look right, and the domain still won't resolve, the fix in roughly seven out of ten cases is boring: your domain's registrar is still pointed at the old name servers, not the four Route 53 gave you when you created the zone. Creating the hosted zone and pointing the domain at it are two separate steps, and Route 53 never does the second one for you — not even if you bought the domain through Route 53 itself.

Wait! if you are a new reader here and don't know about AWS because you didn't had money to learn or from Non Tech background, don't feel bad! I had create one hub, start from here: Learn AWS its free, and all in plain english so it will be easier for u to understand.. once its done come back here, it will be more easier..! Now, let's go back to topic and we will start as usual with Jake.

ake found this out the expensive way. He'd built a one-page order form on an EC2 instance for a Diwali phone-case promotion, pointed a hosted zone at it the night before, and went to bed assuming the domain was live. It wasn't. A customer who'd seen the flyer typed the URL into her phone the next morning and got a blank error page instead of a discount code — and bought her charger cable somewhere else instead.

"I made the hosted zone," Jake said. "Doesn't that mean it's, you know, hosting the zone?" Ethan laughed. "It means Route 53 knows what you want to happen. Nobody on the internet knows to ask Route 53 yet. That's the part you skipped."

Why this happens: the two-step trap

Here's the piece almost nobody explains clearly the first time. A "domain name" and a "hosted zone" are two separate objects that happen to share a name, and Route 53 treats them that way internally too.

Your domain registration is the record that ICANN (the organization that runs the master directory of every domain on earth) recognizes as the owner of record for yourdomain.com. It lives with whichever registrar you bought it from — that could be Route 53's own domain registration service, or it could be GoDaddy, Namecheap, Google Domains' successor, or anywhere else. The registration's job is narrow: it points at a set of name servers (NS) and nothing more.

Your hosted zone is a completely separate Route 53 resource. It's a container for DNS records — A, CNAME, MX, TXT, and so on — for that domain name. When you create one, Route 53 automatically generates a name server (NS) record and a start-of-authority (SOA) record and hands you four name servers, each starting with "ns-". That's it. Nothing tells the registration to actually use those four name servers. You have to go do that yourself, by hand, at the registrar.

If the domain was registered through Route 53 and you let AWS auto-create the hosted zone during that registration, the two are already wired together. But the moment you manually create a second hosted zone — which is exactly what happens when you're following an old tutorial, importing a zone file, or setting up a new environment — you now have a hosted zone that is fully configured and completely disconnected from anything the internet actually asks.

The one-question diagnostic

Before you touch any settings, answer one question: do the name servers at your registrar match the name servers on your hosted zone? Everything else in this post branches off that answer.

1. Get your hosted zone's name servers: open the Route 53 console, choose Hosted zones, click the zone's name, and note the four values listed under "Name servers" in the hosted zone details.
2. Run whois yourdomain.com from a terminal (Linux/macOS) or whois -v yourdomain.com on Windows, or paste the domain into ICANN's public lookup at lookup.icann.org if you don't have whois installed.
3. Compare the two lists, name server by name server. They should match exactly — not "close enough."

If they match, skip straight to Fix 2 — your problem is somewhere other than delegation. If they don't match, or the whois lookup returns nothing at all, start with Fix 1.

Fix 1: update the name servers at the registrar

This is the fix that resolves the majority of "I made a hosted zone and nothing happens" reports. The process differs slightly depending on where the domain is registered.

1. If a third-party registrar owns the domain (GoDaddy, Namecheap, or similar): log in there, find the DNS or nameserver settings for the domain, delete whatever name servers are currently listed, and replace them with the four from your Route 53 hosted zone — including the trailing region-style suffix (awsdns-##.com/.net/.org/.co.uk). Save, and don't touch the hosted zone's own NS or SOA records to "help." Route 53 built those automatically; adding or deleting entries there breaks delegation rather than fixing it.
2. If Route 53 owns the domain registration too: in the Route 53 console, go to Registered Domains, select the domain, and update the name server list there to match the hosted zone. Registered Domains and Hosted Zones are separate pages in the same console — it's easy to edit one and assume the other updated automatically.
3. Leave the registrar's own name servers out of the list entirely. The final list should contain exactly the four Route 53 name servers — no leftover ones from the old provider mixed in.

Fix 2: make sure a record exists for the exact name being typed

If delegation checks out, the next most common cause is simpler than it sounds: there's a record for yourdomain.com but not www.yourdomain.com, or the other way around. DNS does not treat those as the same name. A browser typing www.yourdomain.com gets NXDOMAIN if only the bare apex has a record, even though the hosted zone is otherwise perfectly healthy.

In the Route 53 console, open the hosted zone and look at the record list literally, character by character, against whatever the visitor is typing. Two records are the minimum for most sites: one for the apex (yourdomain.com) and one for www. If you're only running one, decide which one is canonical and add a redirect or an alias for the other rather than leaving it to return NXDOMAIN.

This is also where alias records earn their keep. An alias record pointed at a CloudFront distribution, an Application Load Balancer, an S3 static site endpoint, or several other AWS resource types can sit at the zone apex — something a plain CNAME record is not allowed to do — and it automatically tracks the target's IP address if that ever changes, at no query cost. If you're setting up the apex and www together, that's the pairing worth knowing about; the site's earlier guide on wiring a custom domain to CloudFront over HTTPS walks through that exact setup once resolution itself is working.

Fix 3: give propagation the time it actually needs — and no more

Once name servers change at the registrar, the previous DNS provider's answers don't vanish immediately — resolvers around the world that already cached the old name servers keep using them until that cached entry's TTL expires. The default TTL Route 53 assigns to a new hosted zone's NS record is 172,800 seconds, or two days. That's the honest ceiling on how long a fresh delegation can take to be visible everywhere, though most resolvers pick it up far sooner.

While you wait, test from more than one vantage point. A public DNS checking site that queries from several global locations at once will tell you whether the new answer has actually reached most of the internet, or whether it's just your own ISP's resolver still holding a stale cache — those are very different problems with very different fixes.

Fix 4: find and retire a duplicate hosted zone

This one is genuinely confusing the first time it happens, because everything you're looking at appears correct. It happens when a domain is registered through Route 53 — which auto-creates a hosted zone at registration time — and someone later creates a second public hosted zone for the same name, perhaps while following a tutorial that assumed none existed yet. You now have two hosted zones with the same domain name, each with its own set of four name servers, and only one of them is the one your registration actually points at.

Any records added to the "wrong" hosted zone will look perfect in the console, pass every internal test-record check, and never be reachable from the outside, because nothing on the internet is asking that zone's name servers anything.

1. In Hosted zones, search for your domain name and check whether more than one entry appears.
2. Open each one and note its four name servers.
3. Compare each set against the whois output from the diagnostic step. Whichever set matches whois is the "live" zone.
4. Move your records into the live zone, and either delete the orphaned zone or leave it empty — but don't add anything to it going forward.

Fix 5: check for a DNSSEC mismatch

This is the fix that surprises people who've already done everything else right. DNSSEC (Domain Name System Security Extensions) adds a cryptographic signature to DNS answers so a resolver can verify they weren't tampered with in transit. It's a real security feature, and it's also the single most common cause of a domain that shows correct, matching name servers everywhere and still returns NXDOMAIN.

The mechanism: DNSSEC needs a chain of trust between the parent zone (the registry that runs .com, .org, etc.) and your hosted zone, established through a Delegation Signer (DS) record. If that chain breaks — the DS record at the parent still references an old signing key, or DNSSEC was enabled on one side of a migration but not re-established on the other — a DNSSEC-validating resolver won't just show a warning. It treats the domain as unresolvable and returns NXDOMAIN, the identical symptom as a plain name-server mismatch, which is exactly why this fix gets missed: everything you'd normally check to diagnose NXDOMAIN comes back clean.

To check: in the Route 53 console, open the hosted zone and look for a DNSSEC signing status panel. If signing shows as enabled but you can't account for why, or if you recently migrated the domain, that's the thread to pull. Ethan's take on this one is blunt: "If DNSSEC isn't something you deliberately turned on for a reason you can name, turning it off and re-verifying resolution is a faster diagnostic step than staring at NS records a fourth time."

Fix 6: confirm the domain hasn't expired or been suspended

A domain that's expired, in a post-expiry hold, or suspended by the registrar for unpaid renewal or a compliance issue will return NXDOMAIN regardless of how correct your hosted zone is, because the registry has effectively removed it from the top-level directory. This is the check people skip because it feels like it couldn't possibly be the problem — right up until it is.

A whois lookup will usually show the domain's status codes (things like "clientHold" or "pendingDelete") alongside the name servers. If the domain shows no name servers at all in whois, or the registrar's dashboard shows an unpaid renewal or a pending transfer, that takes priority over every DNS-side fix in this post — none of them matter until the registration itself is active.

Fix 7: check whether a health check pulled your record out of rotation

This one only applies if you've configured failover, weighted, or multivalue routing with health checks attached — but it's easy to forget once it's set up. If a record has "Evaluate Target Health" turned on, or a non-alias record has an associated health check, Route 53 will stop including that record in DNS answers the moment the health check reports the target as unhealthy. If every weighted or failover record behind a name is unhealthy at the same time, Route 53 has nothing valid to hand back, and the query can come back empty or as NXDOMAIN depending on the configuration.

Check the health check's status in the Route 53 console under Health checks. If it's showing unhealthy, the DNS layer is doing exactly what you configured — the fix is in whatever it's checking (an EC2 instance, a load balancer, an on-path firewall rule) rather than in the hosted zone itself.

Automating the check, so you're not doing this by hand every time

Once you've run through this checklist a couple of times manually, the "click into the console, then run whois, then compare" routine gets old fast. Two tools cover almost everything above without a browser.

1. dig +short NS yourdomain.com shows what the internet is currently being told, live, from whichever resolver your machine uses. Add dig +trace NS yourdomain.com when you want to see the full delegation path from the root servers down, one hop at a time, rather than just the final answer.
2. aws route53 get-hosted-zone --id Z1R8UBAEXAMPLE pulls your hosted zone's own four name servers directly from the Route 53 API, so you're comparing against the source of truth instead of whatever's cached in a console tab you opened an hour ago.
3. If the domain is registered through Route 53, aws route53domains get-domain-detail --domain-name yourdomain.com --region us-east-1 returns the registration's current name servers, expiry date, and lock status in one call — useful for catching Fix 6's expired-or-suspended case before it becomes a surprise.

Line up the output of all three against each other and the mismatch, if there is one, shows up immediately instead of after five browser tabs.

Third-party DNS checkers: when they help, when to skip them

Global propagation-checking websites are genuinely useful for one specific thing: confirming whether a name-server or record change has actually reached resolvers in other parts of the world, or whether you're only staring at your own ISP's stale cache. For that one question, they're faster than asking a friend in another country to run dig for you.

Where they're the wrong tool is anything involving your account or infrastructure specifics. Pasting a private hosted zone's internal subdomain names, an internal load balancer's DNS name, or anything from a non-public zone into a random third-party lookup site hands your internal naming conventions to a service you don't control, for no benefit — none of those tools can see private hosted zones anyway, since those only resolve inside your VPC. For public records, they're fine. For anything with "private" or "internal" in the name, run dig from your own machine or a resource inside the VPC instead.

When you've tried everything and it still won't resolve

A few less common situations that don't fit neatly into the seven fixes above but are worth naming honestly:

Subdomain delegation. If you've delegated a subdomain (say, app.yourdomain.com) to its own hosted zone rather than putting an NS record for it in the parent zone, the NS records inside the subdomain's own hosted zone must exactly match an NS record you manually created in the parent zone. This is a separate check from the registrar-level one above, and it's easy to do the parent-zone delegation correctly while forgetting this second, internal one.

A resolver on your own network is lying to you. If a corporate VPN, a router-level DNS filter, or a "protective" DNS service is forwarding queries somewhere other than the public internet's resolvers, it can show you a stale or wrong answer even after everything above is fixed. Testing from a different network — mobile data instead of Wi-Fi, for instance — rules this in or out in under a minute.

You haven't actually waited as long as you think. "It's been a while" and "it's been past the TTL" are different claims. If the NS record's TTL was still at its original 172,800-second default when you made the change, "a while" needs to mean up to two full days before you escalate further.

Don't forget email while you're in here. If the domain went through a hosted-zone recreation or a zone-file import to get to this point, MX, SPF, and DKIM records are separate line items that don't come back automatically — a domain can resolve perfectly for web traffic while its mail silently starts bouncing, because nobody re-added the mail-related records during the fix. Worth a quick look at the record list before calling this closed.

Route 53 vs. Route 53 Resolver vs. Route 53 Global Resolver

These names get confused constantly, and the confusion has gotten worse rather than better as AWS has added services with overlapping names. Here's the plain distinction: "Route 53" on its own refers to the authoritative DNS service this whole post is about — hosted zones, records, domain registration, health checks, and routing policies. It answers the question "where does this domain name point?"

Route 53 Resolver is a different thing entirely, and it answers a different question: "how does traffic inside my VPC look things up, both on the public internet and against my own private hosted zones?" Every VPC gets one automatically, reachable at a fixed internal address, and it's what lets an EC2 instance resolve both public domain names and private DNS records without you configuring anything.

Ethan puts it this way: "If you're debugging why a website won't load in a browser, you almost certainly don't need to open the Resolver section of the console at all. That's for EC2 instances and on-premises servers talking to each other, not for the public internet finding your homepage."

What Route 53 actually does, feature by feature

"How does Route 53 work" is really three separate jobs bundled under one name. Knowing which job you're in determines which part of this post applies to you.

What this actually costs — and what a lost domain costs

None of the fixes above cost anything to apply — updating name servers, checking DNSSEC status, and fixing a duplicate zone are all free operations. The hosted zone itself runs $0.50 a month for each of your first 25 zones, standard DNS queries are billed at $0.40 per million, and queries answered through alias records to supported AWS resources are free, which is one more reason to prefer alias records over plain CNAMEs where AWS allows it.

The number that actually mattered to Jake wasn't any of those. It was the cost of a broken domain during the one morning it needed to work: a customer, gone, over a mismatch that would have taken under two minutes to find and fix with a single whois lookup. "I don't care what Route 53 charges a month," he said afterward. "I care that I didn't check the thing that takes ninety seconds before I told people the site was live."

Frequently asked questions

Why doesn't my domain resolve even though the hosted zone looks correct?

The hosted zone can be perfect and still be invisible to the internet if the domain's registration still points at a different set of name servers. Run a whois lookup and compare it against the four name servers listed in the hosted zone; a mismatch there overrides everything else in the zone.

What is the difference between Route 53 and Route 53 Resolver?

Route 53 is the authoritative DNS and domain registration service that answers "where does this domain point?" Route 53 Resolver (now called Route 53 VPC Resolver) is the recursive resolver built into every VPC that answers "how do resources inside this VPC look up names?" A public website's resolution problem is almost always a Route 53 hosted-zone or registration issue, not a Resolver issue.

How does Route 53 work in general?

You create a hosted zone that holds DNS records for a domain, Route 53 assigns four name servers to that zone, and you delegate the domain to those name servers at whatever registrar holds the registration. Once delegated, any DNS query for that domain is answered authoritatively by those four Route 53 name servers according to whatever records and routing policies you've configured.

What is Route 53 Resolver, exactly?

It's the recursive DNS resolver automatically available inside every Amazon VPC, reachable at a fixed internal address. It answers queries for local VPC domain names, private hosted zone records, and performs recursive lookups for public domain names on the internet. Inbound and outbound endpoints extend it to resolve names between your VPC and an on-premises network.

Which features are available with Route 53?

Domain registration, public and private hosted zones, seven routing policy types (simple, weighted, latency-based, failover, geolocation, geoproximity, multivalue answer, and IP-based), alias records, health checks, Traffic Flow, DNSSEC signing, query logging, and the VPC Resolver with its inbound/outbound endpoints and DNS Firewall.

I searched "Route 53 construction update" and got results about a highway. What's going on?

Nothing wrong on your end — Route 53 is also the name of a well-known Illinois state highway with an ongoing multi-year reconstruction project, and search engines mix results for both under the shared name. If you landed here looking for road construction and detour information, this article isn't it; if you landed here from an AWS error message, you're in the right place.

How long does Route 53 propagation actually take?

The default TTL on a new hosted zone's NS record is 172,800 seconds — two days — which is the honest worst case for a name-server change to reach every resolver globally. Most resolvers pick up the change well before that, but if you need a change to go live quickly, lower the NS record's TTL before making the change rather than after.

Do I still need to update name servers if I registered the domain through Route 53?

Not if the domain was registered through Route 53 and you kept the hosted zone Route 53 auto-created at registration time. You do need to update them if you later created a separate, second hosted zone for the same domain, or if you registered the domain elsewhere and are now pointing it at Route 53 for the first time.

Why does www.mydomain.com work but mydomain.com doesn't (or vice versa)?

DNS treats the apex domain and the www subdomain as two completely separate names. If a record exists for one but not the other, the one without a record will return NXDOMAIN even though the hosted zone and delegation are otherwise fine. Add a record — or an alias, for AWS targets — for whichever one is missing.

Can DNSSEC really cause NXDOMAIN even when my records are correct?

Yes. If the chain of trust between the parent zone and your hosted zone is broken — commonly a stale Delegation Signer (DS) record left over from a migration — a DNSSEC-validating resolver will refuse to trust the answer and return NXDOMAIN, even though the name servers, records, and everything else are configured correctly.

How do I check if my Route 53 hosted zone is even active?

Open the hosted zone in the console and confirm it lists an NS record with four name servers and a single SOA record. If either is missing or you've added extra NS/SOA entries, that's already a sign the zone was altered from its default state and should be reviewed before anything else.

What if I have two hosted zones for the same domain?

Only one of them is delegated to by your registration — whichever one's name servers match your whois lookup. Move any records you actually need into that zone and stop adding anything to the other one; records in the orphaned zone are never reachable from the public internet no matter how correct they look.

Does deleting and recreating the hosted zone fix a stuck domain?

Almost never, and it usually makes things worse. Deleting a hosted zone and creating a new one generates four brand-new name servers, which then have to be re-entered at the registrar, restarting the full propagation wait from the beginning for no benefit.

Why does nslookup work on one network but not another?

Different networks use different DNS resolvers, and each one caches answers independently. A resolver that already cached your domain's old name servers will keep returning them until its own copy of the TTL expires, even after the correct answer is available everywhere else. Testing from a second network, like mobile data instead of Wi-Fi, tells you whether the fix has actually propagated or whether you're only looking at one stale cache.

Can I use Route 53 for DNS if my domain is registered somewhere else?

Yes. You create a public hosted zone in Route 53 for the domain, then go to your existing registrar and change the domain's name servers to the four Route 53 assigned. The registration itself never has to move; only the name-server delegation does.

What is Route 53 Global Resolver, and is it related to my resolution problem?

Route 53 Global Resolver is a separate, newer service — an internet-reachable recursive resolver for clients anywhere, distinct from the VPC-only resolver every VPC already has. It's unrelated to whether your public website resolves; that's governed entirely by your hosted zone's records and its delegation from the domain registration, not by any resolver service.

Revision note. Written August 2026, covering current Route 53 console behavior for public hosted zones, domain registration, DNSSEC signing, and the VPC Resolver/Global Resolver naming split. This will need a revisit if AWS changes the default NS record TTL or restructures how Registered Domains and Hosted Zones are linked in the console. If you're reading this at 2am with a dead domain and a launch in the morning, take a breath — the fix is almost always a two-minute name-server check, not something broken in your setup.