New Update NextDNS adds several new Early Access security features

[Brahman]

Ai generated:

NextDNS has introduced several new Early Access security options under the Security tab. These are aimed at blocking infrastructure that is commonly abused for phishing, malware, command-and-control traffic, data exfiltration and bypassing traditional security controls.
Free Hosting Domains blocks free hosting subdomains such as *.pages.dev, *.vercel.app and *.netlify.app, which are frequently abused to host phishing and malicious content. Legitimate websites using these platforms with their own custom domain names should not be affected.
Tunneling Endpoints blocks domains associated with tunneling services such as ngrok and Cloudflare Tunnel. While these services are perfectly legitimate, attackers often use them to expose phishing pages or malicious servers to the Internet.
Data Drop Services blocks services that can be used to exchange or collect data. These can be abused by malware for command-and-control communication and data exfiltration, although there are legitimate uses for these services as well.
Residential Hosting blocks domains that resolve to residential IP ranges. Compromised home connections and residential proxies are increasingly used to host phishing sites, malware infrastructure and C2 servers.
Decentralized Web Gateways blocks public gateways that provide access to decentralized networks such as IPFS. These gateways have legitimate uses, but can also be abused to host content that is difficult to take down or block.​

 

[Jonny Quest]

@Brahman thanks for the heads up
At this point, is where I support them for $20. even though I never hit my 300,000 free quire limit.

edit: done

 

[TairikuOkami]

So much for NextDNS doing nothing. They focus on the development, not social interactions.
As an introvert, I completely relate. I wanted to buy a special dish available once a year, but ...

 

[Bot]

Ai generated:

View attachment 299926
View attachment 299927​

Hi, these look like useful high-risk infrastructure filters, but I would not enable all five blindly—especially on a household profile where legitimate development, file-sharing or remote-access services may be used.

What they add in practice​

The important distinction is that these options block categories of infrastructure, not malicious content confirmed on each domain. That can stop a newly created phishing or command-and-control address before conventional reputation lists catch up, but it inevitably increases the chance of blocking legitimate services.

• Free Hosting Domains: probably the most broadly useful against disposable phishing pages. It may also break legitimate `pages.dev`, `vercel.app` and `netlify.app` sites using their provider subdomain; custom domains are a separate case according to the shown description.
• Tunneling Endpoints: a strong choice for ordinary home users who never use ngrok, Cloudflare Tunnel or similar tools. Developers and remote-access users should expect friction.
• Data Drop Services: potentially the noisiest category because webhooks, text/file sharing and configuration services have plenty of legitimate uses.
• Residential Hosting: potentially useful against infrastructure running behind residential connections, but DNS categorisation of this sort deserves observation during Early Access.
• Decentralized Web Gateways: sensible if nobody needs IPFS or another decentralized-web gateway.

A sensible rollout​

I would enable them one at a time, then watch the NextDNS logs for blocked requests and actual breakage:

1. Start with Free Hosting Domains and Decentralized Web Gateways.
2. Add Tunneling Endpoints if nobody uses tunneling or self-hosted remote access.
3. Try Residential Hosting, while watching for services that unexpectedly stop resolving.
4. Leave Data Drop Services until last because its legitimate-use surface appears broader.

If something breaks, the log should identify the queried domain and the blocking category. Allowlist only the specific domain after confirming that it belongs to the intended service; turning off the whole category is the blunter fix.

These controls are useful defence in depth, not substitutes for browser anti-phishing, endpoint protection or sensible account security. DNS filtering can block a hostname, but it cannot inspect every URL path, decide whether content on an allowed shared platform is malicious, or undo access through an already permitted domain.

Early Access is the operative phrase​

The screenshots establish that the options are present and show NextDNS's descriptions, but they do not provide detection rates or false-positive measurements. Claims such as “heavily abused” should therefore be read as the provider's rationale, not as evidence that every address in the category is dangerous.

For technically quiet home networks, enabling most of these may be worthwhile. For developers, businesses, or anyone using webhooks, tunnels and hosted preview sites, staged testing is the better approach. Infrastructure can be dual-use; apparently the Internet neglected to colour-code the malicious half.

 

[Jonny Quest]

Hi, these look like useful high-risk infrastructure filters, but I would not enable all five blindly—especially on a household profile where legitimate development, file-sharing or remote-access services may be used.

What they add in practice​

The important distinction is that these options block categories of infrastructure, not malicious content confirmed on each domain. That can stop a newly created phishing or command-and-control address before conventional reputation lists catch up, but it inevitably increases the chance of blocking legitimate services.

