AWS Route 53:
how one checkout resolves eight names

A hosted zone is Route 53’s container for one domain’s records. Each record has a name, a value, and a type that says what the value is: an A record holds an IPv4 address, an NS record holds server names. Creating a zone for shop.example writes two records you never asked for.

The NS record lists four name servers, the servers that hold the zone’s records and answer from them. The SOA record holds the zone’s timers. The four servers sit under four different top-level domains, .com, .net, .org and .co.uk, so trouble in one top-level domain leaves the other three names reachable.

A zone costs $0.50 a month. An account holds 500 zones and a zone holds 10,000 records before quotas or extra fees apply.

At 14:01:30 the customer’s phone asks its resolver at 192.0.2.53 for shop.example. That is query #1. A resolver is a server whose job is to find answers by asking other servers. This one has nothing cached for the shop, so it asks the .example registry, which is query #2. The registry returns a referral: no address, only the names of the four name servers to ask next.

Those four names are in the registry because the shop gave them to its registrar, the company a domain is bought through. That hand-off is delegation. Resolvers follow the registry’s copy, not the NS record inside the zone. Delete the hosted zone and recreate it, and Route 53 assigns four new servers while the registry still lists the old four.

How a resolver gets from the root of DNS down to a registry is a walk of its own, covered in what happens when you press Enter. This resolver starts with the registry’s servers already cached, as real resolvers nearly always do.

Route 53 arranges its capacity as 2,048 virtual name servers and gives each hosted zone four of them. AWS calls the method shuffle sharding: every customer gets a different combination of four. A flood of queries aimed at one domain lands on that domain’s four servers, and every other domain keeps at least two servers the flood does not reach.

There are 730,862,190,080 ways to choose four servers from 2,048, and no two customer domains share more than two. Each virtual name server answers from more than 200 locations by anycast: one IP address announced from many places, with each query reaching the nearest.

The service-level agreement counts a zone as unavailable only when all four name servers fail to answer for a full minute. It pays credits for any month under 100%.

The resolver picks one of the four name servers, ns-2051.awsdns-67.co.uk, and asks it for shop.example: query #3. The shop’s site is a CloudFront distribution, which is reached by a name and has no fixed addresses. The usual record for that is a CNAME, which says “this name is another name”. A CNAME may not share its name with any other record, and the bare domain, called the zone apex, already holds NS and SOA.

An alias record is Route 53’s way around that. Route 53 looks up the target itself and answers with plain A records, in one query where a CNAME takes two. Queries for an alias to an AWS resource are free. An alias answers one record type, so IPv6 needs a second alias of type AAAA. Its TTL comes from the target and can’t be set.

Two timers follow every change to a record. The first belongs to Route 53: the change is reported as PENDING, then as INSYNC once every name server has it, generally within 60 seconds. The second belongs to resolvers. Each keeps the answer it already cached for the record’s TTL: 60 seconds for an alias to a load balancer or CloudFront, and whatever you set on other records.

An answer of “no such name”, which DNS calls NXDOMAIN, is cached too. A resolver keeps it for the lesser of the SOA record’s TTL and the SOA’s minimum field. In a new Route 53 zone those are 900 and 86,400 seconds, so the answer is kept for 900 seconds, which is 15 minutes.

The phone’s first lookup took three questions, and each one is a query: the phone to its resolver, the resolver to the registry, and the resolver to Route 53. Route 53 answered one of the three, so only that one can appear on a bill. Standard queries cost $0.40 per million, and a query for an alias to an AWS resource costs nothing.

For the next 60 seconds everyone behind that resolver gets the cached answer, and Route 53 receives nothing. AWS’s documentation says the query log of a busy record may show one query for every several thousand that users made. The query count is 3.

A routing policy is a setting on a record. Several records share one name and type, each with its own identifier, and Route 53 picks among them when a query arrives. There are eight policies: simple, weighted, latency, failover, geolocation, geoproximity, multivalue answer and IP-based.

Each policy reads one input: nothing at all, a weight you set, the asker’s network, the health of a target, or the asker’s location. Every policy except IP-based also works in a private hosted zone, the kind that answers only inside your own networks (chapter 03). Most policies allow 100 records for one name and type.

