Setting up BIND 9 on FreeBSD 9.1 as Master with Dynamic Updates

5 Apr

Now we need to configure BIND9 for the master nameserver of our domain. The first step is to start the service so a rndc key is generated:

[phocking@qryr ~]$ sudo service named onestart
wrote key file “/var/named/etc/namedb/rndc.key”
Starting named.

Now let’s cd to the /etc/namedb directory as we have a few things to edit here, and I like typing as little as possible (believe it or not!)

[phocking@qryr ~]$ cd /etc/namedb

Generate public/private keypair for our zone:

[phocking@qryr /etc/namedb]$ sudo mkdir keys
[phocking@qryr /etc/namedb]$ cd keys

[phocking@qryr /etc/namedb/keys]$ sudo dnssec-keygen -b 512 -a HMAC-MD5 -v 2 -n HOST ns1.wecansolve.org
Kns1.wecansolve.org.+157+28408

Now copy the key itself to the clipboard – the part you should highlight is italicized:

[phocking@qryr /etc/namedb/keys]$ sudo cat Kns1.wecansolve.org.+…+….private
Private-key-format: v1.3
Algorithm: 157 (HMAC_MD5)
Key: k8caOu.-.-.-.-.-awvgie+A1agaEWmuc.-.-.-.-.-rodJSGrZ+uAmxmeqrk-.-.-.-.-.XXAcWX8x2pc5g==
Bits: AAA=
Created: 20130405053748
Publish: 20130405053748
Activate: 20130405053748

Chmod the keys directory/files to 400 to ensure only root has access to the keypair:

[phocking@qryr /etc/namedb/keys]$ sudo chmod -R 400 /etc/namedb/keys;

Now we need to add our keys (and other applicable settings) in the appropriate spots in the named.conf file. The IPv4 address of this vm is 199.48.128.154 so that is something we need to keep handy going into the named configuration:

[phocking@qryr /etc/namedb/keys]$ cd ..

Copy named.conf to named.conf.dist in case we fuck up real bad!

[phocking@qryr /etc/namedb]$ cp named.conf named.conf.dist

Invoke an editor on named.conf:
[phocking@qryr /etc/namedb]$ vi named.conf

We will only focus on the parts that we need to change. Add our public facing IPv4 address to the listen-on paramater:

listen-on { 199.48.128.154; 127.0.0.1; };

As we have IPV6 addresses, we should uncomment this paramater:

// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver. To give access to the network, specify
// an IPv6 address, or the keyword “any”.
listen-on-v6 { ::1; };

Always take advantage of your provider’s upstream cache. Not only is this required for compliance with RFC 1132 which uses ominous tones throughout such as being necessary for ‘the health of the Internet as a whole’ – it reduces the amount of upstream bandwidth both you and your provider utilize which is a win-win. Let’s look at the standards set forth in the RFC:

6.1.3 SPECIFIC ISSUES

6.1.3.1 Resolver Implementation

A name resolver SHOULD be able to multiplex concurrent
requests if the host supports concurrent processes.

In implementing a DNS resolver, one of two different models
MAY optionally be chosen: a full-service resolver, or a stub
resolver.
(A) Full-Service Resolver

A full-service resolver is a complete implementation of
the resolver service, and is capable of dealing with
communication failures, failure of individual name
servers, location of the proper name server for a given
name, etc. It must satisfy the following requirements:

o The resolver MUST implement a local caching
function to avoid repeated remote access for
identical requests, and MUST time out information
in the cache.

o The resolver SHOULD be configurable with start-up
information pointing to multiple root name servers
and multiple name servers for the local domain.
This insures that the resolver will be able to
access the whole name space in normal cases, and
will be able to access local domain information
should the local network become disconnected from
the rest of the Internet.
(B) Stub Resolver

A “stub resolver” relies on the services of a recursive
name server on the connected network or a “nearby”
network. This scheme allows the host to pass on the
burden of the resolver function to a name server on
another host. This model is often essential for less
capable hosts, such as PCs, and is also recommended
when the host is one of several workstations on a local
network, because it allows all of the workstations to
share the cache of the recursive name server and hence
reduce the number of domain requests exported by the
local network.

——————————————————————————–

/// If you’ve got a DNS server around at your upstream provider, enter