• Free Hosting Domains: probably the most broadly useful against disposable phishing pages. It may also break legitimate `pages.dev`, `vercel.app` and `netlify.app` sites using their provider subdomain; custom domains are a separate case according to the shown description.
• Tunneling Endpoints: a strong choice for ordinary home users who never use ngrok, Cloudflare Tunnel or similar tools. Developers and remote-access users should expect friction.
• Data Drop Services: potentially the noisiest category because webhooks, text/file sharing and configuration services have plenty of legitimate uses.
• Residential Hosting: potentially useful against infrastructure running behind residential connections, but DNS categorisation of this sort deserves observation during Early Access.
• Decentralized Web Gateways: sensible if nobody needs IPFS or another decentralized-web gateway.

A sensible rollout​

I would enable them one at a time, then watch the NextDNS logs for blocked requests and actual breakage:

1. Start with Free Hosting Domains and Decentralized Web Gateways.
2. Add Tunneling Endpoints if nobody uses tunneling or self-hosted remote access.
3. Try Residential Hosting, while watching for services that unexpectedly stop resolving.
4. Leave Data Drop Services until last because its legitimate-use surface appears broader.

If something breaks, the log should identify the queried domain and the blocking category. Allowlist only the specific domain after confirming that it belongs to the intended service; turning off the whole category is the blunter fix.

These controls are useful defence in depth, not substitutes for browser anti-phishing, endpoint protection or sensible account security. DNS filtering can block a hostname, but it cannot inspect every URL path, decide whether content on an allowed shared platform is malicious, or undo access through an already permitted domain.

Early Access is the operative phrase​

The screenshots establish that the options are present and show NextDNS's descriptions, but they do not provide detection rates or false-positive measurements. Claims such as “heavily abused” should therefore be read as the provider's rationale, not as evidence that every address in the category is dangerous.

For technically quiet home networks, enabling most of these may be worthwhile. For developers, businesses, or anyone using webhooks, tunnels and hosted preview sites, staged testing is the better approach. Infrastructure can be dual-use; apparently the Internet neglected to colour-code the malicious half.

Thanks Bot, as that was my thought, too. Which ones to enable and why.

 

[Bot]

Thanks Bot, as that was my thought, too. Which ones to enable and why.

For a typical home setup, I’d start with:

• Free Hosting Domains — useful against disposable phishing sites, though it may block legitimate projects on provider subdomains.
• Decentralized Web Gateways — low-impact if you never use IPFS.
• Tunneling Endpoints — enable if nobody uses ngrok, Cloudflare Tunnel or similar developer/remote-access tools.

I’d test Residential Hosting separately and leave Data Drop Services until last, since legitimate webhooks and sharing services make that category more likely to cause surprises.

Enable one category at a time and check the NextDNS log if anything stops working. That makes the culprit obvious and lets you allowlist one verified domain instead of disabling the whole category. Early Access is a good place for measured enthusiasm rather than clicking every shiny switch.

 

[Sampei.Nihira]

OK.
Enabled on the PC:

• Free Hosting Domains
• Decentralized Web Gateways
• Tunneling Endpoints

and disabled:

• Residential Hosting
• Data Drop Services

@Bot,do you recommend the same setup for my Android smartphone, or would you suggest a different one?

P.S.

@Bot

Could you answer my question?

 

[Sampei.Nihira]

@Bot
Could you take a look at the previous thread and kindly reply?
Thank you.

 

[Bot]

@Bot
Could you take a look at the previous thread and kindly reply?
Thank you.

Yes, I’d use the same three enabled categories on Android as a sensible starting point:

• Free Hosting Domains
• Decentralized Web Gateways
• Tunneling Endpoints

The operating system does not materially change what those DNS categories block. What matters is which apps and services the phone uses. The main Android-specific caution is Tunneling Endpoints: work/VPN, remote-access, development or self-hosting apps may legitimately depend on such infrastructure. If you use any of those, test them after enabling it.

I’d still leave these disabled initially:

• Data Drop Services — mobile apps may use legitimate sharing, webhook or upload services.
• Residential Hosting — broader category with more potential for unexpected breakage while it remains Early Access.

Use the phone normally for a few days and inspect the NextDNS log if an app fails. The blocked category and domain should help identify the cause; allowlist a domain only after confirming it belongs to the expected app or service. No need to make Android stricter merely because it is a phone.