At 14:02:07 the customer taps Pay. The phone asks its resolver for api.shop.example, which is query #4, and the resolver asks Route 53, which is query #5. The name has two latency records, one for each Region. Each is an alias to that Region’s load balancer.

Route 53 answers with the record whose Region has the lowest latency for the asker’s network. It reads that from measurements AWS has collected “over a period of time” between networks and Regions. Nothing is probed when the query arrives. The answer here is us-east-1: 198.51.100.20, with a TTL of 60 seconds. Latency queries cost $0.60 per million, though a query for an alias to a load balancer stays free.

Query #5 arrives at Route 53 from 192.0.2.53, the resolver, and a resolver can be far from the customers who use it. Many resolvers therefore add a field called EDNS Client Subnet to the query: the first 24 bits of the customer’s address, here 203.0.113.0/24.

Route 53 uses that subnet for latency, geolocation, geoproximity and IP-based routing. Without it, Route 53 falls back to the resolver’s own address. The resolver AWS runs inside a VPC never sends the field, so a query that starts inside a VPC is located by the address of AWS’s resolver fleet.

Weighted routing gives each record an integer from 0 to 255. A record’s share of answers is its weight divided by the sum of the weights for that name. Weights of 90 and 10 send one answer in ten to a new stack, and a weight of 0 stops answers for that record. Blue/green and canary releases done in DNS work this way.

The share is of answers, not of users. One cached answer serves everyone behind that resolver until its TTL runs out, so a weight of 10 can deliver much more or much less than a tenth of the requests. When the split has to be exact, AWS’s own DevOps Professional sample question prefers weighted target groups on one load balancer.

Geolocation routing picks a record by the asker’s continent, country or US state, most specific first. It needs a default record. Without one, an asker who matches none of your locations gets no answer at all.

Geoproximity routing picks the nearest resource, and a bias from −99 to +99 grows or shrinks each resource’s reach. For a positive bias Route 53 compares distance × (1 − bias ÷ 100). Since 2024-01-10 geoproximity is an ordinary record setting. IP-based routing matches the asker’s address against ranges you upload, as specific as a /24 for IPv4.

Queries #4 and #5 bring the query count to 5. The resolver now holds 198.51.100.20 for 60 seconds, and every customer behind it is sent to us-east-1 without Route 53 being asked again. A client that ignores TTLs keeps the address even longer.

AWS Global Accelerator makes the same choice somewhere else. It gives you two fixed anycast addresses that never change, and AWS’s edge network picks the Region for each new connection, so no DNS answer has to expire first. That is why exam scenarios with clients that cache DNS, or with partners that need fixed addresses, point to Global Accelerator.

A health check is Route 53 servers in eight Regions, called health checkers, each requesting a URL you name. A checker must open a TCP connection within 4 seconds, then receive a 2xx or 3xx status within 2 more. An optional string match reads the first 5,120 bytes of the response body. An HTTPS check never validates the certificate.

Every checker runs on its own clock. At the standard 30-second interval the endpoint receives a request about every two seconds. At the fast 10-second interval it receives more than one a second. The shop’s check on us-east-1, hc-use1, costs $2.50 a month: $0.50 for a check on an AWS endpoint, $1 for HTTPS and $1 for the fast interval.

Each checker judges alone. It flips its verdict only after FailureThreshold consecutive results that disagree with it: 3 by default, and 1 to 10 are allowed. Route 53 then counts the verdicts. The endpoint is healthy when more than 18% of the checkers say so, which means a network fault on one continent can’t mark it down.

The reverse also holds. An endpoint that only a fifth of the checkers can reach still counts as healthy, even while most of the internet can’t reach it. A firewall that admits too few checkers marks a working endpoint unhealthy, so allow the address ranges AWS publishes under ROUTE53_HEALTHCHECKS in ip-ranges.json.

At 14:06:00 the health URL starts failing. Three failed 10-second checks later, at about 14:06:30, hc-use1 is unhealthy and Route 53 stops returning the us-east-1 record. Latency routing now answers every query with us-west-2. A resolver that cached the old answer at 14:06:29 keeps it for 60 more seconds, so the last customers switch by about 14:07:30.

