DNS, DHCP and Time Service Clusters
The three services nobody capacity-plans for, and the first three that page the whole company at the same minute when they fail.
What this usually looks like
Name resolution, address assignment and time grew one office at a time. Each works, none of them is redundant, and each is now a dependency of everything.
- One DNS server on a rack shelf answers for the entire company, and nobody knows what happens if it stops.
- The zone file is edited in production, at night, by the one person who understands it.
- DHCP has no second node, so a lease database failure strands every new device that boots.
- Clocks across the estate drift by seconds, which makes log correlation during incidents guesswork.
Three ways to buy this
Audit if you want to know how bad it is. Build if you have the team and want the capability. Managed if you don't want to own the pager. Most engagements start with the audit and decide afterwards.
Audit
A fixed-price health check — the cheapest way in
- Dependency map: what breaks when resolution, leases or time stop
- Single-point-of-failure review across all three services
- Zone hygiene report — stale, shadowed and duplicated records
- DNSSEC, TSIG and dynamic-update posture assessment
Build
One-off delivery: design, code, hardening, handover
- Resolver HA or anycast pair per site, with a hidden primary
- Zone management in Git with validation and a staged publish step
- Kea DHCP HA pair with replicated lease database and failover testing
- Authoritative time with redundant reference clocks and drift alerting
- Internal CA with automated certificate issuance and renewal
Managed
Build plus 7×24 on-call, SLA and quarterly drills
- Zone and record change management with validation on every change
- Lease-scope, reservation and DNS-record drift monitoring
- Time-source health and drift alerting across the estate
- DNS and DHCP failover drill each quarter, with a report
- Certificate expiry watch with renewal ahead of expiry, always
What we actually deploy
Specific tooling, not categories. If a version matters to your decision, ask — we will tell you which one we would pick and why, including when the answer is the older one.
Authoritative DNS
- BIND 9
- Knot DNS
- PowerDNS
- NSD
- hidden primary + secondaries
- catalog zones
- TSIG
- DNSSEC signing
Recursive & internal resolution
- Unbound
- dnsdist
- CoreDNS
- systemd-resolved (client policy)
Anycast & load distribution
- BGP anycast
- VRRP/keepalived
- ECMP with dnsdist
- health-checked resolvers
DHCP
- Kea DHCP (HA hook)
- ISC DHCP failover
- subnet delegation
- DDNS integration
- option 82 / relay policy
Time & frequency
- chrony
- ntpd (legacy estates)
- GPS / GNSS refclock
- PTP (IEEE 1588) grandmaster
- NTS authentication
PKI & certificates
- step-ca
- EJBCA
- OpenSSL CA
- cert-manager
- ACME / internal ACME
- HSM-backed root
AAA & access
- FreeRADIUS (HA)
- tac_plus
- Kerberos KDC
- 802.1X integration
What we will be measured on
These are the numbers we put in the delivery report. If we cannot measure it, we do not promise it.
- Losing any single resolver leaves resolution fully intact — proven by drill, not by design.
- A zone change reaches production in under 5 minutes including validation and a tested rollback.
- DHCP lease-database failover completes in under 30 seconds with no duplicate address allocation.
- Clock offset across the estate stays within 10 ms, with alerting before drift becomes a log problem.
- Every one of the three services has a documented failover procedure that has been exercised.
What we would build, and where the weak point is
The hidden primary is a deliberate single point of failure for writes — that is the point, because it makes zone changes reviewable. What must never be a single point is resolution itself, which is why the secondaries are paired per site and the drill tests one site leaving service entirely.
marks a single point of failure we would raise with you rather than hide. Every architecture has one; the question is whether you know where it is.
What we don't do
Every vendor says yes to everything. Here is where our answer is no, or where someone else needs to be in the room. If this list looks wrong for your situation, tell us — we would rather argue about scope before the contract than after.
- Requires partner
Domain registration, ownership and registrar operations
We manage the zones; the registration and its legal ownership stay with you and your registrar.
- Requires partner
Enterprise DNS filtering and threat-feed policy
We will deploy and operate an RPZ pipeline if you have a feed provider. We do not sell feeds.
- Out of scope
Mail content filtering and anti-spam policy
We will run a mail relay cluster for delivery reliability; deciding what is spam is a different product category.
- Requires partner
Physical GNSS antenna installation and roof access
We specify the placement and lightning protection; a licensed contractor installs it.
What it looked like last time
An insurance group whose entire internal resolution ran on one physical server on a rack shelf: rebuilt as an anycast pair per site with a hidden primary, zone management moved into Git, and DHCP moved to a replicated Kea HA pair — with a drill that took one site out of service and produced no user-visible effect.
Anonymised under NDA. No client names, no logos, no invented metrics. Full case library on the work page.
Talk to the network services engineer about your foundation network services
Send us the architecture, or just describe what broke most recently. You'll get an engineer's answer, not a discovery questionnaire.
Talk to a network services engineer: botonwa@gmail.com · +86 130 5181 3099