Serious Discussion DNS Providers for Home Users – Still Cloudflare/Quad9, or Did NextDNS/Control D Finally Win?

[Andy Ful]

Your observation is plausible, but it doesn’t prove an “Avast API” link

Even if your results are “almost the same” (including the same misses), there are a few non-Avast explanations that can still produce that pattern:

• Shared upstreams (especially Google Safe Browsing): if both products rely heavily on GSB (directly or indirectly), you can end up with very similar allow/block decisions—particularly on fresh, fast-moving phishing. DNS-level use of GSB is still domain-focused, but if many PhishTank entries are on domains that get flagged quickly, the overlap can look near-total.

I did not say that my observation proves something. There are some possible explanations. But not shared upstreams.
In tests, I could identify Google Safe Browsing detections. They were about 10% of all blocks. I also tested public versions of NextDNS and Control D. The results on half-hour-old samples were about 30%. It is far too little.

• Domain clustering in PhishTank samples: “many half-hour-old URLs” can still map to a smaller set of domains (or reused infra). If the same domains repeat, two different tools can converge on nearly identical results without sharing a vendor API.

There is some clustering, but the same effect is visible on all non-clustering domains.

• The same fundamental limitation causing the same misses: if a chunk of your samples are on compromised legitimate domains or shared platforms where blocking the whole domain is too destructive, both DNS filtering and an extension may miss them (or choose not to hard-block).

This could explain some misses, but not blocks.

My guess is that some NextDNS advanced features work very similar to those used by Avast.

 

[Bot]

I did not say that my observation proves something. There are some possible explanations. But not shared upstreams.
In tests, I could identify Google Safe Browsing detections. They were about 10% of all blocks. I also tested public versions of NextDNS and Control D. The results on half-hour-old samples were about 30%. It is far too little.

Fair point: if you already isolated GSB blocks (~10%), “shared upstreams” is unlikely to explain 90%

If your tuned NextDNS config is getting ~90% on ~30-minute-old PhishTank entries, while “public” NextDNS/ControlD profiles are ~30%, the most likely drivers are:

• Your enabled blocklists/categories (especially aggressive anti-phishing/malvertising lists). This alone can produce a huge jump versus any default/public resolver profile.
• NextDNS internal Threat Intelligence / dynamic blocking (whatever they use behind the scenes). Even if they don’t disclose sources publicly, a dynamic system can react faster than static public resolver policies.
• Heuristic-style DNS protections (if enabled in your config), for example blocking patterns like newly-registered domains, lookalikes/typos, suspicious TLDs, etc. (I’m not claiming NextDNS definitely uses each of these; the point is that “non-list, non-GSB” DNS heuristics can inflate early blocking rates on very fresh phishing.)
• Dataset characteristics: PhishTank “half-hour-old URLs” can still concentrate on certain infrastructures. If your config blocks those infrastructures broadly (more aggressive), you’ll score high quickly.

How to pinpoint what caused the “90%” (without guessing sources)

• Run the same PhishTank domain set through staged configs:
  • Baseline: no third-party blocklists/categories (as close to “default allow” as possible)
  • + Your security categories (no third-party lists)
  • + Add one blocklist at a time (HaGeZi, etc.)
  This will show which component causes the big jump.
• De-duplicate by domain before scoring. Count “unique domains blocked” rather than “URLs blocked.” This avoids a few heavily reused domains making the result look stronger than it is.
• Track false positives in parallel. Very high early phishing coverage at DNS level often correlates with higher daily-use breakage, so a second score like “legit sites broken in a normal day” helps interpret the 90%.

About the ~30% public resolver result

That number is believable for very fresh phish, because many public DNS resolvers aim to avoid collateral damage and don’t run aggressive per-user policies/lists. Your customized config is essentially “turning the dials” toward higher sensitivity, which is exactly how you get a big uplift on brand-new samples.

Conclusion: if GSB is only ~10% of your blocks, your high score is most likely coming from your enabled lists/categories and/or NextDNS’s internal TI/dynamic decisions (not necessarily any Avast integration). The clean way to prove it is staged re-testing with one variable changed at a time and scoring on unique domains.

There is some clustering, but the same effect is visible on all non-clustering domains.

If the “same hits and same misses” persists even after removing clustering, that still can happen without any direct vendor API sharing

When two protections converge on near-identical outcomes across many distinct domains, the usual explanations are:

• Same (or highly overlapping) phishing intelligence feeds that are not Google Safe Browsing. Many products—DNS services and extensions—license or ingest the same commercial feeds and/or the same public sources (including PhishTank itself in some ecosystems). I can’t confirm which specific feeds NextDNS or Avast use beyond what they disclose, but “feed overlap” remains a strong explanation even if it’s not GSB.
• Similar heuristics producing similar decisions on very fresh phish: blocking newly-registered domains, high-risk TLDs, punycode/homograph patterns, suspicious NS/provider patterns, or other DNS-visible signals. Two independent vendors can implement comparable heuristics and therefore miss/block the same edge cases.
• Same “hard-to-block safely” miss class: compromised legitimate domains and shared platforms. If a URL is on a legitimate domain (or a big shared platform), both DNS filtering and a reputation-based extension may avoid blocking the whole domain, leading to matching misses even when domains are not repeating.

How to pin down what is driving your 90% in NextDNS (without guessing sources)

• Use NextDNS log attribution at the per-domain level: export blocked domains and group them by “Blocked by …” (your blocklists vs built-in security categories vs TI feed vs GSB). This tells you which module actually accounts for the 90%.
• Run controlled A/B toggles on the same saved domain set: disable one category/list at a time and re-check. The component that causes the large delta is your real driver.
• Classify the misses (even a small sample): are they mostly “legit-but-compromised domains / shared platforms” vs “brand-new random domains”? If they cluster in the first class, matching misses between DNS and an extension is expected.

Conclusion: if GSB is only ~10% of your blocks, the “almost identical” outcome is most consistently explained by non-GSB feed overlap and/or similar heuristics plus the same unavoidable miss classes (compromised/shared domains). The reliable way forward is per-domain “Blocked by…” attribution and one-variable-at-a-time toggles on the same fixed domain set.

This could explain some misses, but not blocks.

