Identify DNS spoofing across Australian networks

DNS spoofing can send a familiar web address to the wrong server, redirect a visitor to a phishing page, or make a site appear unavailable. On Australian networks, the cause may be a compromised router, rogue DHCP server, poisoned cache or upstream interference. The absence of a visible warning does not make the behaviour trustworthy, particularly when an address changes between lookups.

The Domain Name System (DNS) translates a name such as example.com.au into an IP address. Spoofing supplies a forged answer, while cache poisoning plants a false answer for later users. A typo-squatted domain is different: the entered name is genuinely mapped as registered rather than falsely resolved.

Not every failed page proves an attack. An outage, overloaded resolver, content filter, expired certificate or faulty website can look similar. The useful question is whether the DNS answer is inconsistent, implausible or different on a clean network path. That distinction prevents routine maintenance being treated as a breach.

Reliable identification depends on comparison, timing and evidence. Test from more than one device and network, record the resolver and returned IP address, and preserve logs before changing settings. Australia’s mix of NBN fixed-line, fixed wireless and satellite services, plus providers such as Telstra, Optus and TPG, can create legitimate differences in reachability and filtering.

Spot the warning signs

A strong indicator is a trusted domain returning an unexpected IP address, one outside the provider’s documented range, or one shared by unrelated services. Other signs include redirects to look-alike domains, certificate warnings on familiar names, intermittent failures that disappear after a cache is cleared, and traffic going to an unfamiliar server. Attackers may briefly return a correct answer, so one successful lookup is weak evidence.

The failure pattern helps narrow the cause. If every device on home Wi-Fi sees the forged answer but a phone on mobile data resolves correctly, suspect the router, DHCP service, local DNS configuration or upstream path. If both networks fail, check the domain, site and broader connectivity. If only one browser is affected, a secure DNS setting, extension, browser profile or cached response is more likely.

Build a reliable DNS baseline

Start by documenting what the network returns. Where dig is available, run dig example.com.au A and note the answer, status, TTL and server. Repeat it several times, then repeat it on mobile data or a trusted hotspot. A screenshot with the time, resolver and IP result is more useful than a vague report that a site looked wrong.

Compare the result with an independent lookup. dig @1.1.1.1 example.com.au A and dig @8.8.8.8 example.com.au A query named public resolvers directly, although they may show different CDN locations and do not prove an attack. Compare names, addresses and flags with a trusted source; use dig +trace example.com.au only when appropriate. An unusually short TTL can indicate a fast-changing answer, but it is not conclusive.

Compare resolvers and routes

Run the same hostname through the ISP resolver, the router’s advertised resolver, a second trusted recursive resolver and the operating system’s configured resolver. If local answers agree but consistently differ from an independent path, filtering or an upstream routing change is more plausible than random spoofing. Forged answers often vary between resolvers or contain addresses unrelated to the expected service; a block page or deliberate NXDOMAIN response suggests filtering.

Account for privacy and security tools. DNS over HTTPS and DNS over TLS can hide queries from the router and bypass ISP-level controls, while a VPN can change both resolver and route. Some Australian businesses and schools use mandatory filters, and provider practices differ. Test without bypassing organisational controls unless authorised, and use an approved second network rather than an unknown VPN.

Inspect devices, routers and packets

Check which DNS servers devices actually use. On the router, review DHCP settings, the WAN connection, firmware, custom DNS entries and recently installed management software. Automatic assignment of an unfamiliar resolver is concerning, especially when every connected device receives it. Access administration only through the trusted local address, update firmware from the vendor’s official channel, and change credentials if access may have been compromised.

Cached answers can preserve the symptom after the source problem is fixed. Clear the relevant cache with ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS, or sudo systemd-resolve --flush-caches on many Linux systems. Restarting the router may refresh its cache but also interrupts service. Re-test after each change and note whether the answer, latency or reachability changes.

Packet capture provides stronger evidence. Wireshark can show DNS over port 53, while encrypted DNS may use port 853 or HTTPS on port 443. Look for replies to queries that were not sent, mismatched transaction details, implausible addresses or inconsistent TTLs. Resolver and router logs can show whether the false answer entered through DHCP, local configuration or an upstream response. If encryption hides the payload, use endpoint and resolver logs rather than assuming the traffic is harmless.

Separate spoofing from ordinary faults

Local conditions often imitate tampering. An NBN fixed-line service can fail at the cabinet or provider, while fixed wireless and satellite links have different latency and availability; outages, captive portals, overloaded resolvers and filtering rules may leave DNS working but prevent pages loading. Try another device, reboot network equipment, confirm the domain works elsewhere, and test a raw IP only diagnostically. Never enter credentials merely because an IP opens a page with expected branding.

For a plain-language check of common causes, the basic web troubleshooting notes explain network interruptions, filtering, caching, and domain or hosting problems, with steps such as retrying later, checking the connection and trying another device or network. Use these checks before alleging an attack. If only one hostname fails and DNS returns the correct address, the fault more likely involves the website, hosting or certificate configuration than DNS poisoning.

Response actions for a suspected DNS attack

If a forged answer is found, isolate affected devices from the suspect network while keeping evidence. Switch to a trusted mobile connection, record timestamps, screenshots, resolver addresses and returned IPs, and avoid repeatedly loading the suspicious destination. Disconnect rather than merely changing DNS if the router may be compromised; a compromised device can override later settings.

• Isolate and preserve: Use a trusted hotspot, retain DNS and router logs, and note which devices, accounts and services showed the false answer.
• Verify independently: Compare the hostname through a second resolver and network, and use authoritative DNS information to confirm the expected address.
• Repair the path: Correct DHCP and resolver settings, update router firmware, remove unauthorised entries, and clear caches one stage at a time.
• Escalate proportionately: Contact the ISP or network administrator, reset exposed credentials, and seek specialist help when routers, banking or business systems are affected.

Then assess impact, not only the hostname. Rotate passwords entered on impersonated pages, revoke active sessions, alert affected banks or service providers, and report significant incidents to the Australian CERT through its ReportCyber service. Australian Cyber Security Centre guidance is relevant when a business, school or government network is involved. Keep raw logs private until tokens, internal hostnames and other sensitive data are removed.

Use the next DNS anomaly as a prompt to run a controlled comparison: check one known domain across two resolvers, record the addresses, then repeat from a separate network. Preserve the evidence, correct the resolver path and keep monitoring until results are stable across devices and providers.