Install Bind as an authoritative DNS server

Prerequisites

A fixed IP address

Vocabulary

Glue Record

It is possible for a zone to be the authority for its own name server. For example, the name servers for the zone google.com are ns1.google.com, ns2.google.com... This causes a chicken egg problem where to get the IP of ns1.google.com, you need to ask ns1.google.com. To solve this, it is possible to use glue records. These are additional records in the parent zone that contain the IP of the child zone name servers.

Primary Name Server

The primary name server is the source of the data. This is the one that you use to change the data.

Record

A record is an entry in a zone. Records have both a type that categories the kind of data that it contain. Some common types are

A: used for IPv4 addresses
AAAA: used for IPv6 addresses
SOA(Start of Authority): contain technical info about a zone
TXT: General purpose record that can contain freetext
NS: Indicate authoritative name servers for a zone
MX: Contain the mail server of a domain
CNAME: this record is an alias to another record.

Secondary Name Server: Secondary name server are used for redundancy and load balancing. They hold a complete copy of the data from the primary server and can answer to the same queries.
Zone: A DNS zone is a portion of the DNS space. For example, if you look at example.org hierarchy, you see 3 zones. One for .(the root), one for .org and one for .example.org. Each zone contains the records for the part of the DNS space it control. For example, the last zone will contain the record for www.example.org.

Install

# apt install bind9

Configure

Limit Information Disclosure

Version might be useful to an attacker that is searching known vulnerabilities on your server. Let’s make its life more difficult by hiding it.

Note that it is not an excuse to run old vulnerable software. The goal is just to slow down attacker in case of newly published security exploit, so you have enough time to update before getting pwned.

To prevent the information being returned edit the file /etc/bind/named.conf.options and add the version and hostname lines

options {
    
    version none;
    hostname none;
    
}

Response Rate Limiting (RRL)

DNS servers can be abused to perform DoS attacks on other innocent victims. This are several issues for that

attacker will waste your bandwidth while attacking other servers
you are seen by the victim as the source of the attack. You can then appear in blacklists which will be an issue for you
you are making DoS attacks easier for the attackers and contribute to the problem

For more details, read the quick introduction to response rate limiting from ISC (Bind author).

Rate limiting allows to render such attacks ineffective while still answering legitimate responses. To enable this, add the block rate-limit in file /etc/bind/named.conf.options

options {

        rate-limit {
                responses-per-second 10;
                exempt-clients { 127.0.0.1; ::1; };
        };

}

Listen on public IP

By default, Bind will only reply to queries from localhost. To use it as an authoritative server, you must make it listen on a public IP. Once again the file to modify is /etc/bind/named.conf.options

options {

        listen-on { any; };
        listen-on-v6 { any; };
        allow-recursion { 127.0.0.1; ::1; };

}

The 3 options to modify are (these should already be there in the file):

listen-on: List of IPv4 addresses to listen on. any; means all. Otherwise you can list IPs: listen-on { 203.0.113.23; 127.0.0.1; }
listen-on-v6: Same as above for IPv6 addresses
allow-recursion: IPs to witch the server will reply to recursive queries (when it need to contact other severs to get the response). This must never contain any public IP.

Firewall

Bind will listen on port 53, on both TCP and UDP. Assuming that you configured nftables as described, you can edit file /etc/nftables/main_config.conf and add

# Bind
add element  inet main  tcp_port_in { 53 }
add element  inet main  udp_port_in { 53 }

and activate it using

$ sudo /etc/nftables/reload_main.conf

Reload Configuration

Bind9 can be told to reload its configuration using

$ sudo rndc reload

Warning: This command is working asynchronously. It is recommended to verify that everything was fine using

$ sudo systemctl status bind9.service 
● bind9.service - BIND Domain Name Server
   Loaded: loaded (/lib/systemd/system/bind9.service; enabled)
  Drop-In: /run/systemd/generator/bind9.service.d
           └─50-insserv.conf-$named.conf
   Active: active (running) since Mon 2016-08-08 19:30:41 UTC; 1 weeks 5 days ago
     Docs: man:named(8)
  Process: 6086 ExecStop=/usr/sbin/rndc stop (code=exited, status=0/SUCCESS)
 Main PID: 6091 (named)
   CGroup: /system.slice/bind9.service
           └─6091 /usr/sbin/named -f -u bind

