How to Read Probe Data From Australian ISPs and DNS Servers

For Australians trying to make sense of which sites their ISP quietly blocks or mangles, raw probe data can look like a wall of jargon. The probe network runs small automated tests from vantage points across multiple countries, including nodes that measure reachability, DNS resolution, and HTTP response codes. When you filter those results to Australia, you get a window into how Telstra, Optus, TPG, iiNet, and smaller providers actually treat traffic on the ground, separate from the glossy claims on their websites.

This walkthrough covers how to navigate the dashboard, what each field means, and how to interpret patterns that show up repeatedly. It assumes no technical background beyond being comfortable opening a browser and reading a basic table. By the end, you should be able to tell whether a blocked site is being intercepted by your ISP's DNS, dropped at the network level, or simply returning an error from the server itself.

What Probe Data Actually Measures

Each probe is a tiny automated check that asks a specific question: when a connection is attempted from a particular country, what actually happens? The probes record the DNS response, the TCP handshake, and the final HTTP status. If any of those steps fail in a way that looks deliberate rather than accidental, the result is flagged as a potential block or filter.

For Australian users, this matters because the country has a layered filtering regime. The eSafety Commissioner maintains a block list for child sexual abuse material, ACMA orders ISPs to block certain offshore gambling and piracy sites, and individual providers often add their own family-friendly filters on top. Probes do not tell you why something is blocked, only that the connection did not complete as expected. That ambiguity is by design: the data is meant to be indicative, and you are expected to cross-check before drawing strong conclusions.

A single failing probe is rarely meaningful. The signal emerges when dozens of probes, run from different Australian vantage points, agree that a domain is unreachable or consistently returns a redirect to a warning page. Reading the data well means thinking in clusters of results, not individual rows. Have a squiz at the bigger picture before jumping to conclusions.

Filtering Results for an Australian View

The country selector on the dashboard is the first control to learn. Once you pick Australia, every column updates: the source IP blocks shift to Australian ranges, the timestamp entries align with local time, and the resolver labels start showing providers like Telstra or Optus. The default view usually returns the last 24 hours, which is useful for catching fresh incidents but can hide longer-running blocks.

If you are debugging a site you cannot reach from home in Perth or Brisbane, switch the time window to seven days. Australian ISPs occasionally apply temporary blocks during court-ordered takedown windows, and a longer view will reveal whether a domain is permanently filtered or just briefly unreachable. The probe network is volunteer-run, so gaps in coverage are normal; an empty cell does not always mean the site is accessible, only that no probe confirmed it.

Local vantage points are spread unevenly. New South Wales and Victoria tend to have the densest probe coverage because more volunteers run nodes there. If you live in Hobart or Darwin and notice fewer data points, that reflects the network rather than any actual difference in filtering. The platform documents its methodology, including how vantage points are recruited and how often they are audited, on the project description page.

Reading a Probe Result Row by Row

Each row in the results table carries a fixed set of fields, and the columns are mostly sortable. The most important ones for an Australian user are the source country (should read AU), the resolver used, the queried domain, the HTTP status returned, and a final verdict column that summarises the outcome.

Field	Typical Australian Value	What It Tells You
Resolver	Telstra DNS, Optus DNS, Google 8.8.8.8, Cloudflare 1.1.1.1	Who answered the DNS lookup
HTTP Status	200, 301, 403, 0 (no response)	Whether the site actually replied
Verdict	OK, Blocked, Tampered, Timeout	The probe's classification
Source AS	AS1221 (Telstra), AS7474 (Optus)	The network the probe ran from

A verdict of "OK" with HTTP 200 means traffic flowed normally. "Blocked" usually means DNS returned an unexpected IP, often the address of an ISP warning page or a sinkhole. "Tampered" is reserved for cases where a page came back but its content looked altered, such as an injected notice. "Timeout" means no response arrived within the probe's wait window, which on the NBN can also reflect a flaky FTTN link rather than censorship.

Spotting Patterns Across Local ISPs

Once you understand a single row, the next step is comparing across providers. Australians often switch between Telstra, TPG, and Aussie Broadband, and the same domain can behave very differently on each. TPG-owned networks historically applied broader DNS-level blocks than some competitors, while Telstra's resolvers have at times returned NXDOMAIN for domains on ACMA orders.

A useful habit is to pick a domain you know is blocked, such as one of the well-known offshore gambling sites, and search for it across multiple Australian resolvers. If four out of five resolve it normally and one returns a sinkhole IP, the block is almost certainly at the DNS resolver level, not deeper in the network. If every resolver fails and the TCP probe also drops, the filtering is happening on routing equipment, which is rarer but technically more serious.

Regional differences show up too. The NBN's multi-technology mix means an FTTP connection in Sydney may reach a target that an FTTN connection in Adelaide cannot, simply because of the access network rather than any active filtering. Comparing probe source ASNs helps separate transport problems from policy decisions.

Submitting Your Own URLs for Review

If you stumble on a site that looks blocked but does not appear in the public results, the platform accepts submissions. The submission form lets you paste a URL or IP, choose the country context (Australia), and add a short note about what you observed. Submissions enter a moderation queue and, if confirmed, feed into future probe runs.

It is worth noting what submissions cannot do. They do not trigger an immediate retest of the entire network, and they are not a way to lodge a formal complaint with your ISP. For that, the TIO (Telecommunications Industry Ombudsman) and ACMA remain the relevant bodies, and the project's contact page explicitly steers users towards those channels for individual disputes.

The best submissions include the time, the ISP, the type of connection (FTTP, FTTC, HFC, FTTN, or wireless), and what the user saw in their browser. Screenshots help. Without that context, moderators often cannot tell whether a failure reflects a genuine block or a local misconfiguration on the submitter's home router, especially given the quirks of Aussie-made networking gear.

Cross-Referencing and Common Pitfalls

A common mistake is treating probe data as definitive proof of censorship. It is one signal among several, and the platform itself flags its data as indicative. Pairing probe results with manual testing from your own connection, ideally using a different DNS resolver like 1.1.1.1 or 9.9.9.9, gives you a much clearer picture. If a site loads fine through Cloudflare's DNS but not through your ISP's default, the issue is almost certainly the resolver.

A quick cross-referencing checklist:

• Test the same domain through a third-party resolver such as 1.1.1.1
• Repeat the test at different times of day, including evenings when contention is highest
• Compare results from at least two Australian ISPs to rule out local issues
• Pay attention to the source ASN, not just the country label

Another pitfall is ignoring the resolver field entirely. Many Australians leave their router on automatic DNS, which usually points at the ISP's own resolvers. Changing those settings to a third-party resolver can bypass certain DNS-level blocks without changing anything else about your connection. It is not a workaround for everything, particularly not for IP-level or SNI-based filtering, but it is a useful diagnostic step.

Filter categories you will encounter in the data:

• DNS sinkholing by the ISP resolver, returning a warning page IP
• IP-level null routing, where packets simply disappear
• SNI-based blocking at the edge of the network
• HTTP 451 responses with explanatory legal notices

Finally, remember that the project is volunteer-supported and presented as a beta. Coverage gaps, stale entries, and occasional false positives are part of the deal. Treat the data as a starting point for your own investigation rather than a final verdict, and you will get the most out of it.

The practical takeaway is simple: pick a resolver, pick a vantage point, read the verdict column, and compare across at least two Australian ISPs before drawing conclusions. That habit alone will tell you more about your real browsing environment than any marketing material from a provider ever will, fair dinkum.