// its IP address here, and enable the line below. This will make you
// benefit from its cache, thus reduce overall DNS traffic in the Internet.

forwarders {
208.79.80.18;
};

// If you enable a local name server, don’t forget to enter 127.0.0.1

// first in your /etc/resolv.conf so this server will be queried.
// Also, make sure to enable it in /etc/rc.conf.

^^This will be the second thing we do after we finish editing this file.

Now we create an entry for our zone file using the key that we copied and are going to paste here:

key ns1.wecansolve.org. {
algorithm “HMAC-MD5”;
secret “8caOu.-.-.-.-.-awvgie+A1agaEWmuc.-.-.-.-.-rodJSGrZ+uAmxmeqrk-.-.-.-.-.XXAcWX8x2pc5g==;
};

zone “wecansolve.org” {
type master;
allow-update {
127.0.0.1; key “ns1.wecansolve.org”;
};
file “/etc/namedb/dynamic/wecansolve.org”;
};

Chown /etc/namedb/named.conf to bind:bind which is what the service runs as and additionally chmod the named.conf to ensure only root has access to the private key

stored in the named configuration:

[phocking@qryr /etc/namedb]$ sudo chown -R bind:bind /etc/namedb/named.conf

[phocking@qryr /etc/namedb]$ sudo chmod 400 named.conf

Add 127.0.0.1 to /etc/resolv.conf:

[phocking@qryr /etc/namedb]$ sudo vi /etc/resolv.conf

nameserver 127.0.0.1
nameserver 208.79.80.18
nameserver 208.79.80.244

Now it is time to create a seed zone file that can be dynamically updated with the dnssec key. Invoke an editor to create the zone file:

[phocking@qryr /etc/namedb]$ cd dynamic
[phocking@qryr /etc/namedb/dynamic]$ sudo vi wecansolve.org

$TTL 3600 ; 1 hour default TTL
wecansolve.org. IN SOA ns1.wecansolve.org. hostmaster.wecansolve.org. (
2013040401 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
300 ; Negative Response TTL
)

; DNS Servers
IN NS ns1.wecansolve.org.
IN NS ns1.rootbsd.net.

; MX Records
IN MX 10 mail.wecansolve.org.

IN A 199.48.128.154

; Machine Names
localhost IN A 127.0.0.1
ns1 IN A 199.48.128.154
mail IN A 199.48.128.154

; Aliases
www IN CNAME wecansolve.org.

Now that we have our named configuration and zone files, it always is best practice to double-check the configuration and validate that everything is correct and working properly.

[phocking@qryr /etc/namedb/dynamic]$ sudo named-checkconf
[phocking@qryr /etc/namedb/dynamic]$ named-checkzone wecansolve.org wecansolve.org
zone wecansolve.org/IN: loaded serial 2013040401
OK

I prefer to use rndc to interact with named and the ISC says that you should use rndc instead of signals to interact with a running daemon.

[root@qryr /var/named/etc/namedb]# sudo rndc reload
server reload successful

[phocking@qryr /etc/namedb]$ dig @localhost ns1.wecansolve.org

; <<>> DiG 9.8.3-P4 <<>> @localhost ns1.wecansolve.org
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46745
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; QUESTION SECTION:
;ns1.wecansolve.org. IN A

;; ANSWER SECTION:
ns1.wecansolve.org. 3600 IN A 199.48.128.154

;; AUTHORITY SECTION:
wecansolve.org. 3600 IN NS ns1.wecansolve.org.
wecansolve.org. 3600 IN NS ns1.rootbsd.net.

;; ADDITIONAL SECTION:
ns1.rootbsd.net. 1107 IN A 208.86.227.242

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Apr 5 03:56:00 2013
;; MSG SIZE rcvd: 111

