You created a public hosted zone for example.com in Route 53 and added an A record for www, but the name still does not resolve anywhere on the internet. What step is most likely missing, and where is it performed?

## Two separate things that both say "example.com" DNS resolution is a walk down a delegation chain: a resolver asks the root which servers serve `com`, asks those which servers serve `example.com`, and only then asks *those* servers for `www.example.com`. Each step is a set of NS records published by the **parent**. A Route 53 hosted zone is the last link in that chain — the servers that finally answer. Creating one is a purely local act: AWS allocates a zone, gives it an SOA record and a set of NS records at the apex, and assigns four name servers (the *delegation set*), typically one in each of four different top-level domains (`.com`, `.net`, `.org`, `.co.uk`) for resilience. None of that touches the `com` zone. Until the registrar tells the registry to publish those four names as the delegation for `example.com`, no resolver on earth has any reason to ask Route 53 anything. That is why the symptom is total: not a stale answer, not the wrong address — nothing at all. ## Where the fix is applied At the domain's **registrar**, in whatever it calls the name-server field. Two AWS-specific wrinkles catch people: 1. **Route 53 Domains is not Route 53 hosting.** If you registered the domain with AWS, the registrar side lives under *Registered domains*, and the hosted zone lives under *Hosted zones*. Registering a domain does create a hosted zone and wire the two together automatically — but if you later delete that zone and create a new one, the automatic link is not re-established. 2. **Recreating a zone changes the name servers.** Delete a public hosted zone and create it again with the same name and you get a *different* delegation set. Everything in the zone looks the same, and the domain stops resolving because the registrar still points at the old four. If you need stable name servers across zones, `CreateReusableDelegationSet` gives you a delegation set you can reuse for many zones. ## The NS record inside the zone The hosted zone also contains an NS record at its own apex, listing the same four servers. This is not what delegates the domain — it is the authoritative copy of the delegation, which should agree with what the parent publishes. Editing it does not change the parent, and deleting it breaks the zone. When you compare, you are checking that two independently-maintained lists agree. ## Verifying ```bash # what Route 53 says the zone's name servers are aws route53 get-hosted-zone --id Z0123456789ABCDEFGHIJ \ --query 'DelegationSet.NameServers' # what the internet is actually delegated to dig +short NS example.com @1.1.1.1 ``` If the second output is empty, the domain is not delegated at all — the registrar step never happened, or the domain is not registered. If it lists a different provider's servers, the domain is delegated somewhere else and your Route 53 zone is an unused draft. If it matches, delegation is fine and the problem is inside the zone. After you fix the registrar, expect a delay: the parent's NS records have their own TTL (commonly a day or two at the TLD), and resolvers that already cached the previous delegation will keep using it until it expires. This is the part to say out loud in an interview — it is the reason "I changed it and it still doesn't work" is usually not a second bug. ## The cutover version of the same question Moving an existing, live domain to Route 53 is this problem with stakes. The safe order is: build the zone completely in Route 53 first and compare it record by record against the current provider; lower TTLs at the *old* provider ahead of time so clients re-check quickly; then repoint the registrar; and leave the old zone serving identical answers until the delegation has fully aged out everywhere. Repointing the registrar before the records exist creates exactly the outage described in this question, only on a domain that people are using.