One door, every connection
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, and 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, and I held onto one framing all year: make it a product, not a science project. We wrote the 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.
A team of four, an architecture of one
The build was deliberately small: roughly 0.5–1 front-end, 1.5–2.5 back-end and 0.5–1 QA engineer in any given month. I was the only PM — domain analysis, product architecture, functional and system design, interaction prototypes at 30-plus screens per version, requirement specs, and the day-to-day running of the team. I also carried product definition for the underlying DNS capability itself (its engineering sat with a separate resolver team, outside the four-engineer count), while threat intelligence came from a sister product team with its own PM. Part of the job was simply keeping all of it converging on one product.
With four engineers, you get one architecture — re-platforming halfway is not a recoverable event. So before writing a single feature spec 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 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.
630, 730, 830, 930
I committed the team to a pilot on June 30, and then to a monthly train — versions named by their ship date, each planned under one rule: 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, in writing. “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.
We were the first customer
We piloted on ourselves: 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.
What twelve months bought
- 0→1, complete: 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; national-event assurance duty supported.
- 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 SecCat, the story that opens this collection. If you arrived here from there, you now know where the heart came from.
Notes from a blank page
Three things from that year became permanent equipment. 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. And a handover is a product artifact: the departure Q&A, honest about what was verified and what wasn’t, is what made the product survivable without me. As the next case shows, build-vs-buy verdicts are never final either.