3 Enterprise DNS Deployment Models Compared

Why the Wrong DNS Can Take the Whole Office Offline at Tea Time

Last year we handled an incident for an auto-parts export trading company in Shunyi. By the time our engineer arrived on site, more than twenty computers across the office could not open the customer inquiry system. After a round of checks, the cause was not a network outage but DNS resolution timeouts — the company was using broadband arranged by its landlord, with a local carrier DNS server at 202.106.0.20, and response latency had climbed to 3 seconds. This is not an isolated case. DNS has long been treated as an invisible layer in IT architecture, noticed only once it fails. For an SME, the DNS deployment model it chooses directly determines how fast employees can open web pages, the availability of upstream business systems, and how often the IT department gets woken up in the middle of the night.

Carrier DNS: Low Effort, Hidden Risks

For most SMEs in China, once network equipment is connected to broadband it uses the carrier-assigned DNS servers by default. China Telecom, China Unicom and China Mobile each run their own recursive resolution nodes, with common IPs such as 202.96.128.86 and 202.106.195.68. This approach costs nothing, requires no configuration and is picked up automatically on the router’s WAN port, so it is genuinely convenient. But the problems are just as real — latency rises noticeably when resolution crosses carriers. When a Beijing Telecom user accesses a SaaS system hosted in Alibaba Cloud’s East China region, the DNS layer first has to reach the carrier’s node, and if that node does not use Anycast or has an imperfect caching strategy, the first resolution can take 500 milliseconds or more.

More troublesome still is response hijacking on carrier DNS. In some regions, when a broadband user enters a domain that does not exist, the carrier’s DNS forcibly redirects them to an advertising page or the carrier’s own portal. That is tolerable for an employee looking something up, but it is a disaster for business systems — if code hard-codes the IP of an internal domain and that domain happens not to exist, the browser is redirected to a strange address and the session simply breaks. I have seen more than one company whose OA system failed to log in intermittently for this reason, with the problem traced back to DNS only at the end of the investigation.

Self-Hosted Recursive DNS: The Practical Bar for Unbound

At a technology company in Wangjing that does outsourcing for Japanese clients, I deployed a self-hosted recursive DNS based on Unbound for their server room. Unbound was chosen mainly because it is lightweight and uses few resources — a single 4-core, 8 GB virtual machine can handle resolution for 500 endpoints — and it supports DNSSEC validation. Installation is not complicated: on Ubuntu 20.04, a simple apt install unbound plus a few lines of configuration gets it running. The key is getting the caching strategy right — Unbound’s default cache time is twice the TTL value, but many small and mid-sized websites set their TTLs erratically, so some records stay cached too long and go stale.

The greatest value of self-hosted recursion is control. You decide whether to enable DNSSEC, whether to block specific domains, and whether to do split-horizon resolution for the internal network. The Wangjing outsourcing firm had a requirement at the time: Japanese customers accessing their test environment needed to go through the Japan node, while local employees needed to go through the domestic node. That split logic is implemented in Unbound through the view module, resolving the same domain to different IPs in the two regions — a few lines of configuration in a self-hosted setup.

But the bar is very real. Self-hosted recursive DNS requires someone with basic Linux skills and knowledge of the DNS protocol, able to read logs and debug when something goes wrong. SMEs are already short-staffed on IT; if a single Windows Server is running file sharing, standing up a separate Linux environment just for DNS is arguably over-investment. More importantly, the egress bandwidth of a self-hosted resolver caps overall resolution capacity — if the company has only one 100 Mbps line and egress is saturated, recursive resolution will stall as well.

Private DNS Services and DoH/DoT: A New Choice for Security and Privacy

The biggest change in DNS over the past two years has been the gradual adoption of DoH (DNS over HTTPS) and DoT (DNS over TLS). Traditional DNS queries use plaintext UDP port 53 and are easily intercepted by a man-in-the-middle on the corporate network or logged by the egress gateway. DoH/DoT encapsulate DNS requests in an HTTPS/TLS tunnel, so carriers or intermediary devices see only an HTTPS connection and cannot tell which domains were queried.

Cloudflare’s 1.1.1.1 and Google Public DNS 8.8.8.8 both support DoH/DoT, and internal devices that support them can be configured directly. But there is a practical issue — many companies’ egress firewalls block non-standard port traffic by default. DoT uses port 853 and DoH uses port 443; if those ports are not opened, the device configuration will not work. From a security standpoint DoH/DoT does prevent DNS poisoning and hijacking, but real-world deployment has to go hand in hand with network policy adjustments.

For companies with higher security requirements, private DNS services can now be self-hosted as well — for example, deploying an internal solution based on AdGuard Home or CoreDNS and exposing it externally over DoH. Once the corresponding client is installed on employee computers, resolution requests travel through an encrypted tunnel to the internal DNS server, which then performs upstream recursion. This model suits R&D-driven companies or scenarios that are sensitive to data leakage. The Network Equipment Package Siwenlide deployed for a manufacturing client included an internal DNS based on AdGuard Home, which both accelerates resolution and blocks employees from reaching phishing domains.

Recommended Approach for SMEs: Layered + Redundant

Based on our experience serving more than 300 companies in Beijing, the most practical approach for an SME (under 50 people) is a two-tier structure: configure two public DNS resolvers on the egress gateway or router as a fallback, such as 223.5.5.5 (Alibaba) and 119.29.29.29 (Tencent) — both have many domestic nodes and respond quickly, and are far more reliable than carrier DNS. If business systems have high demands on resolution stability, such as ERP or cloud-based OA, add a DNS cache server on the LAN, using either the Windows Server DNS role or dnsmasq on Linux; its main job is to cache resolution results for internal domains while relieving pressure on the egress.

If budget allows and you want to raise the security bar further, consider upgrading internal DNS to a DoH/DoT-capable solution, or use a commercial DNS security service directly. Siwenlide’s sTrust zero trust solution includes protection at the DNS layer, able to identify and block access to malicious domains — a good fit for enterprise clients with information security compliance requirements.

1. Basic tier: dual public DNS (Alibaba 223.5.5.5 + Tencent 119.29.29.29). Zero cost; suits companies with fewer than 30 employees and business systems that do not depend on self-hosted domains.
2. Intermediate tier: a LAN DNS cache server (Windows Server DNS or dnsmasq) plus dual public DNS upstreams. Suits companies of 30-100 people with internal domains.
3. Enterprise tier: self-hosted recursive DNS (Unbound/adGuard) + DNSSEC + DoH/DoT egress, combined with security solutions such as sTrust. Suits organizations with more than 100 people or R&D-driven companies.

There is one more detail to watch for when choosing a solution: DNS failover should be automated. Some companies’ routers support DNS failover, switching automatically to the backup server when the primary DNS times out. The feature looks simple, but it spares you the awkward situation of an overnight outage that nobody notices.

DNS may look like the most inconspicuous part of your infrastructure, but when it fails, it has the widest impact and the longest troubleshooting chain. If your company has not yet worked out a DNS strategy, now is the time to start — after all, repairing a DNS failure usually takes far longer than deploying a stable DNS setup.