This is a good summary.<p>I run both authoritative (nsd) and resolving (unbound) nameservers. They require literally zero maintenance. Before nsd, I ran djbdns, which also required zero maintenance. I've run BIND, back in the dark ages. Rumor has it that BIND doesn't suck any more, but I've seen no reason to confirm.<p>If you are able keep sshd up and running on your hosted or colo'ed server, you have the skills required to run a nameserver reliably. It's that easy. I recommend nsd and/or unbound.<p>If the article does not persuade you that you want to do so, then don't bother. But if you do want to, don't be dissuaded by assuming it will be difficult.
I'm writing a safe Rust DNS server library:<p><a href="https://gitlab.com/leonhard-llc/ops/-/tree/safe-dns/safe-dns" rel="nofollow">https://gitlab.com/leonhard-llc/ops/-/tree/safe-dns/safe-dns</a><p>My goal is to have libraries for all the common services. Then I can run web, APIs, DNS, and email from a single static binary, with no config files.<p>Then the next stage is to run the server in a unikernel in a VM, eliminating the OS. The following stage is to run the server directly on bare metal, eliminating the hypervisor kernel and OS. The final stage is to run the server as firmware directly on the CPU, shipping built-from-source firmware for all peripherals, eliminating all unauditable binary blobs from the server.
I don't agree that it's decentralized, it tries to be but it's really distributed with a few root servers with a few people that have keys to them.<p>Eventually there will be a decentralized name system for probably a decentralized P2P radio system, and I'm trying to build that: <a href="http://radiomesh.org" rel="nofollow">http://radiomesh.org</a><p>But it's proving more tricky than I could have ever dreamed, right now I have scrapped 433MHz LoRa on Rasperry Zero and I'm moving to 169MHz plain radio on Raspberry Pico.<p>As for running your own it's very easy with these simplified lines of Java and dns4j (excluding port 53 UDP stuff):<p><pre><code> Message query = new Message(data);
Header header = query.getHeader();
Record question = query.getQuestion();
Message response = new Message(query.getHeader().getID());
response.getHeader().setFlag(Flags.QR);
response.addRecord(question, Section.QUESTION);
Name name = question.getName();
int type = question.getType();
int dclass = question.getDClass();
String host = name.toString(true).toLowerCase();
...
response.addRecord(new ARecord(name, dclass, 300, "someIP"), Section.ANSWER);
...
response.getHeader().setFlag(Flags.AA);
return response.toWire(512);
</code></pre>
Everyone should run their own DNS on the same process as their HTTP and SMTP servers... because without DNS nothing exists.<p>There are few things more frustrating than having your DNS provider be down for hours without recourse!
Another interesting way subdomains leak is through TLS cert registration. I.e. you can plug a domain into this search [0] and find subdomains that have public TLS certs.<p>I just noticed a full blog post on this topic is also on the front of HN right now. [1]<p>[0] <a href="https://transparencyreport.google.com/https/certificates?hl=en" rel="nofollow">https://transparencyreport.google.com/https/certificates?hl=...</a><p>[1] <a href="https://shkspr.mobi/blog/2022/01/should-you-use-lets-encrypt-for-internal-hostnames/" rel="nofollow">https://shkspr.mobi/blog/2022/01/should-you-use-lets-encrypt...</a>
I'm enjoying running a pi-hole on my local network that also has unbound running on it for resolving dns queries. Works like a charm, and it's nice and quick.
I run BIND on the router at each site I administer. The router gets a real domain name and is the authoritative nameserver for that domain. isc-dhcp-server is configured to assign a publicly routable IPv6 to each client, and update the BIND zone records with the client hostnames, so each client automatically has a publicly routable domain name, hostname.domain.com, with AAAA records pointing to their IPv6. They are firewalled of course.
I thought more common would just be a caching server (e.g. dnsmasq) for small networks with slow connections to the outside world (and this also helps with local hostnames).
Another good reason to run your own private DNS resolver is censorship. I originally set it up after my ISP was sued to block access to thepiratebay.com. The court was satisfied that a DNS blackhole was good enough..
Some warning. Please do not put a resolver directly onto the internet.
As nice as it might be to have a DNS ad-blocker or your own names reachable all over the internet, the server <i>will</i> be part of DDOS attacks through traffic amplification and you don't want that.
Run your own recursive server and instrument the crap out of it: <a href="https://github.com/m3047/rear_view_rpz" rel="nofollow">https://github.com/m3047/rear_view_rpz</a> You can't get local knowledge from anywhere else.<p>The latest BIND has DoT (DNS over TLS) out of the box, or you can put nginx in front of any decent DNS server to terminate TLS just like you do with a web server (this is fundamentally TCP not UDP however).
Another reason you might want to run your own BIND server is to enable reverse-lookups for your internal machines. On my home network, a reverse-lookup for 10.0.9.30 resolves to tara.nono.io (i.e. `dig 30.9.0.10.in-addr.arpa ptr` → tara.nono.io.)
I have been managed for years a cluster of recursive authoritative DNS cluster for a broadband ISP (around 30k subscribers). We have also 2 authoritative DNS servers running bind, but the operations were fully automated through a bunch of custom python scripts (the NOC operators can request a new record by themselves).<p>For the recursives one, I started with bind, but after a few months I replaced it to unbound and it's works like a charm. The only problem that I experienced was about DDoS, mainly generated by ultra cheap chineses home router with buggy firmware.
Anyway after a few attacks, we start implementing an application monitoring solution and we were able to mitigate the attacks in a short time.<p>On my laptop I run a a docker container with grimd (<a href="https://github.com/looterz/grimd" rel="nofollow">https://github.com/looterz/grimd</a>) as recursive DNS and DoH proxy. I can filter out lot of dab requests and tracking and have visibility of what my DNS traffic is. It's not hard to configure
Silly question coming from someone not very experienced with DNS servers/resolvers, is there a way to download/cache/resolve all country specific domains (ccTLDs)? I know there are many sites that sell zone files, like <a href="https://zonefiles.io" rel="nofollow">https://zonefiles.io</a>, but aren’t the DNS records supposed to be something freely available?
Have you ever wanted to build a toy nameserver that returns funny programmatic results? Then have a look at Python’s dnslib.<p>Example where the magic happens in ~40 lines of code:<p><a href="https://github.com/paulc/dnslib/blob/master/dnslib/shellresolver.py" rel="nofollow">https://github.com/paulc/dnslib/blob/master/dnslib/shellreso...</a><p>Hurricane Electric can sit in front of it if you like (and your records are dynamically generated but bounded to a known finite set), god bless them <i><salute></i>:<p><a href="https://dns.he.net/" rel="nofollow">https://dns.he.net/</a><p>Example where you might want this: you wrote a nameserver that runs arbitrary shell commands!
Lost me at wanting to run BIND. BINDs security track record is poor and does not show promise of improvement. Run something else. There are plenty of systems that can consome or convert from bind format if thats what you want.
One use case that i can think of is split DNS, when you'd like to return different data to different clients, about which i wrote on my blog: <a href="https://blog.kronis.dev/tutorials/how-to-run-a-split-dns-server" rel="nofollow">https://blog.kronis.dev/tutorials/how-to-run-a-split-dns-ser...</a><p>That said, outside of serious enterprise settings, you can do all sorts of things without hosting your own DNS servers - even odd ones, like making records on public DNS servers for your internal network. Sometimes using a dynamic DNS client (e.g. ddclient) is actually easier than caring about setting static IP addresses (if you just want to let DHCP handle everything), when you don't care about that sort of data being exposed. Of course, that's not to say that people should actually do stuff like that, just that they can.<p>On a more practical note, if you use the DNS servers of someone like NameCheap or GoDaddy, you might run into limits for how many records for a domain you can create. For example, NameCheap allows up to 150 records (<a href="https://www.namecheap.com/support/knowledgebase/article.aspx/10058/10/namecheap-dns-limits/" rel="nofollow">https://www.namecheap.com/support/knowledgebase/article.aspx...</a>).
One thing the fine article does not list as a reason to run your own DNS is if you need a secondary name server. There are plenty of options (Route 53, etc.) if you only need a primary, but all Internet domains should have at least two authoritative servers (for redundancy). There are far fewer secondary server options available from DNS providers, so it is often a good idea to run your own.
> it’s almost 40 years old<p>I was shocked that DNS was <i>only</i> almost 40 years old - I would have guessed it was at least older than me, but she's right. According to <a href="https://datatracker.ietf.org/doc/html/rfc882" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc882</a> it's almost 10 years younger...
Hypothetically if some scary evil person were to register a domain with some accredited registrar - say GoDaddy or Tucows - could they arbitrarily seize it for "content policy" reasons? Like "your site has Dave Chapelle jokes which we don't like" so we took your domain.<p>Or do they stand to lose something in a major way if they do this?
The blog post indicates running a resolver would have privacy enhancing benefits. Am I misunderstanding something here? Isn't the resolver mostly unusable without an upstream source that could then log all queries? Or is there a records bulk download option?
Not expressly mentioned in the "user interface" bit: not all hosting services allow all possible RRTypes and you may want to deploy uncommon or newly specified RRTypes like TLSA or the possibly-soon-to-be-specified SVCB and HTTPS RRTypes.
There's a fundamental mistake in this article.<p>I quote: "But the “phone book” mental model might make you think that if you make a DNS query for google.com, you’ll always get the same result. And that’s not true at all!"<p>Phone books are not a static model either. If you were to look up "Walmart" in your local phone book, you're going to get a different set of phone numbers for the Walmart stores around you as compared to five states to the West or East of where you are. As such, the mental model really is apt.
The main reason I run my own name server is to support IP over DNS tunneling. Having direct and easy control over the normal records it serves is also nice.
reason: you want to route application traffic through a local daemon but the computing device will not allow you to access /etc/hosts or run a firewall like iptables/nftables/pf<p>One way to redirect application traffic to a local daemon, e.g., something like sslsplit or stunnel, is using firewall rules. Another way is to use DNS.<p>Running DNS for oneself with a custom root.zone allows one to redirect traffic, for example, to a loopback address where the daemon is listening. The DNS server can run locally on a loopback or private address (for use while at home/office), or remotely on a public address (for use when travelling).<p>For example, I use a local proxy server instead of remote DNS lookups. When I visit example.com, there is a local DNS lookup to a local DNS server listening on the loopback. No DNS packets leave the computer. The local DNS server returns the loopback address of the proxy. The proxy, which has the remote address of example.com stored in memory, then accesses example.com.
Been using pfBlockerNG [1] for years and haven't seen ads for a long time. They are even filtered out from Youtube Videos, through DNS sink. I am using it from my offsite-server at my parents house through IPSEC. Also protects family members from accessing bad IPs, based on several global malicious IP filter lists.<p>[1]: /r/pfBlockerNG
We use the excellent gdnsd (<a href="https://github.com/gdnsd/gdnsd" rel="nofollow">https://github.com/gdnsd/gdnsd</a>), mainly for its geo-DNS configurability. Have been using it for probably 5-6 years now, handling hundreds of millions of queries per day, and never had an issue with it.
Thanks for this great article! My two cents:<p>> reason: do something weird and custom<p>Oh yes please! Previous discussions on this topic:<p><a href="https://news.ycombinator.com/item?id=28218406" rel="nofollow">https://news.ycombinator.com/item?id=28218406</a> (HTML over DNS)<p><a href="https://news.ycombinator.com/item?id=25620411" rel="nofollow">https://news.ycombinator.com/item?id=25620411</a> (DNS Key Value Storage)<p><a href="https://news.ycombinator.com/item?id=22808121" rel="nofollow">https://news.ycombinator.com/item?id=22808121</a> (Wikipedia over DNS)<p>> reason: geo DNS<p>Please don't do this! IP addresses aren't geolocated in the common sense. The good way to get content closer to your users is to announce your IP space from your different locations. Then client ISPs can choose the best route depending on peering policy and number of hops.<p>If your DNS lies depending on the IP who asks, you're going to have quite a bunch of people redirected to the "wrong" (far/slow from their perspective) server. The only exception i can think of is for split-horizon DNS where your local resolver advertises local IP addresses.
I found one of challenge when running a public dns resolver(and authoritative name server if we're being target) is DNS Backscatter. Up till nowsaday I don't really know how people solve this problem.<p>Anyone can lighten me up on how to defend this kind of attack? I really want to run my own dns server
reason: You want to use dynamic wildcard SSL certificates via Letsencrypt. Because they need to be validated via DNS.<p>reason: You want to use anycast (rent cheap VPS servers that support BGP)<p>The anycast managed services that exist will takes days to sync all servers, thus you can't use DNS validation with Letsencrypt. Solution: Run your own Anycast ...<p>That said, anycast is overkill, because DNS has caching built in to it's protocol, if the user has looked up your IP once, it will be cached on the user machine next time he/she looks it up. And if you have a fairly popular domain, it will also be cached at the ISP or whatever DNS resolver the user has.
On my LAN the only DNS server I'm running are resolvers. I have a pihole instance that is backed by stubby to filter out ads/trackers and send queries outside my network via DNS-over-TLS.
I have lately started to call dns "a global distributed database", rather than decentralized. Decentralized implies some properties that the dns system most definitely does not have.
This is a good list for running DNS servers for publicly resolvable domains. Another common reason is to run a server for internal domains only accessible via VPN.
I started running DNS servers 25 years ago so it doesn't take much mental effort for me. It is easy for me to do, and I have full control over it. I can do it in my sleep.<p>The biggest effort for me was about 24 years ago, when BIND 8 replaced BIND 4.<p>Probably the last thing I had to learn was putting AAAA records in (easy enough) and putting SPF records (yes, I run my own personal postfix as well).
Another point I would add is DNSSEC. With your own authoritative server you actually own the keys and don't have to trust another company.<p>What's also not mentioned is the possibility to run your own hidden master and use a DNS provider (or multiple!) as slaves. This way you have full control over your zone but you don't have to run your own network of nameservers.
DNS is decentralized about as well as TLDs are decentralized... they're not. You'd specifically have to run your own DNS to make it decentralized and use other upstream providers that allow the use of open TLDs.