HaGeZi DNS: Free, Non-Commercial EU Public DNS Servers

HaGeZi DNS offers free, non-commercial public DNS resolvers designed and operated by a private individual for the European community. It provides robust DNS-based blocking of ads, trackers, scam, phishing, fake, and malware domains, helping users achieve greater privacy and security online at zero cost.

Table of Contents

• Cheat Sheet (Quick Start)
  • Pick a server by country and protection level
  • Connect (recommended: encrypted)
  • Platform setup (Apple, Android, Windows, router)
  • Unencrypted fallback (Do53)
  • Verify it's working
  • Something not working?
  • 5 things to know
• Features
  • Security & Privacy
  • Filtering/Blocking
• Logging and Data Handling
• Server Locations & Access
  • Full Protection Servers
  • Threat-Only Servers
  • DNS Stamps
  • Latency
  • Expected IP Addresses
• Web-Based DNS Testing Services
• Getting Help
• Glossary
• Legal & Privacy

Features

• EU-only hosting (Hetzner: Falkenstein, Nuremberg, Helsinki) and jurisdiction, fully aligned with GDPR and ENISA recommendations.
• Fully open-source DNS infrastructure combining Technitium DNS v15.4 Server with Unbound DNS v1.26.0 as an upstream recursive resolver, featuring a local root zone for enhanced privacy, security, and performance.

Security & Privacy

• No recursion via third-party resolvers.
• Strict DNSSEC validation to prevent tampering.
• QNAME minimization enforced for better privacy.
• DNS leak/rebind protection.
• No EDNS Client Subnet: your location is never exposed to upstreams.
• ANY queries dropped to improve server performance and enhance privacy.
• Strict rate limiting for responses and clients.
• Encrypted transport: DNS-over-HTTPS/3 (DoH/DoH3), DNS-over-TLS (DoT), and DNS-over-QUIC (DoQ).
• ECH support: Encrypted Client Hello works alongside DoH/DoT to encrypt the TLS handshake, hiding the website name and making it far harder for observers to see which domains you visit.
• EDE (Extended DNS Errors) support for more descriptive DNS errors.
• Hidden version and identity: CHAOS version.bind and id.server queries are refused for security hardening.
• Firewall restricted to ports strictly necessary for operation.
• Widely known internet scanners blocked at the firewall.
• Known malicious or abusive source IPs blocked at the firewall via locally maintained threat-intelligence blocklists (e.g., Spamhaus, AbuseIPDB), matched entirely on-server without transmitting any connection IP to these third parties.
• Source IPs observed directly attacking the service (e.g., flooding or attacking Do53) are blocked, independently of third-party lists.
• Tor exit nodes are blocked entirely due to persistent attack traffic observed from that network; DNS queries routed through Tor will not be answered.
• OS and DNS software regularly updated for the latest security patches.
• No logging or storage of individual queries per client.
• No sharing of any data with third parties: if nothing shareable is logged, nothing can be shared.

Filtering/Blocking

HaGeZi DNS employs a balanced blocking strategy to deliver robust privacy and security while minimizing unnecessary restrictions. It offers effective protection without excessive blocking, making it ideal for most users. This balance is achieved with the following blocklists:

Blocklist	Link	Blocks
HaGeZi Multi Pro	Link	Ads, tracking, analytics, metrics, telemetry
HaGeZi TIF (Threat Intelligence Feeds)	Link	Phishing, malware, scam, fake, cryptojacking

Blocklists are regenerated every 4 hours and updated on the servers immediately afterward.

Block TTL and Response

• Block TTL: 3600 seconds (1 hour). This reduces the frequency of repeated DNS requests for blocked domains, lowering CPU and network activity on mobile devices and helping save battery life. The value balances caching efficiency and responsiveness without sacrificing block update speed.
• Block response: 0.0.0.0. Blocked domains resolve to 0.0.0.0 instead of REFUSED/NXDOMAIN or 127.0.0.1, so connections fail immediately without local timeouts or retries in many apps, reducing unnecessary traffic.

Special Domain Handling

