BIND Setup

This is a quick guide to setting up an authoritative name server. It's based loosely on this guide for FreeBSD, but has some additional information. https://blog.andreev.it/?p=4096 The original guide does cover GoDaddy configuration of DS records well though.

Installation

Select a version of BIND from packages or ports. In this example, we will install BIND 9.12

mport install bind912

The configuration files will live in /usr/local/etc/namedb/

Next we need to create a RNDC key. This is used to manage BIND from the command line via rndc utility.

rndc-confgen -a

Fix the permissions on the file it just created

cd /usr/local/etc/namedb
chown root:bind rndc.key
chmod 640 rndc.key

Next we need to enable BIND on system startup

sysrc named_enable="YES"

(or edit /etc/rc.conf and add named_enable="YES")

Now you can start it if you want to verify it's working so far.

service named start

Verify it worked with no errors by doing this:

tail /var/log/messages

Optional: if you want to control the slave servers with rndc also, they must have the same rndc key. Copy it over and edit this on the slave BIND config where XXX.XXX.XXX.XXX is an ip address of the master. This has to be before the options directive.

include "/usr/local/etc/namedb/rndc.key";

controls {
inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };
inet XXX.XXX.XXX.XXX allow { XXX.XXX.XXX.XXX; } keys { "rndc-key"; };
};

On the master and slave, you need to fix the listen directives to use the ip addresses. Use your own IP addresses rather than the ones listed here.

//Master serverlisten-on { 127.0.0.1; 70.91.226.201; };

Now restart BIND on both master and slaves

service named restart

You can optionally use rndc to manage them.

rndc reload
rndc status

rndc -s XXX.XXX.XXX.XXX reload

Check your firewall rules. You need TCP and UDP 53 open for DNS and if you are using rndc remotely port 953 open for all the slaves and master between each other.

If you were going to setup a recursive name server, you would use recursion yes. This is a BAD IDEA for an authoritative name server to do.

Now you need to setup the master to allow zone transfers from the slaves. Put this below the listen-on directive.

allow-transfer { localhost; 70.91.226.203; };
notify yes;

You can either use the dynamic directory or master directory to store zone files. This depends on your use case what makes sense.

zone "midnightbsd.org" {
type master;
file "/usr/local/etc/namedb/dynamic/midnightbsd.org";
};

Next you will create the zone file listed above.

$TTL    604800
@       IN      SOA     ns1.midnightbsd.org.       admin.midnightbsd.org. (
                        2018101901;     Serial
                        3H;             Refresh
                        15M;            Retry
                        2W;             Expiry
                        1D );           Minimum

; name servers - NS records
        IN      NS      ns1.midnightbsd.org.
        IN      NS      ns2.midnightbsd.org.

; name servers - A records
ns1.midnightbsd.org.       IN      A       70.91.226.201
ns1.midnightbsd.org.       IN      A 70.91.226.203

; other servers - A records
www.midnightbsd.org.       IN      A       70.91.226.201

You will likely also want MX records for mail delivery. That's out of scope for this article.

You can reload with rncd or using service named restart. Be sure to check /var/log/messages for any errors in case you have typos!

Now slaves are configured a little differently.

zone "midnightbsd.org" {
        type slave;
        masters { 70.91.226.201; };
        file "/usr/local/etc/namedb/dynamic/db.midnightbsd.org";
};

You may also want to add allow-transfer { localhost; 70.91.226.203; }; so that the whole internet can't download your zones.

Restart the slave named.

Now you can test things out with nslookup, dig or drill depending on your preference.

nslookup www.midnightbsd.org 70.91.226.201

nslookup www.midnightbsd.org 70.91.226.203

Both of these should respond with valid records.

You can also test with an online tool to make sure others can find them. https://mxtoolbox.com/dnscheck.aspx

Another option is to query google dns nslookup www.midnightbsd.org 8.8.8.8

DNSSEC

Older BIND release instructions (9.12)

On the master, add this after the listen-on directive in named.conf

dnssec-enable yes;
key-directory "/usr/local/etc/namedb/keys";

add this at the very bottom of named.conf

auto-dnssec maintain;
inline-signing yes;

`Newer bind release (9.16)`

add the key directory to named.conf in options

key-directory "/usr/local/etc/namedb/keys";

Per zone, add

dnssec-policy "default";

You will likely want these in the dynamic directory on MidnightBSD as the permissions are changed on master and it won't be able to write to the directory for the signed files on startup!

If you want to learn more about the DNSSEC changes in 9.16, look at http://ddiguru.com/blog/bind-9-16-release-info The dnssec-policy stuff is new and you can make your own custom rules.

`Shared instructions:`

Create the keys directory

mkdir /usr/local/etc/namedb/keys
cd /usr/local/etc/namedb/keys

Now create the signing keys

dnssec-keygen -a RSASHA256 -b 2048 -f KSK -n ZONE midnightbsd.org
dnssec-keygen -a RSASHA256 -b 2048 -n ZONE midnightbsd.org

cd usr/local/etc/namedb/ && chown -R bind:bind keys

Restart BIND

it should automatically generate signed versions of the zone files. These may not have the same identical version as the tool will increment them on it's own. Continue to make changes to the original unsigned files not the signed ones and bind will do it's thing to keep them updated.

There is one more step. You must modify some records in your registrar for your zones. These are called DS records. If you don't do this, no one will be able to verify your zones. You first need to get info from the keys you generated earlier. They have a web interface to input the values you get from the commands below.

cd /usr/local/etc/namedb/keys
dnssec-dsfromkey Kmidnihgtbsd.org.+008+23956.key
midnightbsd.org. IN DS 23956 8 1 2DA94FECA549E0A2B137FA6C64D09D2CBADF8864
midnightbsd.org. IN DS 23956 8 2 8CC2CB79E1B8A6767F11230485C7499D52162135E1F6DAA503ADEC4470E417A9

