Mastering CDN DNS: Compatibility, Speed, and Precision Optimization

CDN DNS deployment and optimization reflect not only technical and operational capabilities but also operational expertise, ultimately embedding all experience into code. This article interprets CDN DNS optimization from several dimensions, supplemented by case studies, and concludes with the principle of “compatible, fast and stable, minimal yet precise.”

The content is organized from the perspective of Li Meng, chief architect of SpeedyCloud, based on his speech at the 2016 Global Operations Conference in Shanghai.

Initially, the author approached DNS from a development standpoint, later transitioning to DNS operations and eventually becoming an industry expert. Over time, many operational experiences have been distilled into DNS code.

In CDN environments, CDN DNS interacts with services indirectly, making data‑analysis chains difficult and leading to hard‑to‑trace issues. DNS performance optimization is often passive and indirect.

Typical DNS resolution proceeds from the local application to the OS, then to the internal network DNS, the ISP’s DNS, and finally the public DNS hierarchy, with optional caching at each layer (browser cache, Java environment cache, etc.). Differences in Java‑based queries versus standard curl results can arise due to Java’s cache and IPv4/IPv6 handling.

DNS Deployment and Optimization

Key optimization points include NS clustering, selection processes, and extracting BIND’s selection algorithm for analysis.

NS clustering groups domain names under a set of name servers, providing a two‑dimensional freedom where one domain delegates IP resolution to another.

Local DNS selection often uses a smoothed RTT (SRTT) approach: initial SRTT is zero, the NS with the smallest SRTT is chosen, RTT is measured, and SRTT is updated iteratively. BIND’s algorithm, which dominates about 80% of the public DNS market, applies weighted averaging (70% of SRTT, 30% of RTT) and decays the SRTT of non‑selected servers by 2%. Errors incur a penalty of an additional 200 ms.

These mechanisms resemble a real‑world analogy: trying restaurants one by one until a preferred one is found, then switching when it becomes unsatisfactory.

Visualization of Local DNS RTT sequences shows multiple NS with initial SRTT zero; each NS is probed, RTT recorded, and the algorithm gradually favors the NS with the lowest RTT (green sequence), while others decay.

When a previously optimal NS encounters an error, its SRTT receives a penalty, causing the system to shift to a secondary NS until the primary recovers.

Deploying multiple NS in a single location can dilute performance (each additional secondary device may reduce overall speed by 3‑5%). Therefore, a “few and precise” cluster is recommended.

Question 1: How should DNS nodes be placed in regions with poor inter‑connectivity, such as Tibet or Xinjiang? Answer (Li Meng): DNS NS organization offers two degrees of freedom, but protocol constraints limit feasible configurations. Careful planning is required to avoid pitfalls.

Question 2: BIND performs well for small‑to‑medium enterprises, but how does it handle DDoS attacks on domains? Answer (Li Meng): BIND’s code embodies much of the DNS protocol logic, making it a valuable reference for troubleshooting and understanding DNS behavior under attack.

Question 3: When a DNS vendor’s node performs poorly, why does switching IPs not resolve the issue? Answer (Li Meng): The problem often lies with the IP target rather than DNS itself; it is a CDN monitoring issue.

In summary, DNS selection should prioritize compatibility (ensuring all DNS devices are well‑connected), speed and stability (penalizing errors heavily), and minimal precise clustering (avoiding excessive secondary nodes). These principles help improve DNS resolution performance across diverse network conditions.