• Mozilla Firefox canary domain blocked, answered with NXDOMAIN: prevents Firefox from automatically switching to DNS-over-HTTPS in its settings.
• Google Chrome preflight/prefetch domain blocked, answered with NXDOMAIN: applies DNS filtering to resources preloaded via Chrome's private prefetch proxy.
• Apple privacy features allowed: domains required for iCloud Private Relay, Mail Privacy Protection, and Safari Tracking Prevention are explicitly permitted, so ad/tracker blocklists don't inadvertently break these Apple-provided privacy protections.

Logging and Data Handling

• Hourly statistics (processed/blocked domain rankings, per-client query counts) are stored only in RAM, never written to disk, and auto-deleted every hour or on service/server restart. Query counts per client are used solely for rate limiting and are never linked to resolved or blocked domains.
• Error logging: only domains that fail to resolve (e.g., DNSSEC validation failure, upstream/server error, timeout, resulting in SERVFAIL) are logged. Entries are retained for 24 hours for troubleshooting purposes on the legal basis of Art. 6(1)(f) GDPR (legitimate interest in service reliability), and no client IP addresses are stored.
• In-memory DNS cache for enhanced privacy: no query data is ever written to disk, and all entries are automatically cleared on expiry or server restart.
• Firewall-level IP blocking: source IPs matched against local copies of third-party threat-intelligence blocklists, or observed directly attacking the service, are blocked at the firewall (nftables). This matching and blocking happens entirely on-server; no connection IP addresses are sent to the third parties whose lists are used. See PRIVACY for the legal basis.

Server Health / Hourly Statistics

The following links provide server health status and a simplified overview of hourly statistics, including queries, blocked queries, clients, and other metrics:

root.hagezi.org · wurzn.hagezi.org · juuri.hagezi.org · ctif.hagezi.org

Server Locations & Access

Servers are accessible via encrypted DNS protocols, including DNS-over-HTTPS/3 (DoH/DoH3), DNS-over-TLS (DoT), and DNS-over-QUIC (DoQ), as well as unencrypted DNS-over-53 (Do53). Whenever possible, use DoH or DoH3.

Full Protection Servers (Ads, Tracking, and Threats)

These servers block ads, tracking, analytics, metrics, and telemetry in addition to phishing, malware, scam, fake, and cryptojacking domains.

Location	Protocols	Endpoint/URL	Apple Config	Recommended for
Germany, Falkenstein	DoH/DoH3	https://root.hagezi.org/dns-query	Link · QR	AT, BA, BE, BG, CH, CZ, DE, DK, FR, GB, HU, IE, IT, LU, NL, PL, RO, SI, SK
	DoT/DoQ	root.hagezi.org
	Do53	188.34.161.210 2a01:4f8:c17:1c66::1
Germany, Nuremberg	DoH/DoH3	https://wurzn.hagezi.org/dns-query	Link · QR	AT, BA, BE, BG, CH, CZ, DE, DK, ES, FR, GB, GR, HR, HU, IE, IT, LU, MD, MK, MT, NL, PL, PT, RO, RS, SI, SK, TR, UA
	DoT/DoQ	wurzn.hagezi.org
	Do53	159.69.155.94 2a01:4f8:1c1c:d363::1
Finland, Helsinki	DoH/DoH3	https://juuri.hagezi.org/dns-query	Link · QR	DK, EE, FI, LT, LV, NO, SE
	DoT/DoQ	juuri.hagezi.org
	Do53	95.217.163.17 2a01:4f9:c013:dc4e::1

Threat-Only Servers (Security Filtering Only)

This server blocks only phishing, malware, scam, fake, cryptojacking, and other harmful domains, without ad or tracker blocking.

Location	Protocols	Endpoint/URL	Apple Config	Recommended for
Germany, Nuremberg	DoH/DoH3	https://ctif.hagezi.org/dns-query	Link · QR	AT, BA, BE, BG, CH, CZ, DE, DK, ES, FR, GB, GR, HR, HU, IE, IT, LU, MD, MK, MT, NL, PL, PT, RO, RS, SI, SK, TR, UA
	DoT/DoQ	ctif.hagezi.org
	Do53	162.55.58.40 2a01:4f8:1c19:6c19::1

EU and neighboring countries with limited coverage from current server locations: AD, CY, GE, IS, LI, MC, ME, SM.

DNS Stamps

Full Protection Servers

