Categories
Networking Security

DNS for home networks

In very simple terms, a Domain Name Service (DNS), is a service that turns specific network names (host names, service names) into IP addresses. It allows to use mnemonic names (mypc.example.com) instead of IP addresses (192.168.121.234) accessing internal network resources. There are several advantages in using DNS names instead of IP addresses directly:

  • Names are easier to remember and easier to communicate, especially to less technical people. This becomes more important when IPv6 is being used, because IPv6 addresses are much longer and harder to remember.
  • The IP associated with a name can change, even dynamically, but if the name stays the same, and the name mapping is kept up-to-date, configurations using the DNS name instead of the IP address don’t need to be changed. Again this becomes more important using IPv6. Since IPv6 LAN addresses are built from the global (public) prefix assigned by the ISP, LAN addresses too will change when the prefix changes (if the ISP doesn’t assign a static prefix, or when changing ISP).
  • DNS allows some service to be discovered automatically.
  • DNS names make creating digital certificates easy. Public CA won’t sign certificates for IP addresses (unless you can prove you’re the true owner of an IP, impossibile for private addresses), and certificates for host names allow changing the host IP without having to re-generate the certificate.
  • A local DNS service may also be used to resolve external names, with more and better control on that. For example, it can be used to “sinkhole” known bad resources – like ads networks, system known for malware delivery and so on.

One simple example where DNS is useful is in printers configuration. Without a working DNS system, many automatic printer discovery utilities will configure printing using the printer IP. If this changes, printing stop working, until the new IP is configured.

Or course IPs can be assigned manually, or reservations can be set in DHCP servers to ensure a device IP is not changed. But if a network needs to be “renumbered” (i.e. changing the used subnet), then all configurations based on IPs need to be updated. While using a DNS only the DNS mappings need to be updated – in a single place.

DNS names are also useful to set encryption using digital certificates. While a private CA can sign certificates containing IPs also, it won’t be possible to sign them using a public CA.

DNS servers can be integrated with DHCP servers to keep the name-IP mapping up to date. It is also possible to allow clients to update DNS entries, but this is a less secure way to do it, although it might be acceptable in a home network.

For reasons unknown to me, but that should have their roots in saving a few pennies, despite most consumer routers offer both a DHCP and DNS server, rarely they are configurable to work together, making them far less useful than they could be.

Alternatives to a DNS server

For small networks, alternatives to a full DNS server has been implemented, which don’t require a centralized server. They may be based on network broadcast or multicast requests, the latter being more network friendly, and working with IPv6 as well. Unluckily, they are less universal than plain DNS, since different standards have been developed and their implementation depends on the device and its operating system.

Windows, for example, implemented a way to query names using network broadcasts – it’s older than Windows, actually, having being designed in the early 1980s. This system is not efficient, nor universal, and can’t work across different subnets. Non Windows systems usually require additional software and/or configuration to support that, i.e. Samba in Linux. Other OSes can have implemented their own resolution system that usually don’t work with a different one.

Newer alternatives are built on multicast, and are often called mDNS (multicast-DNS) systems, although mDNS is a specific one. Unlike the early Internet, when usually consensus was reached on standards, post 2000 different interests of different groups led to different competing systems being delivered. So Apple went with Bonjour, Microsoft went with LLMNR, but since Windows 10 is trying to support Bonjour-like mDNS services as well, although for better support installing a specific software may be better. Linux has Avahi for that. These systems are also called ZeroConf because they add other automatic publishing and discovery of network services (i.e. printing, file shares, etc.), but these are outside the scope of this article.

Multicast too has the issue it won’t cross subnets unless specific support exists on network devices, or devices connected to different subnets, but this kind of support is rarely – if ever – found on consumer network devices. It becomes impossibile with cascading routers with NAT enabled.

It can still a good choice if everything is in a single subnet, and all device have a decent support for it. DNS, on the other hand, uses unicast packets , and as the Internet shows, and has no problems working across subnets.

