For a Linux server providing external services, the reliability and security of DNS resolution are directly related to business stability. DNS pollution can cause slow resolution or access errors at best, or even redirect users to malicious sites, leading to data leaks, business interruptions, and even security breaches. This article systematically explains best practices for preventing DNS pollution on Linux servers, helping readers build a robust and secure DNS resolution system in production environments.

How DNS pollution works:

DNS is the internet's "phone book," responsible for translating domain names into IP addresses. When DNS queries pass through carriers or unsecured network nodes, attackers can hijack or tamper with them, replacing correct resolution results with incorrect ones. This type of pollution generally takes two forms: domain hijacking and cache pollution. Domain hijacking resolves the target domain to a malicious IP address, such as a phishing website. Cache pollution writes false resolution results to the local DNS cache or an upstream DNS cache server, affecting all subsequent users.

Core Principles for Preventing DNS Pollution:

In summary, Linux servers can prevent DNS pollution by focusing on the following: reducing reliance on insecure upstream DNS servers (such as carrier DNS), using encrypted DNS protocols (DoT, DoH, DNSCrypt), establishing local caching and forwarding services (such as unbound and dnsmasq), specifying trusted root certificates and DNSSEC validation, and implementing a multi-source redundancy strategy to avoid single points of failure. Now let's move on to the practical steps.

Practical protective measures and procedures:

1. Choose a trusted upstream DNS server

Avoid using the default DNS server provided by your carrier. Recommended options include international public DNS servers and DNS servers that support encryption. In Linux, you can specify an upstream DNS server by modifying /etc/resolv.conf:

# Edit resolv.conf and add trusted DNS
nameserver 1.1.1.1
nameserver 8.8.8.8

Note: Some systems (such as those using systemd-resolved) may automatically overwrite resolv.conf. Therefore, you will need to modify the corresponding systemd configuration.

2. Setting up a local DNS cache service

Solution 1: Using unbound

unbound is a lightweight recursive resolver that supports DNSSEC and encryption. The following steps will be demonstrated using Debian/Ubuntu as an example:

Installation:

apt-get update
apt-get install unbound -y

Example configuration file (/etc/unbound/unbound.conf):

server:
    interface: 127.0.0.1
    access-control: 127.0.0.0/8 allow
    verbosity: 1
    do-ip4: yes
    do-ip6: no
    do-udp: yes
    do-tcp: yes

    # Enable DNSSEC validation
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853     # Cloudflare DoT
    forward-addr: 9.9.9.9@853     # Quad9 DoT

Start the service:

systemctl enable unbound
systemctl restart unbound

In this case, all local DNS queries on the server go through unbound and are encrypted, significantly reducing the risk of contamination.

Solution 2: Using dnsmasq

dnsmasq is suitable for small-scale environments, primarily providing local caching and forwarding.

Installation:

apt-get install dnsmasq -y

Configuration (/etc/dnsmasq.conf):

no-resolv
server=1.1.1.1
server=8.8.8.8
cache-size=1000

start up:

systemctl enable dnsmasq
systemctl restart dnsmasq

Suitable for small servers that require fast caching, but not as secure as unbound.

3. Use encrypted DNS protocols

(1) DNS over TLS (DoT)

Use port 853. Common implementations are unbound + systemd-resolved, or stubby.

Install stubby (a lightweight DNS over TLS client):

apt-get install stubby -y

Configure /etc/stubby/stubby.yml:

upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 9.9.9.9
    tls_auth_name: "dns.quad9.net"

(2) DNS over HTTPS (DoH)

DoH can bypass DNS hijacking on some networks. Common tools include:

• cloudflared: Cloudflare's DoH client.
• dnscrypt-proxy: Supports DoH, DoT, and DNSCrypt protocols.

Using cloudflared as an example:

apt-get install cloudflared -y
cloudflared proxy-dns --port 5053 --upstream https://1.1.1.1/dns-query

Configure /etc/resolv.conf to use the local DNS server 127.0.0.1#5053.

4. Enable DNSSEC validation

DNSSEC verifies the source and integrity of DNS data, preventing forged responses.

Using unbound as an example, enable it as follows:

server:
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    val-permissive-mode: no

Verify that DNSSEC is working:

dig sigfail.verteiltesysteme.net @127.0.0.1

If the configuration is correct, the domain name will return a SERVFAIL error, indicating that the verification is successful.

5. Network-layer measures to prevent DNS hijacking

Forced routing rules: Deny return data on port 53 from unknown sources in the firewall.

iptables example:

# 禁止外部 DNS 回复，只允许本地 unbound/dnsmasq
iptables -A OUTPUT -p udp --dport 53 -j DROP
iptables -A OUTPUT -p tcp --dport 53 -j DROP

DoH proxy: Forces all DNS requests to go through an HTTPS tunnel.

6. Multi-source redundancy and monitoring

Configure multiple upstream DNS servers and deploy monitoring scripts to regularly check for abnormal resolution results:

#!/bin/bash
DOMAIN="example.com"
DNS="127.0.0.1"
IP_EXPECTED="93.184.216.34"

IP_RESOLVED=$(dig +short @$DNS $DOMAIN | tail -n1)

if [ "$IP_RESOLVED" != "$IP_EXPECTED" ]; then
    echo "$(date): DNS Pollution detected! $DOMAIN resolved to $IP_RESOLVED" >> /var/log/dns_check.log
fi

Regular verification can promptly detect anomalies.

DNS pollution is essentially a dual security issue at both the network and application layers. Modifying resolv.conf alone cannot completely prevent it. A multi-faceted approach is necessary, encompassing protocol encryption, cache validation, network control, and monitoring and early warning. For production Linux servers, the best practice is: local recursion + encrypted forwarding + DNSSEC validation + multi-source redundancy. This not only ensures the accuracy of domain name resolution but also protects against carrier hijacking, attacker tampering, and man-in-the-middle attacks.