BIND on Rocky Linux: A Practical Guide to Configuring Your Own DNS Server: Part 1

Why Set Up Your Own DNS Server with BIND?

You likely know the meme "It's always DNS". And now you've decided that you don't want to be part of the DNS problem - you want to be the whole DNS problem. This submission in our DNS series is for you.

Running your own DNS server may sound intimidating, but there are lots of good reasons to do it (and likely an equal amount of bad reasons too!). Maybe you need more control, maybe you want enhanced security, or maybe you just want to see if you can finally outrun that DNS ghost that's been haunting your network. Whatever your reasons, setting up your own DNS server using BIND on Rocky Linux from CIQ (RLC) can be rewarding.

We'll begin by exploring some important high-level concepts - DNS classes and DNS record types.

DNS Classes: IN and More

DNS classes specify the protocol group or namespace within which a given DNS record is valid. The most commonly used DNS class is IN, which stands for 'Internet'. Here are the primary DNS classes:

• IN (Internet): This is the most commonly used DNS class. It represents records that pertain to internet resources.
  • Example: example.com. IN A 192.168.1.1
• CH (Chaos): This class is rarely used and was originally intended for use in the CHAOSnet protocol, an early networking system. It is sometimes used to query BIND version information.
  • Example: version.bind. CH TXT "BIND 9.16.1"
• HS (Hesiod): This class was used in the MIT Athena project to store information such as user accounts and is largely obsolete today.
  • Example: example.hs. HS A 192.0.2.1

Understanding DNS classes is essential for managing records correctly in specific contexts, but in most scenarios, the IN class is all you'll ever need to care about.

DNS Record Types

A DNS record is a type of data structure that encodes information about domain name data stored in DNS databases.

