JRehkemper.de

Install Authorative Bind DNS Server on RHEL

Bind or NAMED is an opensource dns server. It can be used as an recursive or authorative dns server.
In this article I will configure it as an authorative dns server on an rhel-based alma linux server.

What does authorative mean?

There are two kinds of DNS-Servers. Recursive and Authorative.
Recursive DNS-Servers will query other DNS-Servers to resolve your request. They are more or less just a worker and do not hold any domains or zones by them selfes.
Authorative DNS-Servers on the other hand do hold one or more DNS Domains or Zones. They usually only answer to requests for those domains and will not resolve any other requested domains.

Installation

First lets install bind from the base repositories.

$ dnf install bind

After that lets start and enable the service, so that it will be also started after a system reboot.

$ systemctl enable --now named

Configuration

The configuration for the dns server is called named.conf, but the location my differ depending on your distribution.
On Alma Linux it is located in /etc/named.conf. Ubuntu on the other hand uses /etc/bind/named.conf.

Lets open the config file and go over a few settings.

$ vim /etc/named.conf
options {
  // on which ip and port should bind listen?
  listen-on port 53 { any; };
  listen-on-v6 port 53 { any; };

  // who may use this dns server
  allow-query     { any; };
  // do not allow recursion; This is to create a recursive dns-server.
  recursion no;

}

By default bind will only listen to localhost requests (127.0.0.1) on Port 53. We need to change the ip to either the external ip of the server or 0.0.0.0 to listen on all interfaces.
allow-query is used to restrict who may use this dns server. If you use it as an recursive dns server, you should restrict this, but since we want to use it as an authorative server, we can set it to any, because we want the whole world to be able to query the ip address of our public services. But if you do so make sure to set recursion to no.

The next step would be to import the zone file. This zone file will contain our dns records, which our dns server will respond to.

zone "mysubdomain.domain.org" {
  type master;
  file "/etc/named/zones/mysubdomaon.domain.org";
}

zone defines the name of the dns-zone or domain that the server should manage.
The type master inecates, that this is the authorative dns server for that zone.
file define the zone file, which will contain the dns records.

Now that our named.conf is configured we need to create our zone files.
For better organisation I like to create a new subdirectory /etc/named/zones/, but that is optional.

$ mkdir -p /etc/named/zones

Then we can create our first zone.

$ vim /etc/named/zones/mysubdomain.org
$TTL    604800

@       IN      SOA     ns1.domain.org. system.domain.org. (
                             01         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
; Name Servers
                IN  NS  ns1.domain.org.

; A-Records for Name Servers
ns1             IN  A   10.0.0.1
                                                                                                  
; Other A-Records
@               IN      A       10.0.0.1
test            IN      CNAME   test.domain.org.
*               IN      CNAME   wildcard.domain.org.

Lets go over some of the settings above.
The $TTL defines how long other dns servers should keep this configuration in cache before requesting an update. If you have frequent changes in you dns, you should keep this value fairly low.

The line @ IN SOA ns1.domain.org. system.domain.org. Defines that this is the authorative dns server. @ at refers to this zone, mysubdomain.domain.org in our case. IN is the keyword to create a new internet record. It will also be used with all the other records. SOA stands for State of Authority which simply means, “I’m the authorative dns server”. ns1.domain.org is the name of our authorative dns server, so the server it self in this case. The last Part system.domain.org is the email-address of the administrator (system@domain.org) which can be contacted in case of problem or other requests.
If you look closely, you will see that all the domain are ending on a dot(.). Technically DNS Adresses always end on a dot, but usualy it is omited for convenience. But since Bind is a DNS Server, it needs the technically correct syntax. In the brackets we have some more information for other dns-server quering this zone.
The serial should be incremented by the administrator everytime a change is made. That way clients can identify if something changed since the last query. The other parameters refresh, retry, expire, cache ttl are all instructions for caching of the dns clients.

Below that are the record definitions, which follow the same syntax.

<name> IN <record-type> <value>

The name is the dns name (which will be suffixed with the value of origin as described earlier).
The record-type can be:

  • A for ipv4 address
  • AAAA for ipv6 address
  • NS for DNS Servers of that zone
  • MX for mail-servers
  • CNAME for aliases
  • and more

Bind also supports wildcard dns-records. That means you can use * to match every subdomain or just match parts like test-*.

The last thing would be to check the configuration for syntax errors.

$ named-checkconf

Starting the Service

Now that the configuration is finished we can start the service or reload if it is already running.

$ systemctl reload named

Configure Firewall

The last thing to do is to open the port in the firewall.
DNS uses port 53/udp.

$ firewall-cmd --add-port=53/udp
$ firewall-cmd --runtime-to-permanent

Test with a client

Now that our DNS Server is setup we can test with an external client.
You can use a few different tools for that.

$ nslookup test.mysubdomain.domain.org <dns-server>

$ dig +<dns-server> test.mysubdomain.domain.org

You should get the correct answer base on your zones file.

profile picture of the author

Jannik Rehkemper

I'm an professional Linux Administrator and Hobby Programmer. My training as an IT-Professional started in 2019 and ended in 2022. Since 2023 I'm working as an Linux Administrator.