Endpoint	Protocol : DNS Stamp
root.hagezi.org	DoH: sdns://AgMAAAAAAAAADjE4OC4zNC4xNjEuMjEwAA9yb290LmhhZ2V6aS5vcmcKL2Rucy1xdWVyeQ
	DoT: sdns://AwMAAAAAAAAADjE4OC4zNC4xNjEuMjEwAA9yb290LmhhZ2V6aS5vcmc
	DoQ: sdns://BAMAAAAAAAAADjE4OC4zNC4xNjEuMjEwAA9yb290LmhhZ2V6aS5vcmc
wurzn.hagezi.org	DoH: sdns://AgMAAAAAAAAADTE1OS42OS4xNTUuOTQAEHd1cnpuLmhhZ2V6aS5vcmcKL2Rucy1xdWVyeQ
	DoT: sdns://AwMAAAAAAAAADTE1OS42OS4xNTUuOTQAEHd1cnpuLmhhZ2V6aS5vcmc
	DoQ: sdns://BAMAAAAAAAAADTE1OS42OS4xNTUuOTQAEHd1cnpuLmhhZ2V6aS5vcmc
juuri.hagezi.org	DoH: sdns://AgMAAAAAAAAADTk1LjIxNy4xNjMuMTcAEGp1dXJpLmhhZ2V6aS5vcmcKL2Rucy1xdWVyeQ
	DoT: sdns://AwMAAAAAAAAADTk1LjIxNy4xNjMuMTcAEGp1dXJpLmhhZ2V6aS5vcmc
	DoQ: sdns://BAMAAAAAAAAADTk1LjIxNy4xNjMuMTcAEGp1dXJpLmhhZ2V6aS5vcmc

Threat-Only Servers

Endpoint	Protocol : DNS Stamp
ctif.hagezi.org	DoH: sdns://AgMAAAAAAAAADDE2Mi41NS41OC40MAAPY3RpZi5oYWdlemkub3JnCi9kbnMtcXVlcnk
	DoT: sdns://AwMAAAAAAAAADDE2Mi41NS41OC40MAAPY3RpZi5oYWdlemkub3Jn
	DoQ: sdns://BAMAAAAAAAAADDE2Mi41NS41OC40MAAPY3RpZi5oYWdlemkub3Jn

Latency

Example WonderNetwork compilation configured for Germany:

To optimize latency, personally measure the response times by pinging each DNS server from your own connection. This factors in your specific network conditions, such as geographic location, ISP routing, and local congestion, giving you a practical, real-world latency measurement. Selecting the server with the lowest ping time maximizes responsiveness and reduces DNS query delays.

Use the provided test scripts to measure actual DNS resolution times (beyond simple ICMP latency), evaluating how quickly each server resolves domain queries in practice:

• dnsperftest.sh (Unix/Linux shell script)
• dnsperftest.ps1 (PowerShell script)

./dnsperftest.sh

Latency cheat sheet (PDF): summarizes measured network latency in milliseconds from six European PoPs (Amsterdam, Falkenstein, Frankfurt, Helsinki, Nürnberg, Vienna) to cities across European countries, highlighting the fastest location per city and EU membership status, based on WonderNetwork ping data.

DNS resolution reference values (ms):

DNS resolve/lookup time (ms)	Rating	What it usually means
< 20	Excellent	Very fast response, often due to a nearby resolver and/or a warm cache.
20-50	Very good	Common target range for good user experience.
50-100	OK	Usually fine, but can add noticeable delay if a page triggers many lookups.
100-120	Average	Often cited as the upper end of "average" DNS lookup time.
120-200	Slow	Suggests distance, routing/latency, resolver load, or extra resolution steps.
> 200	Very slow / problematic	Frequently indicates a real performance or reachability issue (retries, timeouts, overload).

Expected IP Addresses

• 188.34.161.210 / 2a01:4f8:c17:1c66::1 (PTR: root.hagezi.org), Hetzner Online GmbH, Falkenstein, Saxony, DE
• 159.69.155.94 / 2a01:4f8:1c1c:d363::1 (PTR: wurzn.hagezi.org), Hetzner Online GmbH, Nürnberg, Bavaria, DE
• 95.217.163.17 / 2a01:4f9:c013:dc4e::1 (PTR: juuri.hagezi.org), Hetzner Online GmbH/HOS-GUN, Helsinki, Uusimaa, FI
• 162.55.58.40 / 2a01:4f8:1c19:6c19::1 (PTR: ctif.hagezi.org), Hetzner Online GmbH, Nürnberg, Bavaria, DE

