going-flying.com gemini git repository
e4e7b4be3b3b1fa02788879d36caa85c8460bff4 - Matthew Ernisse - 1615321122
new post
diff --git a/users/mernisse/articles/20.gmi b/users/mernisse/articles/20.gmi new file mode 100644 index 0000000..500b03d --- /dev/null +++ b/users/mernisse/articles/20.gmi @@ -0,0 +1,230 @@ +--- +Title: Sysadmining: DNS +Date: 3/9/2021 15:20 + + +## Background +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. + +=> /cgi-bin/rfc?rfc8499 RFC-8499 is a good start + +## Why should you care? +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. + +## My use-case +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. + +### My DNS Servers +``` + _ _ + ( ` )_ + ( INTERNET `) +(_ (_ . _) _) + ^ \ + | \ ++-------------+ \ +| unbound | \ ++-------------+ \ + ^ \ + | :5300 | + v | ++-------------+ | +| bind | <--+ *:53/tcp, *:53/udp ++-------------+ / + / + _ _ / + ( ` )_ / + ( LAN `) +(_ (_ . _) _) +``` + +## Running a recursive resolver +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. + +### Unbound 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. + +## Conclusion +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. +