That is 90 seconds: 3 × 10 to notice, plus 60 of TTL. With standard 30-second checks it is 150. At 14:07:40 the phone asks again, which makes queries #6 and #7, and gets 198.51.100.140. The query count is 7. A failover policy, with one PRIMARY record and one SECONDARY, runs on the same clock.

An alias record can take its health from its target. The setting is called Evaluate Target Health. With it on, an alias to a load balancer is healthy only while every target group that has targets also has at least one healthy target. It needs no separate health check and adds no charge. It can’t be turned on for an alias to CloudFront.

A record with neither a health check nor this setting always counts as healthy, which is the usual reason a failover never happens. One more rule runs the other way: when every record for a name is unhealthy, Route 53 treats them all as healthy and answers from all of them.

Health checkers sit on the public internet, so they can’t reach a private address such as the shop’s database at 10.0.20.14. For anything private, a health check can watch a CloudWatch alarm instead. The alarm’s metric can be the database’s connection count, or a custom metric that a probe inside the VPC publishes.

The health check reads the metric’s data, not the alarm’s state. A setting says what missing data means: healthy, unhealthy, or the last known status. A calculated health check, one whose inputs are other health checks, combines up to 255 of them under a rule such as “healthy if at least 2 of 3 are”.

Changing a record is an API call, and Route 53’s API runs in us-east-1. That API is the control plane. Answering queries and running health checks is the data plane, and it runs everywhere. A failover plan that edits a record therefore depends on the Region it is trying to leave.

On 2025-10-19 at 23:48 PDT a race condition in DynamoDB’s own DNS automation left dynamodb.us-east-1.amazonaws.com with no addresses, and the effects lasted about 14.5 hours. So fail over without API calls. Health checks do that. So do routing controls in Amazon Application Recovery Controller (ARC): on/off switches served by five Regional endpoints, usable while any three answer, for $2.50 an hour, $1,825 a month.

Every VPC has a DNS server at its base address plus two. In 10.0.0.0/16 that is 10.0.0.2, and the same server also answers at 169.254.169.253. It is the VPC resolver, formally the Route 53 VPC Resolver (called Route 53 Resolver until 2026, and still in most exam material). Instances learn its address when they boot.

No security group or network ACL can filter traffic to it, and a query needs no internet gateway or NAT gateway to reach it. One limit does apply: each network interface may send it 1,024 packets a second, an allowance shared with the instance metadata and time services. The AWS VPC tutorial follows this app server’s packets through the filters that do apply.

A private hosted zone answers only queries from VPCs associated with it. The shop’s zone, aws.shop.internal, holds a record named db: a CNAME to the RDS endpoint. When the connection pool looks up db.aws.shop.internal, the VPC resolver follows the CNAME itself and returns 10.0.20.14 in one query, number 8.

Two VPC attributes must both be on for this to work, enableDnsSupport and enableDnsHostnames, and the second is off by default in every VPC except the default one. Every private zone also lists the same four reserved name servers in its NS record. They never answer for the zone on the internet.

The ending of the name is deliberate. ICANN set .internal aside for private names on 2024-07-29, so no registry will ever hand out a public name under it.

A public hosted zone and a private one can have the same name. That arrangement is split-horizon DNS: one question gets one answer from the internet and another from inside the VPC. Inside an associated VPC the private zone answers, and the public zone is never consulted.

The trap is a private zone that matches the domain and lacks the record. The VPC resolver then returns NXDOMAIN, the DNS status for “no such name”, and does not try public DNS. Create a private shop.example holding only admin, and api.shop.example stops resolving inside the VPC. When several private zones overlap, the one with the most specific name answers.

At boot the AWS SDK looks up secretsmanager.us-east-1.amazonaws.com, query 9, and gets 10.0.10.41, an address in the app subnet. That address belongs to an interface endpoint: a network interface in your subnet that leads to the service. With its private DNS setting on, the endpoint comes with a hidden private hosted zone for the service’s name. AWS manages that zone, and only the endpoint’s own VPC can read it.

The application’s code doesn’t change, because the name it looks up is the public one. The endpoint also has names of its own, which begin vpce-. Those are ordinary public DNS records, and they return the same private address to anyone who asks.