Aug 21 09:10:12 server.example.org named[6091]: zone example.org/IN (signed): reconfiguring zone keys
Aug 21 09:10:12 server.example.org named[6091]: zone example.org/IN (signed): next key event: 21-Aug-2016 10:10:12.300
Aug 21 09:10:12 server.example.org named[6091]: reloading zones succeeded
Aug 21 09:10:12 server.example.org named[6091]: all zones loaded
Aug 21 09:10:12 server.example.org named[6091]: zone example.org/IN (unsigned): loaded serial 2016082100
Aug 21 09:10:12 server.example.org named[6091]: running
Aug 21 09:10:12 server.example.org named[6091]: zone example.org/IN (signed): serial 2016082100 (unsigned 2016082100)
Aug 21 09:10:12 server.example.org named[6091]: zone example.org/IN (signed): sending notifies (serial 2016082100)
Aug 21 09:10:12 server.example.org named[6091]: client 203.0.113.199#38278 (example.org): transfer of 'example.org/IN': IXFR started
Aug 21 09:10:12 server.example.org named[6091]: client 203.0.113.199#38278 (example.org): transfer of 'example.org/IN': IXFR ended

This will show you the last lines of the log. If anything went wrong, it should appear in red.

Test for open recursion

Open recursive DNS servers are really BAD. You can test your server at http://openresolver.com.

Adding a Zone

Let's add a zone for example.org to our server.

Secondary Name Server

To ensure the resilience the service hosted on your domain, you must use one or several secondary name servers. The criteria to choose a secondary name server are

Geographic location: This is important for the speed of your DNS queries. Servers far away mean slow DNS responses and will slow down your full product
IPV6: This is becoming more and more important. Make sure your DNS server support it
DNSSEC: If you care about security and plan to enable DNSSEC, you need to make sure that your secondary server support it as well
Support Notify: This is a feature where the master DNS server notify the secondary in case of change. This allows to speed up change propagation

If you are hosting your primary name server on a server that you are renting, there is good chance that your provider provides you with a free secondary name server. Otherwise, search for secondary name server online. They are several free or paid options available.

Zone File

First create a file /etc/bind/master/example.org

$ORIGIN example.org.
$TTL 1d ; Time a cache will keep responses

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;                     Zone                                 ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

@                      SOA    ns1 hostmaster (
                                2016123100 ; serial
                                12h   ; Frequency of zone transfer from slave
                                15m   ; delay before slave retries after a zone transfer failure
                                4w    ; Time a slave will keep the data in case it cannot contact the master
                                1h    ; Time a cache will keep negative responses (NXDOMAIN)
                              )
@                      NS     ns1
@                      NS     ns2

ns1                    A      198.51.100.42
                       AAAA   2001:db8:57:12::1
ns2                    A      203.0.113.42
                       AAAA   2001:db8:af9b:d72e::1

$ORIGIN

Default suffix for the entries bellow. Eg. ns1 will be read as ns1.example.org. Note that the dot at the end is important. Entries that end with a dot don't get the origin added to them.

$TTL

Default Time To Live for entries. This is the amount of time a cache will keep a response.

SOA Record (Start of Authority)

This record define the global parameters of the zone. It contains the following information.

Name Server: Any authoritative name server for the zone. Typically, you will put your primary name server.
Email Address: Email address of the person responsible for the zone. Here the value will be expanded to hostmaster.example.com. Then the first dot is replaced by a @ giving hostmaster@example.com. RFC 2142 recommend to use the value hostmaster here.
Serial Number: This represent the version number of your zone file. This is used for synchronization between your primary and secondary servers.; Recommended format is yyyymmddnn where yyyy = year, mm = month, dd = day and nn = a sequence number in case you update your zone more than once in the day.
Refresh: How often a secondary will poll the primary server to see if the serial number for the zone has increased. RFC 1912 recommends between 20 minutes and 12 hours. Keep it to 12 hours if your secondary name servers support notify.
Retry: If a secondary was unable to contact the primary at the last refresh, wait the retry value before trying again.
Expire: How long a secondary will still treat its copy of the zone data as valid if it can't contact the primary.
Negative TTL: Time during which response for non existent records are cached.

NS Record: We declare two name servers here ns1.example.org and ns2.example.org.
A and AAAA Records: Then we declare IP addresses for our name servers.

Activate Zone File

Edit file /etc/bind/named.conf.local and add the following

zone "example.org" {
    type master;
    file "/etc/bind/master/example.org";
    
    # List of servers that can copy the zone data
    # Check the documentation of your secondary servers to know the IP list that they use
    allow-transfer {
        203.0.113.42;
    };

    # Notify secondary servers when zone is changed
    notify yes;
};

Reload Bind Config

Reload bind and check for any error in logs using

$ sudo rndc reconfig
$ sudo journalctl -n 100 -u bind9.service

Register Name Servers in Parent Zone

The parent zone in the DNS system in the zone directly above yours in the DNS tree.

For example, if you are configuring example.org, the parent zone will be org. If you are configuring dyn.example.org, the parent zone will be example.org.

