⚖️ Ethical Legal Notice: The techniques discussed here demonstrate network vulnerabilities to help system administrators, security students, and home users configure encrypted DNS defenses. Testing these methods against unauthorized networks violates national and international computer security laws.

Imagine opening your laptop in a coffee shop or hotel lobby. You launch your browser, type login.examplebank.com into the address bar, and press Enter. The page loads with the exact colors, logos, and input fields you expect. You type your username and password, hit Submit, and get redirected right to the legitimate website.

Everything looked completely normal. Yet behind the scenes, an attacker on the same local network intercepted your domain lookup and pointed your browser to an IP address they control. Your login credentials were harvested before you even realized what happened.

This attack is known as DNS Spoofing (or DNS Cache Poisoning). To understand how it works and how to protect yourself, we have to look at how domain name resolution was designed in the early days of the internet.

1. The Internet Phonebook and the Flaw in Port 53

Computers do not communicate through human-friendly names like linuxpedia.org. They route network packets using numeric IP addresses like 104.21.45.18. The Domain Name System (DNS) acts as a global directory that translates hostnames into IP addresses.

When you request a website, your computer follows a query path:

  1. Your operating system checks its local DNS cache and hosts file.
  2. If missing, it sends a DNS query packet to your configured resolver (usually assigned by your local Wi-Fi router).
  3. The resolver queries root servers, Top-Level Domain (TLD) servers, and authoritative nameservers until it finds the IP address.
  4. The resolver returns that IP to your computer.
bash - standard dns lookup query with dig 
$ dig example.com A +noall +answer

; <<>> DiG 9.18.28 <<>> example.com A +noall +answer
;; global options: +cmd
example.com.            3600    IN      A       93.184.215.14

Here is the fundamental vulnerability: traditional DNS queries travel over UDP port 53 in plain, unauthenticated text. There is no cryptographic signature verifying that the response came from the real server, and no encryption preventing someone on the local network from reading or faking the answer.

2. How DNS Spoofing Works on Local Wi-Fi

On a shared local network, an attacker does not need to compromise global root servers. They can poison the lookup right between your laptop and your local router using two primary methods:

Method A: Rogue DHCP and DNS Server

When your device joins an open Wi-Fi network, it broadcasts a DHCP request asking for an IP address, default gateway, and DNS server. An attacker running a rogue access point (or a rogue DHCP daemon) can respond faster than the real router, assigning their own computer as your default DNS resolver. Every single website lookup you make is routed directly through the attacker machine.

Method B: ARP Spoofing + DNS Response Injection

If the router is already configured, an attacker can use ARP cache poisoning to position themselves as the Man-in-the-Middle (MitM). They send gratuitous ARP replies telling your machine that the attacker MAC address belongs to the router IP.

bash - observing arp table manipulation 
$ ip neighbor show
# Target gateway ARP entry poisoned to match attacker MAC
192.168.1.1 dev wlan0 lladdr b4:2e:99:a1:4f:12 REACHABLE
192.168.1.185 dev wlan0 lladdr b4:2e:99:a1:4f:12 REACHABLE

Once traffic passes through the attacker machine, their packet filter listens for incoming UDP 53 packets. When your computer asks "What is the IP of target-site.com?", the attacker immediately injects a forged DNS response packet with a matching Transaction ID:

wireshark - dns response packet race 
[Client Request]
Query: target-site.com (Type A) -> Sent to 192.168.1.1:53

[Attacker Injected Response (Wins the race!)]
Response: target-site.com -> 192.168.1.185 (Attacker Web Server)
TTL: 300 seconds

[Real DNS Server Response (Arrives too late, discarded by client)]
Response: target-site.com -> 93.184.215.14 (Legitimate IP)

3. The Fake Portal: What Happens After Redirection

Because UDP is stateless, your computer accepts the first valid-looking response it receives and discards any later packets. Your operating system caches target-site.com = 192.168.1.185.

When your browser connects to that IP, it reaches a local web server (often running Nginx or a lightweight Python server) hosting a cloned replica of the real login form. Here is what happens next:

  1. The user sees a realistic login screen with familiar branding.
  2. The user enters their credentials.
  3. The local web server records the POST data to a local log file.
  4. The server responds with an HTTP 302 redirect sending the user back to the authentic website, making it appear like a minor network glitch.
server.log - captured http post on rogue portal 
[HARVESTED POST REQUEST - /api/v1/auth]
Host: target-site.com
Origin: http://target-site.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64) ...
Payload: username=developer_alex&password=SuperSecretPassword2026!
Action: Credential written to access.log -> Redirecting client to genuine URL
💡 Why Captive Portals Condition Bad Habits:
Public Wi-Fi networks in airports and cafes regularly force users to accept redirection to captive portal splash pages. Attackers take advantage of this muscle memory because people expect popups and login forms when connecting to public networks.

4. Why HTTPS Throws Warnings (And Why People Click Through)

Modern browsers enforce HTTPS encryption. When a browser visits https://target-site.com on the fake IP, the attacker server cannot present a valid SSL/TLS certificate signed by a trusted Certificate Authority (CA) for that domain.

Your browser displays a red security warning: "Your connection is not private (NET::ERR_CERT_COMMON_NAME_INVALID)".

However, attackers often combine DNS spoofing with Typosquatting (registering visually similar domains like rn-bank.com instead of m-bank.com) or using free Let's Encrypt certificates on custom lookalike domains. On public networks where captive portals are common, many users have been conditioned to click "Proceed Anyway" just to get online, walking directly into the trap.

5. How to Protect Yourself: Modern Encrypted DNS

Defending against DNS spoofing requires eliminating unauthenticated cleartext lookups. Here are the three most effective defenses:

Defense 1: Enable DNS-over-HTTPS (DoH) in Your Browser

DNS-over-HTTPS encrypts DNS queries inside standard HTTPS traffic on port 443. To an eavesdropper or local router, your DNS lookups look identical to regular encrypted web browsing. An attacker cannot inspect, redirect, or forge the responses.

Defense 2: Configure System-Wide Encrypted Resolvers in Linux

On modern Linux distributions (Ubuntu, Debian, Fedora), systemd-resolved can enforce DNS-over-TLS (DoT) across all applications, not just your web browser.

/etc/systemd/resolved.conf - systemd encrypted dns 
[Resolve]
# Primary and fallback encrypted Quad9 / Cloudflare servers
DNS=9.9.9.9#dns.quad9.net 1.1.1.1#cloudflare-dns.com
FallbackDNS=149.112.112.112 1.0.0.1
DNSOverTLS=yes
DNSSEC=yes

After editing the configuration file, restart the resolved service to lock in your encrypted lookups:

bash - verify encrypted dns status 
$ sudo systemctl restart systemd-resolved
$ resolvectl status
# Confirm DNSOverTLS is active:
Link 2 (wlan0)
  Current DNS Server: 9.9.9.9#dns.quad9.net
         DNS Servers: 9.9.9.9#dns.quad9.net 1.1.1.1#cloudflare-dns.com
       DNSOverTLS: yes
           DNSSEC: yes/supported

Defense 3: Always Use a WireGuard or OpenVPN Tunnel

When you connect to an encrypted VPN tunnel, your computer routes all network traffic, including DNS requests, directly through the encrypted VPN gateway. Local Wi-Fi attackers only see meaningless encrypted UDP blobs passing to your VPN server.

Summary Checklist

Securing your domain lookups is one of the highest-impact defensive habits you can build. Once your DNS queries are wrapped in TLS cryptography, local network eavesdroppers are locked out completely.