What it means
DNS gives applications a way to look up information associated with a name. Address records commonly connect a website name to an Internet Protocol address, while other record types support functions such as email routing. A recursive resolver finds answers on a client's behalf; authoritative servers publish the records for a domain.
Answers can be cached for a limited time, so a record change may not appear everywhere immediately. Security work involves both protecting the ability to change records and understanding what the observed answer means. A correct DNS answer does not prove that a website is safe, and DNS alone does not authorize access to an application.
See the idea / Networks
Find the address. Then connect.
Follow a DNS answer back to your browser before a separate connection to the website.
An uncached IPv4 lookup for atlas.example. All names and addresses are illustrative.
01 / 06
Name
Your browser needs an address for atlas.example. It has not contacted the website yet.
More about this step
Applications use a resolver to look up DNS records. The browser and its local resolver are grouped here; the recursive resolver is a separate service. This example asks for an A record, which contains an IPv4 address.
Step through at your own pace.
Keep in mindOne successful lookup. Root and top-level-domain referrals are omitted; a cached answer can skip the authority visit. Other record types, IPv6, DNSSEC, and errors are outside this example. An address answer does not establish that a website is trustworthy.
Read the visual, step by step
- Name. Your browser needs an address for atlas.example. It has not contacted the website yet. Applications use a resolver to look up DNS records. The browser and its local resolver are grouped here; the recursive resolver is a separate service. This example asks for an A record, which contains an IPv4 address.
- Ask. Your device sends a DNS question to the recursive resolver. The website does not receive this question. The query names atlas.example and requests its A record. This resolver will obtain an answer for the client. DNS traffic may use different transports; the picture does not claim it is an HTTPS request to the website.
- Find. The resolver has no usable cached answer. It asks an authoritative DNS server for the record. The resolver can follow referrals through the DNS hierarchy to locate the appropriate authority. Those intermediate exchanges are omitted here. When it already holds a usable cached record, it can answer without this visit.
- Receive. The authoritative server replies to the resolver with an address record. The browser is still waiting. The illustrative A record contains 192.0.2.20. This address belongs to a range reserved for documentation; it is not a real destination for this example. A usable DNS answer can be cached according to its lifetime.
- Answer. The resolver returns the address to your device. The browser gets it only after that response arrives. The DNS reply returns to the requester. Neither the question nor its address answer goes from the resolver to the website. Receiving an address does not authenticate the website or guarantee safe content.
- Connect. Your browser uses the address to start a separate connection to the web service. DNS lookup is finished. Connection setup and any TLS or HTTP conversation are later operations between the client and web service. The resolver does not forward the browser’s web request. This chapter shows starting that connection, not proving that the service is safe or that the connection succeeded.
One successful lookup. Root and top-level-domain referrals are omitted; a cached answer can skip the authority visit. Other record types, IPv6, DNSSEC, and errors are outside this example. An address answer does not establish that a website is trustworthy.
Flow references: RFC 1034: resolvers and name servers · RFC 1035: queries, replies, and caching · RFC 5737: documentation addresses
AN ILLUSTRATIVE SCENARIO
A charity website move
A charity moves its donation website to a new hosting service. Its administrator updates the domain's address records, but some visitors still reach the old service because their resolvers retain cached answers. The administrator compares the authoritative records with answers from several resolvers and checks the record's time to live, or cache duration. Meanwhile, the team protects the domain management account and verifies that both the old and new endpoints behave safely during the transition.
Put it to work
- Identify who manages domain registration, authoritative DNS, and the resolver used by your devices; these may be different services and owners.
- Record important names, record types, intended destinations, and cache durations before a planned change; protect the accounts that can edit them.
- Check authoritative and resolver answers after the change, then verify the actual application and its certificate at the intended destination.
dig example.com A
dig example.com AAAAHow to check your work
Compare a documented expected record with an authoritative answer and a client lookup. Confirm that the application reached through that name is the intended service and that change ownership is clear.
Connect the ideas
- IP address
A numeric locator used to deliver packets to a host on a network.
- HTTP
The application protocol that names methods, paths, headers, and bodies for web requests.
- TLS
A protocol that encrypts and integrity-protects an application conversation and checks a certificate for a name.
- Asset
Anything whose disclosure, alteration, destruction, or downtime would harm a person or organization.