In reply to a post by Oliver341:

In reply to a post by smouty:

This is why, if you can, you run your DNS on your router or pihole etc and all clients point to that.

I prefer my cloud-hosted solution. At the very least, resolving DNS locally has privacy implications, since all recursive DNS requests are sent in the clear to every nameserver you need to use to resolve something.

Forgive the belated reply, my account was accidentally deleted and now kindly restored by staff.

Your reply assumes the local resolver must run recursively. If you run BIND, you know it's a recursive resolver - or at least that's a primary use-case for it. Running DNS locally, one can instead use a stub resolver and/or a forwarding resolver such as stubby, dnscrypt-proxy, unbound (with forwards to TLS upstream, not recursively), knot-resolver, blocky, AdGuardHome, Pi-Hole, Technitium, powerdns, systemd-resolved and a multitude of others. Any of these will mitigate the privacy issue, as they use any or a mixture of DoH, DoT, DoQ et al on the upstream.

I have two VPS (for redundancy) running *BSD, which themselves forward to encrypted resolvers as well as serving clients over encrypted DNS. All our family devices connect to that, except on the LAN. Locally, I have authoritative and forwarding DNS running on (again) two separate servers for redundancy - Rocky Linux (Proxmox) and Debian (Rock 5 model B).

Just don't forget that, even with encrypted DNS, one needs to be mindful of the client hello. This can be encrypted also, but support is limited to some Cloudflare sites at present. Even with encrypted DNS, the client hello can and will give away your browsing to your ISP. With encrypted client hello (ECH), the ISP is clueless about the SNI of the endpoint. If that's a single IP hosting a single known server, that's not so helpful. If it's Cloudflare, or another large CDN, it becomes basically impossible to tell which site the target (you) visited, because all they have is a CDN IP, encrypted DNS and encrypted client hello. You can see this for yourself in `wireshark`, which is always fun.

Sorry if any of this is teaching you to suck eggs. Your reply suggested you weren't aware, but on further reflection perhaps your choice of words in 'resolving dns locally' was very deliberate.

In reply to a post by RainmakerRaw:

Sorry if any of this is teaching you to suck eggs. Your reply suggested you weren't aware, but on further reflection perhaps your choice of words in 'resolving dns locally' was very deliberate.

Yes. I am aware DNS servers can forward queries, in fact this is exactly how my BIND server in the cloud functions, queries not blocked by the response policy zone are forwarded to the cloud provider's resolver.

Everything you say is sound advice, and I fully agree that ECH is the missing piece of the privacy jigsaw that needs widespread adoption.

In reply to a post by jchamier:

In reply to a post by RogueAlice:

I switched to a hyprid Quad9 9.9.9.9 as primary with Cloudflare 1.0.0.1 as secondary.

Secondary servers are only used if the first does not respond at all.

That isn't true.

In reply to a post by therioman:

That isn't true.

Windows aids the confusion, in the classic control panel, the servers are labelled as "preferred" and "alternative", which is not the case as neither server is preferred.

No such distinction is made within the modern settings panel.

Edit: my mistake, when editing the settings rather than viewing, the labels are still there. So the confusing labels are still there.

Edit2: and to make matters worse, my second IPv6 DNS server is present in the classic settings but missing in the modern settings. What a bugfest Windows is these days.

Edited by Oliver341 (Fri 23-Feb-24 09:49:31)

In reply to a post by therioman:

That isn't true.

It seems not true today, but it was a few years ago on a few different OSes, as I had real issues with a customer. The problem seems to be some resolvers stop on the first NXDOMAIN they receive, rather than waiting for responses from all and giving you the IP.

In reply to a post by Oliver341:

In reply to a post by therioman:

That isn't true.

Windows aids the confusion, in the classic control panel, the servers are labelled as "preferred" and "alternative", which is not the case as neither server is preferred.

No such distinction is made within the modern settings panel.

Edit: my mistake, when editing the settings rather than viewing, the labels are still there. So the confusing labels are still there.

Edit2: and to make matters worse, my second IPv6 DNS server is present in the classic settings but missing in the modern settings. What a bugfest Windows is these days.

The modern interface for setting networking parameters is garbage, it also lies often about the settings. It's best avoided.

In reply to a post by jchamier:

The problem seems to be some resolvers stop on the first NXDOMAIN they receive, rather than waiting for responses from all and giving you the IP.

Nothing wrong with stopping on receipt of NXDOMAIN, that is a valid result.

In reply to a post by therioman:

The modern interface for setting networking parameters is garbage, it also lies often about the settings. It's best avoided.

It should be embarrassing to MS that so many legacy control panels still exist because the modern ones are so bad.

Just chipping in my vote.

Cloudflare malware blocking built in

Malware Blocking
Primary DNS: 1.1.1.2
Secondary DNS: 1.0.0.2

For IPv6 use:

Malware Blocking
Primary DNS: 2606:4700:4700::1112
Secondary DNS: 2606:4700:4700::1002

In reply to a post by ukhardy07:

Just chipping in my vote.

Cloudflare malware blocking built in

If you genuinely want malware blocking, look elsewhere. Cloudflare's "family" service has long been poor at blocking known malware compared to the competition. For example, this test checked a live list of 163,196 known malware sites. Cloudflare blocked a paltry 6.31% of them(!), Quad9 blocked 84.61%, and ControlD Malware blocked 99.94%.

If you run your own DNS, consider adding Hagezi's TIF (Threat Intelligence Feeds) list.