Install and configure a DNS server with Bind9 on Linux

Emmanuel Gautier / April 19, 2015

9 min read

A service DNS (Domain Name Service) allows domain name resolution to an IP Address and other resources. This service is useful for example for browsing internet websites and not have to know IPs addresses for these websites.


To put in place this kind of service, you need to use a specific technology. The most known one is Bind. This technology, maintained by the Internet Systems Consortium, is used by most of the major existing DNS services across the world including most of the root DNS servers.

In this tutorial, we will learn how to install and configure a DNS service with Bind9. We will use a simple configuration for an HTTP web server, a mail server, ... etc. You don't need to create real service here.

Installation et configuration

The first step is installing the package bind9. If you are on a Debian Like distribution, you can install with the following command:

sudo apt-get install bind9 dnsutils

You need now to configure your system to properly use the fresh new DNS server on your host. To do so, edit the resolv.conf file with the following lines. The DNS queries will be done locally after.

# /etc/resolv.conf

When the server is installed and started, we can configure the first website. The domain name picked does not matter, just avoid using an existing domain name to ease your tests. In this post, we will use the domain name mysite.lan.

The domain name creation is done with a resource named zone creating a new file to define it. This file contains the DNS records sent in the response for a DNS query. These informations can be IP Addresses for different services, sub-domain, TTL before checking again, ... etc.

Here, a configuration example for a domain name:

# /etc/bind/db.mysite.lan
$TTL    604800
@       IN      SOA     ns.mysite.lan. root.mysite.lan. (
                        2           ; Serial
                        604800      ; Refresh
                        86400       ; Retry
                        2419200     ; Expire
                        604800 )    ; Negative Cache TTL
@       IN      NS      ns.mysite.lan.
ns      IN      A
www     IN      A

The domain name configuration is done. Now, we need to declare this configuration in the domain names list of bind9 server.

# /etc/bind/named.conf.local

