DNS and DHCP in a Capture

DNS and DHCP are the two protocols that decide whether a device can do anything at all, and both are still mostly plaintext. That makes them the highest-value captures in a district: a ten-second trace answers questions that an hour of guessing will not.

DNS on the wire

A query is small and self-describing:

The RCODE is the diagnosis. NXDOMAIN means the name does not exist in the zone that answered. SERVFAIL means the resolver tried and failed — a broken delegation, DNSSEC validation, or an upstream problem. A timeout is not a DNS answer at all; it is silence.

Useful filters:

dns                                  all DNS
dns.qry.name contains "marionisd"    one namespace
dns.flags.rcode == 3                 NXDOMAIN only
dns.time > 0.2                       slow answers
dns.flags.truncated == 1             TCP fallback happened

Reading a DNS failure

1. Did the query leave? If not, the client is misconfigured or the capture point is wrong.
2. Did anything answer? No response means the resolver is unreachable or filtering silently.
3. What was the RCODE? NXDOMAIN and SERVFAIL are different problems.
4. How long did it take? 2 ms is a cache hit; 900 ms is a full recursion; 5 s is a timeout.
5. Was it retried? The same question with a new ID, seconds apart, means the first answer never arrived.

A client that queries two resolvers in sequence is normal: the first timed out, and it moved to the second. That pattern tells you one resolver is broken even though the user saw a working page.

DHCP on the wire

The four packets carry more than an address:

A relay adds giaddr, the address of the interface the request arrived on. That field is how the server chooses a scope, and it is the first thing to check when a new VLAN gets no addresses.

A NAK means the server is refusing: the client asked for an address on the wrong subnet, or the lease is no longer valid.

Two Offers for one Discover means two DHCP servers are alive on that segment. That is either a misconfigured failover pair or a rogue server, and the capture shows both server IDs.

Worked example: the 169.254 laptop

A staff laptop shows 169.254.12.9. Capture on the access switch uplink for 30 seconds:

10:22:01.004  client → broadcast  DHCP Discover
10:22:04.010  client → broadcast  DHCP Discover (retry)
10:22:10.021  client → broadcast  DHCP Discover (retry)

No Offer. Three possibilities, in order of likelihood:

1. No relay on the VLAN — the broadcast never reached a server.
2. Scope exhausted — the server heard it and had nothing to give. (Then you would see nothing at the client, but the server log shows the request.)
3. Server unreachable — relay configured, path broken.

The capture proves the client is asking correctly. The next step is on the gateway, not the laptop.

What breaks in production

• A capture filter of port 53 misses DNS over HTTPS, which is exactly the case you were investigating.
• Capturing only the client side, so you cannot tell whether the resolver answered.
• Ignoring the relay address, then blaming the server for a scope that was never selected.
• Reading a retry as a second query, when it is the same question with a new transaction ID.
• Truncated captures that cut the answer section off, so the address is missing.

Checklist

1. You read the RCODE before forming a theory.
2. You check whether the query left and whether anything answered.
3. You know which resolver the client used, and whether it was the intended one.
4. You check giaddr on any DHCP capture from a relayed VLAN.
5. You look for two Offers, not just one.
6. Your capture filter includes 443 when DoH is possible.

Next

The web is encrypted, but the handshake is not entirely. Continue with TLS and QUIC in a Capture.