Cyber Security

DNS Poisoning via DNSMasq — Why It Fails in Modern Applications and How to Protect Our Services

Written by Adam Muiz Updated: 06 Aug 2026 10 min read

Some time ago I told you about DNS router going the wrong way — an incident where VPS1 domain suddenly displays VPS2 content because the DNS settings on the router were accidentally changed. That incident made me realize how much power people have DNS. One configuration line can direct traffic to any server without touching a single line on the destination server.

But today I want to discuss the dark side of the same story. What if the misdirection was not accidental, but intentional? Ie DNS poisoning — and tools like DNSMasq can do it very easily. But interestingly, this once very powerful technique is starting loses its fangs when faced with modern applications. And more importantly: how do we protect our own services from similar attacks.

DNS Poisoning in DNSMasq — As Easy as One Line of Configuration

DNSMasq is a lightweight DNS forwarder that is almost always present in every Linux and embedded router. It's designed for DNS and DHCP caching, but it also has features --address which can override DNS for certain domains: 

# Di /etc/dnsmasq.d/local-override.conf
address=/example.com/192.168.1.100
address=/mail.google.com/10.0.0.5

With the one line above, every device on the network that uses DNSMasq as a DNS server will be redirected to a fake IP every time it accesses that domain. This exactly the same as what happened in the DNS router misdirection story — except, it was done consciously and planned. This isDNS poisoning in its ultimate form pure.

In the server as router setup that I discussed, DNSMasq is the DNS and DHCP backbone. The server that becomes the automatic gateway has full power to override the DNS of every device on the network. This is useful for content filtering or redirect development — but in the wrong hands, it is a deadly weapon.

But Why Does It Fail in Modern Applications?

Back in the day — the early 2000s — DNS poisoning was one of the most effective attacks. An attacker on a public WiFi network can direct the target to a phishing site without a conscious target. But now? Modern applications haveseveral layers of defensethat make DNS poisoning practically useless for spoofing their services.

1. Certificate Pinning

Modern banking, social media, and messaging apps perform certificate pinning — they store the hash of a valid TLS server certificate. Even if DNS poisoning successfully redirects a connection to the attacker's server, the application will reject the connection because the attacker's server's certificate does not match that pin saved in the application. The connection failed before any data was sent.

Example: WhatsApp, Instagram, and TikTok applications have hard certificate pinning. Try pointing their domain to a fake IP — it's not page views that happen phishing, but connection error or SSL handshake failed.

2. DNS over HTTPS (DoH) and DNS over TLS (DoT)

Modern browsers like Chrome, Firefox, and Edge have Secure DNS (DoH) enabled by default. This means that DNS queries are no longer sent to the local DNS server (like DNSMasq on a router), but instead goes directly to the upstream DNS server via HTTPS. Chrome even has a fallback — if DoH fails, it can try the DNS server hardcoded alternatives.

This has a big impact: DNS poisoning at the router level has no effect because the browser does not ask the router to resolve the domain. They asked Cloudflare directly (1.1.1.1), Google (8.8.8.8), or other DoH providers. On the native application side, many use custom DNS resolvers — libraries such as c-ares or Trusted DNS which ignores system DNS.

3. Hardcoded IP Addresses

Some applications (especially those that are CDN-based or have their own servers) perform IP pinning — storing a list of their server IPs directly in the code application. DNS poisoning is useless because the application does not resolve DNS at all. They connect directly to the specified IP.

Example: applications belonging to large companies such as Google, Meta, and Netflix have some hardcoded IPs for critical services. This is not for all services, but enough to make DNS poisoning useless as a single attack.

4. App-Level TLS Validation

Modern applications don't rely solely on the operating system for TLS validation. They have their own trust store and stricter validation policies. Even if a fake certificate is planted in the system (for example via an untrusted root certificate), the application can detect it and refuse the connection.

Example: applications such as Signal, Telegram, and banking apps perform a manual TLS handshake at the application level. They don't care what the OS says — they have own standards.

So DNS Poisoning Is Completely Useless?

Not really. DNS poisoning is still effective for some specific scenarios:

  • Websites without HTTPS — there are still many websites on internal or local networks that do not use HTTPS. DNS poisoning here still works perfectly.
  • Phishing via browser with DoH turned off — many users unknowingly disable Secure DNS. Or use an old browser that doesn't support DoH.
  • Attacks on isolated local networks — in environments where upstream DNS cannot be reached, the device will fall back to local DNS. This is where poisoning works.
  • Redirect to maintenance page or block page — this is a legitimate use, for example in schools or offices that block certain sites via internal DNS.

But to spoof modern services like social media, banking apps, or messaging apps — DNS poisoning is almost guaranteed to fail because of the layers defense above.

How to Protect Our Services from DNS Poisoning

We now know that DNS poisoning is not as effective as it once was for attacking modern applications. But what about our own services? Are we safe from similar attack?

There are several layers of defense that we can implement — and interestingly, some of them we discussed in the previous article about server as router.

1. Force All DNS Through the Server — Block Alternative Port 53

In setting up the server as a router, we have full control at the firewall level. One of the threats of DNS poisoning is when devices on the network use a DNS server others (e.g. public DoH). The solution: redirect all DNS queries to local servers and block DoH to external servers. 

