nextdns VS Unbound

I've been using nextdns a lot for the past few months, and it's been great.

you do not need any kind of special hardware for a DNS adblocker. Personally I just use nextDNS - it's pretty quick to setup - though some of it's adblock lists block access to the app store, so you have to whitelist that or just turn it off when you want to download a new app.

Maybe use a DNS provider that filters? https://nextdns.io Google DNS may do this too, but I’m not sure

Pi-hole (with every reasonable blocklist I can find) protects me from many of these domains. NextDNS would be another option for DNS-based blocking for people who don't want to administer it themselves. I also plan to use DNSTwist to generate additional blocklists for typo-based phishing that I can plug into the Pi-hole for important sites.

I use nextdns.io for this reason,and it has a handy app for ios/android so you can even force it on there for when he's smart enough to use a hotspot or WIFI at a friends house. It's totally worth the 1,99 per month and provides TONS of options

NextDNS CLI - https://github.com/nextdns/nextdns/wiki/UnifiOS

Private DNS suggestions: Quad9: dns.quad9.net Cloudflare: security.cloudflare-dns.com AdGuard: dns.adguard-dns.com NextDNS: (visit https://nextdns.io/)

Also, keep in mind, unless your dns is encrypted your isp can see it. A good way to illustrate this is with something like https://www.dnsleaktest.com I personally use nextdns so that I can block ads etc, but quad9 would be a good choice too. https://www.dnsleaktest.com https://nextdns.io

telefon: * Firefox + uBlock Origin * NextDNS * LibreTube zamiast Youtuba

Version 1.15.0 Configure line: --with-libexpat=/usr/local --with-ssl=/usr --disable-dnscrypt --disable-dnstap --with-libnghttp2 --enable-ecdsa --disable-event-api --enable-gost --with-libevent --with-pythonmodule=yes --with-pyunbound=yes ac_cv_path_SWIG=/usr/local/bin/swig LDFLAGS=-L/usr/local/lib --disable-subnet --disable-tfo-client --disable-tfo-server --with-pthreads --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/share/info/ --build=amd64-portbld-freebsd12.3 Linked libs: libevent 2.1.12-stable (it uses kqueue), OpenSSL 1.1.1n-freebsd 15 Mar 2022 Linked modules: dns64 python respip validator iterator BSD licensed, see LICENSE in source package for details. Report bugs to [email protected] or https://github.com/NLnetLabs/unbound/issues

Unbound DNS

Many users (myself included) opt to leave out third party resolvers entirely and deploy a local recursive nameserver. I use Unbound. In the default recursive operation it queries the root nameservers directly, with responses validated using DNSSEC. So there's no potential of a third party upstream providing incorrect records, either accidentally or deliberately, and no one server gets the opportunity to log the full path of your resolution chain. Your ISP, Cloudflare, Google, OpenDNS or whatever may super duper pinkie promise not to log your resolution history or use it for whatever purpose, but why give them the opportunity to?

The next logical step in this chain usually looks something like "OK, so my queries and their responses are secure, but why do I trust [my ISP/this third party/this faceless megacorporation] exactly?", and...honetly, you shouldn't. One or two more questions and the next thing you know you're running your own full recursive resolver stack.

I wasn't personally particularly happy with any one provider's offering, and didn't want to needlessly include a third party, so I stood up my own APDNS proxy with an iterating nameserver behind it.

I have nextdns CLI installed on OPNSense but I'm looking for a plugin for OPNsense since I have zero visibility with the CLI Anyone know if this is coming soon or in the works? this page says "coming soon": https://github.com/nextdns/nextdns/wiki and this says that nextdns doesn't work with with unbound: https://github.com/NLnetLabs/unbound/issues/132

unbound support DoH to the client (they call it downstream), but it doesn't support DoH to the DNS provider (which at least someone else call upstream)

Noteworthy here is that unbound currently doesn't handle these new query types, but implementation is ongoing.

not really true. https://github.com/NLnetLabs/unbound/issues/411