DNS Testing Methodology & Scoring

What we test

publicdns.info monitors over 109,644 public DNS servers across 220 countries. Every server is re-tested on a rolling 72-hour cycle. We test two things for each server:

1. A-record resolution — we send a standard DNS query for example.com (type A, class IN) and verify the server returns a valid response with at least one answer record and response code NOERROR.
2. NXDOMAIN integrity — we query a randomly generated domain (e.g., a3f7c9e1b2d4.example.invalid) and verify the server returns NXDOMAIN (RCODE 3), confirming it does not hijack non-existent domain lookups.

The combined result of these two queries determines the server's status code, updates its reliability score, and records its latency. Servers that pass both tests and maintain a reliability score above 80% appear in our public directory, country pages, and best-of rankings.

For each server we record IP address, country, reliability score, latency, DNSSEC support, and current status. All listings on the site are drawn directly from this database.

How probing works

Each probe sends a standard UDP DNS query to port 53, requesting an A record for a well-known test domain. The query uses the recursion desired (RD) flag. If a response arrives within the timeout window, we parse the reply code and record the result.

The probe process follows these steps:

1. Open a UDP socket to the target server's IP address on port 53
2. Set a 1.1-second timeout on the socket
3. Send the DNS query packet and start timing
4. Read the response and parse the DNS header
5. Check the response code (RCODE) and answer count
6. If the first query succeeds, send the NXDOMAIN test query for a random domain
7. Record the round-trip time, response status, and any errors

Batch processing: Worker processes consume jobs from a job queue in batches. Multiple workers run in parallel to cover the full 109,644+ server list within the 72-hour cycle. When a worker finishes probing an IP, it writes the results directly to the main database. The queue system uses transactional locking to prevent duplicate work. Each job transitions through states: PENDING → PROCESSING → DONE.

Input validation and security

Before probing any IP address, we validate it to ensure it is a valid public IP. Private network ranges and reserved address ranges are rejected. IPv6 addresses are fully supported.

The reliability score

This is the single most important metric in our directory. The reliability score is an exponential moving average (EMA) that captures a server's consistency over time. It answers the question: "If I send a query to this server right now, how likely is it to respond correctly?"

The formula

After each probe, the reliability score is updated using:

reliability = 0.90 × previous_reliability + 0.10 × (1 if OK, 0 if fail)

The 0.9 decay factor means the score retains 90% of its history on each probe. This makes it responsive to recent failures while being resilient against a single bad result. Newly discovered servers start at 0.50 (50%) as a neutral starting point.

What this means in practice

Recovery trajectory

Climbing back from a failure is deliberately slow. Here is the trajectory of a server that drops from 1.0 to 0.90 after one failure, then succeeds on every subsequent probe:

It takes approximately 20 consecutive successes to climb from 0.90 back to 0.986. This means a server that had one bad day needs roughly 60 days of clean probes (at one probe every 72 hours) to fully recover. This is intentional: reliability in DNS matters more than speed, and we want the score to reflect sustained performance, not a lucky streak.

The 80% listing threshold

Servers with a reliability score below 0.80 (80%) are excluded from all public listings. This threshold filters out servers that are intermittently offline, rate-limiting our probes, or otherwise unreliable. They remain in the database and continue to be probed — if they recover, they reappear in listings once their score crosses 0.80 again.

Additionally, servers where the most recent probe returned TIMEOUT are excluded regardless of their reliability score. This catches servers that have just gone down but have not yet accumulated enough failures to drop below 80%.

Colour coding on the site

• Green — reliability 90% or higher. This server is highly dependable.
• Yellow — reliability 80–89%. Usable but has some inconsistency. Monitor it.
• Red — reliability below 80%. Not shown in listings but may appear in direct lookups.

Why EMA over simple averages?

We chose an exponential moving average over a simple success-rate percentage (e.g., "93 out of 100 probes succeeded") because EMA naturally weights recent results more heavily without requiring a fixed window size. A simple 100-probe average would take 200+ days to compute at one probe every 72 hours. EMA gives a meaningful score after just a few probes and adapts to changing server behaviour without maintaining a history of individual results. The decay factor of 0.9 was chosen to balance responsiveness with stability — it detects problems within 2-3 probe cycles while being resilient to a single transient failure.

