Why Some Blocked Sites Appear as No Answer While Others Show Timeout

A blocked website can fail at several layers of the connection process. “No Answer” usually describes the result of a domain name system lookup, while “Timeout” describes what happened when a system received no reply within a set period. The labels may look equally conclusive, but they point to different technical failures and require different interpretations.

Net Neutrality Monitor tracks and analyses Internet censorship and filtering by Internet Service Providers and DNS servers. It publishes blocked websites and addresses across multiple countries alongside blacklist, probe, DNS and statistical data. The service is presented as a beta, volunteer-supported project developed and powered by AirVPN, with its findings provided for indicative research purposes.

The local connection matters. A DNS request made through an Australian broadband service in Sydney can produce a different result from the same request through a mobile hotspot in Melbourne or a satellite connection near a regional community. Resolver location, provider routing, IPv4 and IPv6 support, caching and the timing of a probe can all affect the outcome.

Understanding the distinction therefore requires looking beyond the status label. A “No Answer” response may reveal a deliberate DNS denial, while a timeout may indicate dropped traffic, an overloaded resolver or a website that has become unreachable for reasons unrelated to censorship.

What the two status labels mean

A browser normally converts a domain name into an IP address before contacting a website. It asks a recursive DNS resolver, which may consult local caches and authoritative name servers. The resolver’s reply can include an IPv4 address, an IPv6 address, a canonical name or an error condition.

“No Answer” commonly refers to a successful DNS transaction that contains no usable address record. In DNS terminology, this is often a NOERROR response with an empty answer section, also called NODATA. Some monitoring systems group NXDOMAIN, which says that a name does not exist, into the same broad category. A domain might legitimately lack an A or AAAA record, although a filtering system can also use an empty or nonexistent response to suppress access.

A timeout is a timing observation rather than a DNS response code. It means a resolver, server or endpoint failed to send the expected reply before the monitoring deadline. DNS packets may have been dropped, TCP fallback on port 53 may have been blocked, or the destination may simply be overloaded. If DNS succeeds but the TCP connection, TLS handshake or HTTP request stalls, the resulting timeout originates later in the path.

Where filtering enters the request path

Censorship can be applied to names, addresses or application traffic. A DNS filter may return NXDOMAIN, an empty answer, a loopback address or a sinkhole IP address. An IP filter may instead accept the DNS lookup and then discard packets sent to the resolved address. This second approach often produces a timeout because the browser knows where to connect but never receives a response.

Other blocks operate after the network connection succeeds. A website service, content delivery network or web application firewall can return an explicit refusal, redirect to a notice or serve an error page. Geographic access controls and streaming rights restrictions can behave similarly. These cases are distinguishable from network-level filtering because the client receives a prompt response, even when that response denies the requested content.

The monitor’s blacklist records can help identify whether a domain or address has already been catalogued. An entry establishes a useful reference point, but it does not by itself reveal which layer failed or whether the result applies to every Australian connection.

Observation	Likely interpretation	Common causes	What it does not prove
No Answer	DNS replied without a usable address	Missing address record, deliberate DNS filtering, broken domain configuration	That the site is blocked nationwide
Name not found	The resolver reports NXDOMAIN	Nonexistent domain, expired configuration, filtered DNS response	That the underlying website is offline
Timeout	No expected reply arrived before the deadline	Packet dropping, resolver failure, blocked TCP fallback, overloaded server, faulty IPv6 path	That a censorship system caused the failure
Refusal or redirect	A server returned an explicit decision	Application block, CDN policy, geographic restriction, website security control	That the connection was blocked upstream

What Australian network conditions can change

Australia’s broadband market includes large providers such as Telstra, Optus, Vodafone and TPG, as well as smaller regional and niche operators. Households in Sydney and Melbourne commonly receive service over the NBN, while some connections use fixed wireless. These networks use different backhaul, DNS infrastructure and routing arrangements, so an identical query can reach a different resolver or authoritative server depending on the plan.

The distinction is also visible in regional and remote Australia. A fixed-line or fixed-wireless connection may use a resolver operated close to the international gateway, while a satellite service can have higher latency and longer resolver timeouts. If a probe is repeated over both IPv4 and IPv6, the results may differ because only one protocol has a working route. Cached answers can further change the apparent result between runs.

Local travel adds another layer. Someone clearing customs at Sydney or Melbourne airports may still be using airport Wi-Fi, a roaming SIM or a mobile hotspot. Each option supplies a different DNS path from the connection used at home. ACMA regulates parts of the Australian communications market, while the eSafety Commissioner administers the Online Safety Act, but neither regulator’s role explains the mechanism behind an individual timeout.

Reading monitor results responsibly

Country-specific results should be treated as observations from a particular time and vantage point. The useful evidence is not just the word “blocked,” but the timestamp, resolver, probe protocol, address family, returned status and any retry information. A single result can reflect a temporary packet loss or a site-side outage. Repeated observations from several locations provide a stronger basis for identifying consistent filtering.

Volunteer probes also introduce legitimate variation. People may use different operating systems, DNS providers, browsers and connection types. Encrypted DNS, including DNS over HTTPS, can bypass a local resolver while still using a provider that applies its own policy. It does not make the destination reachable if the resolved IP address is subsequently filtered, and a separate encrypted-DNS endpoint may itself be unreachable over the tested path.

Evidence should be kept separate from awareness material. A resource such as the Girl Force project can provide community context around online participation, but it does not validate a particular timeout. The same care applies to the monitor’s own findings: they are indicative research data from a beta service, so the underlying records and reproducible conditions deserve more weight than a summary label.

Turning one failure into repeatable evidence

Start by recording the failed domain or IP address with an exact timestamp, the Australian city, the ISP and the connection type. Note whether the attempt used home broadband, mobile data, a VPN, a particular browser or encrypted DNS. Checking the address with both IPv4 and IPv6 can reveal a protocol-specific route problem that a single attempt would conceal.

Retest through another connection and another resolver before classifying the failure as censorship. A domain that produces the same empty response across separate networks is more likely to be filtered or deliberately restricted than one that fails only on a congested local path. Capturing the error page or command output helps identify whether the failure occurred during DNS resolution, connection establishment, TLS negotiation or HTTP exchange.

The concrete next step is to submit one affected URL or IP address through the monitoring process, recording the date, city and connection type so the next comparison has a clear baseline.