Configure With a Registrar

If your zone is for a domain and you don't control the parent zone, you need to configure this in your domain name registrar (the person you bought your domain name from).

Go to the interface of your domain name registrar and register your name servers (ns1.example.org and ns2.example.org).

If your name server address is a subdomain of your zone (here ns1.example.org and example.org) you also need to register a glue record with your registrar.

Configure With Your Own Parent Zone

Assuming your zone is dyn.example.org and the name servers for it are ns1.example.org and ns2.example.org, you need to add these records to the example.org zone

dyn                    NS     ns1
dyn                    NS     ns2

In case your name servers are part of the sub zone (eg. ns1.dyn.example.org), you also need glue records

ns1.dyn                A      198.51.100.42
                       AAAA   2001:db8:57:12::1
ns2.dyn                A      203.0.113.42
                       AAAA   2001:db8:af9b:d72e::1

Register your Zone with Secondary Server

Now go to the configuration for your secondary server and register your domain name.

Validate your Zone

To validate your zone, you can use the following tools

Zonemaster

DNSViz

Editing a Zone

Freeze the Zone

If your zone is dynamic, you first need to freeze the zone

$ sudo rndc freeze dyn.example.org

If you are unsure, run the command anyway, it will show an error in case the zone is not dynamic

$ sudo rndc freeze example.org
rndc: 'freeze' failed: not dynamic

Update the Zone Serial Number

Edit the file of your zone (eg. /etc/bind/master/example.org)

The serial is the number in the SOA record that looks like 2016123100. The format is yyyymmddnn where yyyy = year, mm = month, dd = day and nn = a sequence number in case you update your zone more than once in the day.

This number must increase at every zone update to make sure secondary name servers get the update properly. Otherwise you will create a desynchronization between your primary and secondary servers. This mean that some user will get the new data while some will get the old.

If the date of your serial number has changed since last update, just change it to today's date and reset the sequence to 00.

If you are doing same day update, add 10 to the sequence number.

Warning: For DNSSEC enabled zones, bind will automatically increase the serial number when performing signing operations. While the +10 above will work for most cases, it might not when you just created or updated your zone key. In this case, check the current serial by running dig @ns1.example.org SOA example.org

Update the Needed Records

Reload the Zone

For a non dynamic zone, use

$ rndc reload example.org
zone reload queued

And for a dynamic one, use

$ sudo rndc thaw dyn.example.org
A zone reload and thaw was started.
Check the logs to see the result.

In both case check the log for errors using

$ sudo journalctl -n 100 -u bind9.service

Sign a Zone with DNSSEC

Activate Signing for your Zone

Modify your zone in /etc/bind/named.conf.local and and the following three lines

zone "example.org" {
    #...

    key-directory "/etc/bind/keys";
    auto-dnssec maintain;
    inline-signing yes;

    #...
};

Generate key

$ sudo dnssec-keygen -K /etc/bind/keys/ -a ECDSAP256SHA256 -3 -f KSK example.org
Generating key pair.
Kexample.org.+013+74295
$ sudo chmod 640 /etc/bind/keys/*

Reload zone

$ sudo rndc reconfig

Generate NSEC3 Parameters

$ sudo rndc signing -nsec3param 1 0 10 $(head -c 512 /dev/urandom | sha1sum | cut -b 1-16) example.org
request queued

Validate Zone

At this point your zone should be signing. Wait a few minutes for your primary server to sign all records and for your secondary to get all updates.

You can then validate your zone using the tools mentioned above.

Since you didn't registered our key to the parent zone yet, you will get warnings about non-secure delegation or missing DS records. But everything else should be ok.

Publish Key

Generate a DS Record using

$ sudo dnssec-dsfromkey -2 /etc/bind/keys/Kexample.org.+013+74295.key
example.org. IN DS 74295 13 2 B4ECD847264AD849F1038EB837483DE74F710EAB47F62EF2B224DA6E55294E4F

The output is a DS record that must be registered in your parent zone.

DDNS

Dynamic DNS allows you to change the entries in your name server in real time. It is often used to maintain records for hosts with dynamic IP.

Since dynamic zones are harder to maintain in Bind, you will create a separated subzone separated from our main zone. For this example the zone will be dyn.example.org and the dynamic host home.dyn.example.org.

Create a Subzone

Create the zone dyn.example.org following the instructions above.

If you want DNSSEC for the subzone, follow also instructions to enable DNSSEC.

Make the Zone Dynamic

Now modify the file /etc/bind/named.conf.local and add the update-policy part

zone "dyn.example.org" {
    #...
    
    update-policy {
        grant local-ddns name home.dyn.example.org A;
    };
};

And activate config using

$ sudo rndc reconfig

Anonymous

Search