If a DNS leak test shows IP addresses other than these, your device or network might be leaking DNS queries through fallback resolvers or directly to your ISP. This means requests are bypassing your intended DNS protection and potentially exposing your browsing activity.

Web-Based DNS Testing Services

• DNS Leak Test: dnscheck.tools · dnsleaktest.com · browserleaks.com
• DNS Nameserver Spoofability Test: GRC
• DNS Rebind Test: ControlD
• Domain Lookup Service: DNSclient
• DNS Zone/DNSSEC Status: DNSViz

Getting Help

Contact support@hagezi.org for support and questions. You can also use the official public Matrix support chat, or contact the operator directly via Matrix or Signal.

Glossary

• ANY query: a DNS query type that historically requested all available records for a domain at once; now commonly blocked by resolvers because it is rarely used legitimately and is often abused for denial-of-service amplification.
• CHAOS query: a special DNS query class (distinct from normal domain lookups) used to request server metadata such as version.bind or id.server; disabling it prevents attackers from identifying the server software or instance.
• DNS Stamp: a compact, encoded string (starting with sdns://) that bundles a DNS server's address, protocol, and public key information so compatible client software can configure a connection automatically.
• DNSSEC (DNS Security Extensions): a set of cryptographic signatures added to DNS responses that let a resolver verify a response has not been tampered with in transit.
• Do53: traditional, unencrypted DNS carried over port 53; visible to anyone who can observe network traffic.
• DoH / DoH3 (DNS-over-HTTPS): DNS queries and responses carried inside an encrypted HTTPS connection (DoH3 uses HTTP/3), hiding DNS traffic from network observers.
• DoQ (DNS-over-QUIC): DNS carried over the QUIC transport protocol, combining encryption with QUIC's faster connection setup.
• DoT (DNS-over-TLS): DNS queries and responses carried inside a dedicated, encrypted TLS connection on a separate port.
• ECH (Encrypted Client Hello): a TLS extension that encrypts the initial handshake message, preventing observers from seeing which website hostname a client is connecting to.
• EDE (Extended DNS Errors): a mechanism that adds a specific, human-readable reason code to a DNS error response instead of a generic failure.
• EDNS Client Subnet (ECS): an optional DNS extension that would normally forward part of a client's IP address to upstream servers to improve geographic accuracy; disabling it keeps the client's location hidden from upstream resolvers.
• ICMP (Internet Control Message Protocol): the protocol used by tools like ping to measure basic network round-trip time; it measures raw network latency only, not actual DNS query resolution time.
• nftables: the modern Linux kernel firewall framework used on the servers to enforce IP-level blocking and rate limiting.
• NXDOMAIN: a DNS response code meaning the requested domain does not exist.
• PTR record: a reverse DNS record that maps an IP address back to a hostname.
• QNAME minimization: a privacy technique where a resolver only sends the minimum portion of a domain name necessary to each server in the resolution chain, rather than the full domain name.
• Recursive resolver: a DNS server that performs the full lookup process on behalf of a client, querying other servers as needed, rather than simply forwarding the request elsewhere.
• REFUSED: a DNS response code indicating the server declined to answer the query, distinct from NXDOMAIN (domain does not exist) and SERVFAIL (resolution error).
• Root zone: the top level of the DNS hierarchy; running a local copy allows a resolver to look up top-level domains directly instead of depending on external root servers.
• SERVFAIL: a DNS response code indicating the server encountered an error while trying to resolve the query (for example, a DNSSEC validation failure).
• Technitium DNS Server: the open-source DNS server software used to run the public-facing resolver component of this service.
• Tor exit node: the final relay in the Tor anonymity network through which traffic exits onto the public internet; frequently associated with automated abuse due to its anonymizing nature.
• TTL (Time to Live): the number of seconds a DNS response may be cached before it must be looked up again.
• Unbound: an open-source, validating, recursive DNS resolver used as the upstream resolution engine behind Technitium DNS Server in this setup.

Legal & Privacy

This document covers technical setup and usage only. The full disclaimer, EU privacy policy, Digital Services Act (DSA) content-moderation compliance information, and a glossary of legal terms are maintained in a separate document: PRIVACY.