cerf
Vendor-neutral design pattern

Vendor-neutral design pattern

Enterprise DNS, DHCP, and NTP: designing and troubleshooting the three services that make a network usable

A client that cannot get an address, resolve a name, or trust its clock is off the network. Here is how the three core services fit together and how to find the one that broke.

Three services, one dependency chain

Almost every workstation session begins with the same three questions, answered in order. Who am I on this network? DHCP answers that with an address, subnet mask, default gateway, and a list of options. What is the name I am trying to reach? DNS answers that by translating names to addresses and back. What time is it? NTP answers that so logs line up, certificates validate, and authentication tickets are accepted.

The order matters because the services depend on each other. DHCP is what usually hands the client its DNS resolver (option 6) and, in many designs, its NTP server (option 42). DNS lookups can time out if the resolver address the client received is wrong. Time-based authentication and certificate checks fail if the clock is off by more than the allowed skew. When a user says the network is down, the real question is almost always which of these three broke first, because a failure early in the chain looks like a failure everywhere after it.

The DHCP -> DNS -> NTP dependency chain a client walks at boot
The DHCP -> DNS -> NTP dependency chain a client walks at bootCore network servicesTime-dependent services1. get address + optionssets gateway (option 3)hands resolver (option 6)hands NTP (option 42)2. resolve name3. sync clocktime gates tickets / certsaligns timestampssession beginsWorkstationboots with no configDHCP serveranswers 'who am I?'DNS resolveranswers 'what am I …NTP serveranswers 'what time …Default gatewayoption 3Applicationserverthe actual targetAuth /certificate…Kerberos, TLSLogging / SIEMcorrelation
Trace
Every workstation session answers three questions in order: who am I (DHCP), what am I reaching (DNS), what time is it (NTP). DHCP is what hands the client its DNS resolver (option 6) and NTP server (option 42), so a failure early in the chain looks like a failure everywhere after it.

DHCP with a relay: how a broadcast reaches a server on another subnet

A booting client has no address, so it cannot send a normal routed packet. It broadcasts a DHCP Discover, and the exchange that follows is the four-step DORA sequence: Discover, Offer, Request, Acknowledge. That works trivially when the server sits on the same broadcast domain, but routers do not forward broadcasts, and in an enterprise the DHCP servers live centrally, not on every VLAN.

The fix is a DHCP relay agent, configured on the router or Layer 3 switch that owns the client's gateway and commonly called an IP helper. The relay catches the client broadcast, rewrites it as a unicast aimed at the configured server address, and records the subnet the request arrived on so the server can pick the matching scope. The server then leases an address from that scope. A scope carries far more than addresses: a lease time, exclusions for statically assigned devices, reservations that bind a specific MAC to a fixed address, and options such as option 3 (gateway), option 6 (DNS), and option 42 (NTP). Get the relay right and one central pair of servers can address hundreds of subnets. Get it wrong and an entire VLAN falls back to APIPA.

DHCP DORA across a relay: a broadcast reaches a server on another subnet
DHCP DORA across a relay: a broadcast reaches a server on another subnetBranch VLAN 10.20.10.0/24HQ data center 10.10.0.0/16Central DHCP + option servers1. Discover (broadcast)same relay pathunicast, giaddr = 10.20.10.12. relayed Discover UDP 67failover / split scopeoption 6 in leaseoption 42 in leaseno reply -> link-localBooting clientno IPv4 addressOther VLANhostssame broadcast doma…DHCP relay (IPhelper)L3 switch / routerAPIPA fallback169.254.0.0/16Core router10.10.0.0/16DHCP primaryscopes + optionsDHCP secondaryfailover / split sc…DNS resolverdelivered as option…NTP serverdelivered as option…
Trace
A booting client broadcasts a Discover it cannot route. The relay agent (IP helper) on the VLAN gateway rewrites it as a unicast to the central server, setting giaddr so the server picks the matching scope, then returns Offer and Ack. The lease itself carries options 3, 6, and 42. If no reply is heard the whole VLAN falls back to APIPA.

DNS: authoritative zones, recursion, and the records that matter

A resolver plays two different roles and the exam rewards keeping them straight. It is authoritative for zones it owns, meaning it holds the real records and answers with authority. It is recursive for everything else, meaning it chases the answer on the client's behalf and returns a non-authoritative result. In the design here the internal resolver is authoritative for the company's forward zone and reverse zone, and recursive for the public internet, forwarding those queries out through the edge firewall.

Forward zones map names to addresses: A for IPv4, AAAA for IPv6, CNAME for aliases, MX for mail routing, TXT for text records like SPF, and NS for the nameservers of the zone. The reverse zone does the opposite with PTR records, mapping an address back to a name, which is what mail servers and logging systems check. Primary and secondary servers keep zones redundant, with the secondary pulling copies from the primary. Layered on top are the hardening options: DNSSEC signs records so a resolver can detect tampering, while DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the query itself so it cannot be read or altered in transit.

