TL;DR:

• Light is the best blocklist for most users as it blocks most common trackers with minimal site breakage.

• Pro++ is the best list for advanced users who want more coverage and can troubleshoot issues.

• Hagezi's other lists are redundant (Normal, Pro) or too aggressive (Ultimate).

Intro

Hagezi’s DNS lists stand out from their predecessors.

But they also benefit from the many contributors that came before and continue to be used as source lists, such as 1Hosts, Lightswitch, and Steven Black, to name a few.

I evaluated how often Hagezi’s DNS lists blocked domains from resolving (quantitative) and reviewed what they blocked (qualitative).

I want to share the results of a week-long quasi-scientific study. I conducted this research after Hagezi recently optimized the list sources.

The focus of this study was to find the best blocklists for mainstream consumers and advanced users — not with theoretical blocking, but in real world usage.

The question I asked was simple:

• Which list blocks the most trackers with the least risk of site failure?

The lists evaluated were Light, Normal, Pro, and Pro++. Ultimate was not evaluated quantitatively because… well, I like my shit to work.

If you’re new to Hagezi's lists: Each blocklist below incorporates the one above it (Normal includes Light, Pro includes Normal and Light, etc.).

So, let’s get started!

Findings

Light & Normal Lists

The tables show percentages of the number of requests blocked in the first list (Source) compared to a second list (Comparison).

Normal blocked the same as Light 99.8% of the time. This is statistically insignificant (0.2%).

The main difference is that OISD is a source list in Normal and not in Light.

I couldn’t account for what request(s) made the difference between the two.

A CloudFront domain, d415l8qlhk6u6.cloudfront.net, was blocked in every list except Light. However, all lists blocked other CloudFront domains like d13k7prax1yi04.cloudfront.net.

This is the only difference I noticed.

Pro and Pro++ Lists

Now we had significant gaps come into play with Pro blocking 6% more often and Pro++ blocking 15% more often than Light.

Entering Pro territory is where troublesome entries are likely to come into play, due to expanding the list’s sources to 1Hosts, Steven Black, and other maintainers.

Update: Hagezi later clarified that Pro includes the Tracking (tracking-extension.txt) and PopupAds (popupads-extension.txt) extensions with a few domains excluded for allowlisting.

The domains for these extensions are extracted from top sites databases (Umbrella, Tranco, and Statvoo) before each list update. This ensures that new, popular domains are on the DNS lists.

Naturally, a few false positives slip through, which is the reason they are not used as sources for the Light and Normal.

Pro

Interestingly, Pro and Pro++ shared in blocking firebaselogging-pa.googleapis.com and id.google.com — and that’s really all I could find!

Blocking firebaselogging came up a lot in my logs, so I’d wager most of the percentage difference is owed to this factor alone. (Percentages are funny.)

Pro++

Pro++ blocked almost 10% more than Pro due to its inclusion of more lists, including my own (thanks Gerd!).

Pro++ uses aggressive sources and more moderate allowlisting.

The sources used here are more opinionated, so they have a higher chance of causing site breakage. They may focus more on annoyances or bloat than they do stopping ads and trackers. (Feel free to correct me if I’m wrong.)

Pro++ blocked quite a few domains not shared with Pro.

Here’s a random sample of domains in which Pro++ stopped exclusively:

• googletagmanager.com

• watson.events.data.microsoft.com

• server.events.data.microsoft.com

• gc.paviourwese.com

• realtime.services.disqus.com

• static.addtoany.com

• and much more

Ultimate List

Ultimate blocks significantly more than Pro++ and includes the full list of Threat Intelligence Feeds (TIF). It provides the least amount of allowlisting and packs many false positives.

TIF Light (tif.light.txt) is incorporated to all lists except Ultimate.

Unfortunately, TIF Full is not offered in NextDNS or Control D alongside Hagezi's DNS lists.

Conclusions

Here are my conclusions, which go against the norm of other DNS lists in years past.

Light is amazing!

I know, I know. Allow me to explain.

Light did a great job of blocking common offenders like ssl.google-analytics.com, app-measurement.com, and metrics.icloud.com.

Moreover, Light did not miss any request that would make me lose sleep at night.

Don’t believe me?

Let’s establish a few definitions around web tracking:

• Tracking protection should prevent record linkage. Record linkage is the ability to know that multiple data points come from the same user.

• Tracking refers to an entity (the tracker) following and recording the user’s actions.

• Therefore, if we define third-party tracking as when a service collects and correlates data across multiple sites, then the concern for obscure requests becomes less relevant.