At 14:02:07, during the checkout, the app looks up the receipts bucket, shop-receipts.s3.us-east-1.amazonaws.com: query 10. The answer is a public S3 address, although the VPC has a gateway endpoint for S3. A gateway endpoint adds routes to the subnet’s route table and never changes DNS. The name resolves as it would anywhere, and the route table then keeps the packets inside AWS.

The VPC resolver fetched that answer from public DNS itself, asking from AWS’s own public addresses. Those questions are not counted here. The resolver is a fleet shared between customers, with a shared cache, and no log you own shows whether it asked anyone. It may even serve an answer past its TTL while the servers it would ask are failing.

Queries 8, 9 and 10 all went to 10.0.0.2, and each was answered from a different place. The query count is 10.

The VPC resolver tests every query name against a list of Resolver rules and uses the most specific match. Some rules are automatic. Each associated private hosted zone gets one, EC2’s own names get some, and one covers ., the root of every name. That last rule is called Internet Resolver, and it is why a name nothing else matches is looked up in public DNS.

A forwarding rule names a domain and up to six DNS server addresses, and the VPC resolver sends every query under that domain to those servers instead of answering it. It works like a mail redirection order: anything addressed to that domain goes to the other address, unopened.

The shop’s forwarding rule, rslvr-rr-onprem, sends shop.internal to 10.50.0.10 and 10.50.0.11. Names under aws.shop.internal still go to the private hosted zone, because that zone’s automatic rule names the longer domain.

During the checkout the app server asks 10.0.0.2 for stock.shop.internal: query 11. The forwarding rule matches, so the VPC resolver passes the query to an outbound Resolver endpoint. The shop’s is rslvr-out-hub: two network interfaces in the hub VPC, 10.1.10.20 and 10.1.11.20, in two Availability Zones.

One of those interfaces sends the question to the data centre’s DNS server at 10.50.0.10, over the private connection that joins the two networks. That is query 12, and it comes back with 10.50.4.20. The app’s VPC needs no route to the hub VPC for any of this. The resolver service carries the query to the endpoint itself.

One second later, at 14:02:08, the warehouse system has to confirm the reservation with the orders service in AWS, so it must find orders.aws.shop.internal. It asks the data centre’s DNS server: query 13. That server has a conditional forwarder, its own equivalent of a forwarding rule, for aws.shop.internal. The forwarder points at 10.1.10.10 and 10.1.11.10.

Those two fixed addresses are an inbound endpoint, rslvr-in-hub, in the hub VPC. The data centre’s server sends the question to one of them: query 14. A query that arrives at an inbound endpoint is answered as if it had been asked from inside the hub VPC, so the private hosted zone must be associated with that VPC. The answer is 10.0.10.90, the internal load balancer.

The endpoint is not optional. Servers outside AWS can’t query a VPC’s resolver at its .2 address, even over a private connection: AWS doesn’t support it.

Three mistakes follow from how rules are matched. The first is a forwarding rule and a private hosted zone with the same domain name. If both are called shop.internal, the forwarding rule takes every query and the zone’s records are ignored. Nothing warns you.

The second is a subdomain you want answered inside AWS while its parent domain is forwarded. That takes a system rule: a Resolver rule that tells the VPC resolver to answer a domain itself. A system rule for dev.shop.internal is more specific than the forwarding rule for shop.internal, so it wins for those names.

The third is a loop. Suppose a forwarding rule sends a domain to the data centre, and the data centre forwards that same domain back to an inbound endpoint. Associate the rule with the VPC that hosts that inbound endpoint, and a query can circle between the two networks.

Each endpoint address is a network interface that handles about 10,000 UDP queries a second. If the endpoint’s security group tracks connections, that can fall to as few as 1,500. AWS’s guidance is to add an address when one reaches 50% of its capacity, up to six per endpoint.

Each interface costs $0.125 an hour. The hub has two endpoints with two addresses each, so its 4 interfaces cost $365 a month at 730 hours, plus $0.40 for every million queries that pass through them. Putting each endpoint’s addresses in two Availability Zones is also what earns the 99.99% availability SLA.