The DNS servers use these DNS records to match user or client queries with the corresponding resource (e.g an IP address) in the DNS database. You provide the DNS server with some information or key to what you know (e.g. www.ciq.com and the server returns the corresponding address record (e.g. 99.83.231.61).

DNS records are crucial for the functionality of the domain name system. Below are some of the most popular DNS record types that you should be familiar with:

• A Record (Address Record): This is arguably the most common DNS record type. It maps a domain name to an IPv4 address. The format for the A record type is:

  <hostname> IN A <IPv4 address>

  • Example: www.example.com IN A 192.168.1.1

• AAAA Record: Similar to an A record but maps a domain name to an IPv6 address. The syntax for the AAAA record type is:

  <hostname> IN AAAA <IPv6 address>

  • Example: www.example.com IN AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334

• CNAME Record (Canonical Name Record): Maps an alias name to the true or canonical domain name. The syntax for the CNAME record type is:

<alias> IN CNAME <canonical domain>

• Example: alias.example.com IN CNAME www.example.com

• MX Record (Mail Exchange Record): Specifies the mail server responsible for receiving email on behalf of a domain. The syntax for this record type is:

  <domain> IN MX <priority> <mail server>

  • Example: example.com IN MX 10 mail.example.com

  The 10 in the example represents the priority of the mail server—lower values indicate higher priority.

• NS Record (Name Server Record): Assigns a domain or sub-domain to a set of name servers. Syntax for NS record type is:

<domain> IN NS <name server>

• Example: example.com IN NS ns1.example.com

• TXT Record: Used to store arbitrary textual data. One popular use of the TXT record type is for domain ownership verification. When used for verification purposes, the assumption is that if you can create or add pseudo-random TXT DNS records on demand, it indicates that you own or have privileged access to edit the zone records for that domain. The syntax for the TXT record type is:

  <domain> IN TXT <text>

  • Example: example.com IN TXT "v=spf1 include:_spf.example.com ~all"

• PTR Record (Pointer Record): Maps an IP address to a domain name (reverse DNS lookup). Think of the PTR record at the converse of the A or AAAA record types. The format is:

<reversed-ip>.in-addr.arpa IN PTR <hostname>

• Example: 1.168.192.in-addr.arpa IN PTR www.example.com

• SRV Record (Service Record): Defines the location of servers for specified services. The format of an SRV record is:

_service._proto.name. ttl IN SRV priority weight port target

• Example: _sip._tcp.example.com IN SRV 10 60 5060 sipserver.example.com

In this example, _*sip._tcp.example.com represents a Session Initiation Protocol service running over the TCP (_tcp*) protocol for the domain example.com. The 10 is the priority of the target server, 60 is the weight used for load balancing if multiple servers have the same priority, and 5060 is the port on which the SIP service is running.

• Another common SRV record example used in Windows Active Directory environments is:

_ldap._tcp.example.com IN SRV 0 5 389 adserver.example.com

• Here, _ldap._tcp.example.com represents the LDAP service running over TCP. The 0 is the priority, 5 is the weight, 389 is the port for the LDAP service, and adserver.example.com is the server providing the LDAP service.
• SOA Record (Start of Authority): Indicates the authoritative information about a domain, including the primary name server, contact email, and other settings. Format for SOA record is:

<domain> IN SOA <primary NS> <contact email> ( <serial> <refresh> <retry> <expire> <minimum TTL> )

• The @ symbol represents the root of the zone, meaning it refers to the domain itself (e.g., example.com).
• Example: @ IN SOA ns1.example.com. admin.example.com. ( 2023110101 3600 1800 1209600 86400 )

Understanding these common DNS records types goes a long way in helping to manage your own DNS zones and ensure proper configuration of your own DNS server.

Installing BIND on Rocky Linux

BIND (Berkeley Internet Name Domain) is a veteran DNS server implementation. It's reliable and widely used in countless environments. In fact, if you can maintain and understand a BIND DNS server setup, all other DNS implementations will be like child's play to you.

To get started with BIND on Rocky Linux from CIQ, you need to install it first. Here's how:

sudo dnf install bind

Once installed, you'll next want to review and customize the main BIND configuration file - typically located at /etc/named.conf. This is where the magic happens—you can define your zones, manage forwarders, and generally make BIND do your bidding.

Fun Fact: The Birth of BIND

Did you know BIND was originally developed at UC Berkeley in the early 1980s? It's one of the oldest and most reliable pieces of software on the internet today, powering countless domains and keeping the web connected.

Basic BIND Configuration

With BIND now installed, we're going to configure it to suit our environment in this section. Let's explore some key configuration options using a sample excerpt from a BIND configuration file.

/etc/named.conf - The Heart of BIND

Like we already mentioned, the /etc/named.conf file is the main configuration file for BIND.

To follow along on your RLC server, you can either copy and paste OR use your favorite text editor to create the example configuration stored under /etc/named.conf shown here.

options { 
   directory "/var/named"; 
   allow-query { any; }; 
   recursion yes; 
};


zone "example.com" IN { 
   type master; 
   file "/var/named/example.com.zone"; 
};

• options: This section sets global server options.
• directory: Specifies the directory where zone files are stored.
• allow-query: Defines which clients are allowed to query the DNS server. In this example, we allow any client.
• recursion: Specifies whether the server will perform recursive queries for clients. Setting it to yes allows the server to resolve queries for clients.
• zone: This section defines the DNS zones managed by BIND. In this case, we have a master zone for example.com.

TIP: Although they often appear to be interchangeable, the concept of a DNS zone is distinct from a Domain name. A domain name refers to the entire namespace, such as ciq.com, including all of its subdomains (such as servers.ciq.com). A zone, on the other hand, refers to a portion of that namespace for which a specific DNS server has administrative authority. Put simply, a zone is an administratively manageable portion of a domain namespace.

Zone Files - The soul of BIND

If named.conf is the heart of BIND, then the Zone file can be regarded as the Soul of BIND or the "Tofu & Potatoes" of BIND. You get the point.

The zone file is a plain text file that contains the DNS records for your domain. In the BIND world, zone files are stored under the /var/named directory by default.

Creating a Zone File

Let's look at and create a basic zone file for the example.com domain. The zone information is stored in this path /var/named/example.com.zone. Use your favourite text editor to create the file OR copy and paste to follow along on your RLC server:

$TTL 86400 
@   IN  SOA ns1.example.com. admin.example.com. ( 
       2025110101 ; Serial 
       3600       ; Refresh 
       1800       ; Retry 
       1209600    ; Expire 
       86400 )    ; Minimum TTL


; This is a comment line


; Nameservers 
   IN  NS  ns1.example.com.


; "A" record for example.com 
@   IN  A   192.168.1.1


; "A" records for ns1 and www hostnames 
ns1 IN  A   192.168.1.10 
www IN  A   192.168.1.20

• $TTL: Sets the default Time-To-Live (in seconds) for records.
• @ : Shortcut for the root of the zone (example.com)
• SOA (Start of Authority): Contains administrative information about the zone.
• Serial: A version number for the zone. Increment this number each time you make changes.
• Refresh, Retry, Expire, Minimum TTL: Control how often other DNS servers check for updates.
• NS Record: Specifies the authoritative name server for the domain.
• A Record: Maps hostnames to IP addresses. Here we have 2 separate A records for the hostnames ns1 and www.

Sanity checks for BIND configuration file

named-checkconf and named-checkzone are command tools that can be used for validating your BIND configuration and zone files before putting them into production. This can help with catching and avoiding simple syntax errors or typos that are otherwise tricky to detect in your BIND configuration files.

named-checkconf

Use this tool to check the syntax of your BIND configuration file (named.conf). Its usage is very simple, you only need to pass the name/path of the target named.conf file as an arguement to the command. Like so:

named-checkconf /etc/named.conf

If there are no syntax errors, the command will return nothing, which is a good sign!

named-checkzone

Use this tool to verify the correctness of a zone file. Pass the path to the target zone file as an argument and you are good to go. For example:

named-checkzone example.com /var/named/example.com.zone

This command will validate the zone file and report any issues it detects. At a minimum named-checkzone will return the version number of the target zone. For our demo zone, you should see an output like:

zone example.com/IN: loaded serial 2025110101 OK

If glaring errors are returned, then you can rest assured that your zone files have passed the basic snuff tests.

With all basic checks in place, we can next go on to starting the BIND service.

Starting and Enabling BIND

With our super simple configuration now in place, we are ready to enable and start the BIND daemon.

sudo systemctl enable named 
sudo systemctl start named

Configuring Your Firewall

Make sure your firewall allows DNS traffic on port 53 (both TCP and UDP):

sudo firewall-cmd --add-port=53/udp --permanent 
sudo firewall-cmd --add-port=53/tcp --permanent 
sudo firewall-cmd --reload

Testing Your basic BIND DNS Server

Once everything is set up, it's time to test your BIND DNS server. With RLC, you'll have access to lots of full-featured command-line utilities for testing DNS. We'll use dig and nslookup here:

dig: According to its manual page - dig is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name server(s) that were queried.

To use dig to query your server, run:

dig @localhost example.com

nslookup: is another popular utility for querying domain name servers. nslookup can be used in two modes: interactive and non-interactive.

Let's use nslookup non-interactively by running:

nslookup example.com localhost

These tools help verify that your server is correctly resolving domain names.

Command-Line Tools for Managing BIND Configuration

BIND comes with several command-line tools that can make managing and configuring your DNS server easier. Below, we cover the most common tools:

rndc (Remote Name Daemon Control)

rndc is a simple yet powerful command-line utility for managing the BIND DNS server remotely. It allows you to perform administrative tasks like reloading the configuration, flushing the cache, or even stopping the server—all without relying on an intermediary service manager like systemd.

• Installation: rndc is installed alongside the BIND package, so there are no additional steps needed.
• Configuration: By default, rndc uses a key file for authentication. The configuration file is usually found at /etc/rndc.conf or /etc/rndc.key. This key must match the key in /etc/named.conf to allow secure communication.

Example Usage:

rndc reload 
rndc flush
rndc stop 

These commands allow you to reload the configuration, flush the DNS cache, or stop the BIND service, respectively.

TIP: DNS in HPC Clusters

In high-performance computing (HPC) clusters, DNS plays a crucial role in ensuring seamless communication between nodes. Each node in an HPC cluster needs to be able to quickly resolve the hostnames of other nodes for effective workload distribution. This ensures efficiency and reduces latency, which is critical when dealing with resource-intensive HPC workloads.

Basic++ BIND features and configuration

Our BIND series titles are beginning to read like a car dealership sales pitch trying to upsell you with useless features for your car beyond the basic package. Sigh. No worries - you can trust us. We don't want to sell you anything in this DNS series.

BUT - if you contact us today and get RLC you'll get 24x7 Rocky Linux support from the industry leader - CIQ. This in turn will unlock the Basic++ BIND features covered in the following sections.

Just kidding. BIND is a FOSS project. It comes free with all the basic, basic++ and advanced++ features wheather you're running RLC, Rocky Linux, RHEL, CentOS Stream, Ubuntu or Debian. Of course, we'd prefer that you run it on RLC :-)!