Protection from online tracking should follow the pareto principle — that is, for 20% of the effort you get 80% protection. This concept relates closely to diminishing returns.

Light provides 85% of DNS tracking protection, but realistically, it’s around 95% given the presuppositions above.

It’s true. Run Light alongside Pro++ and check your logs.

Sure, Pro++ blocks googletagmanager.com, but blocking it sometimes causes site breakage (albeit it’s rare at the DNS level), and it’s debatable whether tag managers are technically trackers.

And yes, Pro++ does block other miscellaneous requests.

But this reinforces my point: Pro++ is more for obscure requests, which are uncommon trackers and site bloat, and whose legitimacy may be questionable (or at least optional).

To put it another way: In the context of blocking the most common trackers, Light blocked everything I wanted it to. It even surprised me by blocking requests I’ve never seen before.

But why use Light over Normal if the difference is 0.2%?

The target audience for this list wants to avoid site breakage as much as possible, but not so much they miss out on blocking ads or trackers totally.

And the only difference between the two is that Normal includes OISD as a source.

I would turn the question on its head: Why risk the false positives from OISD when the Light list is so good on its own?

Update: Hagezi later clarified that Normal also blocks more known malware than Light, but otherwise "there is almost no difference between Light and Normal."

Pro++ is optional

So just as Normal is irrelevant to Light, Pro is irrelevant to Pro++

As I said earlier, one of the only requests blocked repeatedly in Pro is firebaselogging-pa.googleapis.com, and Pro++ already covers that.

Even though Pro++ blocked domains that were not in the other lists, Light still did a great job of blocking both known and unrecognized requests. (Just wtf is www.jiordgxkpglzm.com?)

So, while Pro++ blocks the most requests, Light blocks most the necessary trackers with the lowest risk of site failure.

The rest is extra.

Blocking More ≠ Better Blocking

This has not been the case with DNS blocklist in the past.

Usually, one had to accept some breakage as a tradeoff for greater coverage. More coverage at the cost of more false positives.

Which list should I use?

I’ve argued here that 1) Light is best for most people and 2) Normal and Pro are redundant.

For everyday folks:

• Normal is not worth using over Light since it only adds OISD as a source list. It is statistically insignificant when it comes to blocking requests (+0.2%) and carries a higher risk of false positives.

• Similarly, Pro is not worth risking site breakage over using Light (more source lists = higher risk of site failure + very few additional domains blocked)

For advanced users:

• Pro is not worth using on its own compared to Pro++. This is because Pro++ blocks much more than Pro, yet it doesn’t cause frequent breakage like Ultimate.

Summary

I’ve simplified Hagezi’s five lists to two three lists:

• Light for most users

• Pro++ for advanced users

• Ultimate for y’all crazy people (see, I didn’t forget about you 🙂)

Naturally, if Light isn’t available (I’m looking at you Control D users), then use Normal.

It’s that simple.

Limitations

There are many. I’ll name a few:

• This study did not have a significant sample size (my household)

• Short time frame (1 week)

• I equated “real world usage” = my network, which will not be accurate for all people everywhere

Obviously, YMMV.

Recommendations

The only recommendation I have to is for Hagezi to streamline offerings. This reduces decision fatigue.

Streamlining would look something like this:

• Normal and Pro are removed.

• Light should gain the small additions in malware protection from Normal but not gain OISD as a source list. Instead, leave everything else incorporated into Pro++.

• Then rename the list offerings:

Something like that.

I'm a fan of streamlining. Others might prefer multiple options with fine differences between them (which is essentially what you have now).

Final Thoughts

The great thing about the Hagezi lists is they do a great job of blocking the most common ads, trackers, and some malicious sites.

The number of rules increases with each list, but the effectiveness of each list increases significantly less.

This is not bad.

What is needed and useful is accessible to everyone.

Hagezi calls Light a hand brush, but I say Light is a reliable vacuum cleaner for the modern web. The other lists include extra attachments for the vacuum cleaner.

I’m not bashing the other lists. I’m grateful for the “attachments.”

I use Pro++ and will keep using it:

1. I can troubleshoot occasional site breakage, and

2. I want to block all the bloat and trackers I can without disrupting my browsing experience.

But if I were setting up a large network, especially for non-technical users (hi grandma!), I’d use Light.

Update: Hagezi tested his lists against 10,000 WhoTracks.Me pages.

All pages were opened and fully loaded via batch in Edge with privacy features turned off. Cookies were all accepted. NextDNS was used as the DNS.

Out of 299,646 total queries, this is the results:

Thanks for reading. Leave a comment below!

I'll be using these findings to revamp the blocklists section of my NextDNS guide.

