How to Choose a Public DNS Server Based on Reliability and Speed
Use the two numeric columns in a public DNS server list as a first filter, then confirm with a local test. On publicdnsserver.com, each entry shows a Reliability percentage and a Speed value in milliseconds (ms). Lower ms means faster responses; higher reliability means the server stayed online and responsive more often during monitoring. A server that scores well on both is usually the better default, but the fastest server for someone in Chicago is not necessarily the fastest for someone in Singapore, so treat the list as a shortlist rather than a final answer.
What the two columns actually tell you
The site describes its database as public DNS servers reachable over IPv4 and IPv6, spanning over 160 countries, with free and open servers that are "continuously monitored to ensure they remain online and responsive."
- Reliability (%) — the share of checks in which the server responded. A 98.44% server was reachable almost every time it was probed; a 52% server was unreachable roughly half the time.
- Speed (ms) — the measured response time. 5 ms is very fast; 1200+ ms is slow enough to add noticeable delay to every new domain lookup.
Neither number is a guarantee of your own experience. They are monitoring results from the provider's vantage point, and your route to that server may differ.
Reading the sample data
From the list on the page:
| IP | Operator | Country / City | Reliability | Speed |
|---|---|---|---|---|
| 5.188.59.211 | Selectel | Russia, St Petersburg | 98.44% | 91.22 ms |
| 76.9.245.205 | Whiz to Coho | United States, Hillsboro | 97.22% | 166.88 ms |
| 51.75.134.185 | OVH SAS | France, Strasbourg | 93.27% | 28.5 ms |
| 8.20.247.229 | NuCDN | United States, Clifton | 91.41% | 9 ms |
| 172.64.36.255 | Cloudflare | United States, New York | 68.19% | 5.5 ms |
| 211.129.155.175 | NTT Communications | Japan, Taito | 75.88% | 1208.5 ms |
| 86.106.9.209 | TV SAT 2002 | Romania | 81.47% | 1380.75 ms |
Two patterns are worth noticing. First, the lowest-latency entries are not always the most reliable — Cloudflare's 5.5 ms row sits at 68.19% reliability, while Selectel's 91 ms row is at 98.44%. Second, some entries combine mediocre reliability with very high latency (the NTT and TV SAT rows), which makes them poor everyday choices regardless of location.
How to pick one
- Filter by reliability first. Drop anything below roughly 90% unless you have a specific reason to keep it. A server that fails one probe in ten will produce intermittent resolution failures.
- Then sort by speed. Among the survivors, prefer the lowest ms. Under about 50 ms is comfortable; 100–200 ms is usable; 1000 ms+ will feel slow on page loads that resolve many domains.
- Prefer a server near you. The list gives country and city, so start with entries in your own country or region. A 28 ms server in Strasbourg is a strong candidate for European users and a poor one for users in East Asia.
- Check the operator. Large anycast networks (Cloudflare, Akamai, OVH) tend to behave consistently across regions; smaller regional operators can be excellent locally but unreliable from elsewhere.
- Test before committing. Query the candidate directly and compare. For example, on Windows:
nslookup example.com 8.20.247.229
On macOS or Linux:
dig @8.20.247.229 example.com
Run it a few times and note the Query time value. Repeat for two or three candidates and keep the one with the lowest consistent time and no failures.
- Configure it and verify. Set the chosen address as your primary DNS resolver in your OS or router settings, then re-run the same query without specifying a server. If it resolves normally, the change took effect.
Common pitfalls
- Chasing the single lowest ms number. A 5 ms server at 68% reliability will fail more often than a 30 ms server at 95%.
- Ignoring geography. The list's speed figures are measured from the monitor's location, not yours. Always confirm with a local query.
- Assuming free means unmonitored. The page states the servers are free and open and are continuously monitored, but monitoring does not guarantee uptime at your end.
- Forgetting IPv6. Some entries are IPv6-only (for example
2610:a1:1018::5). If your network has no IPv6 connectivity, that server is unusable for you no matter how good its numbers look. - Setting only one server. Configure a secondary resolver so a single outage does not break resolution.
Quick decision rule
If you want one sentence: pick the highest-reliability server in your own country or region whose speed is under ~50 ms, verify it with a local dig or nslookup, and set a second server from a different operator as backup. If no local entry clears 90% reliability, widen the search to nearby countries before accepting a lower-reliability local option.