Ensure we are not recursing queries for anyone but the localhost (even though we know that we are not – still a good thing to check:

[phocking@qryr /etc/namedb]$ dig @localhost google.com

; <<>> DiG 9.8.3-P4 <<>> @localhost google.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20584
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 13, ADDITIONAL: 6

;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 62 IN A 74.125.228.14
google.com. 62 IN A 74.125.228.0
google.com. 62 IN A 74.125.228.1
google.com. 62 IN A 74.125.228.2
google.com. 62 IN A 74.125.228.3
google.com. 62 IN A 74.125.228.4
google.com. 62 IN A 74.125.228.5
google.com. 62 IN A 74.125.228.6
google.com. 62 IN A 74.125.228.7
google.com. 62 IN A 74.125.228.8
google.com. 62 IN A 74.125.228.9

;; AUTHORITY SECTION:
. 449 IN NS j.root-servers.net.
. 449 IN NS d.root-servers.net.
. 449 IN NS i.root-servers.net.
. 449 IN NS g.root-servers.net.
. 449 IN NS f.root-servers.net.
. 449 IN NS k.root-servers.net.
. 449 IN NS e.root-servers.net.
. 449 IN NS m.root-servers.net.
. 449 IN NS h.root-servers.net.
. 449 IN NS c.root-servers.net.
. 449 IN NS l.root-servers.net.
. 449 IN NS a.root-servers.net.
. 449 IN NS b.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net. 449 IN A 198.41.0.4
b.root-servers.net. 449 IN A 192.228.79.201
c.root-servers.net. 449 IN A 192.33.4.12
d.root-servers.net. 449 IN A 199.7.91.13
e.root-servers.net. 449 IN A 192.203.230.10
f.root-servers.net. 449 IN A 192.5.5.241

;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Apr 5 03:56:19 2013
;; MSG SIZE rcvd: 511

[phocking@ns1 /etc/namedb]$ dig @ns1.wecansolve.org google.com

; <<>> DiG 9.8.3-P4 <<>> @ns1.wecansolve.org google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Check from our remote host that we can reach the nameserver and that it is not recursing queries:

root@slitaz:/home/tux# nslookup ns1.wecansolve.org 199.48.128.154
Server: 199.48.128.154
Address 1: 199.48.128.154

Name: ns1.wecansolve.org
Address 1: 199.48.128.154
root@slitaz:/home/tux# nslookup google.com 199.48.128.154
Server: 199.48.128.154
Address 1: 199.48.128.154

nslookup: can’t resolve ‘google.com’

Change the appropriate values in rc.conf. This is a good time to set up all the super basic values in rc.conf that I have neglected up until this point in the series. Some of these values were already there, but this is a fairly comprehensive rc.conf. We want to enable ntpdate to use the SetTimeOfDay() syscall to whatever our ntp pool value is upon every boot. Then we enable ntpd to ensure time remains accurate while the server is running. Of course we enable named as that is what we just spent this time doing. Here we are telling syslogd to not listen on the syslog port and turn up the verbosity. We disable inetd for various security implications. Additionally we disable the Sendmail MTA for inbound connections but allow for it to queue and send outbound messages. Process accounting is a slight performance hit but allows for additional audit information if it becomes necessary – this needs to be enabled with additional commands. Clearing /tmp upon every boot ensures that any sensitive information contained within temporary files is removed upon every boot. Keyrate and kbdflags allows for the fastest rate of keypresses on the console. Fsck_y ensures that if the server crashes and the filesystems are unclean upon startup that fsck will automatically choose yes to all filesystem maintenance tasks which otherwise could hang the server and require remote hands. Dropping and logging icmp redirects helps prevent DoS attacks and is generally good best practice for production servers. Enabling kernel securelevel of 2:

1 Secure mode – the system immutable and system append-only flags may
not be turned off; disks for mounted file systems, /dev/mem and
/dev/kmem may not be opened for writing; /dev/io (if your platform
has it) may not be opened at all; kernel modules (see kld(4)) may
not be loaded or unloaded.

2 Highly secure mode – same as secure mode, plus disks may not be
opened for writing (except by mount(2)) whether mounted or not.
This level precludes tampering with file systems by unmounting
them, but also inhibits running newfs(8) while the system is multi-
user.

All of this together is basic hardening for a FreeBSD install that is facing the public internet. We will do another part in the series with more extensive hardening techniques. For the time being, this gives us what we need:

hostname=”ns1.wecansolve.org”
ifconfig_em0=”DHCP”
ifconfig_em0_ipv6=”inet6 accept_rtadv”
ifconfig_em1=”DHCP”
sshd_enable=”YES”
ntpdate_enable=”YES”
ntpdate_hosts=”pool.ntp.org”
ntpd_enable=”YES”
named_enable=”YES”
syslogd_enable=”YES”
syslogd_flags=”-v -v -ss”
inetd_enable=”NO”
sendmail_enable=”NO”
sendmail_outbound_enable=”NO”
sendmail_submit_enable=”YES”
sendmail_msp_queue_enable=”YES”
accounting_enable=”YES”
clear_tmp_enable=”YES”
update_motd=”NO”
keyrate=”FAST”
allscreens_kbdflags=”-r fast”
fsck_y_enable=YES
icmp_drop_redirect=”YES”
icmp_log_redirect=”YES”
kern_securelevel_enable=”YES”
kern_securelevel=”2″
dumpdev=”NO”

Before making use of process accounting which is the only thing we just enabled requiring additional actions, it must be enabled. To do this, execute the following commands:

[phocking@qryr /etc/namedb]$ sudo touch /var/account/acct
[phocking@qryr /etc/namedb]$ sudo accton /var/account/acct

Now it is time to reboot this guy and double check everything is working properly:

[phocking@qryr /etc/namedb]$ sudo shutdown -r now
Shutdown NOW!
shutdown: [pid 66526]
[phocking@qryr /etc/namedb]$
*** FINAL System shutdown message from phocking@qryr ***

System going down IMMEDIATELY

System shutdown time has arrived

Log back in, and now look:

Last login: Fri Apr 5 01:14:34 2013 from c-67-165-123-62.hsd1.wa.comcast.net
FreeBSD 9.1-RELEASE (GENERIC) #0 r243826: Tue Dec 4 06:55:39 UTC 2012

Welcome to FreeBSD!

Before seeking technical support, please use the following resources:

o Security advisories and updated errata information for all releases are
at http://www.FreeBSD.org/releases/ – always consult the ERRATA section
for your release first as it’s updated frequently.

o The Handbook and FAQ documents are at http://www.FreeBSD.org/ and,
along with the mailing lists, can be searched by going to
http://www.FreeBSD.org/search/. If the doc package has been installed
(or fetched via pkg_add -r lang-freebsd-doc, where lang is the
2-letter language code, e.g. en), they are also available formatted
in /usr/local/share/doc/freebsd.

If you still have a question or problem, please take the output of
`uname -a’, along with any relevant error messages, and email it
as a question to the questions@FreeBSD.org mailing list. If you are
unfamiliar with FreeBSD’s directory layout, please refer to the hier(7)
manual page. If you are not familiar with manual pages, type `man man’.

Edit /etc/motd to change this login announcement.

[phocking@ns1 /usr/home/phocking]$

So, last thing to is verify that our dynamic updates work:

[phocking@ns1 /usr/home/phocking]$ nsupdate
> server localhost
> update add test.wecansolve.org 3600 IN A 199.8.128.154
> send
> quit
[phocking@ns1 /usr/home/phocking]$ dig @localhost test.wecansolve.org

; <<>> DiG 9.8.3-P4 <<>> @localhost test.wecansolve.org
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14203
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; QUESTION SECTION:
;test.wecansolve.org. IN A

;; ANSWER SECTION:
test.wecansolve.org. 3600 IN A 199.8.128.154

;; AUTHORITY SECTION:
wecansolve.org. 3600 IN NS ns1.rootbsd.net.
wecansolve.org. 3600 IN NS ns1.wecansolve.org.

;; ADDITIONAL SECTION:
ns1.rootbsd.net. 5424 IN A 208.86.227.242
ns1.rootbsd.net. 5249 IN AAAA 2001:470:7:b86::d000
ns1.wecansolve.org. 3600 IN A 199.48.128.154

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Apr 5 04:21:50 2013
;; MSG SIZE rcvd: 160

Delete the test dynamic dns entry:

[phocking@ns1 /usr/home/phocking]$ nsupdate
> server localhost
> update delete test.wecansolve.org
> send
> quit
[phocking@ns1 /usr/home/phocking]$

 

And that should be about it for this second part of the series.

 

Leave a comment

The Vital Edge by Gideon Rosenblatt

Work, society and the human experience in an era of machine intelligence.

Esko Kilpi on Interactive Value Creation

The art of interaction, the design of digital work and the science of social complexity

Jeremy Waldrop's Blog

Unified Data Center Stuff