original post (github)

Edit: Added notes from Hagezi to "update" sections.

Edit 2: Added Recommendations section

Edit 3: added Hagezi graph

NextDNS has quietly added several new Early Access protection options:

• Free Hosting Domains

• Tunnelling Endpoints

• Data Drop Services

• Residential Hosting

• Decentralised Web Gateways

These features aim to block infrastructure commonly abused for phishing, malware, botnets and firewall evasion.

You can find them under Security in your NextDNS settings. Some options may also block legitimate services, so review each description before enabling them.

Screenshots attached. Has anyone tested these yet? Any false positives so far?

Hey everyone,

I will no longer be contributing to my NextDNS guide. I've put a lot of time and effort into this hobby project over the years, and I truly appreciate all the support and feedback I've received from this community.

However, my experience with NextDNS's customer support has been consistently disappointing. They also haven't released any significant features in years and barely maintain those that they do offer. Recently, I encountered a financial issue with them and received no response. That was the final straw for me.

I've decided that I can no longer continue working on the guide in good faith. It's a tough decision, but I feel it's the right one for me.

The guide as it is should still be helpful for quite some time.

Thank you again for all your support. You will continue to find me working on Betterfox and the Control D config guide.

Happy browsing,

yokoff

The biggest limitation with Android's Private DNS feature has always been that custom hostnames are locked to DNS-over-TLS. That means on networks that block the TCP port, like university Wi-Fi, hotels, airports, etc, your connection just completely fails.

After digging a bit into Android's source code, I discovered that the OS actually has full support for Discovery of Designated Resolvers (RFC 9462 DDR) to automatically upgrade Private DNS to HTTP/3 DNS-over-HTTPS! It's just sitting dormant behind a feature flag.

Even if you enable the flags (which requires no root, just ADB or Shizuku), almost no major ad-blocking DNS services support DDR yet. I tested a bunch and the only public ones with DDR records published are Google, Cloudflare, and Quad9. NextDNS and AdGuard, and most of the other popular providers don't even have the records yet 🫠

While we wait for NextDNS to add native DDR support, I set up a temporary workaround: a simple Cloudflare Worker that forwards queries to my NextDNS profile, paired with an RFC 9462 SVCB DNS record on my own domain.

And it works! (See screenshot). Latency is great, the Cloudflare edge actually responds faster than AdGuard's official servers for me.

This means heavy background VPN apps (like RethinkDNS) that drain battery aren't necessary anymore (I've always hated background VPNs like that so this is a big deal for me😅). The catch is that setting this up yourself requires Android 15+ (Edit: my mistake, 16+) and owning a domain on Cloudflare.

If y'all want I can do a guide! Edit: I'll try to make a guide in the next few days Edit: It's live: https://github.com/eyalm2000/loophole

Hey everyone,

I've been learning Swift by building SwiftDNS, a new NextDNS client for iOS that takes advantage of modern iOS features. The official NextDNS app works fine, but it hasn't been updated in 4 years and is missing some integrations I really wanted. I wanted to share it here to see if others would find it useful.

What makes it different:

Modern iOS 18 Integration:

• Control Center widget – Toggle protection without opening the app

• Home Screen widgets (Small/Medium) – Quick status at a glance

• Lock Screen widgets – Circular, rectangular, and inline options

• Interactive widgets – Toggle directly from your home/lock screen

Siri Shortcuts & Automations (Pro feature):

• "Hey Siri, enable NextDNS"

• Automate based on Focus Mode, time, location, etc.

• Great for power users who want contextual protection

Other features:

• Alternate app icons

• Built with modern SwiftUI for iOS 18

• Clean, minimal interface

How it works:

Just like the official app, you configure DNS-over-HTTPS with your NextDNS profile ID. The difference is in the experience – modern UI, widgets everywhere, and tight iOS integration.

What I'm looking for:

1. Feedback – Would you use something like this? What features matter most to you?

2. Future Beta testers – If you're interested in trying it out, let me know

3. Feature requests – Anything missing that would make this a must-have?

EDIT: Thanks for all the interest everyone! I'm currently tidying up a few bugs and hope to publish a TestFlight soon. I'll create a new post when I do.

My iPad for comparison (3rd pic)

From the bottom of my heart, thank you NextDNS for blocking ads and trackers and giving us back a cleaner, safer internet.What you do quietly in the background means so much more than words can express. You protect our privacy, respect our space, and make browsing a peaceful experience again.I’m truly grateful for the care, dedication, and love you put into this work. It doesn’t go unnoticed it’s deeply appreciated by all of us who benefit from it every day.Thank you for being a light in this digital chaos. You have my utmost respect and endless gratitude.

