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

[ForgottenSeer 123960]

So the Suricata setup in a Linux VM on a Chromebook is a absurdism not for home use? Why did you label it a beginners guide?

Are you deliberately playing dumb, or do you actually not understand how education works?

'Beginner' refers to the Curriculum Level, not the Deployment Environment.

If I write a 'Beginner's Guide to Forensic Autopsy,' I am teaching students the basics of pathology. I am not suggesting they dig up their backyard to practice on the weekend.

My Suricata guide is a textbook for learning network anatomy. My NextDNS advice is a protocol for securing a home network.

One is a classroom lesson, the other is a production strategy. If you can't separate the 'University Lab' from the 'Living Room,' you are proving exactly why complex tools shouldn't be in your hands.

 

[LinuxFan58]

Are you deliberately playing dumb, or do you actually not understand how education works?

If I write a 'Beginner's Guide to Forensic Autopsy,' I am teaching students the basics of pathology. I am not suggesting they dig up their backyard to practice on the weekend.

From your point of view it may be clear, but for instance the comparison above is confusing: I don't have corpses in my back yard.

 

[Andy Ful]

Most of the 'advanced' crowd you’re referencing are just effectively parsing a community guide or an AI-generated script. That’s not expertise, that’s obedience.

I do not expect expertise from advanced users, but rather experience in how to avoid trouble and how to troubleshoot when having a problem.
By saying that "CZT is for advanced users," I had in mind that it should not be recommended to most users.
As you noticed, using CZT does not make anyone an advanced user. However, advanced users won't suffer when using it. Others will most probably be unhappy or will require some help from the advanced user when configuring CZT. Some users can make simple configurations based on available videos.

I think that there is no need to discourage MT readers from using CZT. Its complexity can do it better.

 

[rashmi]

Damn, this thread's like... "Har team mein sirf ek hi gunda ho sakta hai... Aur is team ka gunda main hoon!" ("There can only be one gangster in every thread... And I'm the gangster of this thread!")

 

[Templarware]

I use none of the above, since a short while ago I started using DNS4.eu. So far I like it. (The protective + adblocking version.)

DNS4EU For Public

Discover comprehensive information on the DNS4EU public resolver services. Compare available options, learn about features, and find answers to frequently asked questions to optimize your DNS privacy and performance

www.joindns4.eu

Is DNS4.eu better than Control D free - Hagezi Pro Plus?

 

[Morro]

I have never tried ControlD, so I cannot say, sorry.

 

[ForgottenSeer 123960]

I do not expect expertise from advanced users, but rather experience in how to avoid trouble and how to troubleshoot when having a problem.
By saying that "CZT is for advanced users," I had in mind that it should not be recommended to most users.
As you noticed, using CZT does not make anyone an advanced user. However, advanced users won't suffer when using it. Others will most probably be unhappy or will require some help from the advanced user when configuring CZT. Some users can make simple configurations based on available videos.

I think that there is no need to discourage MT readers from using CZT. Its complexity can do it better.

You are defining 'Experience' as 'Pain Tolerance.' That is a critical error.

You argue that we shouldn't discourage users from using Cloudflare Zero Trust because 'its complexity can do it better.' Better at what? Generating support tickets?

In security engineering, complexity is not a feature, it is surface area. Every unnecessary policy, tunnel, and configuration knob is a potential point of failure. You admit that non-advanced users will 'most probably be unhappy' or 'require help.'

If a solution requires a user to be 'advanced' just to avoid being miserable, it is a bad recommendation for a general thread. True experience isn't demonstrated by how well you troubleshoot a broken system; it's demonstrated by choosing a system that doesn't break.

NextDNS isn't 'lesser' because it's simple. It's superior because it achieves the same perimeter denial without turning the user into a part-time sysadmin.

 

[Andy Ful]

Divergent,​

I explained how you should understand my words in my previous post. The semantic discussion of the correctness of every word is off topic here and useless because most posters on MT are not native English speakers. So, let's continue on topic posts about DNS providers for home users.

@Bot, could you make a very short summary of this thread? Please include as little information as possible about Cloudflare Zero Trust, because most users will not use it at all.

 

[Bot]

Divergent,​

I explained how you should understand my words in my previous post. The semantic discussion of the correctness of every word is off topic here and useless because most posters on MT are not native English speakers. So, let's continue on topic posts about DNS providers for home users.

@Bot, could you make a very short summary of this thread? Please include as little information as possible about Cloudflare Zero Trust, because most users will not use it at all.

Very short thread summary (minimal CZT details)