# nftables — redirect port 53 ke DNSMasq lokal
table ip nat {
    chain prerouting {
        type nat hook prerouting priority 0; policy accept;
        udp dport 53 redirect to 53
        tcp dport 53 redirect to 53
    }
}

# Blokir DoH ke Cloudflare, Google, Quad9
table ip filter {
    chain forward {
        type filter hook forward priority 0; policy accept;
        ip daddr 1.1.1.0/24 tcp dport 443 drop
        ip daddr 8.8.8.0/24 tcp dport 443 drop
        ip daddr 9.9.9.0/24 tcp dport 443 drop
    }
}

With these firewall rules:

  • All DNS queries on port 53 — from any device — will be directed to the local DNSMasq
  • DoH to public servers (Cloudflare, Google, Quad9) will be blocked
  • Browsers that try DoH will fall back to regular DNS that we control

2. DNSSEC validation in DNSMasq

DNSMasq supports DNSSEC validation — a mechanism that ensures that DNS answers actually come from authoritative nameservers and not modified midway. With DNSSEC, even if an attacker succeeds in spoofing DNS, the fake answer will be rejected because the cryptographic signature is invalid. 

# Di /etc/dnsmasq.conf
conf-file=/usr/share/dnsmasq/trust-anchors.conf
dnssec
dnssec-check-unsigned

Important note: DNSSEC validates the integrity of answers from upstream, but does not prevent poisoning at the local level. If someone changes the DNSMasq configuration directly on the server, DNSSEC will not help. But to prevent attacks from outside the network — it is very effective.

3. Real-Time DNS Queries Monitoring

When the server is setup as a router, all DNS queries go through DNSMasq. We can enable logging to monitor suspicious patterns: 

# Di /etc/dnsmasq.conf
log-queries
log-facility=/var/log/dnsmasq.log

From these logs, we can detect anomalies such as:

  • Device suddenly resolves an unusual domain
  • Repeated DNS queries to the same domain within a short period of time (malware indication)
  • Domain resolved to an IP that it shouldn't be

I personally use tail -f /var/log/dnsmasq.log for live monitoring. But on a larger scale, it can be integrated with dashboards such as which is discussed in the server article as a router — all DNS logs go into the database and can be visualized.

4. HTTPS with HSTS and Certificate Pinning

DNS poisoning is useless if our service uses HTTPS properly. But there is one loophole: the first time the user accesses our service (first connection) is still vulnerable to MITM attacks if the attacker can intercept the first connection. The solution:

  • HSTS (HTTP Strict Transport Security) — tells the browser that this domain should only be accessed via HTTPS. Once the browser gets the HSTS header, all subsequent connections will be forced HTTPS, even if the user types http://.
  • HSTS Preload — register the domain with hstspreload.org so that the browser knows that your domain is HTTPS-only even before the first connection.
  • Certificate Pinning via HPKP (deprecated in Chrome) — modern alternatives can use the Expect-CT header to ensure valid certificate.
# Di Nginx — HSTS header
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

5. Use a Secure DNS Server for Upstream

DNSMasq is just a forwarder — it still relies on upstream DNS servers. If the upstream DNS server we use is not secure, all the layers below it are meaningless. Use a DNS server that supports DNSSEC and has a good reputation:

  • Cloudflare 1.1.1.1 (DNSSEC + DoH/DoT)
  • Google 8.8.8.8 (DNSSEC + DoH/DoT)
  • Quad9 9.9.9.9 (DNSSEC + block malware domains)
# Di /etc/dnsmasq.conf
server=1.1.1.1
server=8.8.8.8
# Gunakan DoT atau DNSCrypt untuk enkripsi upstream
# (tapi itu topik artikel terpisah)

6. Firewall Rules — Don't Just Rely on DNS

DNS poisoning is just one attack vector. If the attacker already has access to the local network, he can carry out ARP spoofing or IP spoofing which cannot be prevented by any DNS. Therefore, firewall rules remain the last defense.

In setting up the server as a router, we have full control: 

# nftables — blokir koneksi langsung ke IP yang mencurigakan
table ip filter {
    chain input {
        type filter hook input priority 0; policy drop;
        # hanya izinkan koneksi yang diperlukan
        ct state established,related accept
        iif lo accept
        tcp dport {22,80,443} accept
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
        # izinkan forward hanya untuk device yang dikenal
        ip saddr 192.168.1.0/24 accept
    }
}

Conclusion

DNS poisoning via DNSMasq is a technically easy technique to perform — just one line of configuration and all devices on the network can be redirected to a fake server. But modern applications have evolved with layers of defense such as certificate pinning, DoH, hardcoded IP, and app-level TLS validation that making this technique almost useless for spoofing large services such as social media or banking apps.

However, to protect our own services, we cannot rely on just one layer of defense. A defense-in-depth approach is required:

  • Firewall to control DNS traffic and block external DoH
  • DNSSEC validation to ensure the integrity of DNS answers
  • Monitoring DNS logs to detect anomalies
  • HTTPS + HSTS to secure connection
  • Trusted upstream DNS

The router DNS misdirection story is a reminder that a single point of failure at the DNS level can mess everything up. But by understanding how it works — and how against it — we can build systems that are much more resilient to attacks at the network level.

If you are serious about securing your home or small office network, concept of server as The router that I discussed before is the right foundation. From there, all these layers of security can be built on top of a single point of control: the Linux server which you yourself have control over.