In the last article of our Home Server series, we tackled the deployment of a timeserver. This also provided us with some useful tooling to set up more container deployments. Let's continue on this approach and tackle DNS and DHCP.
This series is explaining how we are setting up a home server from scratch. You can find links to the previous articles below.
- Intro & Concept
- Hardware & OS
- Time, DHCP, DNS Server
- Git Server
- File, Calendar, Contact Sync
- Application Dashboard
This time, we will automate more deployments. Let's go! :)
Before going into the deployment, I have to introduce two core technologies. In case you already know what DNS and DHCP are, please feel free to skip this section.
DNS (Domain Name System) is a technology, that resolves hostnames into IP Addresses. This seems, pretty low-tech, isn't it? Well, basically every browser request that you are performing uses DNS. I don't want to go into too many details, but it works pretty much like this.
- You will open a Browser and point to https://example.com
- Your Browser will go to the next available DNS recursive resolver, which is most likely from your ISP or another public machine
- The resolver queries a DNS root nameserver
- The root nameserver will provide you with the address for the Top Level Domain (TLD) nameserver (.com in our case)
- The resolver then makes a request to the TLD nameserver
- The TLD nameserver answers with the domain's nameserver
- The domain nameserver replies to the resolver with a valid IP address
- The browser makes a request to this IP address
As you can see, there are many requests happening. Very often, this allows your ISP to track what you are doing. But, this isn't the concern here. There is an even more interesting thing.
Ads on a website are typically coming from another server. For example, if you open a website (https://youtube.com), you may see advertisements. In general, these advertisements are located on another domain (youtube.adnet.com) or subdomain (ads.youtube.com). This allows us to use filters and exclude these ads from our network.
You may not be aware of it, but basically every modern router already provides DHCP. In case you are using your Wi-Fi at home or LAN connection, you may already have a running DHCP service. This service is meant to provide you with a valid IP address in your local network.
So... why should you bother to set up your own? Well, there is a lot that you can learn from your own setup. Getting some understanding of typical network services (like DHCP, DNS, NTP, etc.) is pretty valuable when it comes to debugging. But, there is also the benefit, that you can learn more about Podman and containers in general. In addition, you will get the benefits of a fully customizable behavior.
Since DHCP provides IP addresses already, it slowly became the standard way of promoting general network settings. If a new device joins your network, you are able to provide an IP address, but also a gateway, DNS servers, NTP servers and much more.
Furthermore, it is mandatory that your home server has a static IP Address on its own for this case. So, let's skip it for now.
Pi-hole is meant to provide network wide ad blocking. This is done by offering a DNS caching server/forwarder and a list of filters. If you configure your machines (either manually or via DHCP) to use Pi-Hole as your DNS server, the service will take care of the rest.
- Cache of DNS requests
- Avoid DNS requests to know ad servers
- Improve network performance (by reducing DNS requests and traffic)
- Provide monitoring statistics
So, it is an awesome choice for a DNS server for us. Optionally, you can also use the DHCP capabilities. Please check out the very detailed documentation of Pi-hole beforehand.
For the setup, we are opting for a Podman container (yet again) and automate the deployment with Ansible (yet again).
Let's create a new Ansible playbook that deploys Pi-hole in a Podman container.
As you can see, we are playing a bit with variables (because we can). Let me go through these.
We also need a template, that provides our container as a system service. This concept was already done in the previous article with NTP. In case you want to know more about Podman and systemd, please consider reading the article "Podman - systemd container management".
For now, let's create the template.
That's already it. We can run our playbook and hope that everything works (crossing fingers).
# Run the playbook
$ ansible-playbook -i IP_ADDRESS, -u USER -k -K ansible/playbooks/deploy_pihole_container.yml
And that should be it. You can also log in to the home server and check via systemd if everything is up.
# Check if the service is running
$ systemctl status container-pihole-app.service
# Check if the container is really running
$ podman ps -a
If you really want to have a look at DHCP + DNS via Pi-hole, you will need to run the container with
--network=host, since DHCP works on broadcast only. Most likely this will conflict with local DNS resolvers, and you need to take care of these, too.
Furthermore, please read the Pi-hole articles very thoroughly.
After the deployment, you can test the configuration from any other machine in your network. The below commands can be used on a Mac or Linux device.
# Test DNS resolving with dig
$ dig @HOME_SERVER_IP_ADDRESS example.com
;; ANSWER SECTION:
example.com. 20404 IN A 220.127.116.11
# Test DNS resolving with nslookup
$ nslookup example.com HOME_SERVER_IP_ADDRESS
If this is working well, you can continue with the configuration of Pi-hole.
Configuring Pi-hole can be done with the web interface. Point your browser to
http://HOME_SERVER and you should be prompted with a login. Enter your chosen password from the above setup step. You should see the initial configuration screen.
Here you can find all the settings you might like:
- configure your own domain records
- configure your upstream DNS resolver (including a cool list)
- configure the DHCP server (if you know what you are doing)
I recommend to start with the basics and slowly dig more into it.
To make your DNS, NTP (optionally DHCP) setup work in your entire network, you need to perform some more steps in your local network.
After setting up, testing and configuring your Pi-hole container, you need to adjust some settings on your router to promote the new DNS server to your network. Alternatively, you can configure a single client, as described in the following section.
Search for the DHCP settings in your router. In my case, the setting is hidden in
Home -> Network -> Settings -> DHCP -> local DNS server.
Edit this setting, so it points to your new DNS server (aka home server)
After this edit, you should monitor your network for at least 24h very closely. Many clients will not see these updates on the same day, but will only update them when re-connected (got a new address via DHCP).
Since this topic is completely different for each router, the Pi-hole community started to document these.
If you just want to re-configure a single client, you can do this without touching your router. Windows, macOS, and Linux support the usage of a dedicated DNS server. But, this can also lead to weird situations. If you configure a device manually and carry it over to a new network, you might need to touch it again.
If you are using Fedora as your workstation, you might be lucky.
Open "Settings" aka "GNOME Settings" and look for your wired connections in the "Network" panel and for wireless connections in your "Wi-Fi" panel. After opening the existing you connection, you will find a dialog similar to the screenshot below.
In the IPv4 and IPv6 tab, you are able to configure your own DNS server.
I have entered my home server address here and marked that DNS should not be automatic. Hitting apply will save the changes and they will be used immediately.
Repository & Code
As always, the code is made public in my fedora_homeserver repository.
I am also creating a collection for such deployments, which is under heavy development. Ultimately, it will replace most of the container deployment code in my personal home server.
Docs & Links
Lastly, let me provide some useful links, that might be helpful.
As you might have recognized, the Fedora Home Server articles took a bit longer. Doing these network things right and providing enough background information to get started was my goal. Doing this right took some time. I really hope, that the articles help you to play more with your home server.
Now, let's have a look at the coming articles, where we will deploy even more things with Podman and also give k3s a brief try.
You can follow this series with the next article, if you like.