Homelab DNS Server with Raspberry Pi and Bind9

Installation Bind9

Once we have a static IP and have rebooted the Raspi, we can install Bind DNS.

Sudo apt-get install bind9

To get quick and easy results you may use a configuration script written by Virtual aspects. It will build all required configurations and zone files.

I will show here the most important files and their functions. You will find all files in directory /etc/bind.

  • named.conf: The central configuration file. From here further configuration files are merged by include commands. This makes configurations better readable.
  • named.conf.options: Is loaded from named.conf. This defines the basic behavior of Bind. E.g. on which interfaces bind should answer and to whom DNS requests are forwarded (Forwarders). When Bind is installed, a file with this name will be created with default values. It is recommended to rename this file and to create a new one.
  • named.conf.local: Is loaded from named.conf. Here you define local zones. For each forward and reverse zone there’s a database file in which the address assignments are defined.
  • named.conf.default-zones: Is loaded from named.conf. Structure is similar to named.conf.local, but with zones for localhost and broadcast.
  • db.<domain>: Forward zone file for each domain
  • db.<subnet>.in-addr.arpa: Reverse zone file for each subnet. The subnet is specified in reverse order. E.g. 10.1.20.0 would have the reverse zone file db.20.1.10.in-addr.arpa

Structure of a simple zone

Bind9 zone files have numerous parameters and configuration options. I don’t want to go into this in this article and we will limit ourselves to a minimum. After all, we are talking about a Homelab and not about a security-critical system.

My lab domain is “lab.local” and has the class-C subnet 10.0.10.0./24 with 256 addresses. We need to create two zonefiles for that. One for forward name resolution and one for reverse lookup.

sudo touch /etc/bind/db.lab.local
sudo touch /etc/bind/db.10.0.10.in-addr.arpa

The command above will create two empty files that will become our zone files. Forward zone files have a naming convention of db.<domain>. Reverse zone files are a bit special in naming convention. The name is always db.<subnet in reverse order>.in-addr.arpa. My subnet is not the best example, because 10.0.10 is the same forward and backward. Imagine your subnet is 10.1.20.0/24, then the naming of the reverse zone file would be db.20.1.10.in-addr.arpa.

Let’s first have a look at the forward zone file.

sudo nano /etc/bind/db.lab.local

The first parameter is $ORIGIN. This is the name of the domain, followed by a dot. This entry makes sure that queries are supplemented by the domain name. host01 becomes host01.lab.local. Correct syntax is extremely important for Bind and the service will not start if there are errors in the configuration or zone files.

The second parameter specifies the validity of the entries and the time to live ($TTL). In the example below it is set to one day (1d).

So the first two lines will be:

$ORIGIN lab.local.
$TTL  1d

This is followed by the SOA (start of authority) declaration with information about the name server and the hostmaster email address. Additionally the serial number and refresh and expiration times.

After the SOA declaration the name server responsible for this zone is specified. In the example this is the hostname of the Raspi dns.lab.local.

The actual adress-entries are the so-called A-records.

<host> IN A <IP>

There are also alias names aka canonical names (CNAME). In my case the DNS server is also NTP server. Therefore the alias ntp points to dns.lab.local. Very important is the dot at the end of the name. This is how Bind notices that the name is a fully qualified name (FQDN) and therefore the domain suffix is not appended again.

Below you can see a minimal zone file of the lab.local forward zone.

$ORIGIN lab.local.
$TTL 1d
@ IN SOA localhost. root.localhost. (
2020042901 ; Serial
1d ; Refresh
2h ; Retry
1w ; Expire
2d ; Negative Cache TTL
)
IN NS dns.lab.local.
;
dns IN A 10.0.10.2
ntp IN CNAME dns.lab.local.
;
esx01 IN A 10.0.10.111
esx02 IN A 10.0.10.112
esx03 IN A 10.0.10.113
esx04 IN A 10.0.10.114
vc    IN A 10.0.10.100

Comment lines start with a semicolon. Everything after a semicolon will be ignored. Once we’ve finished editing, we save the zone with [Ctrl] + [o] and exit the editor with [Ctrl] + [x].

Let’s look at the reverse zone file:

sudo nano /etc/bind/db.10.0.10.in-addr.arpa

A reverse zone file has a similar structure. All entries follow the pattern:

<address> IN PTR <fqdn>.

Make sure to use a dot after FQDN. Below you can see a minimal reverse zone file.

$ORIGIN 10.0.10.in-addr.arpa.
$TTL 1d
@ IN SOA localhost. root.localhost. (
2020042901 ; Serial
1d ; Refresh
2h ; Retry
1w ; Expire
2d ; Negative Cache TTL
)
IN NS dns.lab.local.
;
2 IN PTR dns.lab.local.
;
111 IN PTR esx01.lab.local.
112 IN PTR esx02.lab.local.
113 IN PTR esx03.lab.local.
114 IN PTR esx04.lab.local.
;
100 IN PTR vc.lab.local.

Save the file with [Ctrl] + [o] and leave the editor with [Ctrl] + [x].

Now we have forward and reverse zone file for zone lab.local. Before they can take effect, we need to announce the zone to Bind. To do so we edit the file named.conf.local.

sudo nano named.conf.local

Add these lines to the configuration:

zone "lab.local" {
type master;
notify no;
file "/etc/bind/db.lab.local";
};
zone "10.0.10.in-addr.arpa" {
type master;
notify no;
file "/etc/bind/db.10.0.10.in-addr.arpa";
};

Once again, save and exit the editor. The Bind service needs to be restarted in order to commit changes.

sudo service bind9 restart

In case there’s something wrong with with the configuration, the service won’t start.

Summary

We have built a full-fledged DNS and time server with simple means. Thanks to its low power consumption, it can remain powered on or can be started right before the lab environment is started. In my case, the DNS Raspi is connected to a power distribution bar, together with the ESXi hosts. The Raspi boots fast and it is usually finished before the iPMI interfaces of the hosts are online. When the cluster starts, it has full NTP and DNS functionality.

Leave a Reply

Your email address will not be published. Required fields are marked *