DNS: authoritative zones, recursion, and the records behind each answer
DNS: authoritative zones, recursion, and the records behind each answerCorporate networkInternet edgePublic DNSDNS service tierquery name (DoT / DoH)internal name: authoritative A/AAAAaddress -> name: PTRzone transfer AXFR/IXFRexternal name: recurseoutbound 53 / 853walk delegationauthoritative answerInternal clientresolver from optio…Internal DNSresolverauthoritative + rec…Forward zoneA AAAA CNAME MX TXT…Reverse zonePTRSecondary DNSzone transferEdge firewallUDP/TCP 53, 853Internet0.0.0.0/0Root / TLDserversdelegation chainExternalauthoritative…target domain
Trace
The internal resolver is authoritative for the company's forward and reverse zones (it answers with authority) and recursive for the public internet (it chases the answer and returns it non-authoritative). A secondary pulls the zones for redundancy; DNSSEC, DoT, and DoH harden the records and the query.

NTP: the stratum hierarchy and why clocks are a security control

Time synchronization is built as a hierarchy measured in strata. A stratum-0 device is a real reference clock such as GPS or an atomic source. A server directly attached to one is stratum 1. A server that syncs to a stratum-1 source is stratum 2, and so on, with each hop away from the reference adding a stratum number. The design here runs an internal stratum-2 server that disciplines its clock to a public stratum-1 source and then serves that time to every router, switch, server, and client at the site, one stratum down.

Centralizing time this way is not just tidiness. Correlating logs across devices during an incident is impossible if their clocks disagree. Certificate validation rejects a certificate whose validity window does not include the current time. Kerberos-style authentication refuses tickets outside a tight skew. For higher-precision needs there are alternatives: Precision Time Protocol (PTP) for sub-microsecond accuracy, and Network Time Security (NTS) which adds cryptographic authentication so a client can trust that its time source has not been spoofed.

NTP stratum hierarchy: from a reference clock down to every client
NTP stratum hierarchy: from a reference clock down to every clientExternal timeInternet edgeSite time distributionreference (stratum 0 -> 1)public NTPUDP 123 / NTSupstream syncserve stratum 3serve stratum 3serve stratum 3time gates certs / ticketssub-microsecond (hardware TS)Stratum 0referenceGPS / atomicPublicstratum-1…attached to referen…Internet0.0.0.0/0Edge firewallUDP 123 / NTSInternalstratum-2…site time sourceRouters /switchesstratum 3Serversstratum 3End clientsstratum 3Auth /certificate…tight skewPTP grandmastersub-microsecond
Trace
Each hop away from the physical reference adds a stratum. A public stratum-1 source is wired to a stratum-0 clock; the internal server syncs to it (making it stratum 2) and serves time one stratum down to routers, servers, and clients. Correct time gates certificate and ticket validation, so blocked UDP 123 corrodes the whole site.

Troubleshooting: read the symptom, isolate the service

The fastest diagnosis starts from the address a client actually holds. An address in 169.254.0.0/16 is APIPA, the automatic self-assignment a host falls back to when it hears no DHCP reply at all. That points at the relay, a down link to the server, or a scope that has run out of leases (address pool exhaustion). By contrast, a client that has a valid address but cannot reach anything past its own subnet usually has an incorrect default gateway; one that cannot reach some local hosts but not others often has an incorrect subnet mask; and intermittent, address-specific outages that appear right after a new device joins point to a duplicate IP address.

Name problems are their own layer. If ping to a name fails but ping to the raw address succeeds, the transport is fine and DNS is the suspect: check that the client received the right resolver, that the A record exists, and that the reverse PTR matches where it is required. Time problems are quieter but corrosive: an NTP offset that keeps growing, or clients that never sync, usually trace to UDP 123 being blocked at a firewall or to the internal server itself having lost its upstream. The discipline is always the same. Confirm which of address, name, and time is actually broken before touching anything, because fixing the wrong layer just adds a second change to unwind.

Troubleshooting: read the symptom, isolate address, name, or time
Troubleshooting: read the symptom, isolate address, name, or timeNo lease (address never assigned)Valid lease, wrong parametersName layer (DNS)Time layer (NTP)169.254 APIPA: no replyAPIPA: server link downAPIPA: pool exhaustedvalid IP, nothing past subnetsome local hosts onlyintermittent after new devicename fails, IP worksclock drifts / never syncsAffected client'network is down'Relay / IPhelperAPIPA causeDHCP server /linkAPIPA causeScope / addresspoolAPIPA causeDefault gatewayoption 3Subnet masklocal scopeDuplicate IPaddressARP conflictDNS resolver +recordsname layerUDP 123 / NTPupstreamtime layer
Diagnosis starts from the address the client actually holds. A 169.254 address means no lease; a valid lease with wrong reach points at gateway, mask, or a duplicate IP; name fails but IP works isolates DNS; a growing clock offset isolates NTP. Confirm which of address, name, and time broke before changing anything.

Sources

Practice what you just read

6 questions from this architecture

Loading…