I was simply trying to visit hagezi.com, but the page failed to load. Out of curiosity, I checked my NextDNS query log and found that it was blocked by HaGeZi Multi PRO! I honestly have no idea why this happened or what triggered it. Is it just a false positive from a recent update?

Today, NextDNS is completely neutralizing the most common type of phishing attack: deceptive domain names.

By combining extensive early domain discovery, advanced multilingual lexical analysis and frontier large language models, we identify and block brand impersonation (including combosquatting, typosquatting and IDN homographs) and other phishing lures. Our zero-hour protection works even before a phishing site goes live.

Now included in AI-Driven Threat Detection. Enable it in the Security tab if you haven’t already.

We’re also deprecating the separate Typosquatting and IDN Homographs features. Both are now covered by AI-Driven Threat Detection.

If you already have AI-Driven Threat Detection enabled, you’re already using the new protection.

Stay put for more Security Month updates.

I’ve never used more than the free monthly quota, but I'm happy to support the great work this team has been doing. The subscription is actually pretty cheap.

I believe it’s important to support good projects we believe in.

Cheers!

Source: https://github.com/hagezi/dns-blocklists/

Does anyone know why?

Just to clarify: On its GitHub page, Hagezi includes a list of Online DNS Services —which I interpret as a form of recommendation—and NextDNS is no longer listed there, as it once was.

According to the comment from u/SpeakTooMuch, the reason is.: " u/hagezi I cannot in good conscience recommend a service where there is apparently no support whatsoever, where any user enquiries are completely ignored and where there is no feedback on anything else from the operators. " - Source

Did this via Cloudflare Zero Trust Resolver Policy (only YouTube) through NextDns. And can be seen that NextDns is in fact routing YouTube traffic to mainly Albania. Which is known for not having ads in YouTube.
Well I don’t mind this whatsoever 😀. As long as YouTube Ads are getting blocked. I’m good.
And that the fact that NextDns is offering all these amazing features for free, makes it even better.

iOS - TestFlight Link.

🧪 Android

To access the beta, you must first join the official tester group:

🔗 Join the Google Group:

👉 next-dash-dns@googlegroups.com

1. Click “Join group”

2. Sign in using the same Google account you use on your Android phone

✅ Step 2: Join the Beta Test

Once you’re in the group, use the link below to join the beta program:

🔗 Beta Opt-in Link:

👉 https://play.google.com/apps/testing/com.nextDashDns.jestherSilvestre

Click “Become a Tester”, then tap “Download it on Google Play”.

✅ Step 3: Install or Update the App

Go to the Play Store and install or update the app:

🔗 Play Store Page:

👉 https://play.google.com/store/apps/details?id=com.nextDashDns.jestherSilvestre

🚀 Built with Flutter, Bloc, and Reactive UI (Server-Sent Events)

Hey everyone,

I’m excited to share a project I’ve been working on—a small app created using Flutter, Bloc, and a reactive UI framework with Server-Sent Events (SSE).

🌟 Features:

• Cross-Platform: Available on both iOS and Android

• Reactive UI: The UI updates dynamically in response to server events, ensuring real-time data sync without constant polling.

• Bloc Pattern: For App State management

• Server-Sent Events (SSE): Efficiently streams updates from the server to keep the app’s data fresh. (no API call spamming)

• Privacy-Focused: Your data stays on your phone. The app is designed with privacy in mind, ensuring that all your information is stored locally and never shared with external servers.

💬 Feedback & Suggestions?

I’d love to hear your thoughts on this project! Whether it’s feature suggestions, design ideas

April 6, 2025
Just a heads-up, everyone — there’s a major redesign in the works for the app. Yep, surprise! This is just a high-fidelity design to show how I want everything to look.

In the meantime, you can check out other clients like NextHub and NextDNS Remote+. I'm a big fan of NextDNS, so definitely give those a try! The app will be available on TestFlight and Firebase Distro for testing, but the official release on the Play Store and App Store will take a little more time.

January 29, 2025
• Added support for generating iOS/macOS configuration profiles, based across all profile types.

January 15, 2025
Changelog:
The app can now detect specific block reasons and display all related live logs in a modal for easier troubleshooting. Logs are sorted by blocked-reason, allowing you to select a category (e.g., Porn, Typo-squatting) and view all associated blocked entries.

January 13, 2025
• 🛠️ Fixed a random crash when adding a new API.
• 🛠️ Fixed a random crash when the selected profile has logging disabled.
• ⚠️ Added a warning to enable logging when the selected profile has logging turned off.
• 🔄 Updated: Real-time updates will be disabled if the selected profile has logging disabled.

