User Tools

Site Tools


computing:bind9dns

This is an old revision of the document!



  • bind9dns
  • Jonathan Haack
  • Haack's Networking
  • webmaster@haacksnetworking.org

bind9dns


Introduction

This tutorial is for users of Debian GNU/Linux to set up an authoritative DNS server using bind9. An authoritative DNS server serves DNS records about other hosts … that is, you use an authoritative server to serve domain.com's A, AAAA, DMARC, SPF, etc., records. These records can then be queried by a recursive DNS resolver. Bind9 can also do recursion, however, it's far more commonly used as an authoritative DNS server. Unbound, on the other hand, is designed primarily for recursive DNS. If you are just looking to protect against leaks and guard DNS privacy, you should instead head over unbound-dns instead. In this tutorial, we will:

  • Create apache2 reverse proxy (apache2 is public; serves requests upstream to localhost:10000)
  • Create webmin server cluster, configure each node's firewall and fail2ban
  • Adjust webmin's global bind9 settings to work with underlying base server settings
  • Add zone using CLI
  • Add zone using webmin
  • Setup DNSSEC using CLI
  • Setup DNSSEC using webmin
  • Configuring your Registrar's GLUE records, i.e., registering and pointing nameservers

This tutorial presumes you already have a working and sufficiently hardened VM/VPS with a LAMP stack and access to PTR for three different external IPs. If you don't know what some or all of that is, take a step back and start with Apache Survival before proceeding. If you feel comfortable so far, and you have three different VMs/VPSs setup and ready, well then carry on.


Part 1 - Host Setup

Make sure that you set your full hostname with hostnamectl set-hostname nsX.haacksnetworking.com and/or equivalent for your use-case on each node. After that, ensure that each host has local DNS resolution via /etc/hosts/ that informs each node about itself, its alias, and those of every other node in its cluster. Something like this will suffice (on each node):

127.0.0.1       localhost
127.0.1.1       ns1.haacksnetworking.com ns1
 
8.28.86.113     ns1.haacksnetworking.com ns1
8.28.86.114     ns2.haacksnetworking.com ns2
8.28.86.115     ns3.haacksnetworking.com ns3
 
2604:fa40:0:10::11  ns1.haacksnetworking.com ns1
2604:fa40:0:10::12  ns2.haacksnetworking.com ns2
2604:fa40:0:10::13  ns3.haacksnetworking.com ns3
 
# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

A firewall is not strictly necessary so long as fail2ban is running, which ensures that heinous and/or repetitive queries get dropped. If you choose to go without a firewall, ensure you are strictly configuring all services and that you can recite every service listed in ss -tulpn by heart and why they need to be there. It is also okay to use a firewall so long as you do not use it as an excuse for mis-configuring your server(s). In my case, I use ufw which is simply a command line skin for iptables. It makes the configuration a little easier. Here are example configurations for each node:

Here is ns1.haacksnetworking.com:

ufw reset
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 53/tcp
ufw allow 53/udp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Here is ns2.haacksnetworking.com:

ufw reset
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 53/tcp
ufw allow 53/udp
ufw allow from 8.28.86.113 to any port 80 proto tcp
ufw allow from 8.28.86.113 to any port 443 proto tcp
ufw allow from 8.28.86.113 to any port 10000:10010 proto tcp
ufw allow from 2604:fa40:0:10::11 to any port 80 proto tcp
ufw allow from 2604:fa40:0:10::11 to any port 443 proto tcp
ufw allow from 2604:fa40:0:10::11 to any port 10000:10010 proto tcp
ufw enable

Here is ns3.haacksnetworking.com:

ufw reset
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 53/tcp
ufw allow 53/udp
ufw allow from 8.28.86.113 to any port 80 proto tcp
ufw allow from 8.28.86.113 to any port 443 proto tcp
ufw allow from 8.28.86.113 to any port 10000:10010 proto tcp
ufw allow from 2604:fa40:0:10::11 to any port 80 proto tcp
ufw allow from 2604:fa40:0:10::11 to any port 443 proto tcp
ufw allow from 2604:fa40:0:10::11 to any port 10000:10010 proto tcp
ufw enable

As you can see, ns2 and ns3 restrict all access on 80/443 to ns1. This is because there is no need to access these nodes directly, as both bind9 and later webmin will directly instruct these slaves with their configurations. Ns1, on the other hand, should be publicly accessible by design. We will secure it later with a strong password (25 characters or more), a reverse proxy, and fail2ban. One can additionally, if they so choose, add source-IP rules to the master node, but I think this is overkill. In my case, I want the master node to be accessible to me everywhere. The 10000-10010 range is for the webmin clustering features.

The first thing is to establish the root zone on the master and then tit the two slaves to it.

oemb1905 2025/12/26 17:58

computing/bind9dns.1766871198.txt.gz · Last modified: by oemb1905