`Useful Stuff`

Find out what the algorithm numbers are.

https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

Validate the DNSSEC on your domain

https://dnssec-analyzer.verisignlabs.com/

http://dnsviz.net/d/useragent.us/dnssec/

This guide is targeted at the more modern automated key management in BIND. If you want to do this old school, checkout this article https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2

Installation Select a version of BIND from packages or ports. In this example, we will install BIND 9.12

mport install bind912

The configuration files will live in /usr/local/etc/namedb/

Next we need to create a RNDC key. This is used to manage BIND from the command line via rndc utility.

rndc-confgen -a

Fix the permissions on the file it just created

cd /usr/local/etc/namedb chown root:bind rndc.key chmod 640 rndc.key

Next we need to enable BIND on system startup

sysrc named_enable="YES"

(or edit /etc/rc.conf and add named_enable="YES")

Now you can start it if you want to verify it's working so far.

service named start

Verify it worked with no errors by doing this:

tail /var/log/messages

Optional: if you want to control the slave servers with rndc also, they must have the same rndc key. Copy it over and edit this on the slave BIND config where XXX.XXX.XXX.XXX is an ip address of the master. This has to be before the options directive.

include "/usr/local/etc/namedb/rndc.key";

controls { inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; }; inet XXX.XXX.XXX.XXX allow { XXX.XXX.XXX.XXX; } keys { "rndc-key"; }; };

On the master and slave, you need to fix the listen directives to use the ip addresses. Use your own IP addresses rather than the ones listed here.

//Master server listen-on { 127.0.0.1; 70.91.226.201; };

1 2

//Slave server listen-on { 127.0.0.1; 70.91.226.203; };

Now restart BIND on both master and slaves

service named restart

You can optionally use rndc to manage them.

rndc reload rndc status

rndc -s XXX.XXX.XXX.XXX reload

Check your firewall rules. You need TCP and UDP 53 open for DNS and if you are using rndc remotely port 953 open for all the slaves and master between each other.

If you were going to setup a recursive name server, you would use recursion yes. This is a BAD IDEA for an authoritative name server to do.

Now you need to setup the master to allow zone transfers from the slaves. Put this below the listen-on directive.

allow-transfer { localhost; 70.91.226.203; }; notify yes;

You can either use the dynamic directory or master directory to store zone files. This depends on your use case what makes sense.

zone "midnightbsd.org" { type master; file "/usr/local/etc/namedb/dynamic/midnightbsd.org"; };

Next you will create the zone file listed above.

$TTL 604800 @ IN SOA ns1.midnightbsd.org. admin.midnightbsd.org. ( 2018101901; Serial 3H; Refresh 15M; Retry 2W; Expiry 1D ); Minimum

; name servers - NS records IN NS ns1.midnightbsd.org. IN NS ns2.midnightbsd.org.

; name servers - A records ns1.midnightbsd.org. IN A 70.91.226.201 ns1.midnightbsd.org. IN A 70.91.226.203

; other servers - A records www.midnightbsd.org. IN A 70.91.226.201

You will likely also want MX records for mail delivery. That's out of scope for this article.

You can reload with rncd or using service named restart. Be sure to check /var/log/messages for any errors in case you have typos!

Now slaves are configured a little differently.

zone "midnightbsd.org" { type slave; masters { 70.91.226.201; }; file "/usr/local/etc/namedb/dynamic/db.midnightbsd.org"; };

You may also want to add allow-transfer { localhost; 70.91.226.203; }; so that the whole internet can't download your zones.

Restart the slave named.

Now you can test things out with nslookup, dig or drill depending on your preference.

nslookup www.midnightbsd.org 70.91.226.201

nslookup www.midnightbsd.org 70.91.226.203

Both of these should respond with valid records.

You can also test with an online tool to make sure others can find them. https://mxtoolbox.com/dnscheck.aspx

Another option is to query google dns nslookup www.midnightbsd.org 8.8.8.8

DNSSEC Older BIND release instructions (9.12) On the master, add this after the listen-on directive in named.conf

dnssec-enable yes; key-directory "/usr/local/etc/namedb/keys";

add this at the very bottom of named.conf

auto-dnssec maintain; inline-signing yes;

Newer bind release (9.16) add the key directory to named.conf in options

key-directory "/usr/local/etc/namedb/keys";

Per zone, add

dnssec-policy "default";

You will likely want these in the dynamic directory on MidnightBSD as the permissions are changed on master and it won't be able to write to the directory for the signed files on startup!

If you want to learn more about the DNSSEC changes in 9.16, look at http://ddiguru.com/blog/bind-9-16-release-info The dnssec-policy stuff is new and you can make your own custom rules.

Shared instructions: Create the keys directory

mkdir /usr/local/etc/namedb/keys cd /usr/local/etc/namedb/keys

Now create the signing keys

dnssec-keygen -a RSASHA256 -b 2048 -f KSK -n ZONE midnightbsd.org dnssec-keygen -a RSASHA256 -b 2048 -n ZONE midnightbsd.org

cd usr/local/etc/namedb/ && chown -R bind:bind keys

Restart BIND

cd /usr/local/etc/namedb/keys dnssec-dsfromkey Kmidnihgtbsd.org.+008+23956.key midnightbsd.org. IN DS 23956 8 1 2DA94FECA549E0A2B137FA6C64D09D2CBADF8864 midnightbsd.org. IN DS 23956 8 2 8CC2CB79E1B8A6767F11230485C7499D52162135E1F6DAA503ADEC4470E417A9

Useful Stuff Find out what the algorithm numbers are.