Spotting a false positive in our censorship reports

A flagged block on Net Neutrality Monitor can feel like a smoking gun. Before treating any single result as evidence of deliberate filtering, it is worth remembering that probes run across consumer lines and volunteer third-party resolvers, where a single misconfigured server can produce a misleading entry.

In Australia, the picture is shaped by a handful of large retail providers, the National Broadband Network's wholesale layer, and the oversight role of ACMA. A DNS hiccup at a regional resolver in Geelong can look identical to a Sydney-wide block, and the same is true for throttling on a Telstra mobile hotspot during peak hours in Brisbane.

This article walks through the practical checks used to tell a genuine censorship event from an artefact. It assumes no specialist equipment, only a willingness to repeat a few tests from a home connection and to read the data we publish with care.

The methods described below are designed to complement the case studies already published on the site, so anyone interested in the network-level effects of a single domain can start with single domain case study before applying the verification steps outlined here.

How blocking detection actually works

Our probes query DNS resolvers and attempt HTTPS connections from volunteer endpoints across dozens of countries. When a domain resolves to an unexpected IP, returns a TCP reset, or never completes a TLS handshake, the probe records the failure and tags it as a potential block.

The same probe also records the resolver it used, the AS number of the upstream network, and the response time for each step. That metadata is what separates a true block from a flaky connection. A genuine filtering decision is usually consistent across several probes and across different resolvers within the same country.

In Australia, the test outcomes are often coloured by the routing paths inside Telstra, Optus, and TPG, plus the way the NBN's Point of Interconnect can pass on cached DNS responses differently in Perth than in Hobart. None of these network quirks imply censorship, but they do show up in raw data.

Frequent sources of false positives

The most common reason a benign site appears in a report is a stale DNS cache. A resolver may still be serving an old record from before a domain migrated to a new hosting platform, so the IP it returns can point to a sinkhole or a parked domain that has nothing to do with filtering.

A second source is geo-blocking at the origin. Many international services, including streaming platforms and news outlets, restrict access from Australian IP ranges by choice rather than by mandate. The probe sees a refusal to connect and records it as a block, even though the decision came from the website itself.

Local outages matter too. When a backbone provider in Adelaide suffers a fibre cut, every HTTPS probe from that region fails at once. The report will show what looks like a coordinated block, but the underlying cause is physical.

Cloudflare or Akamai front-ends that return a 403 to specific user agents can also be misread. If our probe sends an unusual TLS fingerprint, the edge node can refuse the handshake and the report will list the site as blocked from Australia.

Cross-checking with multiple resolvers

The fastest way to rule out a resolver-specific quirk is to repeat the query against a different resolver. If the result changes, the block was almost certainly local to the first resolver and is not a national-level decision.

Manual testing from a laptop or a phone using a fresh DNS-over-HTTPS server is usually enough. The volunteer panel of probes we publish can also be filtered by resolver, which lets you confirm whether the same outcome appears across several different DNS servers.

The following comparison lists the main verification methods available to readers in Australia.

Method	What it checks	Strengths	Limits
Repeat with a public DoH resolver	DNS-level filtering	Quick, no extra hardware	Can be geo-blocked at origin
Test from a mobile SIM in another state	Network-level routing	Reveals NBN or mobile quirks	Coverage limited to carrier coverage
Inspect raw probe data	Consistent failure across probes	Shows patterns, not single hits	Requires some familiarity with ASNs
Compare with a VPN exit in another country	Geographic filtering	Strong signal on geo-blocks	VPN exit can itself be on a dead line
Submit the URL for community review	Crowdsourced confirmation	Surfaces other Australian reports	Results arrive gradually

Once a method confirms or rules out the block, the result should be recorded against the original entry so future readers can see the full chain of evidence.

Reading probe data for Australia

The probe feed for Australia is grouped by ASN and by state, so a reader can quickly see whether a flagged domain shows the same behaviour from a Telstra consumer line in Sydney and from an Optus business line in Melbourne. A real filtering decision tends to appear in both, while a false positive usually clusters around one resolver or one region.

Readers who want a guided walk-through can follow probe data walkthrough, which explains each column in the export and shows what a clean block pattern looks like compared with a noisy one.

The Australian dataset also includes notes from the eSafety Commissioner when an official direction is in force, so any block that aligns with a published determination is more likely to reflect deliberate filtering than a transient error.

Throttling versus outright blocking

Slow pages and dead pages are not the same thing. Throttling is a deliberate speed restriction, often applied to streaming or P2P traffic by an ISP, while a block is a refusal to deliver the requested content at all.

A simple timing test can help. If the same domain loads in under a second on a mobile hotspot in Darwin but takes fifteen seconds on a home NBN line in Brisbane, the bottleneck is likely to be shaping rather than filtering. A quick walkthrough of this method is described in simple ISP check.

It is worth running the test several times across a day, because throttling often kicks in only during peak congestion windows. A single slow result is rarely enough to draw a conclusion, but a pattern of slow results at the same hour each evening usually points to shaping rather than censorship.

Contributing reliable evidence

The best way to reduce false positives in our reports is to submit clean, reproducible evidence. That means including the resolver used, the timestamp in local Australian time, the AS number, and a note about any other services affected at the same moment.

Photos of error pages, screenshots of traceroute output, and the raw output of a manual dig or kdig command all help. When several readers in different states send similar notes, the dataset becomes much harder to misread.

Reports that follow this format feed back into the volunteer panel and strengthen the project for everyone who relies on it. Each careful submission trims the noise from the next published summary.

The single most useful habit is to repeat the test before reporting. A block that vanishes on the second try was never a block, and catching that at the start saves hours of analysis later. Genuine censorship leaves consistent patterns across probes, resolvers, and time, so consistency is the strongest signal that a reported entry reflects a real decision rather than a passing glitch in the network.