Why would you flush the DNS cache on the victim before triggering DNS spoofing, and what happens if you skip this step?

If mycampus.hslu.ch is already in the OS or browser cache, the victim won't even send a DNS query — they'll use the cached real IP, completely bypassing your spoof.

The DNS cache hierarchy (Linux example):

1. Browser cache (Firefox: 60s, Chrome: 30s by default)
2. OS resolver cache (systemd-resolved, dnsmasq)
3. Local DNS server (router, ISP)
4. Authoritative DNS server (last resort)

A query only goes "out the wire" if all caches miss. Your DNS spoof only intercepts on-the-wire queries.

Flushing each layer:

Why this complicates real attacks:

You flush manually here for clarity, but in a real attack:

• You can't ask the victim to flush their cache
• TTLs are typically short (60-300s for popular domains), so wait → cache expires → next query goes out → spoof works
• Or wait for browser/OS reboot → caches reset
• Or use a reverse shell on the victim to flush remotely

TTL considerations:

When the spoof succeeds, the forged response's TTL determines how long the lie persists:

• TTL too short → victim re-queries soon → if you stop spoofing, real IP returns
• TTL too long → suspicious if the real domain normally has short TTL
• Best practice for attackers: match the legit domain's typical TTL

Tip: Browsers also implement DNS prefetching for links on the page — they resolve names in advance. This can foil spoofing if prefetch happens before you start.

Go deeper:

• Name server (Wikipedia) — caching resolvers and why a cached answer means no query goes on the wire to intercept.
• Time to live — DNS records (Wikipedia) — how TTL governs how long a (real or forged) answer persists in cache.