My guess is that some NextDNS advanced features work very similar to those used by Avast.

You may be right about “similar methods,” but there’s still no public confirmation of an Avast feed/API in NextDNS

At the moment, I’m not aware of any official NextDNS documentation (or staff statement) that says their Security/Threat Intelligence features consume an Avast API/feed. NextDNS does explicitly acknowledge Google Safe Browsing integration, and also notes the limitation that at DNS level they can only handle domains, not full URLs. ([help.nextdns.io](https://help.nextdns.io/t/35y82n2/google-safe-browsing?utm_source=openai))

If it’s not GSB, what could still explain “nearly identical blocks + identical misses”?
Even when you exclude clustering and you already attribute only ~10% of blocks to GSB, there are still realistic ways two products can converge:

• Overlapping (non-GSB) reputation sources: Many security products license the same third‑party intel, or ingest the same public feeds indirectly. That can produce extremely similar block/miss patterns without one directly using the other’s API.
• Similar “safe-to-block” policy decisions: Two vendors may independently decide not to hard-block certain infrastructures (to avoid excessive breakage), leading to similar misses, while aggressively blocking disposable phishing domains leads to similar blocks.
• NextDNS internalization/licensing possibility: NextDNS has historically referenced public TI feed lists in its metadata, but community discussions indicate parts of this area have become less transparent over time, which is consistent with (not proof of) licensed/private sources. ([help.nextdns.io](https://help.nextdns.io/t/60yqxb9/hagezi-threat-intelligence-feeds-only?utm_source=openai))

What you can verify from your side (no guessing required)

• Attribute every block in NextDNS logs (“Blocked by …”): export your blocked domains and count how many come from each module (GSB vs Threat Intelligence Feeds vs your selected blocklists/categories). This identifies what actually delivered the ~90%.
• Run controlled toggles on the same fixed domain set: disable one category/list at a time (or enable only one at a time). The feature that moves the needle is the real explanation.
• Score on unique domains (not URLs) and keep a “breakage/false-positive” score in parallel. Very high early phishing catch rates at DNS level often come with higher collateral blocking.

About Avast Online Security & Privacy
Avast describes the extension as scanning each visited URL and warning/blocking dangerous sites. That “full URL” capability can still end up looking similar to a DNS system if both are largely driven by reputation decisions on the domain/infrastructure involved. ([support.avast.com](https://support.avast.com/en-us/article/Use-Online-Security?utm_source=openai))

Conclusion: your results are consistent with “NextDNS security features + your config are very effective on that dataset,” but there’s still no solid public basis to claim NextDNS is using an Avast API/feed; the most defensible statement is that they may be functionally similar because they can be driven by overlapping reputation intelligence and similar blocking policies. ([help.nextdns.io](https://help.nextdns.io/t/35y82n2/google-safe-browsing?utm_source=openai))

 

[Andy Ful]

Try Symantec browser protection; I bet will block more, but with more FP in daily use.

Fresh samples = up to three-hour-old URLs from Phishtank (all = classified and unclassified):
Tested 44 URLs

Avast missed 6 that were blocked by Symantec
Symantec missed 5 that were blocked by Avast.
Most of the missed samples were Newly Registered Domains.
NextDNS blocks ( ~ 92% of total samples) = all Avast or Symantec blocks, and a few more.

Within the test error, Avast and Symantec have similar block rates, although the missed samples can be different.

Post corrected.

 

[ForgottenSeer 123960]

@Bot If I were to ask AI to explain why using complicated DNS tools with manual configuration like cloudflare zero free would not be a good fit for average home users , then ask if a user that copies ai tutorials and guides messing with manual complex DNS configurations should be doing so without understanding what they are adjusting ("Cargo Cult IT") how would it respond?

 

[Bot]

@Bot If I were to ask AI to explain why using complicated DNS tools with manual configuration like cloudflare zero free would not be a good fit for average home users , then ask if a user that copies ai tutorials and guides messing with manual complex DNS configurations should be doing so without understanding what they are adjusting ("Cargo Cult IT") how would it respond?

Why “complicated DNS tools” (e.g., Cloudflare Zero Trust / Gateway style setups) are often a bad fit for average home users

For most home users, the main value of DNS filtering is “set it once and forget it.” Platforms designed for organizations (even if they have a free tier) tend to add complexity that creates real downsides at home:

• Misconfiguration risk: A small mistake (wrong policy order, wrong resolver endpoint, wrong device enrollment, wrong split-tunnel setting, etc.) can silently reduce protection or break important services.
• Troubleshooting burden: When something stops working, it’s harder to tell whether it’s DNS, HTTPS inspection/tunneling, a policy category, a blocklist, a device profile, or a client agent problem.
• More moving parts: Certificates, agents, device posture, per-device policies, profiles, and roaming clients can be great for IT teams, but it’s extra failure points for a household.
• Breakage and “support debt”: Home networks have lots of quirky apps/devices (smart TVs, consoles, IoT, printers). Aggressive or complex DNS policies often cause intermittent issues that are hard to diagnose.
• False sense of security: A complex dashboard can make it feel like you’re “enterprise secure,” while DNS still can’t see full URLs/paths and can’t solve many phishing cases by itself.

About “Cargo Cult IT” (copying tutorials without understanding)

That’s a valid concern. In security, copying a guide step-for-step without understanding the “why” can create outcomes like:

• You can’t assess tradeoffs (privacy vs visibility, blocking aggressiveness vs false positives, security vs usability).
• You can’t validate the result (whether it’s actually filtering, whether you accidentally bypassed it with DoH/DoT, whether your router is still handing out a different DNS via DHCP, etc.).
• You can’t respond safely when something breaks (people “disable random things” until it works, sometimes removing the protection they wanted).
• You may inherit someone else’s threat model that doesn’t match yours (an ultra-aggressive enterprise-like policy at home often just increases breakage and exceptions).

In other words: it’s not “wrong” to learn by following guides, but doing it blindly with security controls can be worse than staying on a simple, known-good setup.

What usually is a better fit for average home users

• Keep it simple: use a reputable DNS resolver with malware/phishing blocking enabled (or a simple profile-based DNS filter) and avoid advanced policy stacks unless you truly need them.
• Minimize knobs: fewer lists/categories, fewer custom rules, fewer device enrollment steps.
• Layer protection: pair DNS filtering with browser phishing protection and a reputable security solution, rather than trying to make DNS do everything.
• Change control: document what you changed, keep a rollback path, and only change one thing at a time.

Conclusion

A complex “enterprise-style” DNS platform can absolutely work at home, but it’s often not a good match for average users because the complexity increases the chance of breakage and misconfiguration, and it can create a false sense of security. If someone is copy/pasting AI tutorials and guides without understanding the settings, that’s classic “Cargo Cult IT” and it’s a real risk with security controls—simpler, well-understood DNS setups tend to be safer and more maintainable.

 

[ForgottenSeer 123960]

Why “complicated DNS tools” (e.g., Cloudflare Zero Trust / Gateway style setups) are often a bad fit for average home users

For most home users, the main value of DNS filtering is “set it once and forget it.” Platforms designed for organizations (even if they have a free tier) tend to add complexity that creates real downsides at home:

• Misconfiguration risk: A small mistake (wrong policy order, wrong resolver endpoint, wrong device enrollment, wrong split-tunnel setting, etc.) can silently reduce protection or break important services.
• Troubleshooting burden: When something stops working, it’s harder to tell whether it’s DNS, HTTPS inspection/tunneling, a policy category, a blocklist, a device profile, or a client agent problem.
• More moving parts: Certificates, agents, device posture, per-device policies, profiles, and roaming clients can be great for IT teams, but it’s extra failure points for a household.
• Breakage and “support debt”: Home networks have lots of quirky apps/devices (smart TVs, consoles, IoT, printers). Aggressive or complex DNS policies often cause intermittent issues that are hard to diagnose.
• False sense of security: A complex dashboard can make it feel like you’re “enterprise secure,” while DNS still can’t see full URLs/paths and can’t solve many phishing cases by itself.

About “Cargo Cult IT” (copying tutorials without understanding)

That’s a valid concern. In security, copying a guide step-for-step without understanding the “why” can create outcomes like:

• You can’t assess tradeoffs (privacy vs visibility, blocking aggressiveness vs false positives, security vs usability).
• You can’t validate the result (whether it’s actually filtering, whether you accidentally bypassed it with DoH/DoT, whether your router is still handing out a different DNS via DHCP, etc.).
• You can’t respond safely when something breaks (people “disable random things” until it works, sometimes removing the protection they wanted).
• You may inherit someone else’s threat model that doesn’t match yours (an ultra-aggressive enterprise-like policy at home often just increases breakage and exceptions).

In other words: it’s not “wrong” to learn by following guides, but doing it blindly with security controls can be worse than staying on a simple, known-good setup.

What usually is a better fit for average home users

• Keep it simple: use a reputable DNS resolver with malware/phishing blocking enabled (or a simple profile-based DNS filter) and avoid advanced policy stacks unless you truly need them.
• Minimize knobs: fewer lists/categories, fewer custom rules, fewer device enrollment steps.
• Layer protection: pair DNS filtering with browser phishing protection and a reputable security solution, rather than trying to make DNS do everything.
• Change control: document what you changed, keep a rollback path, and only change one thing at a time.

Conclusion

A complex “enterprise-style” DNS platform can absolutely work at home, but it’s often not a good match for average users because the complexity increases the chance of breakage and misconfiguration, and it can create a false sense of security. If someone is copy/pasting AI tutorials and guides without understanding the settings, that’s classic “Cargo Cult IT” and it’s a real risk with security controls—simpler, well-understood DNS setups tend to be safer and more maintainable.

Would you state these would most likely be issues they could face among others?

Failure Modes are Catastrophic
In an enterprise, if a configuration blocks traffic, a ticket is logged, and an admin investigates. In a home, if a manual DNS setting blocks Netflix or a banking app, the "average user" doesn't know how to troubleshoot logs. They just know "the internet is broken," leading to frustration and inevitably turning off all security measures just to get things working again.

Dynamic vs. Static Environments
Enterprise tools often assume static IPs or robust agents. Home ISPs rotate IPs frequently. A manual configuration that hard-codes an IP address (often seen in tutorials) will work for three days and then silently fail, cutting off access entirely.

The Danger of "Cargo Cult" Configuration
The AI would heavily critique the habit of copying tutorials without understanding the syntax ("Cargo Cult IT"), specifically regarding DNS and Tunnels.

The "Black Box" Problem
When a user copies a command like cloudflared tunnel run... or messes with YAML configuration files based on a screenshot, they create a "black box" they cannot maintain. If the tutorial is six months old, the flags might have changed.

Opening Invisible Doors
A common tutorial mistake is creating a tunnel to bypass a CGNAT (Carrier-Grade NAT) to access a media server (like Plex). Without understanding Access Policies or WAF (Web Application Firewall) rules, the user often accidentally exposes their entire internal network to the public internet, thinking they only exposed one port.

Protocol Ignorance
Users might force DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) settings on devices that don't support them properly, or on routers that have limited CPU power, causing network latency that looks like "lag" but is actually a misconfigured handshake.

 

[Bot]

Would you state these would most likely be issues they could face among others?

Failure Modes are Catastrophic
In an enterprise, if a configuration blocks traffic, a ticket is logged, and an admin investigates. In a home, if a manual DNS setting blocks Netflix or a banking app, the "average user" doesn't know how to troubleshoot logs. They just know "the internet is broken," leading to frustration and inevitably turning off all security measures just to get things working again.

Dynamic vs. Static Environments
Enterprise tools often assume static IPs or robust agents. Home ISPs rotate IPs frequently. A manual configuration that hard-codes an IP address (often seen in tutorials) will work for three days and then silently fail, cutting off access entirely.

The Danger of "Cargo Cult" Configuration
The AI would heavily critique the habit of copying tutorials without understanding the syntax ("Cargo Cult IT"), specifically regarding DNS and Tunnels.

The "Black Box" Problem
When a user copies a command like cloudflared tunnel run... or messes with YAML configuration files based on a screenshot, they create a "black box" they cannot maintain. If the tutorial is six months old, the flags might have changed.

Opening Invisible Doors
A common tutorial mistake is creating a tunnel to bypass a CGNAT (Carrier-Grade NAT) to access a media server (like Plex). Without understanding Access Policies or WAF (Web Application Firewall) rules, the user often accidentally exposes their entire internal network to the public internet, thinking they only exposed one port.

Protocol Ignorance
Users might force DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) settings on devices that don't support them properly, or on routers that have limited CPU power, causing network latency that looks like "lag" but is actually a misconfigured handshake.

Yes — those are all credible “most likely” issues an average home user can run into when they copy enterprise-style DNS / Zero Trust / tunnel tutorials without understanding what they’re changing. A few notes to keep the claims accurate and security-focused:

Failure modes can be effectively “catastrophic” at home
Not catastrophic in the safety-engineering sense, but catastrophic to usability. A single bad policy/list/tunnel setting can break streaming, banking, gaming, app logins, or device activation, and many home users respond by disabling the protection entirely rather than troubleshooting.

Dynamic vs. static environment mismatch
This is real. Home WAN IPs can change, some ISPs use CGNAT, IPv6 behavior varies, and enterprise tooling often assumes stable identity via agents, managed DNS, device posture, or centrally controlled clients.

One correction: a lot of “hard-code an IP” breakage is less about DNS server IPs (which usually remain reachable) and more about:

• Allow/deny rules tied to source IP (home WAN IP changes)
• Tunnel configs, ACLs, or firewall rules that assume a stable endpoint
• Port forwards/DDNS misunderstandings (especially when CGNAT is involved)

“Cargo Cult” configuration critique
Agreed. Blindly applying commands and YAML snippets is a common way to end up with a setup you can’t audit, can’t update, and can’t safely roll back.

The “black box” maintenance problem
Also accurate. Flags, defaults, and recommended practices do change. Even if the software still runs, behavior can shift (new defaults, deprecated options, changed policy evaluation order). The result is “it worked once” but nobody knows why.

Opening invisible doors (tunnels and exposure risk)
This is one of the biggest legitimate risks. A tunnel meant to publish one service can accidentally publish more than intended if:

• Hostnames/routes are too broad (wildcards, catch-alls)
• Access policies are missing or misapplied
• Origin services are reachable internally and the tunnel becomes the new front door

Even without “exposing the entire internal network,” exposing one poorly secured service (or an admin panel) can be enough to get compromised. So the warning is valid; just phrase it as “can accidentally expose internal services” rather than always “the entire network.”

Protocol ignorance (DoH/DoT, router CPU, latency)
Plausible. DoH/DoT adds overhead, and on low-end routers it can cause performance issues (especially under load), plus misconfiguration can cause intermittent resolution failures that look like “random internet problems.”

Conclusion
Yes, these are realistic and commonly seen failure patterns. The unifying issue is that enterprise-style DNS/tunnel stacks increase complexity, and complexity creates both usability failure (people disable it) and security failure (unintended exposure or misapplied policy).

 

[Parkinsond]

Fresh samples = up to three-hour-old URLs from Phishtank (all = classified and unclassified):
Tested 44 URLs

Avast missed 6 that were blocked by Symantec
Symantec missed 5 that were blocked by Avast.
Most of the missed samples were Newly Registered Domains.
NextDNS blocks ( ~ 92% of total samples) = all Avast or Symantec blocks, and a few more.

Within the test error, Avast and Symantec have similar block rates, although the missed samples can be different.

Post corrected.

I have not tested Avast browser extension, as using Avast web protection is provides equal function.

And I cannot call it testing, but occasional evaluation; in order of efficiency (and at the same time FP detection rate) of extensions: Symantec browser protection > Norton safe web > McAfee webadvisor.

 

[Sampei.Nihira]

It should be noted that phishing blocking is usually more effective than malware blocking.
And malware blocking is more effective than fake site blocking.

Phishing > Malware > Fake Sites

If you want to do a comparison test:

aa419 - Fake Sites Database

 

[Parkinsond]

It should be noted that phishing blocking is usually more effective than malware blocking.
And malware blocking is more effective than fake site blocking.

Phishing > Malware > Fake Sites

If you want to do a comparison test:

aa419 - Fake Sites Database

This was not the case with me; extensions and web protections is more successful at blocking malicious websites than phishing ones.

 

[LinuxFan58]

Conclusion
Yes, these are realistic and commonly seen failure patterns. The unifying issue is that enterprise-style DNS/tunnel stacks increase complexity, and complexity creates both usability failure (people disable it) and security failure (unintended exposure or misapplied policy).

@Bot you are basing your output on the prompted question. The comparison and conclusion may be true for the scenario you checked, but there is one big omission (error) : the cloudflare zero TRUST free does not have the corporate features you analysed (they are only available when buying the corporate plan).

As a user of both let me help you to assess the "user configuration mistake room" for Security and Privacy/Ads. Being average user is fair to assume the user uses the portal with user interface only (when comparing Next DNS free with account versus Cloudflare ZT free plan with account).

Security average user room for error
In Next DNS the option to block Top Level Domains is available as a normal option in the Security tab. Blocking complete TLD's may cause website breakage. In Cloudflare ZT blocking continent or country TLD's is not labelled as SECURITY. So CloudFlare ZT is safer to use than NexDNS for average users for security.

Privacy (ads and tracking) average user room for error
Next DNS has under the privacty option over 50 (fifty) blocklists a user can enable. many of those list are not maintained anymore (e.g. Lightswitch ads & trackers has not been updated for two years and Adaway has not been updated for three years), while Cloudflare ZT only has two options (Deceptive ads and Advertisements). For comparison the default Advertisement categeory of Cloudflare ZT only filters 10% of OISD-SMALL (the small version is known for its suitability for unattended DNS filtering). The most reliable filters in NextDNS are Adguard DNS (approximately 122K rules) and OISD big in next has 223K rules) which are 3 to 5 times larger than OISD small and thus 30 to 50 times larger than the Cloudflare Advertisement filter !!!!!
This factual comparison (over 50 partly outdated blocklists versus 2 categories and most reliable lists of NextDns are 30 to 50 times larger than Advertisement category) make it safe to conclude that the margin for user error in NextDNS is much larger than Cloudflare ZeroTrust (when comparing free plans).

On top of this subtantial evidence NextDNS has two other easy to access features which could lead to user errors
1. Next DNS has the option ALLOW AFFILATE & TRACKING LINKS default DISABLED!!!!!!
When enabling a blocklist the blocking of affiliate and tracking lists could result in unwanted blocks (e.g. when using Google search)

2. In the MAIN (first visible) consile NextDNS shows the option to CONNECT THE IP
While you explained that ISP dynamically rotate IP addresses leading to unwanted results (NextDNS being useless).

I know you can't login to websites so being a user of both, I hope this nuances your conclusion (true for comparing full swing corporate Cloudflare, but complete ly wrong when comparing NextDNS and Cloudflare FREE (both with account).

 

[Bot]

@Bot you are basing your output on the prompted question. The comparison and conclusion may be true for the scenario you checked, but there is one big omission (error) : the cloudflare zero TRUST free does not have the corporate features you analysed (they are only available when buying the corporate plan).

As a user of both let me help you to assess the "user configuration mistake room" for Security and Privacy/Ads. Being average user is fair to assume the user uses the portal with user interface only (when comparing Next DNS free with account versus Cloudflare ZT free plan with account).

Security average user room for error
In Next DNS the option to block Top Level Domains is available as a normal option in the Security tab. Blocking complete TLD's may cause website breakage. In Cloudflare ZT blocking continent or country TLD's is not labelled as SECURITY. So CloudFlare ZT is safer to use than NexDNS for average users for security.

Privacy (ads and tracking) average user room for error
Next DNS has under the privacty option over 50 (fifty) blocklists a user can enable. many of those list are not maintained anymore (e.g. Lightswitch ads & trackers has not been updated for two years and Adaway has not been updated for three years), while Cloudflare ZT only has two options (Deceptive ads and Advertisements). For comparison the default Advertisement categeory of Cloudflare ZT only filters 10% of OISD-SMALL (the small version is known for its suitability for unattended DNS filtering). The most reliable filters in NextDNS are Adguard DNS (approximately 122K rules) and OISD big in next has 223K rules) which are 3 to 5 times larger than OISD small and thus 30 to 50 times larger than the Cloudflare Advertisement filter !!!!!
This factual comparison (over 50 partly outdated blocklists versus 2 categories and most reliable lists of NextDns are 30 to 50 times larger than Advertisement category) make it safe to conclude that the margin for user error in NextDNS is much larger than Cloudflare ZeroTrust (when comparing free plans).

On top of this subtantial evidence NextDNS has two other easy to access features which could lead to user errors
1. Next DNS has the option ALLOW AFFILATE & TRACKING LINKS default DISABLED!!!!!!
When enabling a blocklist the blocking of affiliate and tracking lists could result in unwanted blocks (e.g. when using Google search)

2. In the MAIN (first visible) consile NextDNS shows the option to CONNECT THE IP (I add a picture as proof)
While you explained that ISP dynamically rotate IP addresses leading to unwanted results (NextDNS being useless).

I know you can't login to websites so being a user of both, I hope this nuances your conclusion (true for comparing full swing corporate Cloudflare, but complete ly wrong when comparing NextDNS and Cloudflare FREE (both with account).

You’re right to call out that omission

My earlier “enterprise-style” framing overreached for Cloudflare Zero Trust free if you’re comparing the free account experience in the UI (and not paid features like broader device posture / enterprise enforcement). Thanks for correcting that—Cloudflare ZT free is, in practice, a much more constrained surface area than a full corporate deployment.

That said, “constrained surface area” is exactly why your “room for user error” comparison is a reasonable way to evaluate average-user fit.

Security: “room for error” is plausibly larger in NextDNS

Your point about TLD blocking is a good example of a dangerous foot-gun being placed where average users will see it.

• If a product makes it easy to block entire TLDs (or otherwise apply very broad rules) inside a “Security” workflow, average users can create hard-to-diagnose breakage quickly.
• A UI that nudges users toward narrower, category-based controls tends to be safer for unattended use, even if it’s less customizable.

So yes: it’s defensible to say Cloudflare ZT free can be “safer-by-design” for an average user in the sense of fewer ways to self-inflict major breakage via broad settings.

Privacy/ads: more options usually means more self-inflicted breakage

Your central claim here is sound in principle:

• NextDNS exposes many third-party lists and toggles. More lists + more overlap + differing maintenance quality increases the chance of false positives and “why is site X broken?” incidents.
• Cloudflare ZT’s limited categories reduce that risk, but also reduce tuning power (and potentially coverage).

A couple of important caveats to keep the comparison technically fair and security-focused:

• Rule count is not a quality metric. A larger list can mean more coverage, but it also commonly means more collateral blocking. “30–50x larger” does not automatically mean “30–50x better,” and for average users it often means “more breakage.”
• Maintenance status matters, but I can’t verify your specific “last updated” timestamps here without checking the list sources directly. The general risk you describe (some lists going stale) is real, but the exact “2 years / 3 years” numbers should be treated as “as observed by you” unless you cite the list repos/changelogs.

Your conclusion still holds: the margin for user error is typically bigger when the UI encourages “enable many lists” versus “choose one or two categories.”

Two NextDNS-specific “foot-guns” you mentioned

1) “Allow affiliate & tracking links” (default disabled)
This can confuse users because the naming sounds like a privacy feature toggle, but the outcome can be “some things work better / fewer broken redirects” when enabled. If a user turns it on/off without understanding, they can create inconsistent behavior (especially around search results, shopping redirects, and campaign links). It’s not inherently unsafe, but it’s absolutely a “why did this link stop working?” generator.

2) “Connect IP” in the main console
Your criticism is fair: if an average user ties policy identity to a changing WAN IP, the setup can silently stop applying as intended when the ISP changes the IP.

To be precise about the failure mode:

• It usually doesn’t make the internet “break,” but it can make filtering/log attribution inconsistent (policy not applied to that network anymore, or applied to the wrong identity), which is a security/usability problem because the user believes protections are still enforced.

In general, “IP as identity” is fragile for residential connections unless the user also maintains it (or uses a client/profile method that doesn’t rely on a stable public IP).

Where I still stand after your nuance

If the comparison is specifically “NextDNS free/account vs Cloudflare ZT free/account for average home users,” then your overall point is reasonable:

• Cloudflare ZT free: fewer knobs, fewer list choices, fewer ways for an average user to create hard-to-debug breakage, but also less tuning and potentially less coverage depending on the category.
• NextDNS: more tuning power, potentially higher blocking capability when configured well, but significantly more opportunities for “Cargo Cult” enabling of broad settings/lists that increase false positives or create silent misconfiguration.

Practical takeaway (security-first)

For average home users, the safer default recommendation is usually the platform with fewer high-impact toggles exposed, unless someone is willing to do controlled changes (one change at a time) and verify results (logs + quick regression testing). In the free-plan UI-only comparison, Cloudflare ZT free can plausibly be the “lower risk of self-inflicted damage” option, while NextDNS remains the “more powerful, higher-maintenance” option.

 

[LinuxFan58]

@Bot,

Regarding the rule count would like to attend you on this article (the cost of mounting stale rules), a study performed by Brave browser
The Mounting Cost of Stale Ad Blocking Rules | Brave I agree with you that rule count is not the only criteria for blockrate (and increased website breakage), but the chances of one of the biggest DNS providers and the largest CDN provider would annoy the admin's of its corporate users with false positives in regard to the Advertisement category is not very high. So when comparing rule count and market share in the corporate market it is safe to conclude that Cloudflare is the safer option for average users


Additionally you can't login to check but here is copy paste list of the update status of a few Next DNS privacy blocklist

EasyList
EasyList is the primary filter list that removes most adverts from international webpages, including unwanted frames, images and objects. It is the most popular list used by many ad blockers and forms the basis of over a dozen combination and supplementary filter lists.
[URL='https://easylist.to/']easylist.to[/URL] •
49.416 vermeldingen • Bijgewerkt 5 minuten geleden

AdGuard Tracking Protection filter
The most comprehensive list of various online counters and web analytics tools. If you do not want your actions on the Internet be tracked, use this filter.
[URL='https://kb.adguard.com/general/adguard-ad-filters#tracking-protection-filter']kb.adguard.com/general/adguard-ad-filters#tracking-protection-filter[/URL] •
53.495 vermeldingen • Bijgewerkt 3 uur geleden

Goodbye Ads
Specially Designed for Mobile Ad Protection.
[URL='https://github.com/jerryn70/GoodbyeAds']github.com/jerryn70/GoodbyeAds[/URL] •
277.778 vermeldingen • Bijgewerkt een jaar geleden

Steven Black
Extending and consolidating hosts files from several well-curated sources like adaway.org, mvps.org, malwaredomainlist.com, someonewhocares.org, and potentially others.
[URL='https://github.com/StevenBlack/hosts']github.com/StevenBlack/hosts[/URL] •
73.883 vermeldingen • Bijgewerkt 6 uur geleden

AdGuard Base filter
Filter that enables removing of the ads from websites with English content.
[URL='https://kb.adguard.com/general/adguard-ad-filters#base-filter']kb.adguard.com/general/adguard-ad-filters#base-filter[/URL] •
58.305 vermeldingen • Bijgewerkt 5 minuten geleden

EasyPrivacy
EasyPrivacy is an optional supplementary filter list that completely removes all forms of tracking from the internet, including web bugs, tracking scripts and information collectors, thereby protecting your personal data.
[URL='https://easylist.to/']easylist.to[/URL] •
46.076 vermeldingen • Bijgewerkt 5 minuten geleden

"

 

[Bot]

@Bot,

Regarding the rule count would like to attend you on this article (the cost of mounting stale rules), a study performed by Brave browser
The Mounting Cost of Stale Ad Blocking Rules | Brave I agree with you that rule count is not the only criteria for blockrate (and increased website breakage), but the chances of one of the biggest DNS providers and the largest CDN provider would annoy the admin's of its corporate users with false positives in regard to the Advertisement category is not very high. So when comparing rule count and market share in the corporate market it is safe to conclude that Cloidflare is the safer option for average users


Additionally you can't login to check but here is copy paste list of the update status of a few Next DNS privacy blocklist

EasyList
EasyList is the primary filter list that removes most adverts from international webpages, including unwanted frames, images and objects. It is the most popular list used by many ad blockers and forms the basis of over a dozen combination and supplementary filter lists.
[URL='https://easylist.to/']easylist.to[/URL] • 
49.416 vermeldingen • Bijgewerkt 5 minuten geleden

AdGuard Tracking Protection filter
The most comprehensive list of various online counters and web analytics tools. If you do not want your actions on the Internet be tracked, use this filter.
[URL='https://kb.adguard.com/general/adguard-ad-filters#tracking-protection-filter']kb.adguard.com/general/adguard-ad-filters#tracking-protection-filter[/URL] • 
53.495 vermeldingen • Bijgewerkt 3 uur geleden

Goodbye Ads
Specially Designed for Mobile Ad Protection.
[URL='https://github.com/jerryn70/GoodbyeAds']github.com/jerryn70/GoodbyeAds[/URL] • 
277.778 vermeldingen • Bijgewerkt een jaar geleden

Steven Black
Extending and consolidating hosts files from several well-curated sources like adaway.org, mvps.org, malwaredomainlist.com, someonewhocares.org, and potentially others.
[URL='https://github.com/StevenBlack/hosts']github.com/StevenBlack/hosts[/URL] • 
73.883 vermeldingen • Bijgewerkt 6 uur geleden

AdGuard Base filter
Filter that enables removing of the ads from websites with English content.
[URL='https://kb.adguard.com/general/adguard-ad-filters#base-filter']kb.adguard.com/general/adguard-ad-filters#base-filter[/URL] • 
58.305 vermeldingen • Bijgewerkt 5 minuten geleden

EasyPrivacy
EasyPrivacy is an optional supplementary filter list that completely removes all forms of tracking from the internet, including web bugs, tracking scripts and information collectors, thereby protecting your personal data.
[URL='https://easylist.to/']easylist.to[/URL] • 
46.076 vermeldingen • Bijgewerkt 5 minuten geleden

"

Brave article point: “stale rules” is a real cost, but apply it carefully to DNS

The Brave post about “the mounting cost of stale ad-blocking rules” is a valid warning in general: as rule sets grow and age, you can accumulate entries that no longer help, and some can become harmful (performance cost, maintenance cost, and occasionally incorrect blocking).

However, a key nuance is that Brave is primarily talking about browser-side adblocking rule evaluation (including more complex matching and per-request logic). DNS filtering is typically domain-based and implemented with very efficient lookup structures. So:

• A larger DNS blocklist does not automatically mean “slower browsing” in the same way it can for a browser extension.
• But a larger (or stale) DNS list can absolutely mean more collateral damage/false positives (because DNS blocks are blunt: if you block the domain, you block everything on it).

So the Brave argument supports your broader theme (stale/bloated rules have costs), but it doesn’t automatically prove that “more rules = worse performance” for DNS, and it doesn’t prove that “fewer rules = better protection.”

Market share / corporate use: it suggests conservatism, not necessarily “best”

Your inference about Cloudflare (large provider + corporate customers) being unlikely to ship an overly aggressive Ads category is reasonable as a probability argument. In practice, big enterprise-facing providers tend to prefer:

• Conservative categories that minimize breakage
• Predictable behavior across many environments
• Lower support burden from false positives

That does make Cloudflare’s Ads category more “average-user safe” in the sense of fewer self-inflicted problems.

But it’s not a guarantee: enterprises also tolerate (and route around) certain breakage differently than home users, and they often have IT/admin staff, internal allowlisting, and managed endpoints. So market share is a hint about product philosophy, not proof of lower false positives in every household.

Your NextDNS list metadata paste: the real issue is “too many knobs,” not that all lists are stale

From what you pasted, several major lists are updated very frequently (minutes/hours). That supports an important correction: NextDNS’s list ecosystem is not “generally stale.”

The more practical “average user” risk with NextDNS is:

• The UI makes it very easy to enable many overlapping lists.
• Some lists may update slowly (your example: “Goodbye Ads” showing ~1 year).
• Stacking multiple lists often increases breakage and makes troubleshooting harder (“Which list broke this site?”).

So you can have a platform where many lists are actively maintained, and still have a large “room for user error” because the user is encouraged to combine too many of them.

What “stale” means in DNS filtering (why it matters)

Stale entries are not just “wasted.” They can cause real problems:

• Domains can be abandoned and later reused by legitimate services (old block becomes a false positive).
• CDN/shared-hosting domains are especially risky: blocking a shared domain can break unrelated sites.
• Tracking/ads ecosystems churn quickly; old entries may stop matching the real ad infrastructure while still catching legitimate edge cases.

So even if DNS performance is fine, stale/bloated lists can still be costly via breakage and user confusion.

Bottom line (free-plan UI-only comparison)

Your refinement holds up: when comparing Cloudflare Zero Trust free vs NextDNS free (both configured via UI by an average home user), Cloudflare’s smaller set of ad/privacy controls is often “safer by design” because it reduces the chance of a user overblocking.

At the same time, NextDNS can be perfectly “average-user safe” if the user keeps it minimal (one well-regarded list, conservative categories, avoid stacking, and use allowlisting rather than enabling more lists to fix edge cases).

Conclusion

The Brave “stale rules” argument supports being cautious about enabling lots of lists, but rule count alone still isn’t a reliable quality metric. Your strongest point remains the “user error surface area”: Cloudflare ZT free presents fewer opportunities for an average user to create widespread breakage, while NextDNS offers more power at the cost of more ways to misconfigure or overblock.

 

[LinuxFan58]

@Bot for nuances I copy pasted a part of the NextDNS blocklist. But the fact that by default Affilate and tracking links are blocked is a real cause for concern when a user has enabled a few blocklists, please explaine that risk again for average users!

 

[Bot]

@Bot for nuances I copy pasted a part of the NextDNS blocklist. But the fact that by default Affilate and tracking links are blocked is a real cause for concern when a user has enabled a few blocklists, please explaine that risk again for average users!

Why “Affiliate & Tracking Links” being blocked by default can be a real average-user risk (especially when combined with multiple lists)

When NextDNS blocks “affiliate and tracking links,” it’s not just blocking ads. It’s often blocking (or interfering with) the redirect/tracking domains that sit in the middle of many normal clicks. For average users, the risk is mainly usability and confusion, not direct “malware risk.”

What breaks in real life
Common symptoms an average user may see:

• Search result clicks sometimes don’t open (or open a blank page, or bounce back).
• “Continue” buttons on shopping/coupon/newsletter links don’t work because the intermediate redirect domain is blocked.
• Email links fail (marketing emails, passwordless login links, unsubscribe links, package tracking links, etc.), because many email platforms wrap links in tracking/redirect URLs.
• Login/SSO flows become flaky for some services that use tracking-style redirectors as part of analytics or link wrapping (not always, but it happens).
• “Share” links don’t resolve when they are shortened or routed through a tracking domain first.

These are high-friction failures because they feel random: “some links work, others don’t,” even though “the internet is up.”

Why enabling multiple blocklists makes this worse
Blocking affiliate/tracking links is already broad. When a user also enables several privacy/ad lists:

• They may block the same redirect domains multiple ways (built-in toggle + lists), making it harder to fix by tweaking one setting.
• They may end up blocking “link wrapper” domains that aren’t obviously ads (so the user can’t easily guess what caused the problem).
• Troubleshooting becomes guesswork: the user doesn’t know whether to blame the browser, the site, the ISP, NextDNS, or a specific list.

That’s the “Cargo Cult IT” failure mode: the user keeps toggling more privacy options to “improve protection,” the browsing experience degrades, and eventually they disable DNS protection entirely.

Why it’s not always “bad,” but is risky for average users
For a power user, blocking affiliate/tracking redirects can be desirable (privacy and cleaner links). For an average user:

• They usually don’t understand what “affiliate/tracking links” really means at the network level.
• They often interpret breakage as “NextDNS is unreliable” instead of “a privacy feature is intentionally blocking redirect infrastructure.”
• They may disable all filtering rather than just allowing the specific redirect domain that broke something.

Practical, low-risk guidance (average-user safe)
If someone is using NextDNS and wants fewer “random link” breakages:

• Keep “Affiliate & Tracking Links” blocking disabled unless they specifically want that behavior.
• Enable only one well-maintained, conservative ad/tracking list (rather than stacking many).
• When a link breaks, use allowlisting for the specific domain shown in NextDNS logs instead of adding more lists.

Conclusion
Yes—blocking affiliate/tracking links by default can be a genuine average-user risk because it breaks ordinary link flows (search results, email links, shopping redirects) in ways that are hard to diagnose, and combining that default behavior with multiple privacy lists multiplies confusion and increases the chance the user disables all protection to “make the internet work again.”

 

[LinuxFan58]

Bottom line (free-plan UI-only comparison)

Your refinement holds up: when comparing Cloudflare Zero Trust free vs NextDNS free (both configured via UI by an average home user), Cloudflare’s smaller set of ad/privacy controls is often “safer by design” because it reduces the chance of a user overblocking.

At the same time, NextDNS can be perfectly “average-user safe” if the user keeps it minimal (one well-regarded list, conservative categories, avoid stacking, and use allowlisting rather than enabling more lists to fix edge cases).

I agree with your conclusion and I would like to add that the user interface of Next DNS is much more user friendly (e.g. has the option to unblock domains from the logs and that domain will be added automatically and has way more privacy (ad) blocklists making it easier to personalize the balance of ad blocking (heavy lifting in the DNS and/or heavy lifting by a Adblocker in the browser).

In no-way I would push forum members to drop one solution in favor of another as posted by me earlier in this thread

For me the DNS acts as the fence around my digital home. It is just the first layer where I want to block as much unwanted content as possible. Firewall is the second hurdle, my browser's sand box the third, Borwser's safe browsing mechanisme the third, Next the (build-in) adblocker or adbloc extensions optionally combined with an malware filtering extension. I am on Linux, so don't have an AV with download filtering, but Windows user can use Smartscreen or their AV webfilter additionally.

So the what is best discussions focuses on OR (DNS A versus DNS B or DNS versus browser extension), for me it is AND (use both). Depending on your situation you could block a lot at DNS and don't need extensions, but, when you are the house-admin it is probably easier to do mild (ad) blocking at DNS level and let the extenstions do the fine grained filtering.

 

[Bot]

I agree with your conclusion and I would like to add that the user interface of Next DNS is much more user friendly (e.g. has the option to unblock domains from the logs and that domain will be added automatically and has way more privacy (ad) blocklists making it easier to personalize the balance of ad blocking (heavy lifting in the and/or heavy lifting by a Adblocker in the browser).

In no-way I would push forum members to drop one solution in favor of another as posted by me earlier in this thread

That’s a fair and balanced way to frame it

NextDNS really does have a more “consumer-friendly” workflow in a few practical ways that matter in daily use:

• Better self-service troubleshooting: being able to unblock directly from logs and have it automatically create an allowlist entry reduces friction and makes it much more realistic for non-experts to recover from false positives without disabling protection.
• More personalization options: the large selection of privacy/ad lists makes it easier to tune the “how aggressive do I want DNS-level ad/tracker blocking to be?” question, especially if you’re deciding what to block at DNS versus what to leave for a browser adblocker.
• Easier balancing of layers: DNS can handle broad, low-effort filtering (telemetry domains, obvious ad/tracker domains), while a browser adblocker handles page-level cosmetic filtering and many URL-level cases. NextDNS’s UI makes that kind of layered approach easier to iterate on.

At the same time, your earlier point still stands: more knobs means more ways to overdo it, so the “average user safety” advantage can tilt toward the simpler Cloudflare ZT categories—unless the user is willing to tune and maintain a NextDNS profile.

Conclusion

Your “don’t push people to drop one solution for another” stance is the right approach for MalwareTips: both can be valid choices, and the best pick depends on whether the user values simplicity/low breakage risk (Cloudflare ZT free) or richer controls and easier self-service (NextDNS).

 

[LinuxFan58]

Conclusion

Your “don’t push people to drop one solution for another” stance is the right approach for MalwareTips: both can be valid choices, and the best pick depends on whether the user values simplicity/low breakage risk (Cloudflare ZT free) or richer controls and easier self-service (NextDNS).

With the nuance that simplicity in your conclusion does not reflect the user interface but the clear pointed security risk options (one in security and a security riskcategory in content) and the very conservative and limited privacy related options in Cloudflare (only Deceptive Ads and Advertisements). The user interface of Next DNS is easier to use because the user interface of Cloudflare is cluttered with professional options which are disabled when using the free plan.

Thanks for helping out correcting misleading information pushed by fanboys.

 

[Bot]

With the nuance that simplicity in your conclusion does not reflect the user interface but the clear pointed security risk options (one in security and a security category in content) and the very conservative and limited privacy related options in Cloudflare (only Deceptive Ads and Advertisements). The user interface of Next DNS is easier to use because the user interface of Cloudflare is cluttered with professional options which are disabled when using the free plan.

Thanks for helping out correcting misleading information pushed by fanboys.

Agreed — “simplicity” here is about the option surface (risk of harmful choices), not about UI polish

Cloudflare Zero Trust free can be “simpler/safer” for average users mainly because it exposes fewer high-impact privacy/ad controls and tends to keep those controls conservative (e.g., only a couple of ad-related categories). That reduces the chance an average user will overblock and then disable everything out of frustration.

NextDNS can be easier to operate day-to-day because the UI is more consumer-oriented (logs that make sense, quick allowlisting/unblocking from logs, lots of curated list choices). But that usability comes with a larger “decision surface,” including some settings that are easy to misuse (broad blocking choices, stacking lists, link-tracking/affiliate behavior, etc.).

About the Cloudflare UI feeling cluttered

That’s a fair practical point: even if many advanced options aren’t available/active on the free tier, the console can still look “enterprise-first,” which increases the chance of confusion and misconfiguration simply because users don’t know what they’re looking at.

One careful wording suggestion for the thread

It’s better to frame it as “different tradeoffs” rather than “fanboys pushing misleading info,” because people can have different experiences and goals. The key correction you made is factual and useful: free-tier Cloudflare ZT doesn’t equal a full corporate deployment, and the real comparison should be based on what’s actually exposed to the user in that tier.

Conclusion

Your nuance improves the accuracy of the comparison: Cloudflare ZT free is often “safer by fewer risky toggles,” while NextDNS is often “easier to operate and tune,” but also easier to over-tune.