Domain names

DNS uses a hierarchical name system – composed of one or more domain names (separated by dots) and a host name. One or more domains managed by a DNS system is called a zone. The top domain name is at the right, and the host at the left. It’s the same system used by Internet names, so in www.example.com www is the host name, com is the top level domain (TLD), and example is the second level domain1. Other levels can be used as needed, so we could have www.site1.example.com, if we wish. This names need to follow a specific syntax defined in RFC 1035.

If your network is connected to the Internet, and needs to access Internet destination also, you can’t choose your domain names freely. Available top levels domain are defined by ICANN and their management delegated to specific organizations – domain names under TLD. A domain name has to be chosen among those not registered yet (and then registered), or DNS name resolution could become messed up. It’s what happening as I’m writing (April 2024) to AVM – which used the domain fritz.box its internal DNS system, when the .box TLD wasn’t defined and delegated yet, but now it is, and AVM didn’t register the fritz.box domain, which ended in another entity hands. Now Internet DNS are resolving names inside the fritz.box domain with whatever IP the owner assigned to it, until AVM can get control of it2.

For other reasons unknown to me, but then again related to money, ICANN has always been reluctant to design TLDs for internal use only. There was the .local TLD defined by the IETF, home.arpa(RFC 8375) is another reserved one, and only recently (January 2024) ICANN has defined the .internal TLD for such use. Other commonly used TLD, like .home3, .priv, or .lan, are not reserved, and could become officially assigned TLDs any time, as soon someone pays ICANN enough.

.local is automatically used by mDNS name resolution, thereby if you have both DNS and mDSN resolution active, they could interfere with each other. home.arpa is a bit long, today most people don’t understand what arpa4 is for (in Italy, it looks a musical instrument…). If you wish to stay safe, and don’t want to register a domain, .internal is the better choice now, although it’s not a short one to type.

A registered domain can also be used for internal domain names, and could be useful if we wish to generate certificates using services like Let’s Encrypt, which won’t generate certificates for internal private domains. This solution would make DNS configuration more complex if the domain is used externally also, since the same name may need to be resolved to a public IPv4 address or a private one depending on which network the DNS query is made (a configuration called split-horizon DNS). Using IPv6, the IP can be the same.

Nothing stops us from using directly the TLD with a host name, and myhost.internal could be resolved as any other domain name. We are used to a second level domain at least, thus maybe something along the line myhost.example.internal looks better. In this case you can choose anything you like as the second level domain, as long as it fits into the DNS name syntax rules.

DNS configuration

Once you have selected your domain name – I’m going to use example.internal5 through this article (but you have to use a different one), it’s time to configure both your DNS server and devices to use it.

Some consumer routers may allow to specify the DNS domain to be used for the internal (LAN) network. Others may not, they could use their own, non modifiable, domain name, or none at all. In the latter case probably the DNS server inside the router just forwards queries to the external configured DNS, and does not perform any local resolution.

A DNS server for a small home network can be deployed on any always-on device that can run it. Many NAS has a DNS server as an option, and configuring one on something like a Raspberry Pi is not difficult.

The first step is to assign each device that needs its IP to be resolved by DNS a host name. Choose it carefully, because when configurations depend on it, changing it will require to change those configurations as well. Inside the same domain, names need to be unique. You can use explicative names (i.e. nas.example.internal) or fancy ones (athena.example.internal) as long as you remember what they mean for you.

Most devices have a setting somewhere that allows to set which DNS name and domain has been assigned to them – which they can show in their management application and use in DHCP requests also – but even if they don’t their IP can still be resolved once mapped into the DNS server.

Then host names and IP have to be assigned to each other. Assignments can be static or dynamic.

Static assignments

Static assignments are simple. In network devices allowing it, there is usually a user interface to insert the host name (and sometimes the full domain name), and the IP assigned it – if there is no user interface there are text files to modify, their syntax depends on the server used.