• The thread centers on which DNS-based filtering options make sense for home users, and how much protection DNS provides compared to browser-level blockers (example given: DNS ~30% vs uBlock/AdGuard ~70%).
• Several DNS options and blocklists are discussed or referenced, including NextDNS, ControlD (with HaGezi lists), and DNS4.eu (protective/adblocking).
• There is disagreement about how to label and recommend more complex networking/security tooling for typical home users, including confusion over what “beginner guide” means (learning material vs practical home deployment).
• The practical takeaway most posters converge on is that simpler, easier-to-maintain DNS filtering plus a good browser content blocker is generally the most realistic setup for most home users.

Conclusion: The main value of the thread is comparing home-appropriate DNS providers/blocklists and reinforcing that browser-level blocking usually carries a large share of day-to-day protection.

 

[Templarware]

I have never tried ControlD, so I cannot say, sorry.

In this case it's just the Hagezi Pro Plus filter, it could as well be NextDNS.

 

[ForgottenSeer 123960]

Very short thread summary (minimal CZT details)

• The practical takeaway most posters converge on is that simpler, easier-to-maintain DNS filtering plus a good browser content blocker is generally the most realistic setup for most home users.

Couldn't agree more bot thank you.

 

[Bot]

Couldn't agree more bot thank you.

You’re welcome.

Key takeaway stands: for most home users, a solid DNS filter + a good browser content blocker gives the best “protection-to-hassle” ratio, with far fewer failure points than more complex setups.

 

[Andy Ful]

@Bot,

Could you make a short summary of the DNS resolvers' effectiveness against phishing? Include info about free products vs. paid ones.

 

[Bot]

@Bot,

Could you make a short summary of the DNS resolvers' effectiveness against phishing? Include info about free products vs. paid ones.

DNS resolvers vs phishing (short summary)

What DNS can do (and why it helps)
DNS filtering can block access to known (or newly identified) phishing domains by returning NXDOMAIN/blocked responses before the browser connects. This is useful because it works for every app/device on the network and can stop “accidental clicks” early.

Why DNS is never “complete” anti-phishing

• DNS only sees the domain name, not the full URL path. Many phishing campaigns live on compromised legitimate domains or use benign hosting/CDNs where blocking the entire domain would cause heavy collateral damage.
• Phishing infrastructure changes fast (new domains, short-lived subdomains), so coverage depends heavily on threat-intel sources and update speed.
• Some phishing is delivered via services that are hard to block safely at the domain level (URL shorteners, free site hosts, shared platforms).

What mainly determines “effectiveness”

• Threat-intel quality and freshness (how quickly new phishing domains get added).
• Policy aggressiveness (more blocking can mean more false positives/breakage).
• Ability to do per-device/per-user policy and quick allowlisting when something is blocked incorrectly.
• Transparency and controls (logs, block reason, easy overrides).

Free vs paid: typical differences

Free public resolvers (often “set-and-forget”)

• Pros: simple, no account, low maintenance, decent baseline protection if they include phishing categories.
• Cons: usually minimal customization, limited/no per-device controls, limited visibility (no logs), and no support/SLA.

Free “custom list” setups (e.g., using reputable community lists on a service that supports them)

• Pros: can be very strong against known bad domains (including many phishing domains) if the lists are well-maintained.
• Cons: still fundamentally list-driven; coverage depends on list update cadence; troubleshooting can be harder without good logs/overrides.

Paid DNS filtering services

• Pros: typically better control (profiles, categories like “phishing”, per-device policies), better troubleshooting (query logs + block reason), and faster recovery (easy allowlist). Some also offer broader threat-intel integration and more responsive updates/support.
• Cons: cost, and sometimes more complexity (more knobs = more chances to misconfigure).

Practical takeaway
DNS filtering is a good anti-phishing “first net,” but it’s not a standalone solution. For best results, pair DNS filtering with browser protections (phishing protection / safe browsing) and a good content blocker—then use DNS logs/allowlists (typically a paid feature) to quickly fix false positives.

 

[Marko :)]

Is DNS4.eu better than Control D free - Hagezi Pro Plus?

I doubt it.

 

[Andy Ful]

Practical takeaway
DNS filtering is a good anti-phishing “first net,” but it’s not a standalone solution. For best results, pair DNS filtering with browser protections (phishing protection / safe browsing) and a good content blocker—then use DNS logs/allowlists (typically a paid feature) to quickly fix false positives.

I tested NextDNS (free personal account, customized for security). It includes almost all blocks of a very good web browser extension: "Avast Online Security & Privacy". Is there somewhere information that advanced NextDNS features include Avast API? From the documentation, I know that NextDNS advanced features include Google Safe Browsing.

 

[Bot]

I tested NextDNS (free personal account, customized for security). It includes almost all blocks of a very good web browser extension: "Avast Online Security & Privacy". Is there somewhere information that advanced NextDNS features include Avast API? From the documentation, I know that NextDNS advanced features include Google Safe Browsing.

No public evidence that NextDNS “advanced features” use an Avast API

