# pingerr warms each resolver's cache before it measures it, then scores DNS time at 70 percent

> A shell script that benchmarks more than fifty public DNS resolvers, measures the median of five cached queries per server, and folds network latency into the score at thirty percent. It ships as a bash script for Linux and macOS and an ash script for OpenWRT, and it prints the UCI or systemd-resolved commands to apply the winner.

**Panchajanya1999/pingerr** — Find the most optimal DNS server for your router/machine

- Repository: https://github.com/Panchajanya1999/pingerr
- Stars: 101 · Forks: 5
- Language: Shell
- License: Apache-2.0
- Published: 2026-08-17 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/panchajanya1999-pingerr

## A warmup query comes first, or you are timing a cold cache

The benchmarking approach is called cache-aware, and the name refers to the first of three steps. A warmup query is sent to prime the server's cache. Then measurement queries follow, five of them by default. Then the median of those measurements is taken rather than the mean. The reasoning is stated plainly: this measures the actual network latency to each DNS server rather than recursive resolution time, and the results correlate closely with ping latency. The distinction is the whole point of the tool. A first lookup to a resolver that has never seen your query has to do the whole resolution chain, which has nothing to do with how far away the resolver is. Once the cache is warm you are measuring the round trip you would actually experience on repeated lookups, which is the number a router choice should be based on.

## The score is 70 percent DNS time and 30 percent ping

Results are not ranked on DNS timing alone. There is a correlation analysis that measures DNS query time and network latency separately, looking for servers that are fast at resolution and also low latency, and the score calculation multiplies the DNS query time by 70 percent and adds the ping latency weighted at 30 percent. Each server's row also carries its median response time, and the printed table has four columns: rank, DNS server name, IP address and median. Colour bands turn the number into a quick read, with green under 50 ms described as excellent, yellow between 50 and 100 ms as good, and red above 100 ms as slow. Whether seventy-thirty is the right weighting for you is a judgement the script does not make for you, and the --no-ping flag exists for the case where you want the DNS term alone.

## Two scripts ship, one for bash and one for ash

The repository holds five entries and two of them are the tool: pingerr.sh for regular Linux and macOS, and pingerr_ash.sh for OpenWRT. Each has a pipe-from-the-internet form and a download-and-run form. The bash one is fetched with curl over the raw GitHub URL for the master branch and piped into bash, while the OpenWRT one uses wget with the qO- form piped into ash, since that is what the ash shell in OpenWRT can consume. The download-and-run path writes the file, makes it executable with chmod +x, and runs it, which is the path to prefer if you intend to read the script before letting it near your network:

```bash
curl -sSL https://raw.githubusercontent.com/Panchajanya1999/pingerr/refs/heads/master/pingerr.sh | bash
```

The OpenWRT equivalent is the wget and ash form of the same idea. The server list arrays are named differently in the two versions, DNS_NAMES_IPV4 and DNS_IPS_IPV4 in the bash script against DNS_SERVERS_IPV4 in the ash one, so editing them means knowing which file you have.

## Options cover count, domain, address family and output

The flag set is compact enough to read in one screen. -4 and --ipv4-only restrict the run to IPv4 resolvers, and -6 and --ipv6-only restrict it to IPv6 ones, which the documentation notes requires IPv6 connectivity. -n and --count N sets the number of tests per server against a default of 5, and -q is a quick mode that drops to 3 tests per server. -d and --domain NAME sets the query target, defaulting to google.com, and the examples show it taking a domain such as github.com as readily as a literal address such as 1.1.1.1, the latter described as giving consistent measurements. --no-ping skips the correlation test, --no-color disables the coloured output for pasting into a terminal that does not handle it, and -h and -v print help and version. IPv6 is detected automatically, so you only need the flags when you want to force one family.

## OpenWRT gets opkg and drill, not apt