Latency measurement

Latency is the round-trip time (RTT) of the UDP DNS query, measured in milliseconds from our probe server. It starts when we write the DNS packet to the UDP socket and ends when we receive the response.

This value includes:

• Network transit time from our probe server to the DNS server and back
• The DNS server's processing time to look up the answer
• Any queuing delays in network routers along the path

What it does not include:

• Latency from your location — your network path is different from ours
• TCP handshake overhead (we use UDP)
• DNS-over-HTTPS or DNS-over-TLS encryption overhead

Important caveat

Because we probe from France, the latency values in our directory are relative to Western Europe. A server in Tokyo that shows 250ms in our directory might show 15ms from a Japanese ISP. For latency from your actual location, use our DNS Gaming Benchmark, which tests directly from your browser.

Latency is stored as a nullable integer. Servers that timed out have NULL latency. The value displayed is from the most recent successful probe only — we do not average latency across probes.

Interpreting latency values

As a general guide for values shown in our directory (measured from France):

• Under 20ms — Server is likely in Western Europe or uses a nearby anycast node.
• 20–50ms — Server is in Europe or has good peering to our probe location.
• 50–100ms — Server is likely in Eastern Europe, Middle East, or US East Coast.
• 100–200ms — Server is in North America, parts of Asia, or Africa.
• Over 200ms — Server is in Asia-Pacific, South America, or Oceania.

These ranges are approximate and depend heavily on network routing, peering arrangements, and whether the server uses anycast. A server in Australia might show 280ms from our probe but 5ms from Sydney.

Latency vs. the Gaming Benchmark

The latency shown in our directory is measured server-to-server via UDP. The Gaming Benchmark measures latency from your browser using timed HTTP requests. These are fundamentally different measurements. The benchmark results are more relevant to your personal experience because they reflect your actual network path, ISP peering, and geographic location. Use our directory latency for relative comparison between servers, and the benchmark for absolute performance from your location.

Status codes explained

Every server in our directory carries one of four status codes based on its most recent probe result. Here is what each means and how it is determined:

OK — Healthy resolver

The server answered both test queries correctly. It returned a valid A record for example.com and returned NXDOMAIN for the random non-existent domain. This is the result you want to see. An OK server is working as the DNS protocol requires.

TIMEOUT — No response

The server did not respond within our 1.1-second probe window. This could mean the server is down, firewalled, rate-limiting, or geographically restricted. TIMEOUT servers are automatically excluded from public listings, even if their historical reliability score is high.

NX_HIJACK — NXDOMAIN hijacking detected

The server passed the A-record test but failed the NXDOMAIN test. Instead of returning NXDOMAIN for a domain that does not exist, it returned an IP address — typically redirecting to an ad page or ISP search portal. These servers technically "work" for normal browsing but break email authentication, DNS blocklists, and DNSSEC authenticated denial of existence.

BAD — Unexpected response

The server responded, but the answer was incorrect. This can mean it returned SERVFAIL, REFUSED, or another error code instead of NOERROR, or the answer section was empty despite the query being valid. BAD servers are misconfigured or intentionally returning incorrect data.

The status always reflects the most recent probe result. Historical probe results are not stored individually — only the current state and the cumulative reliability score are maintained.

For a deeper explanation of each status code with usage recommendations, visit our DNS status codes page.

DNSSEC validation testing

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records. A validating resolver checks these signatures and rejects tampered responses, protecting you from DNS cache poisoning and man-in-the-middle attacks.

How we test it

We query dnssec-failed.org, a domain maintained by the Internet Systems Consortium with intentionally invalid DNSSEC signatures. The expected behaviour:

• Validating resolver: detects the broken signature, refuses to resolve the domain, and returns SERVFAIL. We record dnssec = 1 (validates).
• Non-validating resolver: ignores the broken signature, resolves the domain to an IP address, and returns NOERROR. We record dnssec = 0 (does not validate).

