Configuring DNS in a Home Network

I've been using Ansible to setup my desktop and in the process of building things from scratch, I discovered that my DNS query logs were being spammed with:

Some of these queries are being forwarded to my router by the stub resolver I'm using, dnscrypt-proxy, and some of them have been dropped. The source of these requests in the query logs is (mostly) mentioned as my router (I don't think it is) and sometimes mentioned as my iPhone which makes me think that an infinite loop might be plaguing my network. I'm also seeing a few requests that have a suffix of "ip6.arpa":

In addition to these issues, I also recently started connecting my laptop to my router using the laptop's WiFi interface. Before I started doing this, I used my laptop in docking mode connected to an external monitor and to my router with an Ethernet cable. In this configuration, I had assigned a static IP lease to my laptop's Ethernet interface. However, now that I'm connecting my laptop to my router using WiFi, assigning another static IP doesn't really make sense because I need to know the active IP of my laptop.

Do I really need assignment of static IPs to my trusted LAN clients? What are these queries for DNS PTR records doing in my logs?

This might a somewhat lengthy blog post because I'll try to explain how DNS works in a home network and DNS is by no means a trivial topic to understand.

Infrastructure Overview

Before I begin investigation of why these issues are happening and how to improve my home network DNS, it'd help to take a step back and get an overview of the architecture of my home network.

I have a D-Link DIR-2640 WiFi router with OpenWrt that, for practical purposes, connects to the Internet on behalf of all my other clients. It hosts a DHCP server, operated by dnsmasq, for assigning leases and managing clients inside my LAN. In addition, this router also hosts a local DNS server which answer queries about other local clients inside the LAN. A Raspberry Pi 4 Model B runnning Alpine Linux is connected to this router and it is being used to self-host services that will be used by every other device in my LAN, among which is the primary DNS stub resolver, dnscrypt-proxy.

OpenWrt

dnsmasq

Alpine Linux Downloads

dnscrypt-proxy v2

I have an x86-64 Intel Core i5-12400F desktop, an x86-64 ThinkPad E495 laptop, and two smartphones — an iPhone SE (2022) and an Android. I do have other devices that connect to my router, such as my robot mop and vacuum, but they connect to an isolated VLAN.

Undelegated and Special-Use Domain Names

There are some configuration options in dnscrypt-proxy that are important in the context of this blog post:

The first option responds to queries without a domain name, or other invalid queries, and provides them with a "synthesized" response. I'm not sure what that means and thanks to the author of dnscrypt-proxy and GitHub, I don't think I ever will.

locked issue on dnscrypt-proxy preventing any further discussion

The author was kind enough to grace us with a response on another issue:

> SYNTH 0ms means that these responses were immediately (0 ms) synthesized (SYNTH) by the proxy instead of being sent to a server.

The 2nd option is supposed to prevent sending certain DNS queries which aren't supposed to be sent to nameservers although the name of this option is confusing and potentially misleading. This brings us to the fact that some top-level domains are "special".

Choosing a Name and a Domain For Your Home

Have you ever installed a Linux distribution? An installation should almost certainly ask you for a hostname that you want to use. The hostname(5) man page on Arch Linux says that the file /etc/hostname should

> contain a single newline-terminated hostname string. Comments (lines starting with a "#") are ignored. The hostname should be composed of up to 64 7-bit ASCII lower-case alphanumeric characters or hyphens forming a valid DNS domain name. It is recommended that this name contains only a single label, i.e. without any dots.

It's funny how some systems are still restricted to 7-bit ASCII when the Internet has become a global network and Unicode support is essential for people who don't speak or understand English, which isn't an insignificant number. If you're looking for some advice about which name to choose for your machine, RFC 1178 might be helpful.

RFC 1178: Choosing a Name for Your Computer

Even after you pick a name for your machine, you'll need a top-level domain name, kinda like .com, for your home network. This is where things get messy, to say the least.

According to the RFC 8375 published by the IETF (Internet Engineering Task Force), the domain .home.arpa should be used for home networks. If you named your machine olympus, RFC 8375 suggests that the domain name of your machine should be olympus.home.arpa. In addition, it suggests that

> queries for 'home.arpa.' and subdomains of 'home.arpa.' MUST NOT be forwarded to an upstream cache or to the authoritative DNS server for '.arpa'

RFC 8375: Special-Use Domain 'home.arpa.'

The RFC suggests setting up a local authoritative DNS server for '.home.arpa.' and using it to answer queries for machines on the home network. This can be the DHCP server which assigns leases to machines inside a LAN.

What if we don't fancy using the domain '.home.arpa.'? Well, looks like most people don't and we can't really blame them considering the fact that RFC 8375 was published in May 2018 and before that, home network domain names were a mess because people used these domains for their home networks:

The '.local' top-level domain is an exception in this list because it has been classified as a special-use domain name by the IETF for usage in zero-configuration network scenarios. Its usage in mDNS (multicast DNS) is well defined in RFC 6762. This makes '.local' an invalid choice for usage in home networks.

RFC 6762: Multicast DNS

One might ask the reason for not use zero-configuration networking instead of bothering with DHCP and DNS. My issues with mDNS lie in the fact that it needs a dedicated resolver that isn't your usual stub DNS resolver or recursive DNS server. On Linux, the two popular methods of using mDNS are Avahi and systemd-resolved and I don't like either of them. The zero-configuration set of technologies also include DNS-SD (DNS Service Discovery), which is what I suspect I'm seeing in my logs, thanks to the addition of the iPhone SE (2022) in my LAN (Thanks Apple!).