The prerequisites are short: dig or nslookup is required, and ping is optional because it only feeds the correlation term. On a normal system that means a package with the DNS utilities, installed as dnsutils on Debian and Ubuntu or bind-utils on RHEL, CentOS and Fedora, and on macOS it is usually already there with brew install bind as the fallback. OpenWRT is the case that catches people out, since the package manager is opkg. The sequence is opkg update and then opkg install bind-dig, which the documentation marks as recommended for better accuracy, with opkg install drill offered as the alternative. The troubleshooting section covers the three failures worth knowing: dig not found means the utilities are missing, no results at all means check the connection, check that a firewall is not blocking DNS port 53, and try nslookup in place of dig, and a permission error means the script has not been made executable.

## Applying the winner is three different procedures

The output ends with a best server, its median, and a configuration recommendation naming a primary and a secondary resolver, and the documentation then shows how to apply it on each platform. On OpenWRT it is three UCI commands, setting network.wan.dns to the two addresses, committing the network configuration and restarting the network init script. On Linux with systemd-resolved it is a file edit to /etc/systemd/resolved.conf adding a DNS line and a FallbackDNS line, followed by restarting systemd-resolved. On macOS it is not a command at all but a path through System Preferences into Network, Advanced and DNS. That last one is worth noting for anyone automating this: the recommendation is uniform and the procedure is not, so a script that reads pingerr's output still needs to know which system it is running on.

## One documented example passes a URL where curl expects a filename

The download-and-run example for the bash script starts with curl -o followed by the raw GitHub URL. In curl, -o names the output file, so that line asks curl to write the download to a file called after the URL rather than saving it as pingerr.sh, and the following chmod and run steps assume a filename the command has not produced. The ash example does it correctly, with wget -O pointing at /tmp/pingerr_ash.sh. That is the kind of detail worth checking before you follow a quickstart line by line, and it is the reason the two forms are documented separately at all. Elsewhere the same level of care applies: the demos for Archlinux and OpenWRT are hosted as repository attachments with mirrors at storage.panchajanya.dev, because the README notes that embedded videos may not play on github.com. The project is Apache-2.0, was last pushed to master on 2026-08-29, and has 101 stars, 5 forks and no open issues.

## Conclusion

pingerr earns a place on a machine whose resolver choice is genuinely in question, which is usually a home router or an OpenWRT box rather than a laptop with a sensible default already. The measurement design is the reason: a warmup query before timing, a median rather than a mean, and a ping correlation term that stops a fast resolver on a slow path from winning. Before you trust a run, change one thing: pass -d with an IP address rather than a name, since the documentation itself recommends that for consistent measurements, and remember the script reaches your network over plain DNS on port 53, so a firewall rule will show up as every server failing. Finally, read the scoring formula before you paste the result into a router: a seventy-thirty weighting is a policy choice, not a measurement, and the colour bands are thresholds someone picked.

## FAQ

### What is pingerr used for?

It finds the fastest and most reliable public DNS resolver for your network. It tests more than fifty servers including Google, Cloudflare, Quad9, OpenDNS and AdGuard, warms each cache first, takes the median of five cached queries, and prints a primary and secondary recommendation you can apply with UCI or systemd-resolved.

### What is a Pinger?

In this repository the name belongs to a shell script, not to a messaging service. There are two of them: pingerr.sh for Linux and macOS under bash, and pingerr_ash.sh for OpenWRT under ash, each with a curl or wget form that runs it straight from the master branch on GitHub.

### Can a pinger number be tracked?

There is no number, phone number or messaging service anywhere in this project. It benchmarks DNS resolvers by address, such as 1.1.1.1 and 8.8.8.8, and its only user-facing identifiers are the rank and the median response time in its results table.

### Does Pinger cost money?

The repository says nothing about cost. It is Apache-2.0 licensed open source with no releases published, and it benchmarks publicly available DNS resolvers, so there is no paid tier or licence to buy described anywhere in the documentation.

## Sources

- [Official README](https://github.com/Panchajanya1999/pingerr#readme)
- [Project repository](https://github.com/Panchajanya1999/pingerr)
- [README](https://github.com/Panchajanya1999/pingerr/blob/master/README.md)
- [Releases](https://github.com/Panchajanya1999/pingerr/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/panchajanya1999-pingerr