Queries 11 and 12 took one name out to the data centre, and queries 13 and 14 brought another back in. That is 4 more, and the query count is 14.

AWS Control Tower builds a landing zone: accounts grouped into organizational units, shared logging and security accounts, guardrails that apply to every account, and a factory for new accounts. It creates no Resolver endpoint, rule or hosted zone.

AWS’s reference design adds a network account, here shop-network, with a hub VPC that holds the endpoints, the rules and the shared zones. Every other VPC keeps sending its queries to its own .2 resolver address. Chapter 04 priced the hub’s pair of endpoints at $365 a month, so 40 VPCs with pairs of their own would cost $14,600.

Landing Zone Accelerator, an AWS solution that deploys on top of Control Tower, takes this design as configuration. The sample declares the outbound endpoint, its forwarding rule and the organizational unit the rule is shared with.

AWS Resource Access Manager (RAM) is the service that lets one account share a resource it owns with others. shop-network uses it to share the forwarding rule rslvr-rr-onprem with the Workloads unit. A share can name single accounts, an organizational unit or the whole organization, and it stays within one Region.

Each receiving account then associates the rule with its own VPCs. It can use the rule and can’t edit it. The outbound endpoint behind the rule is shared indirectly: forwarded queries from every one of those VPCs leave through rslvr-out-hub, which the workload accounts never see.

Sharing with a unit has one catch. Move an account to a different unit, and its rule associations are deleted unless the rule is shared with the new unit too.

A private hosted zone is not a resource RAM can share. To let a VPC in another account read aws.shop.internal, the zone’s owner, shop-network, first runs create-vpc-association-authorization naming that VPC. The VPC’s owner, shop-prod, then runs associate-vpc-with-hosted-zone. Afterwards the zone’s owner deletes the authorization, and the association stays.

The Route 53 console offers neither step, so both are done with the CLI, an SDK or an infrastructure template. A zone accepts up to 300 VPCs. For the shop’s 40 VPCs the two required calls come to 80, and every new private zone repeats them.

A Route 53 Profile, available since 2024-04-22, is one shareable object that holds DNS settings: private hosted zone associations, Resolver rules, DNS Firewall rule groups, interface endpoints and query-logging settings. shop-network builds one, rp-shop-dns, and shares it with RAM. Each account then associates it once with each VPC.

Before the Profile, each of the shop’s 40 VPCs needed 4 kinds of association: zone, rule, firewall rule group and query log. That is 160 associations, and the Profile replaces them with 40.

Since 2026-11-09 a VPC can take two Profiles, ordered by priority. A Profile costs $0.75 an hour for up to 100 VPCs, which is $547.50 a month.

The public zone shop.example lives in shop-network, but the production deploy pipeline has to update one record in it, api.shop.example. An IAM condition key, route53:ChangeResourceRecordSetsNormalizedRecordNames, limits a role to the record names you list. A change batch that touches any other name is refused whole, including the changes that would have been allowed.

A team that needs more than one record gets a zone of its own. dev.shop.example is a separate hosted zone in shop-dev, and one NS record in the parent zone delegates it. Service control policies, the organization-wide rules that cap what any account’s roles may do, stop workload accounts removing the shared associations.

None of this sent a DNS question. Shares, associations, Profiles and policies are all configuration, so the query count stays at 14.

A compromised server can encode stolen data as one label of a name and then look that name up: aGVsbG8.x.attacker.example. The label aGVsbG8 is the word “hello” in base64. The server sends the question to the VPC resolver at 10.0.0.2, as it does for every name, and neither security groups nor network ACLs filter traffic to that address.

The VPC resolver fetches the answer from the internet as it would for any public name. That means asking the name server for attacker.example, which the attacker runs, and handing it the whole name. This is DNS tunnelling: data carried out inside the question itself. It works from a subnet with no route to the internet, because the resolver makes the outside connection.

The channel is narrow, and by default it is open in every subnet. A name can be 253 characters long, with each label up to 63, so one lookup carries a couple of hundred characters of payload. The checkout sends no such query, so the query count is still 14.

