Networking / Basic: packet paths and addressing / Lesson 6

Connect naming and automatic configuration

Explain what DNS and DHCP each provide, how caches and leases differ, and why successful bootstrapping does not establish application connectivity.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Distinguish authoritative naming from recursive lookup.
Describe DHCPv4 discovery and configuration options.
Separate lease state, resolver state, and service health.

DNS maps names to typed data

DNS stores resource records under hierarchical names. An A record carries an IPv4 address and an AAAA record carries an IPv6 address; other types have different meanings. A name can have several answers, aliases, or no answer for the requested type. An authoritative server publishes data for a zone, while a recursive resolver follows the necessary referrals and can cache results for clients. The user-facing name is not automatically identical to the machine’s local hostname. Record the query name, type, resolver, response, and time before describing what a lookup established.

A cached answer has a lifetime

TTL controls how long a record may remain cached under the relevant DNS rules; it is not a promise that every client refreshes at exactly the same instant. Different resolvers can therefore show different valid views during a planned change. Negative answers can also be cached under their own rules. Do not replace a resolver merely because one cache has not yet reflected a change. Distinguish NXDOMAIN, no data for a type, and a temporary server failure rather than calling all of them name not found. Later lessons examine validation and encrypted resolver transports.

python Read typed records from an offline zone fixture

records = {('report.example', 'A'): ['192.0.2.20'], ('report.example', 'AAAA'): ['2001:db8::20']}
for kind in ('A', 'AAAA'):
    print(kind + '=' + ','.join(records[('report.example', kind)]))

Expected output

A=192.0.2.20
AAAA=2001:db8::20

The dictionary models two record types for a reserved example name. It performs no DNS lookup and does not claim the name exists on the public Internet.

DHCP supplies configuration through a lease exchange

DHCPv4 can provide an address lease and options such as a subnet mask, router, and DNS servers. A typical initial exchange is described as Discover, Offer, Request, and Acknowledge, but renewals and other state paths differ. The server’s offer is not proof that the client accepted or installed the configuration. Relays can carry client exchanges between subnets and servers, which means the server need not share the client’s Ethernet domain. Keep client identity, subnet selection, offered options, and lease timing together. DHCP does not replace routing or authenticate an application server.

Lease expiry and DNS expiry are different clocks

A DHCP lease controls the client’s right to use assigned configuration under the protocol’s state machine. Renewal and rebinding occur according to supplied or derived timers, while DNS TTL governs cached naming data. Confusing these clocks can lead to an incorrect diagnosis after a device moves or a record changes. A valid lease can include an incorrect router or resolver option, and a static client can bypass DHCP entirely. Inspect the complete intended configuration rather than only the address string. The following calculation is a declared timing fixture, not a DHCP client implementation.

python Calculate remaining time in a synthetic lease

lease_start = 1000
lease_seconds = 3600
observation = 2200
remaining = max(0, lease_start + lease_seconds - observation)
print(f'synthetic_remaining={remaining}s')

Expected output

synthetic_remaining=2400s

The fixture has 2,400 seconds remaining at the declared observation time. It does not inspect a host lease or infer renewal state from this one number.

Check the bootstrap chain one dependency at a time

A client needs usable local addressing, an appropriate route, a reachable resolver when naming is needed, and then the destination protocol path. DNS can succeed while the application port is unavailable, and an address can be assigned while the default route is missing. A browser cache or hosts-file rule can also make one application’s name behavior differ from a direct resolver query. State which source produced the answer and which configuration the application actually used. This course reasons from fixtures only and never renews a lease, changes a resolver, or sends discovery traffic.

Common errors and fixes

A DHCP offer is treated as installed configuration

Why it happens: Intermediate exchange state was confused with client completion.
How to fix it: Distinguish offer, acknowledgement, and applied state.
Prevent it next time: Record the full state transition.

DNS TTL is treated as a lease duration

Why it happens: Naming cache and address configuration clocks were conflated.
How to fix it: Track each protocol’s timers separately.
Prevent it next time: Label timing fields with protocol and scope.

All DNS failures are called NXDOMAIN

Why it happens: Response categories and temporary errors were ignored.
How to fix it: Preserve the exact response type and query.
Prevent it next time: Test no-name, no-type, and server-failure cases.

Check your understanding

1. A client has a valid lease and resolves a name, but the service fails. What remains unproved?

Show worked solution

The selected destination’s transport, TLS identity, and application behavior remain separate. Also confirm that the application used the observed address family and answer. Neither lease validity nor DNS success guarantees the rest of the request path.

2. Why might two resolvers disagree briefly after a record update without either being broken?