There’s an old haiku that turns up taped to monitors in network operations rooms everywhere:

It’s not DNS.
There’s no way it’s DNS.
It was DNS.

It’s funny because it keeps being true. DNS and DHCP are the quietest services on most networks. Nobody looks at their dashboards on a good day, they rarely come up in a budget meeting, and when they’re healthy, nobody thinks about them at all. Then one of them stops, and within minutes the help desk hears that “the internet is down”, “Teams is broken” and “the printers are gone”, all at once, from every building.

This post is a practical look at that moment. What does a DNS or DHCP disruption actually take down? How long do you have before people notice? And how do you find out, on your own schedule, whether your network rides through it?

Two services everything stands on

Every device that joins your network asks DHCP for an address. Almost every connection it makes after that starts with a DNS lookup. Laptops, phones, desk phones, printers, badge readers, cameras, building controls, lab instruments and the virtual machines in your data centre all take the same two steps before they do anything useful.

That’s what makes these services different from most of what you run. An email outage affects email. A DNS outage affects everything that uses a name, which is nearly everything. And because the symptoms look like other problems, the first half hour is often spent chasing the wrong one.

What breaks when DHCP stops

DHCP fails slowly, which is both a mercy and a trap.

A device that already has a lease keeps using its address. Under the DHCP standard, a client tries to renew with its own server halfway through the lease, then asks any server that will listen at about seven eighths of the way through. Only when the lease runs out does it have to give the address up. So when your DHCP service goes down, nothing seems to happen at first. The damage arrives on a schedule, and your lease times set it.

Who	Typical lease	When they feel it
Anything that joins after the outage starts	Any	Right away: no address, no network
Guest and public Wi-Fi	30 minutes to a few hours	Within the hour, in waves
Staff and student wireless	A few hours to a day	Over the morning or the afternoon
Wired desktops	Often days (eight is the Windows Server default)	Possibly not for days

The first row is the one that surprises people. “Anything that joins” includes a laptop waking from sleep in another building, a phone roaming onto a new wireless network, a desk phone rebooting after a power blip, and every machine you try to image with PXE boot. It includes the patient monitor a nurse just plugged in. It includes every virtual machine your automation tries to build.

When leases do start to expire, devices drop off one at a time. Some fall back to a self-assigned 169.254 address and look connected while reaching nothing. The help desk sees a trickle that becomes a flood, with no single moment that says “DHCP is down.”

Two more traps are worth knowing about.

Sites that borrow their DHCP. Many organizations run DHCP centrally and relay each site’s requests to it. That’s a sensible design until the link to a site goes down. The site’s switches and access points are fine, its local servers are fine, and nobody new can get an address, because the DHCP server is on the far side of a broken link.

The recovery stampede. When a long outage ends, every device that lost its lease asks for a new one at the same moment. A server that copes easily with a normal Monday morning can struggle with ten thousand clients arriving in the same minute.

What breaks when DNS stops

DNS fails fast. Within seconds of your resolvers going quiet, anything that needs a fresh lookup stalls. Cached answers carry some things for a while, until their time to live runs out, which is why a DNS outage often looks patchy: one site works and another doesn’t, one browser tab loads and the next one hangs.

The list of what depends on DNS is longer than most people expect:

Sign-in. In an Active Directory domain, computers find their domain controllers through DNS. When DNS fails, logons, Kerberos tickets and Group Policy fail with it. Laptops with cached credentials can still unlock; anything that needs a fresh ticket can’t.
Single sign-on and MFA. Your identity provider, its multifactor service and the certificate checks behind them are all reached by name.
Email. Mail delivery runs on MX records, and the checks that keep spoofed mail out (SPF, DKIM and DMARC) are DNS lookups too.
Every cloud service. Microsoft 365, Google Workspace, your learning or patient records platform, your payroll system: all reached by name.
Your own applications. Databases, message queues, storage and APIs that find each other by hostname, especially on container platforms, where service discovery is DNS.
Phones. Many IP phones find their call servers by name and re-register on a schedule.

A second failure is quieter. When your internal primary DNS server is down, the secondaries keep answering for your zones, but only for so long. Every zone carries an expiry timer in its SOA record. If a secondary can’t reach its primary for longer than that, it stops answering for the zone entirely. A primary that’s been dead over a long weekend can take its secondaries down with it on Tuesday.

And then there’s DNSSEC. If you sign your zones, the signatures have expiry dates. A signing server that’s down for long enough lets them lapse, and every validating resolver on the internet starts treating your domain as broken. Restore that server from a backup that’s missing the signing keys, and you’ll be re-signing your zones and updating your registrar under pressure.

What breaks when IPAM is wrong

IP address management isn’t in the data path. If your IPAM tool goes down, every lease and every lookup keeps working. But during an outage, IPAM is the map, and you’ll want it.

Which subnet is that building on? Which server holds that scope? Which addresses are reserved for the infusion pumps? If the answers live in a spreadsheet last updated in the spring, you’ll be troubleshooting from memory. If they live in three systems that never quite agree, you’ll be troubleshooting three versions of the truth.

What breaks when the tools need the network

The hardest part of a DNS outage is often the fix, because the tools you’d use to fix it depend on the thing that broke.

Your remote-access VPN is reached by name. Your password vault signs you in through single sign-on. Your runbooks sit on a wiki behind the same sign-on. Your monitoring sends its alerts through a cloud service. Even the management console for your DNS servers may want a domain account before it lets you in.

The best-known example is from October 2021, when a routine maintenance command took Facebook’s backbone offline. Its DNS servers, designed to step back when they lost contact with the data centres, did exactly that, and Facebook, Instagram and WhatsApp disappeared from the internet for about six hours. Part of what made it so long was that the company’s own tools for diagnosing and fixing the problem ran on the network that was down. People had to go to the data centres in person.