Route 53 Resolver DNS Firewall checks every query the VPC resolver receives against the rule groups associated with the VPC. Rules run in priority order, lowest number first, and the first rule whose domain list matches the name decides. There are three actions: ALLOW, ALERT (which lets the query through and logs it) and BLOCK. A block answers with NODATA, NXDOMAIN or a substitute name you choose.

The shop’s group, rslvr-frg-egress, has two rules. Priority 100 allows the domain list shop-allowed, and priority 200 blocks *, every other name, with NXDOMAIN. At 14:02:07 the app server looks up api.payments.example. Rule 100 matches, the resolver fetches the answer from public DNS, and the server gets 203.0.113.80. That is query #15. The encoded name from step 1 reaches rule 200 and gets NXDOMAIN.

DNS Firewall costs $0.60 per million queries it inspects. AWS also maintains managed domain lists of known malware and botnet domains, which any rule can reference at no extra charge. Their contents stay private: you can use a list, but no API call returns the domains in it.

A DNS Firewall rule group sits on one path: from a server to the VPC resolver at 10.0.0.2. A process that addresses its question to 8.8.8.8 on port 53 is making an ordinary internet connection, and no rule in the group runs. The same holds for DNS over TLS on port 853, and for DNS over HTTPS, which travels on port 443 like any other web request.

Closing the side path takes network rules. Leave outbound ports 53 and 853 closed in security groups, or deny them in network ACLs. Lookups through the VPC resolver keep working, because neither filter applies to its address. For DNS over HTTPS, AWS Network Firewall can block the known resolver hosts by name. GuardDuty has the same blind spot: its DNS findings cover only queries the VPC resolver handled.

One setting covers the case where DNS Firewall itself can’t evaluate a query. The default is to fail closed: the query is answered with SERVFAIL, so a broken filter stops lookups and never lets them pass unchecked. A VPC can be set to fail open when availability matters more than filtering.

With DNSSEC signing on, Route 53 returns a signature record, type RRSIG, with every answer from shop.example to any resolver that asks for signatures. The signature covers the address records and is made with a zone-signing key that Route 53 creates and manages. A resolver holding the matching public key can check that the answer came from the zone and wasn’t altered on the way.

The zone-signing key is signed in turn by a key-signing key, shop_ksk_2026, backed by a KMS key you own. That key must be customer managed and asymmetric, with key spec ECC_NIST_P256, and it has to be created in us-east-1 wherever the application runs. The AWS KMS tutorial covers asymmetric keys and the key policy that admits a service like Route 53.

To check the signature on answer #3, the customer’s resolver needs the zone’s public keys. At 14:01:30 it asks Route 53 for the DNSKEY records of shop.example: query #16. Signing is available for public hosted zones only, and Route 53 adds no charge for it. The KMS key is billed by AWS KMS.

A signature proves nothing until someone vouches for the key that made it, because a forger can sign with a key of their own. So the .example registry holds a DS record for shop.example: a hash of the shop’s key-signing key, which the shop submits through its registrar. The registry signs that record with its own key.

The same step repeats one level up. The root zone holds a DS record for .example, and every validating resolver ships with the root’s public key. Each key is vouched for by the zone above until the chain reaches a key the resolver already holds. That is the chain of trust. The root’s key changed on 2026-10-11, from key tag 20326 to key tag 38696, only its second change ever.

Order matters at both ends. To start, turn signing on first and add the DS record afterwards. A DS record that points at a key the zone doesn’t publish yet makes every validating resolver reject the zone. To stop, remove the DS record, wait out its TTL, and only then stop signing.

The key-signing key works only while Route 53 can use the KMS key behind it. Disable that key, schedule it for deletion, or change its key policy so that Route 53 is no longer admitted, and Route 53 can’t sign the zone’s keys again. The zone keeps answering at first. Route 53 holds signatures it made in advance, and they stay valid for the next few days.

When the last of them expires, every validating resolver refuses answers for shop.example, while resolvers that don’t validate keep resolving it. The outage arrives days after the change that caused it, and only for some customers. Two CloudWatch metrics report the problem well before that, so put an alarm on each: DNSSECInternalFailure and DNSSECKeySigningKeysNeedingAction.

