DNS and the Request Journey
Find the service before asking it for anything
Follow the responsibility
When someone opens shop.example, their device first needs an address for that name. DNS, the Domain Name System, answers questions about names. It is a lookup system; it does not carry the later shopping request.
Follow the lookup and the connection separately. A wrong address, an expired certificate and a slow database are different failures even though the visitor may only see a page that will not load.
What you’ll learn
- Trace name lookup and the later application request.
- Explain why cached DNS answers delay some routing changes.
- Plan routing changes without assuming instant failover.
Who answers the name lookup?
A recursive resolver does the lookup work for the device. If it has no usable cached answer, it can follow referrals from the DNS root to the relevant top-level domain, then to the domain’s authoritative name servers. The authoritative servers publish that domain’s records.
An A record identifies an IPv4 address; AAAA identifies an IPv6 address. A CNAME points to another name that must be resolved. The resolver returns the answer, and the device then connects to the service. Cached referrals can shorten later lookups.
A routing change has a transition period
A DNS answer has a time to live, or TTL: how long a cache may normally reuse that answer. If a resolver already cached the old address with 300 seconds remaining, changing the authoritative record does not push a replacement into that cache.
Lower the relevant TTL ahead of a planned change, allow existing cached answers to age, and keep the old endpoint working during the transition. Lower TTLs increase lookup traffic. Resolver policies and existing connections mean TTL alone is not an exact global cutover timer.
Choose a safe routing transition
Try the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Compare two practical situations. A DNS change and application failover need a shared plan, but they are separate mechanisms.
Use DNS tools without mistaking them for health checks
Self-hosted authoritative software includes BIND and PowerDNS. Managed services include Amazon Route 53 and Cloudflare DNS. A managed service removes some server operation, but you still own records, access permissions and the cutover plan. Compare pricing and capabilities in current provider documentation.
Inspect the record, authoritative response and cached response separately with a tool such as dig. DNS-based geographic routing can steer answers, but resolver location may differ from visitor location. It cannot make two databases agree or move an established connection.
Read RFC 1034’s DNS model. Product capacity depends on query patterns, cache hit rates and deployment; there is no universal requests-per-second value.
Check your reasoning
Check your reasoning
Bring the decisions together
Separate name resolution from transport and application work. Give record changes an overlap period and inspect the correct failure boundary.
Continue with protocols and proxies to follow the connection after lookup.
Reaching the recap and completing the quizzes are separate milestones.