This technique is reliable because it tests the resolver's actual behaviour, not its configuration claims. All major public DNS providers (Cloudflare, Google, Quad9) validate DNSSEC. Most ISP resolvers do not.

DNSSEC validation carries the highest single weight (25%) in our Privacy Score because it directly protects against DNS spoofing attacks.

NXDOMAIN hijacking detection

NXDOMAIN hijacking is one of the most common ways DNS providers violate the protocol. Here is how we detect it.

The test

During each probe, we generate a random domain name (12 random hex characters followed by .example.invalid) and query the server for its A record. According to the DNS protocol, the server must return NXDOMAIN (RCODE 3) because the domain does not exist.

If the server instead returns an A record containing an IP address, it is performing NXDOMAIN hijacking. We store error = 'nx_hijack' in the database and the server displays as NX_HIJACK in the directory.

Why it matters

NXDOMAIN hijacking causes real problems beyond user annoyance:

• Email authentication failures — SPF and DMARC checks rely on DNS lookups. A hijacked NXDOMAIN can cause legitimate email to be flagged as spam or malicious email to pass checks.
• DNS blocklist breakage — DNSBL services return NXDOMAIN for clean entries. Hijacking makes every lookup appear as a hit, rendering blocklists useless.
• DNSSEC authenticated denial — NSEC/NSEC3 records cryptographically prove a domain does not exist. Hijacking the response breaks this chain of trust.
• Gaming and software issues — game mod servers, custom server lists, and anti-cheat systems that rely on proper DNS error handling can malfunction.

For a detailed explanation and instructions on how to protect yourself, read our NXDOMAIN hijacking guide.

How the DNS Privacy Score works

The DNS Privacy Check evaluates DNS configurations across six weighted dimensions. The composite score produces a letter grade from A+ to F.

The six dimensions

Grade thresholds

Two testing modes

"Check My DNS" runs browser-side heuristics to audit your live DNS configuration. It uses JavaScript fetch requests, WebRTC ICE candidates, and timing analysis to infer what resolver you are using and how well it protects your privacy.

"Check a Specific DNS Server" runs server-side dig queries against any public DNS IP you enter. This produces definitive results for DNSSEC validation, NXDOMAIN hijacking, DoT support, and response latency. Use this mode to audit a resolver before switching to it.

For a complete walkthrough of the Privacy Check tool, see our DNS Privacy Check guide.

How the Gaming Score works

The DNS Gaming Benchmark calculates a composite Gaming Score for each tested server. The algorithm is designed to prioritise what matters most for gaming DNS: fast and consistent resolution.

The four components

Score interpretation

• 85–100: Excellent for competitive gaming. This DNS will not be a bottleneck.
• 70–84: Good for most games. Minor improvements possible by switching provider.
• Below 70: You would benefit from switching to a faster, more consistent resolver.

The weighted approach means a server with 15ms average latency and 2ms jitter can outscore one with 10ms average latency but 10ms jitter. For gaming, the consistent server wins because you need predictable behaviour during fast-paced matchmaking and server switches.

For a complete walkthrough, read our Gaming Benchmark guide.

Data freshness and update frequency

Understanding how current the data is on any given page:

All listing pages pull from the live database. A short-lived cache sits between the database and page rendering to reduce load. This means a server that was probed one minute ago will be visible on the site within minutes.

The "Last probe run" timestamp shown on country and server pages reflects the most recent probe completion time from the database, not the cache age.

How country pages work

Each country page queries the database for all servers matching that country code, filtered by the reliability threshold (0.80+) and excluding TIMEOUT errors. Results are split into two groups:

• Trusted servers — local ISP and regional resolvers operated by organisations in that country
• General servers — global providers (Cloudflare, Google, Quad9, etc.) that happen to have servers in or near that country

This split is determined by checking the server's AS organisation name against a curated list of known global providers in our configuration. Servers not on the global provider list are classified as trusted/local. Pages with more than 50 servers are paginated.

How the "Best" rankings work

Our Best Gaming, Best Privacy, and Best Family rankings are curated lists maintained in a dedicated provider file. Each provider entry includes IPv4 and IPv6 addresses. Before display, we verify every IP exists in the database and filter out any IPs that have been removed or dropped below the reliability threshold. This ensures the "best" lists only recommend servers we have recently verified as operational.

