How to Read Raw DNS Response Logs from Network Probes

Raw DNS response logs show what happens when a probe asks a resolver to translate a domain name into an IP address. They can reveal whether a request received a normal answer, returned an error, timed out, or was redirected by filtering infrastructure. Reading them correctly requires attention to several fields at once rather than relying on a single status label.

For Australian users, the result may vary between an NBN connection in Brisbane, a mobile network in Melbourne, and a business connection in Perth. Different providers can operate different resolvers, apply separate policies, or route DNS traffic through filtering systems. A log is therefore evidence of one measurement path at one moment, not a universal statement about every connection.

The records on Net Neutrality Monitor are intended for indicative research. They help identify patterns across probes, countries, resolvers, and domains, while preserving the distinction between an observed DNS result and a confirmed explanation. The most useful reading method combines the raw fields with repeated tests, comparison data, and knowledge of how DNS works.

What a probe actually records

A probe usually begins with a DNS question containing a domain name, such as example.com, and a record type, such as A for IPv4 or AAAA for IPv6. It sends that question to a selected resolver and records the reply. The log may also identify the probe location, resolver address, transport protocol, timestamp, and test identifier.

The timestamp matters because DNS results can change quickly. A domain may use a short time-to-live, rotate between servers, or sit behind a content delivery network. A filtering rule can also be introduced or removed during the day. A result measured from Sydney at 9 am should not automatically be treated as identical to a result from Adelaide several hours later.

Some probes use ordinary DNS over UDP, while others may test TCP or encrypted DNS protocols. The transport affects what an observer can see and how a network operator can intervene. A successful UDP answer does not prove that every DNS method available to Australian users will produce the same result.

Read the response line by line

Start with the question section. Confirm the queried name and type, including the final dot if the logger displays a fully qualified domain name. A request for site.example with type A is different from a request for site.example with type AAAA, CNAME, MX, or TXT. Filtering may affect one record type while leaving another untouched.

Next, inspect the response code, often shown as RCODE. NOERROR means the DNS transaction completed without a protocol-level error, but it does not guarantee that useful address data is present. NXDOMAIN means the resolver states that the queried name does not exist. SERVFAIL indicates that the resolver could not complete the lookup, while REFUSED means it declined to answer.

The answer section tells you what the resolver returned. An ordinary response may contain one or more IPv4 or IPv6 addresses, a canonical-name record, or a chain of aliases. Look for an empty answer section, unusual addresses, very short TTL values, and authority records that contradict the apparent result. Flags such as AA, RA, and RD can help show whether the answer is authoritative and whether recursion was requested or available.

Separate DNS failure from website blocking

A blocked domain can produce several different signatures. The resolver may return NXDOMAIN, provide a local block-page address, return 0.0.0.0, or simply fail to respond. None of these patterns alone proves why the block occurred. It might be an ISP policy, a resolver policy, a broken authoritative server, or a temporary routing problem.

This is why a DNS observation should be compared with a direct IP test and with another resolver. The explanation of DNS versus IP blocking is useful when a domain fails to resolve but its known address remains reachable. That difference can indicate name-resolution interference, although it can also arise from modern hosting systems that change addresses frequently.

A returned address can be deceptive as well. Some filtering systems direct users to a warning page, a policy notice, or a sinkhole server. If the same address appears for many unrelated domains, it deserves investigation. Test the address with the original hostname and inspect the HTTP or TLS certificate; a shared block page may not behave like the intended service.

Compare probes and resolvers

The strongest clue comes from contrast. If several probes using the same resolver receive the same unusual answer, the resolver itself may be applying a policy or suffering a configuration problem. If only one probe differs, local connectivity, caching, packet loss, or a location-specific rule becomes more plausible.

Resolver identity must be read carefully. An IP address may belong to an ISP, a public DNS operator, a corporate network, or a security service. The DNS server visible in a log is not always the organisation that ultimately decided the answer. Forwarders and upstream resolvers can sit behind the address shown to the probe.

Australian comparisons should account for the market structure. A household using Telstra, Optus, TPG, or another NBN retailer may receive DNS settings through the router, while a phone on a mobile network may use carrier-managed infrastructure. A user in Sydney and another in regional Queensland can therefore see different results even when they request the same domain at the same time.

Account for policy and local conditions

Australia has a mixture of voluntary industry arrangements, court-ordered website blocking, and regulatory powers. The Australian Communications and Media Authority can request or require action in specific online-safety and illegal-content contexts, while court orders have supported blocking of some sites associated with serious criminal activity. These mechanisms do not produce one universal DNS signature.

Category matters when interpreting a result. A gambling-related domain, for example, may be subject to a regulatory action, a commercial security filter, or an ordinary outage. A page advertising free spins for play should not be treated as evidence of a block merely because a resolver returns an error; the domain, date, provider, and response details still need to line up.

Everyday network habits create additional variation. Australians often use ISP-provided routers, workplace Wi-Fi, university networks, and mobile hotspots interchangeably. Corporate or school filters may override home settings, and some routers cache an answer longer than the resolver’s advertised TTL. A raw log helps identify these differences, but it cannot infer a user’s complete browsing environment.

Preserve evidence without overreading it

Record the complete measurement context: domain, query type, resolver, probe location, timestamp, transport, response code, flags, answer records, TTLs, and any timeout or retry information. A single line containing only “blocked” loses the details needed for independent review.

It is also useful to retain the test conditions and compare repeated observations. A domain behind a large cloud platform can return different addresses in Melbourne and Canberra without any censorship being involved. The same principle applies to research datasets outside networking: satellite crop estimates become meaningful when their collection date, geographic coverage, and method are known.

Use the following quick checks before assigning a cause:

• Confirm the queried hostname and record type.
• Check RCODE, answer count, and returned addresses.
• Compare the resolver with at least one independent resolver.
• Repeat the measurement at a different time.

When assessing an apparent block, also check:

• Whether the result is consistent across probes.
• Whether an IP connection behaves differently.
• Whether the returned address belongs to a shared warning or sinkhole service.
• Whether the domain has recently changed its DNS configuration.

Turn raw entries into defensible findings

A useful finding describes an observed pattern precisely. “Resolver X returned NXDOMAIN for this domain from two Australian probes on a stated date” is defensible. “Australia blocked the website” is much broader and may be unsupported unless independent evidence confirms the scope and mechanism.

The comparison below summarises common response patterns. It is a guide for forming hypotheses, not a replacement for the full packet or log context.

Log pattern	What it may indicate	What to verify
NOERROR with expected A/AAAA records	Normal name resolution	Reachability, TLS, and HTTP response
NOERROR with a shared unusual address	Sinkhole, warning page, or redirected response	Address ownership and certificate
NXDOMAIN from one resolver	Resolver policy, stale data, or authoritative change	Other resolvers and authoritative servers
SERVFAIL or repeated timeout	DNSSEC issue, outage, filtering, or packet loss	Retries, transport, and domain health
REFUSED	Resolver access policy or restricted recursion	Resolver documentation and probe settings
Empty answer with authority data	Valid negative response or incomplete lookup	SOA records, query type, and DNS chain

Keep the wording proportional to the evidence. Net Neutrality Monitor’s network censorship research can provide broader context, but the raw record remains the foundation for a specific observation. Look for repeated measurements, matching results from different probes, and a clear distinction between DNS interference and blocking at the web, IP, application, or hosting layer.

The key lesson is simple: read the question, response code, flags, records, resolver, location, and time together. A raw DNS log does not merely say whether a site worked; it shows how a particular network path answered a particular question. That context is what turns an isolated response into reliable evidence.