DNS, DHCP and the services a network cannot run without

Why this matters

If you had to pick the two services whose failure produces the most support calls, it would be these. Between them they answer the two questions every connection begins with: what is my address, and what is the address of the thing I want?

They are also the two services whose failures are most often misdescribed. A user whose DNS has failed says "the internet is down", because from where they are sitting that is what it looks like. A user whose DHCP has failed says the same thing. Learning to separate those two states from an actual connectivity failure is one of the highest-value skills in this entire exam.

This objective is also where the exam asks for specific record types and specific DHCP fields, so there is a small amount of detail to hold alongside the model.

The lesson

What DHCP hands out besides an address, and why the other three fields matter more

DHCP is routinely described as "it gives the machine an IP address". It gives four things, and the address on its own is the least useful of them:

• The address, which identifies the host.
• The subnet mask, which tells the host which other addresses are local. Without a correct mask the host cannot decide whether to deliver directly or hand traffic to the router, which is the single most consequential decision it makes. Lesson 12 is entirely about this.
• The default gateway, which is where anything non-local goes. A host with no gateway can reach its own subnet perfectly and nothing else, and users describe that as "the internet is down" while the printer next to them works.
• The DNS server addresses, without which the host has connectivity and can resolve nothing. This is the state where an address pings and a name does not.

The exchange itself is four messages, and the mnemonic DORA is worth having: Discover (client broadcasts), Offer (server proposes), Request (client asks for the offered address), Acknowledge (server confirms). Because the first message is a broadcast, DHCP does not cross a router by itself — a relay agent is what forwards it, and its absence is the standard explanation for one subnet getting addresses while another does not.

Lease times, reservations and the difference between a reservation and a static address

A DHCP address is a lease with a duration. The client attempts renewal at half the lease time, and again later, and only falls back to a full discover if those fail.

The lease length is a real design choice:

• Short leases suit guest networks and high-turnover environments where addresses must be recycled quickly. The cost is more traffic and more frequent renewal.
• Long leases suit stable office networks. The cost is that addresses stay allocated to devices that have left, so a pool can exhaust.

A reservation ties a specific address to a specific hardware address, so the device always receives the same one — but it still receives it from the server, along with the mask, gateway and DNS settings. A static configuration is set on the device itself and the server knows nothing about it.

The difference is examinable and matters operationally. A reservation is managed centrally: change the DNS servers on the DHCP scope and every reserved device follows. A static address does not follow, which is why the machine somebody configured by hand two years ago is still pointing at a decommissioned resolver. Static addresses also have to be excluded from the pool by hand, and the address conflict that follows when they are not is a classic fault.

How a name becomes an address, step by step, and where each step can fail

The resolution path, in order, with the failure at each step:

1. The hosts file. Checked before anything else on most systems. An entry here overrides DNS entirely — useful for testing, and a classic malware persistence trick.
2. The local resolver cache. Holds recent answers, including negative ones. This is why a name that failed once keeps failing briefly after the problem is fixed.
3. The configured DNS server. Usually the router or an internal server.
4. Recursion. If the configured server does not know, it asks the root servers, then the top-level domain servers, then the authoritative server for the domain, and returns the answer.
5. The authoritative server holds the real record.

Failures to recognise:

• No DNS server configured: everything by name fails, everything by address works. This is the definitive test.
• DNS server unreachable: same symptom, different cause.
• Stale cache: one name resolves to an old address after a change.
• A hosts file entry: one name behaves differently from every other, and nothing on the network explains it.
• Wrong record at the provider: it fails for everyone, everywhere, which is how you tell it apart from all of the above.

Record types a technician meets: A, AAAA, CNAME, MX and TXT

The record types in scope, with what each is for:

• A — a name to an IPv4 address. The common case.
• AAAA — a name to an IPv6 address. Same job, larger address.
• CNAME — an alias from one name to another name. The lookup then continues on the target. Useful for pointing several names at one service, and the source of confusion when someone expects it to hold an address.
• MX — where mail for this domain should be delivered, with a preference value so that lower-numbered servers are tried first. A domain with no MX record receives no mail, which is a complete diagnosis on its own.
• TXT — arbitrary text, used in practice for domain ownership verification and for mail authentication policies.
• PTR — the reverse mapping, address to name. Used in logging and by mail servers as a sanity check on senders.
• NS — which servers are authoritative for the domain.

The technician-level habit is to query the record directly rather than inferring it from behaviour. nslookup on any platform, or dig where it is available, will return the specific record type asked for and will let you ask a specific server — which is how you distinguish a bad record from a bad resolver.

The hosts file, caching, and why a change takes effect on one machine and not another

DNS changes propagate unevenly, and almost every complaint of the form "it works for me and not for him" traces to one of three caches.

• The record's time-to-live. Every answer carries one, and resolvers are entitled to serve the cached answer until it expires. Lowering the TTL before a planned change is the professional preparation for a migration.
• The resolver's cache. The organisation's or the provider's server may hold the old answer for everyone behind it.
• The client's cache. Both the operating system and, separately, the browser keep their own. Flushing the operating system cache does not clear the browser's, which is why a page still resolves wrongly in one application and correctly in another.

The hosts file sits outside all of this. It is checked first, it never expires, and nothing on the network can override it. That makes it the right tool for testing a migration before the record changes — and it makes an unexpected entry a finding rather than a curiosity, since redirecting a well-known name locally is a standard malware behaviour.

The practical sequence when a name resolves wrongly on one machine: check the hosts file, flush the client cache, query the configured server directly, then query a known public resolver. Each step rules out one layer, and the layer where the answers start disagreeing is the one holding the stale record.