In the context of cybersecurity and domain name management, "domain name pollution" and "DNS pollution" generally refer to the same phenomenon. Both are common terms for "DNS cache poisoning" or "DNS spoofing," where the DNS resolution result is tampered with—via a forged response—while in transit, causing the user to be directed to an incorrect IP address.

What truly requires clarification—and is frequently confused during daily troubleshooting—is the distinction between DNS pollution and DNS hijacking. While both manifest as "abnormal domain name resolution," they differ significantly in terms of where the attack occurs, their observable characteristics, and how they are resolved.

Key Differences: DNS Pollution vs. DNS Hijacking

In short: DNS pollution is like an "imposter messenger" intercepting your request and deceiving you with a fake response; DNS hijacking is like the "post office itself being subverted," providing you with the wrong address from the very start. How DNS Poisoning Works

DNS queries typically use the connectionless UDP protocol and lack any built-in authentication mechanism. When your device sends a query to a local DNS server (a recursive resolver), the request travels through your service provider’s network. If monitoring equipment detects a query for a specific domain name, it can instantly forge a response packet and send it to you before the legitimate response from the actual DNS server arrives. Your device accepts this forged result, while the subsequent, authentic response is ignored.

This poisoning can spread: if a recursive DNS server accepts the forged response and caches it, then every subsequent user who queries that server for the same domain will receive the incorrect result for the duration of the TTL (Time-to-Live)—a phenomenon known as "cache poisoning."

Detection and Diagnosis

The key to diagnosis is cross-verification from multiple sources to determine whether the issue is a localized "hijack" or a broader "poisoning" event.

1. Global Resolution Comparison: Use tools like `dnschecker.org` or `viewdns.info` to check how a domain name resolves from various locations around the world. If only a specific region (e.g., a particular service provider in China) returns an anomalous IP address while other regions return the correct one, it is a classic sign of DNS poisoning.

2. In-depth Command-Line Probing: Use `dig` or `nslookup` to query both your local default DNS server and a trusted public DNS server (such as `8.8.8.8`), then compare the results.

If your local DNS returns an incorrect result but `8.8.8.8` returns the correct one, the issue lies somewhere along your local network path—likely a hijack or localized poisoning.

3. Observing Access Behavior: If a site opens but its content has been replaced with advertisements or redirects, suspect a hijack. If a site fails to open entirely, returns an `NXDOMAIN` error, or yields vastly different results depending on the region, suspect DNS poisoning.

Solutions: A Layered Approach

Strategies for addressing these issues should be applied based on the specific type of problem encountered.

For DNS Poisoning (Interference with the transmission path):

Enable Encrypted DNS (DoH/DoT): This is the most direct and effective solution for end users. Encapsulate DNS queries within an encrypted tunnel. This prevents intermediary devices from identifying the content of the queries, thereby making it impossible for them to craft targeted, forged responses.

Deploy DNSSEC: DNSSEC uses digital signatures to verify the authenticity of DNS responses. Even if a forged, "polluted" packet arrives first, it will be rejected due to a signature verification failure, ensuring the integrity of the resolution result at a structural level.

Utilize Anycast-based distributed authoritative DNS: Anycast ensures that resolution requests are answered by the geographically nearest node. This shortens the network path and makes it more difficult for an attacker to inject interference precisely. Furthermore, a distributed architecture enhances the overall resilience of the resolution service against attacks.

Addressing DNS Hijacking (Tampering with Server Records)

Immediately audit and lock resolution records: Log in to your domain registrar and DNS hosting platform to check whether A records or NS records have been modified without authorization. Correct any unauthorized changes immediately and enable two-factor authentication (2FA) to prevent further tampering.

Enable Registry Lock: Lock the domain at the registry level. Any changes to NS records or other critical information will then require an additional, manually reviewed authorization process—effectively blocking the possibility of "redirection" at the source of administrative control.

Implement HTTPS + HSTS across the entire site: Even if a DNS resolution is briefly hijacked to point to an incorrect IP address, HSTS forces the browser to connect exclusively via HTTPS. If an attacker cannot provide a valid SSL certificate, the browser will block the connection, preventing users from being directed to phishing pages.

DNS pollution is akin to dealing with a "forger on the delivery route," while DNS hijacking is like dealing with an "insider who has turned against you." Understanding this distinction allows for the application of the right countermeasures: use encrypted DNS and DNSSEC to block tampering along the communication path, and employ account security measures and Registry Locks to safeguard the authority over your DNS records. By covering all these layers, you ensure that your domain resolution remains trustworthy and available, even when faced with various forms of interference.