One might assume that using '.home', '.lan', '.corp', '.mail' or one of the other TLDs mentioned before might be safe choices. Unfortunately, they aren't. Although '.home', '.corp', and '.mail' have been identified as high-risk TLDs to delegate for any purpose whatsoever, we don't know when greed may overcome rationality as evidenced in these drafts.

Unicast Use of the Formerly Special-Cased 127/8

Unicast Use of the Formerley Reserved 0/8

I wonder if I'll see an IPv6-only Internet (with each node having its own unique IPv6 address that is publicly accessible on the Internet rather than behind a NAT or a draconian firewall) before I die or in the next 50 years, whichever is earlier.

ICANN board meeting that deferred delegation of '.home', '.corp', and '.mail' indefinitely

> Whereas, on 30 July 2014, the ICANN Board New gTLD Program Committee adopted the Name Collision Management Framework. In the Framework, .CORP, .HOME, and .MAIL were noted as high-risk strings whose delegation should be deferred indefinitely.

You'll notice that '.home', '.corp', and '.mail' haven't been reserved as special-use domain names like '.home.arpa'. They're simply classified as "high-risk" and their delegation has been deferred. If you use one of these domains and they are delegated in the future, you may need to reconfigure your home network to avoid unexpected issues.

Addressing the New gTLD Program Applications for .CORP, .HOME, and .MAIL

Consideration of .CORP, .HOME, and .MAIL and other Collision Strings

So, what are supposed to pick if we don't like using '.home.arpa.' as our home network domain? The only other valid choice is purchasing a domain name exclusively for the purpose of usage as a home network domain. I have a website with an apex domain of 'ayushnix.com' so I purchased the name 'ayushnix' on the '.one' TLD. I use 'ayushnix.one' exclusively inside my home network.

Here's a blog post from Daniel Aleksandersen about this topic.

"What domain name to use for your home network" by Daniel Aleksandersen

Other Special Domains

The RFC 6761: Special-Use Domain Names mentions

These domains are like '.local', special-use domain names reserved for specific purposes. The ".test" domain isn't supposed to be looked up by upstream DNS resolvers and a negative response has to be returned in case it is looked up. The ".localhost" domain is meant to be used for localhost loopback resolution so it should get the same treatment as ".test". The ".invalid" TLD should be replied with an NXDOMAIN response by caching stub resolvers. The ".example" domain and the "example.org", "example.net", and "example.com" domains are reserved for use in documentation.

A recently released RFC 9476: The .alt Special-Use Top-Level Domain, reserves ".alt" as a special-use domain name for alternative namespaces that aren't meant to be resolved via the traditional DNS infrastructure. The RFC states that both caching and recursive DNS resolvers SHOULD NOT recognize names in the ".alt" namespace.

RFC 9476: The .alt Special-Use Top-Level Domain

Here's a summary of how various well-known undelegated and special-use delegated domain names should behave inside a home network.

Although it may seem sloppy to forward queries with undelegated domains like ".lan" to upstream DNS servers, I think that's how a local DNS server should behave, unless these undelegated domains are already being used in your home network domain. We didn't have a definitive domain that was free (as in price) to use before 2018 but after ".home.arpa", I feel there's little reason to use undelegated domain names. If you don't like the ".home.arpa" domain, buy a domain that you like and use that instead.

How do we actually configure the domain we've decided to use on a Linux (and other UNIX-like) machine?

Resolving Names and Hostnames

If you're using a Linux distribution with glibc and systemd, the hostname(5) man page probably mentions that the /etc/hostname file

> should contain a single newline-terminated hostname string. Comments (lines starting with a "#") are ignored. The hostname should be composed of up to 64 7-bit ASCII lower-case alphanumeric characters or hyphens forming a valid DNS domain name. It is recommended that this name contains only a single label, i.e. without any dots.

The hostname(7) man page provided by the Linux kernel itself is relatively more agnostic although it still mentions glibc. However, what's interesting to note is that the hostname(7) man page implies that the hostname can either be a single label as mentioned in hostname(5) earlier, or it can be a FQDN (fully qualified domain name), such as "olympus.home.arpa".

When using Linux distributions with musl, such as Alpine Linux, the usage of FQDN as the hostname seems to be encouraged. This is evident when executing the "setup-hostname" script provided by Alpine Linux because it explicitly asks for a "fully qualified form, e.g. 'foo.example.org'" as a hostname. I'm not sure why but it might be because musl didn't support specifying the search domain using the "search" directive in "/etc/resolv.conf" before version 1.1.13.

TO BE UPDATED ...

---

¹ I mostly regret buying an iPhone because of how restricted, dumb, and user-hostile iOS is. It reminds me of GNOME and GTK and everything in that ecosystem, which I despise. Still, I wouldn't say that the experience has been completely negative. I bought the iPhone SE 3rd gen primarily because of its small form factor, which I really like. I also like apps like the Mona app for Mastodon, which I feel is significantly better than any Android alternative. The iOS dialer is much better than the Android dialer because it integrates call logs from other apps like Signal and WhatsApp. But yeah, that's about it.

---

Updated: 2023-10-28

Created: 2023-10-15

Home