Check Whether a Domain Is Blocked Where You Are

A domain can look unavailable even when the website itself is running. This guide explains how to manually resolve a domain to check if it's blocked at your location, using DNS results, direct connection tests and controls that separate local filtering from an ordinary site error.

Start with the recursive DNS resolver assigned by your operating system or router. It asks an authoritative nameserver for an IP address, often using a nearby cache. That address is a clue, not proof: one hostname can legitimately resolve to different addresses for CDN routing, IPv4 versus IPv6, or a regional service.

A blocked domain may produce no answer, a deliberately invalid address, or a server-level failure. Other domains may resolve normally but refuse traffic, terminate the TLS handshake or show a filtered page. Testing several layers is therefore more reliable than treating a blank browser screen as a verdict.

Keep the test tied to the connection you want to assess. Record the ISP, connection type, resolver, approximate location and time, because Australian broadband, fixed wireless and mobile paths can differ. Repeatability matters more than a dramatic single result.

What a DNS lookup can tell you

DNS resolution involves several parties. Your device normally speaks to a recursive resolver, which may answer from cache or contact authoritative nameservers. ISP-operated resolvers can apply category-based filtering; a public resolver follows its own policy. A lookup therefore tests the resolver's answer as much as the destination.

Blocking can occur before routing, during routing, or at the web service. DNS filtering tends to change the name-resolution result, while IP or SNI filtering can allow a correct address but prevent a connection. Application-level controls can return a page with the hostname present. No single command identifies all three mechanisms.

A failed lookup can reflect an outage, geoblocking, an expired domain, a takedown or an international shutdown rather than an Australian ISP block. Neumon’s analysis of international shutdowns shows why country and event context belongs in the notes before a result is labelled censorship.

Set up a location-faithful test

Australian home connections add context. The line may be NBN FTTP, FTTN or fixed wireless through retail brands such as Telstra, Optus, TPG, iiNet, Aussie Broadband or a regional provider. DNS controls can vary by ISP and product. A .com.au address may still use offshore hosting, while CDN answers vary by city, so "my connection" needs more than a postcode.

For example, an Optus mobile hotspot in Brisbane and an Optus home service in Melbourne follow different paths. A VPN or proxy can shift DNS and traffic overseas. In the familiar Australian troubleshooting phrase, give it a go on the device and line you care about, but keep the VPN off when observing the home connection.

Check the active resolver first. On Windows, ipconfig /all lists DNS servers; on macOS, use scutil --dns; Linux users can inspect resolvectl status. Browsers may use their own secure DNS provider, explaining why Chrome or Firefox differs from PowerShell or curl.

For a harmless commercial example, use the Garmexpresss store as a candidate hostname, then add a known control such as an Australian government or banking site. If the control also fails, investigate the connection before attributing the result to filtering.

Run the first lookup on Windows

On Windows, open PowerShell and query the normal resolver first. Resolve-DnsName shows the answer type and data, while nslookup is useful in Command Prompt or a terminal that lacks the cmdlet. Replace example.com with the exact hostname, including www if that is the address you use.

Resolve-DnsName -Name example.com -Type A

Repeat the lookup against separate recursive resolvers, such as Cloudflare at 1.1.1.1, Google at 8.8.8.8 and Quad9 at 9.9.9.9. These queries do not create a local viewpoint: an ISP may intercept DNS traffic, and each resolver has its own policy and cache. A difference is informative because those policies and caches differ.

Resolve-DnsName -Name example.com -Type A -Server 1.1.1.1
nslookup example.com 1.1.1.1

Read the status before the address. NOERROR with an answer is normal. NXDOMAIN says the name does not exist, although a filtering resolver can mislabel a blocked name that way. SERVFAIL can indicate filtering, broken DNSSEC validation or an upstream problem; a timeout needs another resolver to distinguish policy from packet loss. Repeated 0.0.0.0 answers may be a sinkhole signal.