Validating is a separate choice from signing. Inside a VPC it is a per-VPC setting on the VPC resolver, and the shop has it on, so the payment answer in step 2 was validated before the app server got it. That completes the chapter’s tally. Query #15, checked by DNS Firewall, and query #16, the key lookup, take the query count from 14 to 16.

Query logging for a public hosted zone writes one line for each query Route 53 receives. The lines go to CloudWatch Logs only, and the log group must be in us-east-1. A line has ten space-separated fields: a format version, the time, the zone ID, the name, the record type, the response code, the protocol, the edge location that answered, the resolver’s address, and the client subnet if the resolver sent one.

The line for query #5 ends 192.0.2.53 203.0.113.0/24. The first value is the customer’s resolver. The second is the phone’s network, cut to a /24 by that resolver before it asked. The phone’s own address, 203.0.113.50, appears nowhere in the line. The field IAD89-C1 names the Route 53 edge location that answered.

A lookup that a resolver answers from its cache never reaches Route 53, so it never produces a line. Of the checkout’s 16 queries, 4 reached Route 53 and have a line here: #3, #5, #7 and #16.

Resolver query logging records the queries the VPC resolver handles: those from servers in the VPC, those arriving from the data centre through an inbound endpoint, and those it forwards out. Each one becomes a JSON record in CloudWatch Logs, S3 or Amazon Data Firehose. One configuration can be shared across accounts, so the shop’s 40 VPCs log to one bucket in shop-logs. Route 53 charges nothing for it.

The record for query #15 holds the question in query_name and query_type, the result in rcode and answers, and the asker twice. srcaddr is the address 10.0.10.27, and srcids.instance is the EC2 instance ID. An address can belong to a different server by tomorrow. The instance ID still identifies this one.

Three more fields, firewall_rule_action, firewall_rule_group_id and firewall_domain_list_id, exist only on records whose query matched an ALERT or BLOCK rule. Allowed queries carry no firewall fields. Query #15 matched the ALLOW rule at priority 100, so its record has none of the three. The blocked name from chapter 06 would have all of them.

Every log source has a blind spot, and the Resolver query log’s is the least expected. AWS’s documentation says it holds “only unique queries”: when the VPC resolver answers from its cache, it writes no record. So the number of records for a name depends on its TTL as much as on how often servers ask. The public zone’s log has the same gap one level out: it misses whatever outside resolvers answered from cache.

The other two sources miss DNS questions altogether. VPC flow logs skip traffic to the VPC resolver entirely, as the AWS VPC tutorial shows for this same shop. CloudTrail records API calls, so it shows who changed a record and never who asked for one.

Counting log lines therefore undercounts queries, sometimes by thousands to one for a busy name. The logs tell you which names were asked, by whom, and what came back. They don’t tell you how often.

Place all 16 queries in the log that records them. The Resolver query log has 6: every question the app server sent to 10.0.0.2, plus the one that arrived through the inbound endpoint. The public zone’s query log has 4. The data centre’s DNS servers logged 2, in a log the shop owns and AWS never sees.

The other 4 were answered on servers the shop doesn’t run. Queries #1, #4 and #6 went from the phone to its resolver, and #2 went from that resolver to the .example registry. If one of them got a wrong answer, no log of the shop’s would show it.

For those the evidence is indirect. A health check or a synthetic probe run from outside shows whether the name resolves from where the probe sits. The public zone’s log shows a failure by omission: the line that should have followed, such as #3 after #2, and didn’t.

Two tools take caches out of the question. dig @ns-2048.awsdns-64.com api.shop.example sends the question straight to one of the zone’s four name servers, so the answer is what Route 53 holds now and not what a resolver cached a minute ago. It still depends on where you run it, because a latency record is chosen by the asker’s location.

aws route53 test-dns-answer removes that dependence. You supply a resolver address and a client subnet, and Route 53 reports the answer that pair would get, without any query being sent. It works for public hosted zones only. Run it during the outage with the customer’s resolver and phone, and the response holds 198.51.100.140, the us-west-2 address.

With caches ruled out, work down the path in order. Do the registry’s name servers match the zone’s? Is the health check healthy, and if not, what is its last failure reason? Which Resolver rule or hosted zone matched the name? Or is the answer correct and only old, still inside its TTL on some resolver?