HaGeZi DNS: a free public resolver run by one person, and where it refuses you

Two resolver tiers, one blocklist or two

HaGeZi DNS is not a piece of software you install. It is a pair of public recursive resolvers, free and non-commercial, designed and operated by a private individual for the European community, and the difference between them is which blocklists they load. The full protection servers combine the HaGeZi Multi Pro list, which covers ads, tracking, analytics, metrics and telemetry, with the HaGeZi TIF list, which covers phishing, malware, scam, fake and cryptojacking. The threat-only servers load the TIF list alone. Everything else about the two tiers, the encrypted transports, DNSSEC validation, the no-logging policy, the hosting in Falkenstein, Nuremberg and Helsinki, is shared between them.

The blocklists are rebuilt every four hours

Both lists are published on a mirror under the hagezi-mirror.dnsbunker.org domain and are regenerated every four hours, with the servers picking up the new versions immediately afterwards. The filtering policy is described as balanced, aiming to avoid unnecessary restrictions while still blocking the listed categories, and the project states that there is no intentional censorship beyond privacy, ad and security filtering. A balance claim is easy to make and hard to verify from outside, so the practical check is the report path: false positives and requests to unblock a domain go to the dns-blocklists issue tracker, to [email protected], or to the public Matrix support chat.

Blocked domains answer with 0.0.0.0 rather than REFUSED

Two details change how a block feels on a phone. The block TTL is 3600 seconds, one hour, which cuts down how often a blocked name is looked up again and reduces network activity and battery use on mobile devices. The block response is 0.0.0.0 rather than REFUSED, NXDOMAIN or 127.0.0.1, so the connection fails straight away instead of the app waiting for a local timeout and retrying. The same mechanism is why a blocked domain can look like a network fault rather than a policy decision, and it is worth knowing before you spend an evening debugging your router.

The Firefox canary domain is a narrow trick

Firefox is blocked from resolving the Mozilla Firefox canary domain, and the reply is NXDOMAIN. The stated purpose is signalling to Firefox that the network already applies DNS filtering, so Firefox does not switch on its own DNS-over-HTTPS by itself and your queries keep reaching this resolver. It affects automatic activation only. If you deliberately enabled DoH in Firefox settings, that choice is respected and the canary handling does not override it. This is a small, clearly documented hack, and it is the sharpest example in the project of a design decision made for one client rather than for the protocol at large.

Encrypted transports and a deliberately quiet server

DoH, DoH3, DoT and DoQ are all served, and the documentation recommends connecting with encryption rather than falling back to plain port 53. Behind that, the service runs Technitium DNS Server with Unbound as an upstream recursive resolver and a local root zone, so no recursion happens through third-party resolvers. QNAME minimization is enforced, there is no EDNS Client Subnet so your location is not exposed upstream, ANY queries are dropped, and the firewall is restricted to the ports needed for operation. The CHAOS version.bind and id.server queries are refused, which is a small sign that the operator would rather not advertise the stack. No individual queries are logged or stored per client, and no query data is shared with third parties.

Where the resolver stops answering altogether

Two policies produce visible failures that are easy to mistake for a broken configuration. Tor exit nodes are blocked entirely because of persistent attack traffic from that network, so a DNS query routed through Tor gets no answer at all. Separately, source IPs seen attacking the service, including flooding plain port 53, are blocked, and known abusive addresses are dropped at the firewall using locally maintained threat intelligence lists such as Spamhaus and AbuseIPDB, matched entirely on the server so no connection IP reaches those third parties. IP-based lists can carry false positives, and the documentation points those cases at [email protected], or privately at Matrix and Signal. Strict rate limiting on responses and clients is a further reason a single busy client can be told to slow down.

The repository is documentation and tooling, not the server

The repository layout makes the shape of the project clear. The top level holds CHEATSHEET.md for the quick start, PRIVACY.md for the privacy policy, the EU Digital Services Act compliance disclosure and the glossary of legal terms, plus docs/, images/, mobileconfig/ and scripts/. The servers themselves run on rented Hetzner hardware and are not something you deploy from this repository, so adopting HaGeZi DNS is a configuration decision rather than a deployment. The release history explains the shape: the repository has no GitHub releases at all, and the last push was on 2026-10-03, with the service changing continuously rather than being cut into versions. The project is licensed GPL-3.0, which covers what is published in the repository, not the hosted service.

Choosing a server and verifying it answers

The cheat sheet is the path for a new user, and it reads as a sequence: pick a server by country and protection level, connect with encryption as the recommended option, run the platform setup for Apple, Android, Windows or a router, keep the unencrypted Do53 fallback in reserve, then verify that it is working. A troubleshooting section and a short list of things worth knowing follow it. This article deliberately stops short of printing addresses, because the current servers and their expected IP addresses live in the cheat sheet and in the documentation for server locations, and the point of a resolver list is that it moves. Reading the current CHEATSHEET.md before you configure a device is the first concrete step, and the verification step in that same file is the one to run afterwards.

Editorial conclusion

HaGeZi DNS suits a European user who wants ad and threat blocking without paying or handing query data to a commercial resolver, and the cheat sheet in the repository is the place to start: pick a server by country and protection level, connect with DoH, DoT or DoQ, and run the verification step in the same file. It is a poor fit if you need Tor, if you share an IP with a scanner, or if you want a resolver you can host and version yourself, because the servers are operated on rented Hetzner hardware and the repository holds documentation rather than deployable server software. Before switching a device over, read the current CHEATSHEET.md for the live addresses, confirm the resolver answers over the encrypted transport you intend to use, and keep your existing resolver configured as a fallback.

Frequently asked questions

Official sources

1. hagezi/dns-servers on GitHub
2. Issues
3. License: GPL-3.0
4. README