Walk through how api.example.com is resolved to an IP address when nothing is cached.

The OS asks a recursive resolver, and that resolver walks from the root servers, to the .com servers, to the domain's own servers.

Step by step:

• Your application calls the OS resolver (the stub resolver). It checks /etc/hosts and any local cache first.
• Then it sends a recursive query to the configured recursive resolver. Examples are your ISP's resolver, your cloud provider's resolver, or 1.1.1.1. This resolver does the real work.
• The resolver asks a root server. The root server doesn't know the answer. It sends back a referral: the name servers for .com.
• The resolver asks a .com TLD server (TLD means top-level domain). It sends back a referral to the authoritative name servers for example.com. These come from the domain's NS records.
• The resolver asks one of the authoritative servers. That server returns the A or AAAA record for api.example.com. Sometimes it returns a CNAME instead, and the resolver must do another lookup for the CNAME's target.

The resolver returns the answer to your application. It also caches each step for that record's TTL (time to live). So the next lookup under example.com skips the root and TLD servers.

Queries use UDP port 53. Large responses use TCP instead.