The most surprising thing about DNS resolution is that your computer often doesn’t actually ask the authoritative DNS server for a record; it asks a recursive resolver that already knows the answer.
Let’s see this in action. Imagine you want to know the IP address for example.com.
You’d typically run:
dig example.com
This command, by default, sends a DNS query to the resolver configured on your local machine. On most Linux/macOS systems, this is found in /etc/resolv.conf.
nameserver 127.0.0.53
search example.local
Here, 127.0.0.53 is likely systemd-resolved, which acts as a local caching resolver. It will first check its cache. If it doesn’t have the answer, it will then query other DNS servers, like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1.
To directly query a specific DNS server, like an AWS Route 53 resolver, you can use the +short option with dig and specify the server’s IP address. For Route 53, you’ll often use the public DNS resolvers provided by AWS, which are 172.31.0.2 (within a VPC) or 53.25.0.1 (the AWS Public DNS). However, to test your specific Route 53 hosted zone, you’ll want to query the Route 53 Resolver endpoint within your VPC.
If you have a Route 53 Resolver inbound endpoint set up, you can find its IP address in the AWS console. Let’s say it’s 10.0.1.10. To query an A record for myapp.example.com from that endpoint, you’d run:
dig @10.0.1.10 myapp.example.com A +short
This command tells dig to send the query directly to the IP address 10.0.1.10 (your Route 53 Resolver inbound endpoint) for the A record of myapp.example.com. The +short option strips away all the extra DNS message details, giving you just the IP address if it’s found.
To query for a CNAME record:
dig @10.0.1.10 myapp.example.com CNAME +short
To query for an MX record:
dig @10.0.1.10 example.com MX +short
This direct querying is crucial for troubleshooting. If dig example.com works but dig @10.0.1.10 myapp.example.com A +short doesn’t, you know the problem isn’t with your local machine’s DNS configuration or general internet connectivity, but specifically with how your Route 53 hosted zone is configured or how your VPC’s DNS is set up to resolve to it.
When you create a private hosted zone in Route 53 and associate it with a VPC, Route 53 automatically creates a DNS resolver for that VPC. This resolver is accessible via the .2 address of your VPC’s DNS server. For example, if your VPC’s DNS server is 10.0.0.2, you can query your private hosted zone records using:
dig @10.0.0.2 myapp.example.com A +short
This is the most common way to test private hosted zone resolutions from within the VPC.
The reason Route 53 resolvers are so fast for records within your hosted zones is that they are co-located within your VPC. When you query 10.0.0.2 for myapp.example.com, the request doesn’t need to traverse the public internet to find an authoritative server. It’s handled locally by the AWS infrastructure responsible for your VPC’s DNS.
One common pitfall is assuming that the public Route 53 DNS servers (53.25.0.1, 53.25.1.1) can resolve your private hosted zones. They cannot. Those public resolvers are for public records and are not aware of your private VPC resources. You must use the VPC’s .2 DNS server or a Route 53 Resolver endpoint configured for your VPC.
If you are querying a public Route 53 hosted zone from outside AWS, you can use public DNS servers like 8.8.8.8 or 1.1.1.1, or even AWS’s public DNS resolvers.
dig @8.8.8.8 mypublicapi.example.com A +short
This command directly asks Google’s public DNS resolver to find the A record for mypublicapi.example.com. The 8.8.8.8 server will then perform its own recursive lookup, eventually finding the authoritative Route 53 servers for that domain.
The next step is understanding how to simulate different network conditions or test DNSSEC validation using these tools.