Understanding Transparent And Encrypted DNS Censorship

When a device looks up a website name, it usually asks a DNS resolver to translate that name into an IP address. This routine exchange can also become a point of control. An Internet Service Provider, public hotspot, enterprise network or national filtering system may interfere with the request, prevent a response, or return an address chosen by the operator.

The difference between transparent and encrypted DNS censorship is primarily about visibility and control. Transparent filtering acts on ordinary DNS traffic that can be inspected in transit, while encrypted DNS protects the contents of the lookup from many observers. Encryption does not guarantee access, however. A network can still block resolver servers, target destination addresses, or use other signals to identify restricted services.

How DNS Filtering Works

Traditional DNS commonly uses UDP or TCP on port 53. Because the request and response are readable, a filtering device can identify a domain such as a news site, file-sharing service or social platform. It may then drop the request, return an error such as NXDOMAIN, send the user to a warning page, or provide an incorrect IP address.

This process is often called DNS interception or DNS tampering. The user may believe the website is offline when the problem is actually the resolver path. A browser can also show a generic connection failure if the returned address is unreachable. In Australia, the result may differ between a home NBN connection, a mobile network in Sydney, and a public Wi-Fi service in a Melbourne library because each network can use different resolvers and filtering policies.

DNS censorship is only one layer of website blocking. An ISP may combine resolver manipulation with IP blocking, URL filtering, proxy inspection or court-ordered restrictions. Australia has a long-running system of ISP-level blocking for specific sites under legal processes, so a DNS result should be treated as evidence of a network condition rather than proof of a universal ban.

What Transparent Interception Reveals

Transparent censorship is relatively easy to observe because the DNS exchange remains visible to equipment between the user and the resolver. A probe can compare the answer from an ISP resolver with answers from an independent resolver, then look for mismatched IP addresses, repeated failures, forged responses or redirects. Timing can also reveal whether a request was filtered immediately or simply suffered a network outage.

The exact response matters. An empty answer may indicate deliberate suppression, but it can also result from a misconfigured resolver or a domain that has no current records. A block page is stronger evidence of intentional intervention, particularly when it appears consistently across several probes. Repeating tests from more than one Australian provider can separate a local fault from a broader pattern.

Transparent filtering does offer a useful measurement advantage: researchers can often identify the manipulated response and compare it with an expected one. The weakness is that modern networks increasingly move DNS into encrypted channels, making ordinary port-53 tests less representative of what every user experiences.

How Encryption Changes Censorship

DNS over TLS, known as DoT, sends DNS queries through an encrypted connection, usually to a resolver on port 853. DNS over HTTPS, or DoH, carries the same type of request inside HTTPS traffic, commonly over port 443. This prevents a simple observer from reading individual domain requests between the device and the chosen resolver.

Encryption changes the censor’s options rather than removing them. A provider may block known DoH or DoT resolver addresses, restrict port 853, interfere with the TLS connection, or use IP and traffic patterns to identify a service. If the resolver itself follows a filtering policy, the lookup can still be denied even though outsiders cannot see its contents.

The destination connection can also expose information. A censor may inspect the requested IP address, TLS metadata, certificate behaviour or application traffic after DNS resolution. Encrypted Client Hello can reduce some hostname visibility during TLS setup, but it does not hide every network signal. In practice, encrypted DNS improves privacy and reduces casual manipulation while leaving several routes for network-level blocking.

Comparing Measurement Signals

The most useful way to interpret censorship data is to examine several signals together. A failed lookup through a local resolver, a successful lookup through an encrypted resolver and an unreachable destination suggest a different situation from a consistent block page returned by the ISP. Probe location, resolver choice, protocol and test time all affect the result.

Signal	What it may indicate	Important limitation
NXDOMAIN from an ISP resolver	Domain suppression or resolver error	The domain may genuinely have no record
Incorrect or unexpected IP address	DNS poisoning or redirection	CDN and geo-routing can produce different valid addresses
Timeout on port 53	Dropped DNS request or ordinary network fault	A single test cannot establish intent
DoH or DoT connection failure	Encrypted resolver blocking or service outage	The resolver may be unavailable for unrelated reasons
DNS succeeds but the site does not load	IP, TLS, application or destination blocking	DNS is not the only censorship layer
Warning or legal notice page	Deliberate filtering is likely	The page may come from a proxy or local network policy

For Australian users, comparisons are especially valuable because the local market includes large fixed-line and mobile providers, smaller NBN retailers and independent privacy-focused resolvers. A result seen on Telstra mobile service in Brisbane may not match one seen through an NBN reseller in Perth. That difference is useful evidence, not necessarily a contradiction.

The probe data guide explains how country-level tests can be read without confusing a failed probe with a confirmed nationwide block. This distinction is important when measurements come from different networks or are collected at different times.

Practical Ways To Check A Result

A careful check should preserve the conditions of the test. Record the network, resolver, protocol, time and domain, then repeat the lookup. A result observed once on a café network near Central Station may reflect that venue’s filtering equipment rather than the policy of the mobile carrier or the broader Australian Internet.

Useful checks include:

• Compare the default ISP resolver with a reputable independent resolver.
• Repeat the test over both a home NBN connection and a mobile network where possible.
• Test ordinary DNS against DoT or DoH without changing several variables at once.
• Compare returned IP addresses and inspect whether they belong to the expected provider.
• Record failures, redirects and warning pages rather than labelling every error as censorship.

Privacy and measurement goals should be kept separate. Encrypted DNS can prevent an access provider from casually reading domain lookups, but the selected resolver may still log requests or apply its own blocking rules. A resolver operated by a company overseas can also introduce different legal, commercial and operational considerations from an Australian ISP resolver.

Net Neutrality Monitor presents its data as indicative research from a volunteer-supported beta project. Its blacklist, DNS, probe and statistical records are most valuable when used comparatively. A pattern across several probes and methods is stronger than an isolated result, particularly for domains delivered through content delivery networks or hosted across multiple countries.

Reading Results With Care

Censorship reports should describe what was measured rather than assume why it happened. A domain may fail because of DNS tampering, a routing problem, expired infrastructure, geoblocking, an overloaded resolver or a deliberate access restriction. Encrypted DNS can narrow the likely explanations, but it cannot identify every filtering mechanism by itself.

Look for consistency across time and networks. If a domain returns the same unexpected address from multiple probes, while independent encrypted lookups return a different address, DNS interference becomes more plausible. If every lookup succeeds but HTTPS connections fail only on one provider, investigation should move beyond DNS to IP filtering, TLS handling or application-layer controls.

For practical use, keep a small record of the domain, network, resolver type, response and timestamp. That simple habit makes results from Sydney, Adelaide or regional Queensland easier to compare and helps distinguish a recurring policy from a temporary outage. The most reliable takeaway is to treat transparent and encrypted DNS tests as complementary evidence: compare protocols, compare networks, and verify the destination before calling a failure censorship.