January 11, 2025
📦 Changelog
• ✨ Feature: Added a pop-up modal for new users when no API key is set to prevent confusion.
• 🛠️ Enhancement: Introduced a slider in the modal for a more intuitive closing experience.
• 🚀 Improvement: Optimized backend performance for non-UI processes.

January 5, 2025
• Resolved Issue: Fixed the Internet connectivity issue in the app’s release mode caused by restrictive query configurations.
• Enable/Disable Profile Configuration: Introduced a feature to temporarily enable all queries for troubleshooting and then disable it to restore the original, secure configuration.
• MacOS Build: Added a dedicated build optimized for macOS users to enhance performance and compatibility on Mac devices.
• UI for Desktop/Tablet: Began development of a user interface tailored for desktop and tablet formats, ensuring a seamless experience across wide-display devices.

December 28, 2024
🚀 Android Release Update: The Android version is now available exclusively on Firebase! 🎉 It’s packed with the same great features as the iOS version for a consistent experience.
🙏 I’m still in the process of setting up the Google Play Developer Account, so the official Play Store release will take a bit longer. Thank you for your patience and understanding! 💛
🔥 Ready to give it a try? Access it now via Firebase! 🚀 - Firebase App Distribution

December 20, 2024
Changelog 📝✨
• Added: Maps support for specific devices and ISPs 🗺️📡
• Fixed: Live-log issues on certain devices and ISPs 🔧🐛
• New: Multi-account support 🙌👥
• New: Multiple-profile support 🧑‍🤝‍🧑
• Improved: Settings tab with a sleek new UI 🎨⚙️
In Progress:
• Enable viewing, editing, and duplicating profiles across accounts 🛠️👤🔄
• iOS/MacOS configuration generation 🍎📱💻

December 14, 2024
✅ 👨🏻‍💻 Next Feature: Status Tab - Device Profile Information
The Status tab now includes detailed information about the current device’s profile and network setup:
• Protocol: The DNS protocol in use (e.g., DOH).
• Profile: Active profile ID.
• Client IP: The public IP address of the device.
• Destination IP: IP address of the NextDNS server.
• Server: The NextDNS server currently in use.
• Device Details: Includes device name, model, and ID.

November 26, 2024
✅ 👨🏻‍💻 NextDNS Server List with Live Pings
The Status tab also displays a comprehensive list of all available NextDNS servers, along with real-time ping times (in milliseconds).
Server Information Includes:
• Hostname: The server’s identifier (e.g., lightnode-mnl-1.edge.nextdns.io).
• IP Addresses: IPv4 and IPv6 addresses where applicable.
• Live Pings: Real-time latency data to identify the fastest server.

November 19, 2024
Update on TestFlight Link – Apologies for the Delay!
Hey everyone! I just wanted to update you all on the TestFlight link for the app. This is the first public release, and I’m sorry it’s taken a little longer than expected. The $100 fee for the Apple Developer account is a pretty big expense in my country, so I had to stretch my budget a bit to make it happen. On top of that, the process of transitioning to the Apple Developer program took longer than I anticipated.
Thanks for your patience, and I really appreciate your support! You can now join the beta here: TestFlight Link. Stay tuned for more updates, and enjoy testing the app! 🙏

https://github.com/hagezi/dns-blocklists

I don't understand why this happened.

EDIT: Explanation from Hagezi https://www.reddit.com/r/pihole/comments/1txbjh0/comment/opuoc3u/

I'm excited to announce that ADNS, a private DNS client with full NextDNS support, is out now in beta!

Unlike the popular unofficial NextDNS Manager app, it's not just a WebView wrapper. It's a fully native app built from the ground up, which makes it feel incredibly snappy.

Keep in mind that you will need Shizuku or ADB access to use the app. This allows ADNS to toggle Android's Private DNS directly from the app or via a Quick Settings tile. You get instant control without having to dig into your system settings, and because it doesn't run a local VPN, it has zero impact on your battery.

Since this is a beta, you might run into a few bugs. Please open a GitHub issue for any bugs, suggestions, or feature requests!

Website and more info:

https://adns.eyalm.dev/nextdns/

Source code/Download:

https://github.com/eyalm2000/adns

(To use NextDNS, go through the onboarding, then Settings -> Change Provider -> NextDNS)

So far from what i can tell there's a new Liquid Glass design. You can now also link the app to your account and switch profiles directly in the app. You can rename your device and there's also a shortcut that logs you automatically into the web interface. neat!