💾 Archived View for going-flying.com › ~mernisse › 20.gmi captured on 2024-08-18 at 17:24:15. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-06-16)
-=-=-=-=-=-=-
DNS is probably the least thought of and most critical service on the Internet above layer 3 that end users use. It is also very often farmed out to registrars or hosting providers by smaller sites or large DNS providers (most notably thanks to the outages they called, dyn) in the case of larger sites. DNS is so critical because it is the service discovery layer of the Internet. It is responsible for telling your computer where to go to find anything that you refer to by anything other than an IP address. I am mostly looking to highlight points for a budding system administrator thinking about running a DNS server for themselves. General familiarity with the appropriate RFCs that describe the DNS system, protocol, and conventions is always a good idea.
Because DNS is so critical the perceived performance of your network and Internet connection are often times a result of DNS. If it seems like pages take a long time to start loading or load jerkily that could easily be DNS. Webpages these days (foolishly) contain resources from many different services and so require many DNS lookups to load. If those lookups are slow then the page will have to wait periodically for those to complete to continue to load resources. Also, you may want to provide the ability to easily access services internal to your own network and providing DNS is a good way to provide that for your self. Finally once you get to the point where you are hosting services on the Internet, providing your own DNS servers is a good way to ensure you maintain control over the reachability of your site and allow yourself easy migration to future services.
I provide two types of DNS service. Public DNS is provided for my domains, currently going-flying.com and ub3rgeek.net. I have two DNS servers, one runs along-side all the other services I provide (mail, web, gemini, etc..) on the public Internet and the other runs on a small DigitalOcean droplet that is dedicated to the task. The other type is an internal caching resolver, which provides lookup services to clients on my network. Those run on the public server as well as on a VM at each location. The service stack looks something like the drawing below. This is most certainly more complex than needed for a basic DNS server.
_ _
( ` )_
( INTERNET `)
(_ (_ . _) _)
^ \
| \
+-------------+ \
| unbound | \
+-------------+ \
^ \
| :5300 |
v |
+-------------+ |
| bind | <--+ *:53/tcp, *:53/udp
+-------------+ /
/
_ _ /
( ` )_ /
( LAN `)
(_ (_ . _) _)
A recursive resolver is a DNS server that is configured to be able to go out and find DNS information on the broader Internet. This is what the public DNS servers like 8.8.8.8 or 1.1.1.1 do. You configure your computer to use your resolver and it will go out on your behalf and start asking questions. Critically it will then most often cache the answer for a period of time so that if you ask again the response won't require going out and interrogating other servers. If I ask my local resolver for the address of www.outlook.com twice, you can see the difference in response time from 851mS to 3mS.
; <<>> DiG 9.10.6 <<>> www.outlook.com @192.168.196.3 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7516 ;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;www.outlook.com. IN A ;; ANSWER SECTION: www.outlook.com. 1200 IN CNAME outlook.office365.com. [ ... snip ...] ;; Query time: 851 msec ;; SERVER: 192.168.196.3#53(192.168.196.3) ;; WHEN: Tue Mar 09 14:53:45 EST 2021 ;; MSG SIZE rcvd: 224 ---- ; <<>> DiG 9.10.6 <<>> www.outlook.com @192.168.196.3 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11625 ;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;www.outlook.com. IN A ;; ANSWER SECTION: www.outlook.com. 1196 IN CNAME outlook.office365.com. [ ... snip ...] ;; Query time: 3 msec ;; SERVER: 192.168.196.3#53(192.168.196.3) ;; WHEN: Tue Mar 09 14:53:48 EST 2021 ;; MSG SIZE rcvd: 224
There are several software packages that can be a recursive resolver, one of the oldest and certainly the most widely used is BIND, the Berkley Internet Name Domain. BIND is notable because as the de-facto standard it is most often where new features in the DNS system are first implemented. For a long time I just used BIND everywhere, but once DNS over TLS became a going concern I decided to tack on a separate resolver so I could leverage the privacy protections that DoT brings. So for this I'd suggest running unbound as a resolver layer. It has a solid cache, is fast, is under active development and supports several performance features like cache preloading and stale record serving which when you are looking at the high latency of DNS over TLS (or even DNS over HTTPS) can help the user experience greatly. In practice I run unbound with only a few additions to the default Debian config.
server: verbosity: 0 use-syslog: yes log-servfail: yes do-tcp: yes port: 5300 interface: ::1 do-ip4: yes do-ip6: yes prefer-ip6: yes rrset-roundrobin: yes use-caps-for-id: yes version: "There is always Peng." num-threads: 16 cache-min-ttl: 1200 hide-identity: yes hide-version: yes minimal-responses: yes so-reuseport: yes tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
This is just general tuning, found in many unbound tuning guides. I am shortening responses, moving the listening port to 5300 since I only want BIND to talk to it (in your case you probably want to leave it listening on port 53), binding it only to the local host (again, you probably don't want this), and obscuring the software version number. I also quiet down some unneeded default logging.
# DNS flag day, 2020 edns-buffer-size: 1232 msg-buffer-size: 65532
This conforms to some best practices that have changed since the introduction of DNSSEC. DNSSEC allows your system to know that the answer it is getting is what the owner of the domain intended it to be, but it does that by making the answers much larger with cryptographic signatures. This ensures we can receive those larger answers.
serve-expired: yes serve-expired-ttl: 3600 prefetch: yes prefetch-key: yes
Additional performance enhancements by prefetching popular domains and by allowing unbound to serve stale records. If a record is in the cache and it has expired within the last hour it will be returned to the client. In the background the server will go fetch the record from the Internet and update the cache so the next time it is asked it will have the fresh answer.
# Disable Mozilla DoH forwarder TYVM. # https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https # https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet local-zone: "use-application-dns.net" static
Because I'm providing DNS over TLS, I do not want my browser to bypass it. This trips the switch in Firefox to tell it to not try to work around my servers.
forward-zone: name: "." forward-addr: 2620:fe::fe@853#dns.quad9.net forward-addr: 2620:fe::9@853#dns.quad9.net forward-addr: 9.9.9.9@853#dns.quad9.net forward-addr: 149.112.112.112@853#dns.quad9.net forward-tls-upstream: yes
Finally, this is the bit that tells unbound to talk upstream to DNS over TLS DNS resolvers.
This is a pretty simple way to start yourself down the path of hosting your own DNS services. Setting up a resolver is easy and will help you understand some of the most important parts of the system. It also gives you a lot of control. If you have heard of something like Pi-Hole, most of what it is doing is blocking DNS entries by providing you with a specially configured DNS server. In fact, they use unbound to do that under the covers (last I looked). One of the most visited posts on my web blog is actually one about using various block lists to turn my DNS servers into ad and malware blockers.
https://www.going-flying.com/blog/better-ad-blocking-and-safer-dns-with-unbound-and-cloudflare.html
Next time, tricks from the flip side of DNS, the authorative server -- where I serve up my own DNS information for the rest of the world to use.
🚀 © MMXX-MMXXIV matt@going-flying.com