Moving along now.

Beyond the basic sample that we covered earlier for the example.com zone, we'll be going over some slightly more advanced BIND setups. Specifically sub-domains and split DNS.

Sub-Domains

Sub-domains are an excellent way to organize and manage different sections or services of your main domain. For example, if you have a main domain example.com, you might want sub-domains like blog.example.com or shop.example.com.

In BIND, setting up a sub-domain is as simple as first creating the stub for the sub-domain in /etc/named.conf and then adding a new record to your zone file.

An example stub entry for the shop.example.com sub-domain in /etc/named.conf file might look like this excerpt here:

zone "shop.example.com" { 
   type master; 
   file "/var/named/shop.example.com.zone"; 
};

Here's an example of adding sub-domain records to the - /var/named/shop.example.com.zone - zone file for shop.example.com. Create the file using a text editor or copy & paste the configuration to follow along on your server.

$TTL 86400 
@   IN  SOA ns1.example.com. admin.example.com. ( 
       2023110101 ; Serial 
       3600       ; Refresh 
       1800       ; Retry 
       1209600    ; Expire 
       86400 )    ; Minimum TTL


; Nameservers 
   IN  NS  ns1.example.com.


; A records for subdomain 
shop IN  A   192.168.1.40


; Additional records 
ns1 IN  A   192.168.1.10 
www IN  A   192.168.1.20 
blog IN  A   192.168.1.30