Repeat the test on macOS and Linux

macOS and Linux provide dig, which makes the resolver explicit. Run it without a server to use the system configuration, then name public resolvers for comparison. The +short form is compact; omit it when you need the query status, flags and answer section.

dig example.com A +short
dig example.com AAAA +short
dig example.com @1.1.1.1 +short
dig example.com @9.9.9.9 +short

Query both A and AAAA records. A service can publish only one address family, and a local resolver may synthesise an IPv6 address for IPv4-only sites through DNS64. That is normal connectivity behaviour, not automatically censorship. host example.com 1.1.1.1 is a quick alternative on systems with host installed.

dig +trace example.com can reveal the delegation path, but consumer connections often block direct root and authority queries. Treat a failed trace as a diagnostic limitation, not proof of blocking. Compare a working control and two resolvers before testing transport.

Probe the returned IP address

Once DNS returns an address, test that address without performing another lookup. curl --resolve keeps the original hostname in the URL, HTTP Host header and TLS server name while connecting to the supplied IP. This helps reveal a failure after resolution, although the traffic still follows the same network path.

curl -I --connect-timeout 10 --resolve example.com:443:YOUR_IP https://example.com/

An HTTPS handshake can be inspected with openssl s_client. Set the server name with -servername; omitting it may fail even when the site works. A handshake plus an HTTP error shows the path reached the service; a timeout or reset may involve routing, filtering or the server. Ping failures are weak evidence because many servers block ICMP.

openssl s_client -connect YOUR_IP:443 -servername example.com </dev/null

Country context is essential. Net Neutrality Monitor publishes country censorship reports and accepts URLs or IP addresses for monitoring; its reports combine probe, blacklist, DNS and statistical observations. The project is a beta, volunteer-supported service developed and powered by AirVPN, and its findings are indicative research, not an authoritative ruling on every Australian observation.

Compare evidence before deciding

Bring the signals together rather than forcing a binary answer. The system resolver, public resolvers and an IP-level HTTPS request answer different questions. CDN and split-horizon DNS can create legitimate variation, so a changed IP is not proof of censorship.

Signal	Likely interpretation	Limitation
System resolver returns NXDOMAIN or SERVFAIL	Possible filtering or resolver failure	Confirm with another resolver and a control
System resolver times out, public resolver works	Local DNS or path problem	May be filtering, not necessarily censorship
Public resolvers return different addresses	GeoDNS, CDN, round-robin or cache variation	Address differences alone prove little
DNS resolves and curl --resolve succeeds	Reachable on this path at this time	Does not cover every network or later content filtering
DNS works but TLS or HTTP fails	SNI policy, server issue or content restriction	Compare another IP and hostname

Method matters. The dress-making programme guide from IDF Bangalore illustrates why an intervention should address a defined barrier rather than a surface symptom; similarly, classify a DNS failure by layer and population.

Use corroboration. A block is more credible when the domain consistently fails on the local resolver, works through a permitted independent path, and matches observations in the same country and time window. If one browser or resolver fails, check secure DNS, cached answers, a control domain and raw command output first.

Record one reproducible result

Save a compact evidence record: timestamp and time zone, full hostname, ISP and access type, active resolver, resolver addresses queried, A and AAAA answers, command output, direct HTTPS result and browser result. Also note whether a VPN, proxy, mobile network or secure-DNS setting was active.

For repeated checks, Neumon’s guide to automating censorship checks shows how its API supports checks from your own servers. Automation helps compare resolvers and networks over time, but preserve raw responses rather than a yes-or-no flag; transient DNS failures can resemble policy blocks.

Keep one working control result and one suspect result beside the paired resolver test. That bundle helps distinguish a local effect from a site-wide outage or configuration change. Open a terminal on the connection you want to test, replace example.com with the hostname under test, run dig +short example.com and dig +short example.com @1.1.1.1, then save both outputs with the timestamp.