What happens when a device looks up a domain name?¶
Before a device can connect to a service such as example.org, it usually needs to find an IP address for that name. It does this through the Domain Name System (DNS).
The short version¶
The device checks for an answer it already has. If there is no usable answer, it asks a DNS resolver. The resolver finds the relevant DNS record and returns it. The device can then try to connect to the address supplied.
The lookup supplies a route to try. It is not the connection itself.
A DNS answer can also be false if a response or cache has been manipulated. This is often described as DNS spoofing, DNS poisoning or cache poisoning. Establish which resolver supplied the answer and compare its records with the expected authoritative data before assuming the returned route was genuine.
The lookup, step by step¶
- The application asks for a name. A browser, app or background service needs information about a domain.
- The device checks locally. The browser, operating system or router may already hold a cached answer.
- The device asks a resolver. If there is no usable local answer, the query goes to a DNS resolver. This may be operated by an internet provider, workplace, mobile network or public DNS service.
- The resolver finds the answer. It may use its own cache or follow the DNS hierarchy to the authoritative server for the domain.
- The answer returns. This may include an IPv4 or IPv6 address, an alias or another type of DNS record.
- The application tries the connection. The returned address gives the application somewhere to connect.
Follow one ordinary lookup¶
Dave types shop.example into a browser. The browser has no saved answer, so the laptop asks its configured resolver. The resolver returns two addresses and the browser tries one of them.
| Stage | Example record or state | What it can establish |
|---|---|---|
| Application request | Browser asks for shop.example | The browser needed DNS information for that name |
| Resolver query | shop.example, type A, client 192.168.1.24 | The named client asked that resolver for an IPv4 answer |
| Resolver answer | 198.51.100.20, TTL 300 | That resolver supplied this address with a five-minute cache lifetime |
| Connection attempt | Destination 198.51.100.20:443 | A separate record is needed to show that a connection was attempted |
| Application activity | URL, page or account event | Browser, proxy or service records are needed to show what was requested or done |
The rows may be held by different systems. A resolver log does not automatically contain the later connection, and a network record showing the address may not retain the domain name.
Why different devices may get different answers¶
A name can lead to several IP addresses. Services use this to spread demand, recover from failures or direct users to nearby infrastructure. Cached answers can also mean two devices briefly receive different results.
What to look for in an investigation¶
If a DNS lookup matters, try to establish:
- the domain name requested;
- the date, time and time zone;
- where the query was recorded;
- the apparent client address or device;
- the query type; and
- the answer returned, if it was logged.
The lookup and the later connection are separate events. Use the DNS record to understand how the device found the service, then look for the connection, application or device records that show what happened next.
Operational takeaway
Treat the DNS question, DNS answer and later connection as linked but distinct events. Preserve the name, query type, answer, timestamp and observation point, then compare them with the connection and application records.