In this example, blog and shop are sub-domains pointing to different IP addresses. This allows you to delegate and separate the administration of different parts of your DNS tree amongst different services or business units within your organization.

Split DNS

Split DNS, also known as split-horizon DNS, is a special purpose DNS configuration where different DNS responses are provided based on the source of the query. This can be useful when you have both internal and external networks and want to serve different DNS records depending on whether the request comes from inside or outside your network. The "views" keyword is responsible for Split DNS feature in BIND.

In BIND, you can achieve split DNS by creating multiple views in your /etc/named.conf configuration file. Here's an example:

view "internal" { 
   match-clients { 192.168.1.0/24; localhost; }; 
   zone "example.com" IN { 
       type master; 
       file "/var/named/internal/example.com.zone"; 
   }; 
};


view "external" { 
   match-clients { any; }; 
   zone "example.com" IN { 
       type master; 
       file "/var/named/external/example.com.zone"; 
   }; 
};

In this configuration:

• Internal View: Only clients from the 192.168.1.0/24 subnet and localhost will use the internal view, which can include internal-only records.
• External View: All other clients will be served by the external view, which contains public records.

This approach enhances security by ensuring that sensitive internal IP addresses are not unintentionally exposed to the outside world (public).

And speaking of security, we'll wrap up this intro guide to BIND with some quick tips for securing your DNS service.

Securing Your BIND Server

Seeing as you've decided to run and maintain your own DNS server, there are some important security considerations that you should keep in mind. We already touched on some of these earlier in this guide, but we are now collecting and repeating them here in point/checklist form.

These high-level considerations and tips can help you be a good netizen and improve the security posture of the DNS servers that you administer for your organization.

1. Limit Recursive Queries: Only allow recursive queries from trusted IPs.
2. Use DNSSEC: Enable DNSSEC to protect against certain types of attacks.
3. Rate Limiting: Set up rate limiting to avoid abuse.
4. Regular Updates: Keep BIND updated to ensure you have the latest security patches.

Wrapping Up

Setting up your own DNS server with BIND might seem like a lot of work, but it gives you complete control over your network's name resolution. Plus, the next time someone blames DNS, you can proudly say, "I got this." In the next part of our series, we'll delve deeper and explore some advanced DNS server features that you can leverage with BIND.