Comment by exiguus
21 hours ago
I concur and generally advise against using large corporate DNS providers. Instead, consider setting up your own DNS infrastructure, such as your own recursive servers, or opt for a trustworthy DNS provider like Freifunk or CCC, rather than Google, Cloudflare, or Quad9.
The advantages of self-hosting recursive servers include complete configurability, absence of censorship, tracking, and rate limits. However, like any self-hosting solution, it requires an investment of time and money. It's also important to note that DNS lacks an authentication layer, so for access restrictions, it should be placed within a private network or VPN.
The issue of pre-configured DNS over HTTPS (DoH) in many browsers and mobile devices can be addressed through firewall rules on your router.
For creating your own DNS infrastructure, I recommend dnsdist if you have ample time, though bind and unbound are also viable options.
For the past three years, I have been running dnsdist with recursive servers on two ARM VPS instances, costing around 14 EUR per month. This setup provides me with DNS over TLS (DoT), DoH, and other features. I use them with unbound (TLS) or dnsproxy and dnscrypt-proxy across routers, servers, and other machines. For mobile devices, I utilize DoH directly.
Previously, I used bind in recursive mode without any encryption beyond SSH tunneling or VPN.
Alternatively, I can recommend ffmuc as a DNS provider.
I also run my own recursive DNS server on a VPS I rent, but I freely share it with other users of the Internet. This causes my "personal" signal of queries to authoritative servers to effectively disappear, and I also (marginally) benefit from caching effects of other users' lookups.
Are there any security risks with sharing it wiyh others?
Well, concerning technical risks, DNS Cache Poisoning[0] is a thing - but I keep the software implementing my recursive DNS service up to date very eagerly, so I guess the risk of falling victim to such an attack is rather low.
[0]: https://en.wikipedia.org/wiki/DNS_spoofing#Cache_poisoning_a...
I haven't taken this step yet, but I have considered it. Could you recommend whether I should share the service on a list such as dnscrypt.info/public-servers?
I was not aware of such a directory existing in the first place :) I only advertise "my" service (it only implements DNS and DoT) through word of mouth in communities I participate in.
How do you secure it against being used as a reflector in a UDP amplification attack?
Probably rate limits, making sure response minification is fully enabled, and maybe set a low truncation size?
You can't run a public service without reflecting something, but you can endeavour to make the reflection ratio small.
dnsdist support QPS limits [1] and eBPF filtering [2]. And you can use dynamic Rules to drop traffic and there are several rules to set UDP and TCP limits.
A in production config looks like: https://github.com/freifunkMUC/ffmuc-salt-public/blob/main/d...
[1] https://www.dnsdist.org/advanced/qpslimits.html
[2] https://www.dnsdist.org/advanced/ebpf.html