NextDNS publicly documents/labels at least one upstream source in the UI/features: Google Safe Browsing. NextDNS staff have also clarified that their GSB integration is domain-based (DNS can’t evaluate full URL paths). ([help.nextdns.io](https://help.nextdns.io/t/m1hly35/google-safe-browsing?utm_source=openai))

For Threat Intelligence Feeds (TIF), the situation is different: NextDNS has internalized that component, meaning the sources are no longer publicly visible in their metadata repository. ([github.com](https://github.com/nextdns/metadata/))

Because of that internalization, I’m not aware of any official/public documentation showing that NextDNS’s “advanced/security” features include Avast TI/API specifically (and the public materials above don’t confirm it).

Why your blocks may look similar to Avast Online Security

• You may be seeing overlap from shared/common sources (especially Google Safe Browsing, and widely-used public phishing feeds/lists), rather than a direct Avast integration. ([help.nextdns.io](https://help.nextdns.io/t/m1hly35/google-safe-browsing?utm_source=openai))
• Also, some “same result” comparisons are misleading because browser extensions can work at full URL level while DNS filtering is mostly domain-level.

What you can do in practice

• Use the NextDNS Logs “Blocked by …” reason to confirm whether a domain was blocked by Google Safe Browsing vs Threat Intelligence Feeds vs a configured blocklist. (This won’t prove Avast, but it will pinpoint the NextDNS module involved.)
• If it’s blocked by Threat Intelligence Feeds and looks wrong, the safe path is to allowlist the specific domain (if you’re confident it’s legitimate) and report it to NextDNS support/community—since the upstream TIF sources are not public anymore. ([github.com](https://github.com/nextdns/metadata/))

Conclusion: based on what’s publicly available, you can confirm NextDNS uses Google Safe Browsing, but you can’t verify an Avast API/source for NextDNS TIF because that part is internalized and not documented publicly. ([help.nextdns.io](https://help.nextdns.io/t/m1hly35/google-safe-browsing?utm_source=openai))

 

[Andy Ful]

Why your blocks may look similar to Avast Online Security

• You may be seeing overlap from shared/common sources (especially Google Safe Browsing, and widely-used public phishing feeds/lists), rather than a direct Avast integration. ([help.nextdns.io](https://help.nextdns.io/t/m1hly35/google-safe-browsing?utm_source=openai))
• Also, some “same result” comparisons are misleading because browser extensions can work at full URL level while DNS filtering is mostly domain-level.

The blocks do not look similar, but they are almost the same. Furthermore, the missed samples by NextDNS are also missed by Avast.
The test was conducted on many half-hour-old samples from PhishTank. Almost all such samples were unclassified during the test. The blocks cannot overlap much with shared/common sources.

Thanks for the clarification. I also would not confirm that NextDNS can use the Avast API.
However, it is interesting that tweaked NextDNS can block about 90% of half-hour-old (unclassified) samples from PhishTank, while the best free anti-phishing web browser extension from Avast can block about 80%.

 

[Bot]

The blocks do not look similar, but they are almost the same. Furthermore, the missed samples by NextDNS are also missed by Avast.
The test was conducted on many half-hour-old samples from PhishTank. Almost all such samples were unclassified during the test. The blocks cannot overlap much with shared/common sources.

Thanks for the clarification. I also would not confirm that NextDNS can use the Avast API.
However, it is interesting that tweaked NextDNS can block about 90% of half-hour-old samples from PhishTank, while the best free anti-phishing web browser extension from Avast can block about 80%.

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.
• 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.
• 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).

How to validate what NextDNS is actually using (without guessing)

• In NextDNS Logs, check the “Blocked by …” reason for each blocked domain and tally the sources (for example: “Google Safe Browsing” vs “Threat Intelligence Feeds” vs your enabled blocklists). This is the closest you’ll get to attribution from the product side.
• Re-test by extracting and de-duplicating domains from your PhishTank URL set first. This avoids “URL volume” inflating what is actually “domain coverage.”
• Time-slice testing (e.g., at +30 min, +2h, +24h) helps show whether you’re seeing a fast intel source (often GSB-like behavior) or slower list-driven coverage.

About the “90% vs 80%” result

That difference can happen, but it’s hard to generalize from it because DNS filtering and browser extensions don’t operate on the same signals (DNS = domain-level, extension = can be URL/content/JS-based). I also can’t confirm the claim that a specific Avast extension is the “best” free anti-phishing extension in general; that tends to vary by test methodology and time window.

Conclusion: the safest interpretation is “your tuned NextDNS profile is performing very well on your dataset,” but similarity to Avast results still isn’t evidence of an Avast API feed; the actionable next step is to use NextDNS log attribution (“Blocked by…”) plus domain de-duplication to confirm what’s actually driving the blocks.

 

[Parkinsond]

while the best free anti-phishing web browser extension from Avast can block about 80%

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