DNS and DHCP are core services that many home networks provide. Usually these services are handled by an appliance such as a router provided by a person’s Internet Service Provider. Even though one of the major goals of the 2021 edition of the Stein Home Network is to simplify the infrastructure, (see Stein Home Network – 2021 Edition), the appliances I have are not flexible enough to handle things such as reserving an IP address for a specific device or providing services with different configurations for individual VLANs. Therefore a virtual machine running a version of Linux will still be employed to provide those services. However, complexity will be reduced by no longer having multiple physical and virtual servers with a shared data store and fail-over capabilities. This means that a server outage can impact these vital services, but some redundancy has been built into the design to mitigate the impacts of outages as much as possible. (For a detailed description of the redundant DNS and DHCP configuration previously employed see DNS and DHCP – 2017 Edition.)
The main goals for DNS and DHCP are:
- Allow configuration of dynamic and static IP assignments
- Work across multiple VLANs and subnets
- Handle IPv6 lookups and assignments
- Provide internal subdomains hosted locally and not exposed to the Internet
- Update internal forward and reverse DNS with dynamically-assigned DHCP client information
- Outsource top-level DNS to a third party with dynamic DNS support
- Simplicity
- Privacy
The technologies and providers used in this solution are:
- unRAID for hosting virtual machines
- An Ubuntu server instance running in a virtual machine
- dnsmasq for DNS and DHCP services
- dnscrypt-proxy for proxying external DNS queries over an encrypted channel
- Namecheap for DNS registration and dynamic IP management
- Cloudflare 1.1.1.1 / 1.0.0.1 for secure (encrypted) DNS resolution
- Ubiquity Unifi Security Gateway Pro 4 (USG) as a backup DNS resolver
For information about dynamic DNS and how Namecheap factors into this design, please see Dynamic DNS – 2021 Edition. Also please note that some of the descriptions about how DHCP and DNS work are just to convey a general idea of how they work and are not meant to be exactly technically correct; this is not a how-to guide, but a high-level overview of how I implemented DNS and DHCP capabilities on my home network as well as some insights on why I chose these specific technologies.
The first step for implementation of this design is to create a new virtual machine and load a version of the Ubuntu server operating system onto it. This solution does not need much in the way of CPU, memory, or disk space, so a very small, base install of Ubuntu should be fine. The dnsmasq package is then installed and configured in a way that it can either answer a DNS request or forward the request on to another DNS server. This allows for me to create an internal network with its own set of private names that may only be used when on that network. For example, my top-level domain name of “thesteins.org” has names that are addressable from the Internet such as “www.thesteins.org” and “media.thesteins.org”. But my private sub-domain of “internal.thesteins.org” and the names under that such as “KARYLPC.internal.thesteins.org” are only resolvable (viewable) by devices on my home network.
When a device on my home network queries for the address of a computer on the “internal.thesteins.org” domain, the dnsmasq service provides the answer. On the other hand, if my device makes a query for a domain outside of my home network such as “google.com”, the dnsmasq service forwards that request to a server on the Internet in order to provide a response. Therefore, when I am on my home network and want to reach my desktop named “KARYLPC.internal.thesteins.org” my device will be able to resolve that name to an IP address. (The IP address is a name that a computer understands how to use to reach another computer. DNS allows us to type something like “google.com” into a browser instead of something like “172.217.4.46” or “2607:f8b0:4009:804::200e”.) However, if I was not on my home network and my device tried to look up the name “KARYLPC.internal.thesteins.org”, it would not receive a response.
My home network also contains a separate area for guest access. This network is on a VLAN (virtual network) and does not have access to things on the “internal” home network. This is used mainly to provide visitors to the house a WiFi connection to the Internet, but not allow them to access anything on the home network. That network also needs DNS and DHCP services, but a very simplistic implementation is more than adequate. Therefore, instead of connecting the Ubuntu server to the guest network so it can communicate DNS and DHCP data, I decided to use the DNS and DHCP services on the router to service the guest VLAN. This is a change to the previous implementation and only done to simplify the configuration needed.
Another change is that DNS queries sent to servers on the Internet will be done over an encrypted, (secure or unreadable), channel. This is mainly for privacy, but can have some security benefits depending on how the servers being used to answer queries are configured. This is a new addition and one I have wanted to do ever since Cloudflare released their 1.1.1.1 service. By encrypting–i.e. making the data unreadable except by the destination server–DNS queries, people who can view your traffic, (think a public WiFi access point in a restaurant), will not be able to see what sites or places you are visiting. Many popular DNS servers–such as those owned by Google or your Internet provider–can also capture, store, analyze, and use your data as they see fit. Given that people or companies can only see or capture the name of the computer or service to which you are trying to connect and not specific pages on a web site, it is not totally invasive. However, I am not interested in giving Google or Comcast information about what general sites I may visit for free when they may profit from that data. Since the Cloudflare solution is stated as one where they will not sell your data or use it for targeting advertising, and is mature, I decided to switch from Google to that.
Encrypted communication also improves security. If someone is able to capture your DNS query and then craft an answer and send it to you before the proper server replies, they can send you to a totally different site with possible malicious intent. In a case like that you may enter “google.com” in your browser, but when your computer tries to resolve “google.com” to something it understands, the bad actor seeing that query sends a reply making your browser connect to a totally different place. (And that place can be full of different “hacks” that can try to do things such as take control of your computer.) The encryption not only means that the attacker cannot see what the query contains, but cannot insert anything into the encrypted channel. Of course, the destination server may have to turn around and query another server over the Internet to resolve a name, so the security can still break down. But since Cloudflare is well-established as a security-conscientious company, it is likely that they take precautions against such attacks when reaching out to other servers over the Internet.
Since dnsmasq does not currently forward requests over an encrypted channel, dnscrypt-proxy is used. That software is installed on the same server as dnsmasq. When dnsmasq needs to query a server on the Internet it instead sends that query to the dnscrypt-proxy service which in turn sends the query to Cloudflare over an encrypted link. If there is ever an issue with Cloudflare or the dnscrypt-proxy service, the built-in DNS resolver on the Ubiquity appliance acting as the main router for the home network is used. While that does not provide any encryption or internal resolution services, it will still allow devices to successfully perform DNS queries for places on the Internet.
As far as DHCP is concerned, dnsmasq is easy to configure to meet all my goals. For example, my main desktop computer may be assigned a random IP address by dnsmasq using DHCP, but any device on the home network can reach it if I tell it to go to “KARYLPC.internal.thesteins.org”. If a device needs to always have the same IP address when it connects to the home network, (useful for “port forwarding” rules–not discussed in this article), dnsmasq can do that too. While I no longer have dnsmasq serving both the “internal” and the “guest” networks, that has proven to be well within its abilities.