Static assignments rely on static IPs to be assigned – manually or through DHCP reservations. If you just need to access devices that can be configured this way, it might be all you need.

If the DNS server is just a little sophisticated, you will see you can create different type of entries – A, AAAA, PTR, MX – more about this later.

Dynamic assignment

Many DNS servers can receive updates from DHCP servers and/or clients. When a DHCP server assigns an IP to a device, it can also tell the DNS server to create, update or delete the hostname/IP mapping. Some DHCP clients can do that as well, if configured so.

It is more secure to allow only the DHCP server to update DNS entries, since it gives more control, unless each client is fully trusted. Dynamic assignments may introduce some security risks since a system might try to register itself with the same name of an another resource (internal or external), and then intercept the traffic destined to it.

Still dynamic assignments are useful to avoid to give each device a static IP or reservation, and be able to access them by name, without having to look for the actual IP first. If you wish to exchange file between Alice and Bob PC using SMB, and they are named after their users, you might just open the \\alice.example.internal path and see what shared folders are available, regardless of what IP was assigned.

Some systems may come with DHCP and DNS already integrated, other may need to explicitly configured that way. Many consumer routers I’ve seen till now just offer static DNS entries, and their DHCP server doesn’t update the DNS entries, making it less useful, since many devices that might be accessed by different users – like printers, for example – come with their DHCP client enabled by default, and few users change those settings.

DNS names resolution

Once you setup you DNS server, you have to configure clients to use it for DNS names resolution. That can be done manually, or using DHCP6. Among other things, DHCP can also assign a list of DNS servers to be queried, and domains to be searched when the host name is not fully qualified (FQDN – fully qualified domain name), which means its name its not full specified up to the root. For example www.example.com is a FQDN, www is not. If a list of domains to search is configured (manually or via DHCP), the DNS client will try to attach them in order to get a positive answer. So if the list is example.internal, example.com, the client will try www.example.internal and if no address is returned it will try www.example.com too. This allows to type less, but beware of unwanted resolutions it could lead to.

Usually more than one DNS server is configured- but beware, they are not used sequentially in the order they are assigned. A system can query them all at once, and use the answer from the first responding. If you have a single DNS server inside a home network, is fine to assign it only – knowing that if doesn’t work, DNS names resolution will fail. Using more than one server implies they need to be kept in sync somehow, but that’s a feature not available in consumer routers.

When a client asks for a name resolution (“DNS query”) a DNS server will usually perform a sequence of operations:

  • Most DNS server keep a cache of recent name resolutions. They will look there first. How long a name/IP mapping is kept in cache depends on the setting of the entry locally or in a remote DNS server it could be minutes, or days.
  • If the name is not found in the cache, the DNS server will look in its zones (domains), if configured so, and if it can answer the query directly from them, it will do so.
  • If it can’t answer the query, then in depends on the DNS configuration:
    • It if is configured to forward queries to an upstream DNS that can resolve the name, it will ask it. This is the common configuration for consumer routers, the “WAN” DNS will be used for forwarding, These DNS has to be able to resolve any domain not handled locally themselves, and are called recursive DNS.
    • If it is configured for iterative queries, it will start to ask the root DNS servers – a list of them is available to any DNS server. These know only about the TLDs, but can tell which DNS servers manage each TLD. Then our DNS server will ask those DNS servers. Again, these servers can’t resolve everything but will tell which DNS servers manage the second level domain in the query – and the process repeats, until a specific DNS server down the hierarchy is found that can resolve a host name into an IP. This is expensive, requiring several roundtrips, and thereby less used, and usually not available on consumer devices. Forwarding queries to your ISP DNS, or the Google/Cloudflare/etc. ones is usually faster – albeit they could track queries made.
  • If no DNS server asked can return a result, a response telling the name cannot be resolved is returned (NXDOMAIN). Some ISPs don’t do that following the standard, and may return something different, i.e. redirecting to some destination of theirs, for example an HTTP page with some kind of similar results. That is bad.