Probe infrastructure

Our probing currently runs from a single location:

Architecture

The probe system consists of three components:

1. Queue setup — populates the probe queue with all IP addresses from the main database that need re-testing (based on their last probe timestamp)
2. Workers — multiple PHP processes that pull batches from the queue, probe each IP, and write results back to the main database
3. Monitor — tracks overall queue progress and worker health

The entire probe cycle is designed to complete within 72 hours. Worker processes are started and managed from the probe server. Results are written directly to the same database that the website reads from.

Why a single location?

A single well-managed probe location gives us consistent, comparable data across all servers. Every server is tested from the same point under the same conditions, so reliability scores and status codes are directly comparable. Adding probe locations introduces the complexity of reconciling results that may differ by geography (a server could be OK from France but TIMEOUT from Asia). We chose to start with clean, comparable data from one location and expand carefully.

Future plans

We plan to add probe locations in additional geographic regions to provide more diverse latency data and reduce blind spots caused by single-location probing. Additional probe nodes will independently query servers and report results back to the central database. The reliability formula will be extended to weight results from multiple vantage points, giving a more accurate picture of a server's global availability. Priority regions include North America, Asia-Pacific, and South America.

How our testing compares to other DNS benchmarks

Several tools test DNS server performance. Each serves a different purpose:

Where other tools benchmark a curated list of 30 to 200 well-known providers, we monitor the full population of publicly reachable DNS resolvers — including ISP defaults, regional operators, and niche providers that no other service tracks. For personal latency testing from your location, use our browser-based Gaming Benchmark.

Limitations and transparency

No monitoring system is perfect. Here are the known limitations of our methodology, and what we are doing about them:

Single probe location

All latency data reflects the network path from France. A server in Asia that shows 250ms in our directory might show 5ms locally. We mitigate this by clearly labelling latency as probe-relative and offering the Gaming Benchmark for local latency testing. Additional probe locations are planned.

Trailing reliability indicator

The exponential moving average means the reliability score lags behind reality. A server that crashed 5 minutes ago may still show 99% reliability because the next probe has not run yet. The 72-hour cycle means the worst-case detection lag is 72 hours. We exclude servers whose most recent probe returned TIMEOUT as an additional safety measure.

Servers that block our probes

Some DNS servers restrict queries to specific IP ranges or geographic regions. These servers show as TIMEOUT in our directory even though they work perfectly for users in the allowed range. We cannot distinguish between "genuinely down" and "firewalled against our probe IP" without additional probe locations.

Browser-side privacy test heuristics

The "Check My DNS" mode of the Privacy Check uses browser-side JavaScript heuristics. These are useful for quick audits but have inherent limitations:

• The encrypted DNS test checks DoH endpoint reachability, not whether your current queries are encrypted
• IPv6 detection via WebRTC can be blocked by browser settings or extensions, creating false passes
• Server identification uses timing patterns that can be affected by CDN routing changes or network congestion

For definitive results, use the "Check a Specific DNS Server" mode, which runs real dig queries server-side.

DNS leak detection accuracy

The DNS leak test works by querying a unique subdomain of dnsprobe.online and checking which resolver IP contacts our authoritative DNS server. This technique depends on NS delegation working correctly. In rare cases, intermediate caching layers or corporate DNS proxies can obscure the true resolver identity.

DNSSEC test scope

We test DNSSEC validation using a single domain (dnssec-failed.org). A resolver could theoretically have selective DNSSEC policies that pass our test but fail on other domains. In practice, resolvers that validate DNSSEC do so globally, making this a reliable indicator.

Rate limiting and false timeouts

Some DNS servers employ rate limiting that may throttle our probes, causing intermittent TIMEOUT results. A server that works perfectly for normal users may show reduced reliability in our directory because it detects our probe pattern and throttles responses. We use a 72-hour cycle specifically to minimise this effect — each server receives only two queries every three days, which is well below most rate-limiting thresholds. However, servers that are particularly aggressive about rate limiting may still be affected.

Anycast routing variability