zone "mysite.lan" {
  type master;
  file "/etc/bind/db.mysite.lan";

Before restarting the server, we will check the configuration to ensure this file is correct to avoid DNS server errors and unavailability of the service. The named-checkzone, included with the package bind9, will check the file syntax.

sudo named-checkzone mysite.lan /etc/bind/db.mysite.lan

We can now restart the server to apply the new configuration.

sudo service bind9 restart


It exists different records type storing different information. Here is a list of the most common ones:

A Record

An A record is a type of DNS record that maps a domain name to an IPv4 address. A DNS resolver uses A records to find the IP address associated with a domain name, allowing web browsers and other applications to connect to servers on the internet.

An A record typically consists of the following parts:

  • name: the domain name for which the record applies, such as
  • ttl: the time-to-live value for the record, which determines how long other DNS servers and clients should cache the record before requesting an update.
  • class: the DNS class, usually IN for internet.
  • type: the type of DNS record, always A.
  • address: the IPv4 address associated with the domain name, such as

Here is an example of an A record:

www    IN    A    A.B.C.D

In this example, the A record maps the domain name to the IPv4 address The 3600 value specifies a TTL of 3600 seconds (1 hour), meaning that other DNS servers and clients can cache the record for up to 1 hour before requesting an update.

AAAA Record

This record is similar to A record and indicates the IPv6 for a given domain this time.

www    IN    AAAA    ::A

CNAME Record (Canonical Name)

It allows creating an alias pointing to another record for the current domain name or another one. It is possible to create CNAME pointing to another CNAME record, but you should avoid it since it increases the number of DNS queries done before resolving the address.

mail    IN    CNAME  www
ftp     IN    CNAME  ftp.domain.tld.
www     IN    A      A.B.C.D

MX Record (Mail Exchange)

The MX record point to an email server. This record must point to a A or AAAA record and can't point to a CNAME record.

However, it is possible to have multiple MX records with priority data allowing having a fallback solution in case an MX server is unreachable.

         IN    MX  10  mail1
         IN    MX  50  mail2
mail1    IN    A       A.B.C.D
mail2    IN    A       A.B.C.D

NS Record (Name Server)

The NS record indicates a DNS server for the domain.

      IN    NS    domain.tld.
ns    IN    A     A.B.C.D

TXT Record

This type allows storing text content. This record is used a lot to verify you are the owner of a domain name. For example, some services like Google Search Console, Github, mail SaaS solutions use this verification method.

domain.tld.    IN    TXT    "text"

SPF Record

An SPF record (Sender Policy Framework record) is a type of DNS record that specifies which mail servers are authorized to send email messages on behalf of a domain name. It helps prevent email spoofing and improves email deliverability by allowing mail servers to check if incoming email messages come from a legitimate source.

The SPF record contains a list of authorized IP addresses and/or hostnames that are allowed to send email messages for a particular domain name. When a recipient mail server receives an email message, it checks the SPF record of the sending domain to verify that the message was sent from an authorized server. If the SPF record doesn't list the sending server, the recipient mail server may reject the message or mark it as spam.

Here's an example SPF record:

v=spf1 ip4: ip4: a -all

DKIM Record

A DKIM record (DomainKeys Identified Mail record) is a type of DNS record that provides a digital signature for email messages to verify that they were sent by an authorized sender and have not been tampered with in transit. DKIM is used for email authentication and can help prevent email spoofing and phishing.

To use DKIM, the sender's mail server signs outgoing email messages with a private key, and the recipient's mail server verifies the signature using a public key published in the DKIM record. If the signature is valid, the message is considered authentic and is more likely to be delivered to the recipient's inbox.

Here's an example DKIM record: IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCdZiQO4OvAK8nhxWgFphLT0y+WJ...more key data...yQIDAQAB"

In this example, the DKIM record specifies a selector (selector1) and a domain ( that correspond to the DKIM signature applied to the outgoing email messages. The v=DKIM1 tag indicates the version of the DKIM protocol used, and the k=rsa tag specifies the algorithm used for the signature. The p tag contains the public key data for the domain, which is used to verify the signature.

SRV Record

A SRV record (Service record) is a type of DNS record that specifies the location of a service on a domain name, such as a SIP server for VoIP, a LDAP server for directory services, or a XMPP server for instant messaging.

The SRV record contains several fields of information, including the service name, the protocol used, the domain name of the service, and the port number where the service is located. The record also specifies a priority and weight value that can be used to determine the order of preference for multiple service providers.

Here's an example SRV record: IN SRV 10 60 5060

SOA Record

A SOA record (Start of Authority record) is a type of DNS record that provides authoritative information about a DNS zone, including the primary nameserver for the zone, the email address of the responsible person for the zone, and various timing values that control how DNS information is cached and updated.

The SOA record is usually the first DNS record in a zone file and contains the following fields:

  • name: the name of the zone, typically the domain name followed by a period.
  • ttl: the time to live value for the zone, which determines how long other DNS servers should cache the information in the zone before requesting updates.
  • class: the DNS class, typically IN for Internet.
  • type: the record type, always SOA.
  • primary nameserver: the hostname of the primary nameserver for the zone.
  • responsible person: the email address of the person responsible for the zone, using a special format with the @ replaced by a . and the . replaced by ..
  • serial number: a version number for the zone that is incremented each time the zone is updated.
  • refresh: the interval at which secondary nameservers should check the primary nameserver for updates.
  • retry: the interval at which secondary nameservers should retry a failed zone transfer.
  • expire: the maximum time that secondary nameservers should use the zone data before considering it expired.
  • minimum TTL: the minimum time to live value that should be used for any record in the zone. IN SOA (
  2022030101 ; serial number
  86400      ; refresh every 24 hours
  7200       ; retry every 2 hours
  604800     ; expire after 1 week
  3600       ; minimum TTL of 1 hour


Now, it's time to check that our DNS server is working properly and check the records you configured are taken into account. For testing purposes, you can use the dig command line. You may need to install it first depending on your Linux distribution.

dig -x

You should have something similar to the following output in your terminal:

; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> -x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63705
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0


;; Query time: 4 msec
;; WHEN: Wed Apr 08 16:30:11 CEST 2015
;; MSG SIZE  rcvd: 63

You can also show all the DNS records for a domain name with the following command:

dig mysite.lan

You can now compare all the records output from the command and that you previously configured. you should have seen the records you configured displayed.


If you're seeking solutions to a problem or need expert advice, I'm here to help! Don't hesitate to book a call with me for a consulting session. Let's discuss your situation and find the best solution together.

Share this post
Follow the RSS feed

Subscribe to the newsletter

Get the latest news about tech new articles and projects.