Context
Every connection on the internet begins with a DNS lookup. Inside a large organization, the recursive resolver — the server that answers those lookups — quietly sees everything: every domain every device asks for, before any traffic flows. That makes it two things at once. It is critical infrastructure that must never fail. And it is the single best sensor in the building: a workstation resolving a crypto-mining pool or a known command-and-control domain is telling you something no firewall log states so plainly.
In 2022, China Telecom’s security division ran a group-level cybersecurity innovation program. The secure-DNS track came straight from the top: the division’s CEO, a network-operations veteran, wanted a recursive DNS with security attributes built in-house. I was tapped to lead it, with one framing I held onto all year: make it a product, not a science project.
We wrote the product goal as a deliberate duality: keep the resolver itself controllable, stable and secure (it is infrastructure), and use DNS behavior to protect everything behind it (it is a sensor). The internal one-liner: guard one door of the enterprise perimeter — the one every connection walks through first.
My role
I was the product manager — the only one. Domain analysis, product architecture, functional and system design, interaction prototypes (30-plus screens per version), requirement specifications, and day-to-day leadership of a deliberately small cross-functional build: roughly 0.5–1 front-end, 1.5–2.5 back-end and 0.5–1 QA engineer in any given month. I also carried product management for the underlying DNS capability itself — its engineering sat with a separate resolver team, outside that four-engineer count, but its product definition was mine. Threat intelligence came from a sister product team with its own PM; my job included keeping all of it converging on one product.
Decision 1 · Model first, screens later
With four engineers, you get one architecture. Re-platforming halfway is not a recoverable event — so before writing feature specs I spent the opening weeks on domain analysis: abstracting the business entities and their relationships, then layering the system so every later feature had a place to land.
The shape that survived all year: an access layer at the bottom; a DNS protocol layer (recursion, EDNS, query logging, domain blocking); a security support layer — threat intelligence organized by category (mining sites, botnet/trojan/worm domains, phishing, command-and-control); and core product modules on top (interception policy management, multi-dimensional threat analysis, resolution analytics, host identification), all threaded together by one management platform.
The same discipline went into the data model. Interception policy, for example, was designed as an inheritance system — node-level overrides global, office areas inherit from their parents, manual selection beats defaults — so that a customer with a hundred sites could be governed with a handful of rules.
Screens changed every month. The model never had to.
Decision 2 · A monthly release train against a fixed pilot date
I committed the team to a pilot on June 30 and then to a monthly cadence — versions named by their ship date (630, 730, 830, 930), each with a rule I enforced in planning: every release must visibly extend the product, and sequence follows scenario dependency, not stakeholder noise.
- 630 shipped the spine: dedicated recursive resolution, threat detection, dangerous-access blocking — real users on day one.
- 730 paid down what I had deliberately downgraded to protect the pilot date: blacklist management, data export, fit-and-finish on search, requester views and policy delivery.
- 830 introduced multi-tenancy and office-area structures, and reworked threat handling around the host’s point of view.
- 930 added delegated administration and usage management — the release where an internal tool became a sellable B2B product.
The trade-offs were explicit: encrypted-DNS variants (DoT/DoH) were scoped out as low-priority for the target scenarios, and “downgrade now, backfill next month” was a named mechanism rather than a broken promise. Four releases went through the full develop-test-launch cycle. All four shipped.
Decision 3 · Dogfood before customers
We piloted on ourselves first: a provincial carrier subsidiary’s office network plus our own division’s offices. Before launch I defined what the pilot had to prove — operational stability, detection and blocking accuracy, end-to-end user experience — and designed the reporting framework around it: resolver availability, average QPS, mean resolution time, interception counts, false-positive and miss rates, ops success rates. Access came through a deliberately temporary boundary-forwarder scheme, marked as such so nobody mistook scaffolding for architecture.
The same year, the system stood duty in national-event security-assurance windows — infrastructure’s version of a stress test with an audience.
Results
- 0→1 in twelve months: from a blank page to a working product system — architecture, management platform, threat-intel integration, four shipped releases.
- Live pilot with real users on a provincial carrier subsidiary’s office network and our own division’s offices; supported national-event assurance duty.
- A roadmap to general availability (report management, standardized capability modules for compliance scenarios, integration with company-wide order and notification systems) defined and handed to the organization.
- At year-end I was reassigned to the division’s security-capability platform — and closed my part with a full written handover, down to a Q&A document annotating which edge cases were verified and which remained open.
The epilogue that became a prologue
Here is the part I could not have planned. After I moved on, the company built a new SMB security product — on a vendor’s DNS core, not this one. Within two years, that product was mine. What I did with it — and with the resolver I had left behind — is the next story: SecCat.
What I learned
- On infrastructure products, the data model is the product. The policy-inheritance design outlived every screen that displayed it.
- A tiny team is a sequencing problem, not a resourcing problem. The monthly train with explicit downgrade-and-backfill kept four engineers shipping like a team twice the size.
- A handover is a product artifact. The Q&A I wrote at departure — honest about what was verified and what wasn’t — was what made the product survivable without me. And as the next case shows: build-vs-buy verdicts are never final.