Once the client resolved a name, it usually keeps it in its own cache until the entry lifetime (returned in the query too), or its local settings, make it expire. Thereby, most of the time changing DNS don’t speed up your “internet” much, but for the first query7.

DNS record types

DNS servers allow to store different types of records. The most common name are those used to resolve host names into IP addresses, but there are others:

  • A record: used to map a host name to an IPv4 address.
  • AAAA record: used to map a host name to an IPv6 address.
  • CNAME record: an alias to a A or AAA entry.
  • PTR record: reverse mappings – IP to host name.
  • MX record: used to tell which mail servers are available for domain. Used for mail server to mail server communications.
  • TXT record: human readable information, also used to communicate specific information like SPF, DKIM, DMARC (and more) for a domain.
  • SRV record: indicates at which host and port network services reside, without the need to defined specific records like the MX one.
  • Other records like NAPTR, NS, SOA, etc. are outside the scope of this article, and usually not available on consumer devices.

For a simple home DNS system usually only A (and AAAA ones if there is IPv6 support) records can be specified, and sometimes CNAMEs. Note that the use of IPv4 and IPv6 requires the creation of separate records for each host.

PTR records could be managed automatically or not by the DNS system, creating them as needed when A or AAAA records are created. Some DNS server do it, others don’t. Reverse lookups – identifying a host name from its IP address are usually more important over the Internet than inside a LAN, but they could be nice to have.

MX records are used by mail servers to find the server they should deliver mail to, while SRV records can be used for automatic server discovery, for example by VoIP or mail clients, but their use is outside the scope of this article. Unless you have a very complex setup with different kind of local server with automatic service discovery, all you need are A (AAAA if using IPv6 too) and maybe PTR records, and that’s what simpler DNS systems allow to configure only.

Testing DNS name resolution

Once the DNS server is configured with all the records for the hosts, and the devices are configured with the DNS server IP, everything should work. If something doesn’t, the two primary tools used to test if DNS is working are nslookup (Windows/Linux/macOS) and dig (Linux/macOS). Bot allow to perform different type of queries, and select which DNS server to use for resolution, using by default the OS configured one. The ping command will attempt to resolve any host name used, but it won’t allow to change the DNS server used.

Conclusion

Configuring and using a local DNS server for a home network can greatly simplify its use and configuration and keep them working even when underlying IPs are changed. It can also help securing a network allowing to create proper TLS digital certificates instead of relying on self-signed ones, and to control which queries are answered and which are not.

FootNotes
  1. Actually all names should end with a dot that represent the “root” zone, but that’s usually omitted, and this omission is permitted. ↩︎
  2. AVM routers won’t ask external DNS to resolve anything in the fritz.box domain, but any device not using the router as its DNS server will bypass that. ↩︎
  3. Actually there was an attempt in RFC7788 to reserve .home, but it was withdrawn by RFC 8375 and replaced with the silly home.arpa, as nobody could make money from it, I guess . ↩︎
  4. ARPA was of course the predecessor of DARPA, the US agency that started the ARPANET network that later became the Internet. You have to be old enough to remember it, though. ↩︎
  5. Some example domain are reserved for documentation use, example.com, example.org., example.net, and the top level example. too, to avoid clashes with any domain that can be actually registered. See RFC 6761 ↩︎
  6. With IPv6, you can also use RA (Router Advertisements) to configure DNS servers. Or use a combination of SLAAC/RA and DHCP if more settings are needed. Especially until Google fires the “engineer” who blocks DHCPv6 adoption in Android – but that would let networks control better Android devices instead of Google. ↩︎
  7. In the past many Linux DNS clients didn’t cache DNS answers, so they had to perform a DNS resolution for each connection. That created the legend that you should select other, faster DNS (preferably by user-tracking companies like Google) to improve your connection speed. Windows DNS client always cached resolutions. ↩︎