Major DNS providers like Cloudflare and Google use anycast routing, meaning our probe may reach a different physical server each time depending on network conditions. Latency values for these providers may fluctuate between probes as routing changes. The reliability score smooths out this variability over time, but individual latency measurements should be viewed as snapshots rather than fixed values.

What we do not test

• DNS-over-HTTPS/TLS performance — we probe via plain UDP. Encrypted DNS may have different latency due to TLS handshake overhead.
• Cache performance — our probes test cold-cache behaviour. A server that has your domain cached will respond faster than our latency data suggests.
• Provider logging practices — we verify published privacy policies and feature support, but we cannot audit what happens on the server side.
• DNS-over-QUIC — this newer protocol is not yet part of our testing suite.
• TCP DNS fallback — we test UDP only. Some servers may support TCP DNS (port 53) or have different behaviour for TCP queries.
• EDNS Client Subnet (ECS) — we do not test whether servers support or honour ECS, which affects CDN routing accuracy.

Our commitment to transparency

We publish this methodology page specifically because we believe DNS monitoring data should be auditable. If you disagree with our approach, find an error, or have suggestions for improvement, we welcome feedback via our contact page. Every metric shown on this site is derived from the processes described here — without hidden adjustments or pay-for-placement in our rankings.

Frequently asked questions

How does PublicDNS.info test DNS servers?

We send raw UDP DNS queries to port 53 of each server every 72 hours, testing both A-record resolution and NXDOMAIN integrity. Results update the server reliability score, latency, and status code in our live database of 109,644+ resolvers.

What is a DNS reliability score?

A reliability score is an exponential moving average (EMA) that tracks how consistently a DNS server responds correctly over time. Our formula weights recent probes more heavily — a single failure drops the score from 1.00 to 0.90, and full recovery takes approximately 20 consecutive successful probes.

How do you detect NXDOMAIN hijacking?

We query each DNS server for a randomly generated non-existent domain. The correct response is NXDOMAIN (RCODE 3). If the server returns an IP address instead — typically redirecting to an ad or search page — we flag it as NX_HIJACK.

How is the DNS Gaming Score calculated?

The Gaming Score is a composite of four metrics: latency (40% weight), jitter (30%), reliability (20%), and NXDOMAIN integrity (10%). Latency and jitter are measured from your browser, while reliability and NXDOMAIN data come from our backend monitoring.

How is the DNS Privacy Score calculated?

The Privacy Score evaluates six dimensions: DNSSEC validation (25%), DNS leak detection (20%), encrypted DNS support (20%), ECH/ESNI support (15%), IPv6 exposure (10%), and server identification (10%). Results produce a letter grade from A+ to F.

How does your DNS testing compare to DNSPerf or GRC DNS Benchmark?

DNSPerf tests commercial and enterprise DNS providers every minute from 200+ locations but covers only around 30 major providers. GRC DNS Benchmark is a Windows desktop tool that tests from the user location. PublicDNS.info monitors 109,644+ individual public resolvers every 72 hours from a dedicated probe server, covering the broadest range of DNS servers of any free monitoring service.

Why do you probe DNS servers from only one location?

A single probe location gives us consistent, directly comparable data across all 109,644+ servers. Every server is tested under identical conditions. Additional probe locations in North America, Asia-Pacific, and South America are planned.

Related tools and resources

DNS Privacy Check — audit your DNS for leaks, encryption, DNSSEC, and more. Grades from A+ to F.

DNS Gaming Benchmark — test latency to multiple DNS servers from your browser and find the fastest resolver.

DNS Status Codes Explained — detailed explanation of OK, TIMEOUT, NX_HIJACK, and BAD.

Best Gaming DNS | Best Privacy DNS | Best Family DNS — curated server rankings.

DNS Servers by Country — browse public DNS servers available in 220 countries.

NXDOMAIN Hijacking Guide — what it is, why ISPs do it, and how to stop it.

DoH vs DoT Explained — compare encrypted DNS protocols and choose the right one.

Privacy Check Guide | Gaming Benchmark Guide — tool walkthroughs.

Public DNS Server Directory — browse and search all 109,644+ live-tested resolvers.