resolver in the world to validate ML-DSA-44 DNSSEC
queries a day, across all our resolvers
forwarders. We ask the root ourselves
public resolvers, in Malaysia and Indonesia
Public resolvers
Bring your own filter
Running AdGuard Home or Pi-hole at home, at the office or for your business? Use these as your upstream. You keep your block lists and your logs; we do the recursion and the DNSSEC, ML-DSA-44 included.
| Server | IPv4 | IPv6 |
|---|---|---|
| Sakurako-1 | 151.158.198.49:5301 |
2402:4e20:b00b::1001 |
| Sakurako-2 | 151.158.198.49:5302 |
2402:4e20:b00b::1111 |
| Fizo-1 | 151.158.198.47 |
2402:4e20:c0de::b00b |
| Fizo-2 | 151.158.198.46 |
2402:4e20:c0de::bab1 |
| Kevin-1 | 89.23.82.53 |
2a0f:1cc6:bab1::1111 |
| Kevin-2 | 89.23.82.82 |
2a0f:1cc6:bab1::1001 |
| Ryukura Jakarta | 103.253.245.167:5301 |
IPv4 only for now |
How to use them
AdGuard Home & Pi-hole
Two minutes, and every device behind your filter gets our recursion and DNSSEC.
AdGuard Home
- Go to Settings → DNS settings → Upstream DNS servers.
- Paste the addresses, one per line. Ports go after a colon.
2402:4e20:c0de::b00b 2402:4e20:b00b::1001 2a0f:1cc6:bab1::1111 151.158.198.47 151.158.198.49:5301
- Pick Parallel requests, so the fastest answer wins.
- Put the same addresses in Bootstrap DNS servers, then Apply.
Pi-hole
- Go to Settings → DNS and untick the built-in providers.
- Add ours under Custom DNS servers. Pi-hole writes the port after a
#.
2402:4e20:c0de::b00b 2402:4e20:b00b::1001 151.158.198.47 151.158.198.49#5301
- Save. Then run a test on dnscheck.tools: you should see DNSSEC passing and one of our networks answering, not your ISP.
New · ADoX
Encrypted past us, too
DoH and DoT encrypt the trip from you to us. ADoX covers the next one: ΕΛΠΙΣ Resolver now asks the root, the TLDs and each domain's name server over DNS over TLS, wherever they take it.
How it works
- The first question to a name server goes plain, as always, with a copy over TLS on port 853. Nobody waits on the copy, so it costs no time.
- The server answers over TLS? From then on it gets every question over TLS only, on a connection kept open.
- It doesn't? It gets plain DNS as before, and we try TLS again every hour.
- Servers that take TLS are asked first, so fewer of your names cross the wire in the clear.
- Each question is padded to 128 bytes, so its length gives less away.
What it stops, and what it doesn't
It stops anyone watching the path, like the networks between us and the name server, from reading what we ask. It can't stop someone sitting on the path, who could block port 853 and send us back to plain DNS, which is where we were before.
The name server still sees the question; it has to, to answer it. And DNSSEC checks every answer the same way, however it arrived.
Few name servers take TLS yet. b.root-servers.net and
Facebook's do, and more will as their operators turn it on.
authoritative-dot: opportunistic to elpis.conf.
It's off by default, and the
configuration guide
has the details.
What's inside
Small, fast, and ours
ΕΛΠΙΣ Resolver sits behind the ΕΛΠΙΣ DNS endpoints we run. AdGuard Home faces you and does the filtering; the resolver does the part nobody sees.
Post-quantum DNSSEC
Checks ML-DSA-44, the FIPS 204 signature almost nobody validates yet. Second in the world, after Cloudflare.
What ML-DSA-44 isStraight to the root
Root, then TLD, then the name server with the answer, over TLS where they take it. Nobody upstream keeps a copy of your questions.
What ADoX isSIMD, close to the CPU
Hand-written AVX2, SSE2 and NEON code, picked at startup for your processor. The hot paths run at machine speed.
One small binary
Portable C99 with no dependencies. Runs on Linux, the BSDs and macOS. Build it, copy it, run it.
Built together
Written by the community with help from Claude AI, and reviewed in the open on GitHub.
Battle tested
More than 30 million queries a day across our resolvers, from real people on real networks.
The source, the DNSSEC notes and the reasons the fast paths look the way they do. A resolver you can't read is a promise you can't check.