Your network is smaller than Facebook’s. That problem scales down perfectly.

How long do you actually have?

Before you test anything, do some arithmetic. For each kind of client, write down two numbers: how long before anyone notices, and how long before it really hurts.

For DHCP, the first number is zero for anything joining fresh; for everything else, it’s set by your shortest lease time. The second is roughly half your typical lease, because that’s when renewals start failing in bulk. For DNS, the first number is a few seconds. The second is your typical time to live, plus however long your critical applications retry before giving up.

Those two numbers are your grace window. If the grace window for guest Wi-Fi is twenty minutes and your fastest realistic recovery is two hours, you’ve already learned something important, without breaking anything.

How to test it

Testing resilience doesn’t mean pulling cables at random. It means taking things away on purpose, one at a time, in a controlled way, and measuring what happens. Here’s an order that works.

1. Map what depends on what

List your DNS and DHCP servers, where they sit and what each one serves. Note every scope’s lease time. Note which sites get DHCP through a relay and which have a local server. Note your recursive resolvers and what your clients are told to use. Then walk through your critical services (identity, email, clinical or student systems, phones, building systems) and write down what each one needs from DNS. This list is most of the work, and it’s useful on its own.

2. Run it on paper first

Get the network team, the server team and the help desk in a room for an hour. Pick one scenario, say “the primary DHCP server is gone at 8:30 on a Monday”, and walk through it minute by minute. Who notices first, and how? Who gets called? Can they log in to fix it? Where’s the runbook? A tabletop exercise costs nothing, and it always finds something.

3. Fail one DHCP server on purpose

If you run DHCP as a failover pair, prove that it fails over. In a maintenance window, or better, in a lab that mirrors production, stop one server and watch. Can a brand-new client get an address? Can an existing client renew? How long before the surviving server takes over the whole range?

That last question matters more than it looks. Failover pairs build in a safety delay before the survivor decides its partner is really gone. On Windows Server, the automatic switch to “partner down” is turned off by default, so a server that loses its partner waits for a person to confirm what happened. Until then, in hot standby mode, the standby has only a small reserve of addresses to give out: five percent of the scope, by default. Find out how your pair is set up before you need it.

4. Take resolvers away one at a time

Point a test client at your normal configuration, then stop your first recursive resolver. Most people expect the client to switch to the second one instantly. It doesn’t. By default, a Linux client waits five seconds for the first server before trying the next, on every lookup. Windows moves on faster, but it still waits. “We have two resolvers” and “nobody will notice” aren’t the same statement, and you want to know the real number.

Do the same for your authoritative servers. Stop the primary, query each secondary directly with dig, and check that the answers are right and the serial numbers are current. Look up the expiry value in your SOA records, and decide whether it covers a bad weekend.

5. Cut a site off

Pick a branch, a building or a lab that relies on central services, and simulate losing its uplink. Which services keep working inside the site? Can a new device get an address? Can people still sign in to their machines? For many organizations, this is the most revealing test of all, because it shows which “local” services were never local.

6. Restore from backup, for real

A backup you’ve never restored is a hope, not a plan. Take last night’s backup of your DNS and DHCP configuration and restore it into a clean environment. Time it. Check that the zones load, that the scopes and reservations are all there, and that the DNSSEC and TSIG keys came along. Write the time down: that’s your real recovery time, not the one in the policy document.

7. Practise the human part

Make sure at least two people can reach the DNS and DHCP servers without single sign-on, using local break-glass accounts that have been tested, not just documented. Keep a printed or offline copy of the runbook. Write down the IP addresses of your key servers somewhere that doesn’t need DNS to read. It sounds old-fashioned. It’s what works at 3 a.m.

What to measure

For each test, record a few numbers, and keep them:

Time to detect: from the failure to the first alert, and to the first help desk call.
Time to fail over: until a new client gets an address, or a lookup gets an answer.
Answer rate during the event: the share of DHCP exchanges and DNS queries that succeeded.
Time to restore: until everything is back as it was, including the failed server.
Surprises: every dependency that wasn’t on the list.

Then repeat the tests after every significant change, and at least once a year. Networks drift. A failover pair that worked in March can be quietly broken by a firmware update in September.

How we approach it

At Spatium North we build SpatiumDDI, an open-source platform for DNS, DHCP and IP address management, and this way of thinking is built into how we test it. Every night, our lab installs the latest build as a three-node cluster and breaks it on purpose while it’s serving: it kills the leader, cuts a member off the network, replaces a dead node and runs a rolling upgrade. A watcher makes real DHCP exchanges the whole time, and the surviving nodes have to answer at least 99 percent of them. There’s more about the lab in Built with AI, proven by evidence.

We also designed SpatiumDDI to fail open. The DNS and DHCP engines run beside the control plane, not behind it, so if the management side goes down, your clients keep getting answers. A management system should never be the thing that takes your network down.

But you don’t need our software for anything in this post. Every test here works on whatever you run today.

A checklist to take away

Every DNS and DHCP server, site and scope is listed, with its lease times.
You know the grace window for each kind of client.
Your DHCP failover has been tested in the last year, and you know whether it switches over on its own.
Clients have more than one resolver, and you’ve measured what losing the first one costs.
Secondaries are current, and your SOA expiry covers a long weekend.
Each site’s dependence on central DHCP and DNS is known, and either accepted or fixed.
Backups have been restored into a clean environment, keys included, and timed.
Two people can log in to DNS and DHCP without single sign-on.
The runbook and the key IP addresses exist offline.
The next test is on the calendar.

If you’d like a second pair of hands to plan a test like this, or to run it with you, that’s the kind of discovery work we do. Get in touch.