Configuring DNS-sec on Solaris 10+

Configuring DNS(sec) BIND 9+ and rndc1 on Solaris 10

Primary / Master server: zone-test1, IP: 192.168.1.13

Slave / Secondary server: zone-test1, IP: 192.168.1.14

0. H2n

In order to speed up the DNS setup, the Perl script “h2n” is used here to quickly configure a simple DNS domain.

# cp h2n.tar.gz /var/tmp

# cd /var/tmp

# gzip -d h2n.tar.gz

# tar -xvf h2n.tar

# cd h2n-2.56

# mkdir -p /var/named

# cp -p h2n /var/named

1. Configure a DNS domain using h2n on Primary server “zone-test1” and Secondary “zone-test2”

# cd /var/named

# vi mydomain.txt

-d mydomain.nl. mode=d #domainname, qualify hosts

-n 192.168.1:255.255.255.0 #(Sub)network name, no trailing .

-H /var/tmp/hosts #Alternative hosts file

-u root # user to send mail to (SOA records)

-M #No MX records please

-s zone-test1 zone-test2 # Servers

-z 192.168.1.13 # Seconday Server

# cp /etc/inet/hosts /var/tmp/

# vi /var/tmp/hosts

127.0.0.1 localhost

192.168.1.13 zone-test1

192.168.1.12 zone-mail

192.168.1.14 zone-test2

# ./h2n -f ./mydomain.txt

Don’t mind the complains from the script.

# mv named.conf /etc/

Add the “rndc” part to named.conf:

# vi /etc/named.conf

include “/etc/rndc.key”;

// Define the rndc key for rndc command. Use “rndc-confgen -a -b 512”

// to create a new key

controls {

inet 127.0.0.1 port 953

allow { 127.0.0.1; } keys { “rndc-key”; };

};

and to allow ZONE transfers to the Slave / Secondary Server:

zone “mydomain.nl” { type master; file “db.mydomain”;

allow-transfer { 192.168.1.14; }; };

zone “1.168.192.in-addr.arpa” { type master; file “db.192.168.1”;

allow-transfer { 192.168.1.14; }; };

Create you own “hint file” in /var/named:

# vi db.cache

$TTL 30

. IN NS zone-test1.mydomain.nl.

IN A 192.168.1.13

# vi /etc/resolv.conf

domain mydomain.nl

nameserver 192.168.1.13

And make sure /etc/nsswitch.conf initiates DNS resolution:

# grep dns /etc/nsswitch.conf

hosts: files dns

2. Test the DNS domain on the Master / Primary Server

Make sure you set a ‘tail -f’ on /var/adm/messages and start the daemon:

# in.named

There should be no errors in the messages file. Errors refering to “#953” refer to /etc/rndc.key.

Now test the domain:

# dig zone-test1.mydomain.nl

# dig zone-test2.mydomain.nl

3. Configuring the Slave / Seconday Server on “zone-test2”

# mkdir -p /var/named

# scp zone-test1:/var/named/conf.sec /etc/named.conf

# vi /etc/named.conf

include “/etc/rndc.key”;

// Define the rndc key for rndc command. Use “rndc-confgen -a -b 512”

// to create a new key

controls {

inet 127.0.0.1 port 953

allow { 127.0.0.1; } keys { “rndc-key”; };

};

And add the following:

zone “mydomain.nl” { type slave; file “mydomain.nl”; masters { 192.168.1.13; }; };

zone “1.168.192.in-addr.arpa” { type slave; file “1.168.192.in-addr.arpa”; masters { 192.168.1.13; }; };

# scp zone-test1:/var/named/db.cache /var/named

# scp zone-test1:/var/named/db.127.0.0 /var/named

# vi /etc/resolv.conf

domain mydomain.nl

nameserver 192.168.1.14 # Slave / Secondary IP address here..

4. Testing the Slave / Secondary DNS Server

Make sure you set a ‘tail -f’ on /var/adm/messages and start the daemon:

# in.named -d 3

There shouldn’t be any errors in the messages file.

Now test the domain:

# dig zone-test1.mydomain.nl

# dig zone-test2.mydomain.nl

In /var/named the ZONE files “mydomain.nl” and “1.168.192.in-addr.arpa” should be found as they have been copied over from the Master using a Zone Transfer.

5. Examples with rndc (previously named ndc)

The “rndc” tool which was previously known as “ndc” is a cli tool that allows for local or remote administration of a DNS server eleviating the usage of “kill” commands. The requirement for this tool to work is that in.named listens on the required portnumber (default tcp:953) and on the right IP addresss. Authentication is implemented by using a symetric key secret hmac-md5 key which is typically stored in a file called “rndc.key”.

First of all, in order to startup in.named automatically after booting the OS, use:

# svcs -a |grep dns

# svcadm enable svc:/network/dns/server:default

# svcs -p svc:/network/dns/server:default

To see all of rndc’s arguments, run it without commands:

# rndc

Usage: rndc [-c config] [-s server] [-p port]

[-k key-file ] [-y key] [-V] command

command is one of the following:

reload Reload configuration file and zones.

reload zone [class [view]] Reload a single zone.

refresh zone [class [view]] Schedule immediate maintenance for a zone.

reconfig Reload configuration file and new zones only.

stats Write server statistics to the statistics file.

querylog Toggle query logging.

dumpdb Dump cache(s) to the dump file (named_dump.db).

stop Save pending updates to master files and stop the server.

halt Stop the server without saving pending updates.

trace Increment debugging level by one.

trace level Change the debugging level.

notrace Set debugging level to 0.

flush Flushes all of the server’s caches.

flush [view] Flushes the server’s cache for a view.

status Display status of the server.

*restart Restart the server.

So let’s start the in.named – DNS server on the Primary node “zone-test1” using rndc:

# rndc -s localhost reload -> this will work

# rndc -s zone-test1 reload -> this will fail since named.conf only allows localhost to connect.

Now edit named.conf in order to allow rndc to work using the IP address of zone-test1:

# vi /etc/named.conf

controls {

inet 192.168.1.13; port 953

allow { 127.0.0.1; 192.168.1.13; } keys { “rndc-key”; };

};

In the above example, the first 192… is the port listened on by in.named for incomming requests, whereas the second 192… is the Source IP address allowed to be used for the client rndc program.

Both are needed even for local connections if the 192… address is going to be used. For local administration only, the previous version of named.conf should be used.

# rndc -V -s localhost reload

If neccessary, restart the service:

# svcadm disable svc:/network/dns/server:default

# svcadm enable svc:/network/dns/server:default

The following should now work:

# rndc -s zone-test1 -V -k /etc/rndc.key reload

Now let’s see whether we can use rndc from zone-test2 to zone-test1:

zone-test2:/root # rndc -V -s zone-test1 reload

[…]

rndc: connection to remote host closed

This may indicate that the remote server is using an older version of

the command protocol, this host is not authorized to connect, or the key is invalid.

The error messages in /var/adm/messages is:

zone-test1 named[3290]: [ID 873579 daemon.warning] rejected command channel message from 192.168.1.14#41118”

So now on zone-test1, allow the IP address of zone-test2 to connect.

zone-test1:/root # vi /etc/named.conf

controls {

inet 192.168.1.13 port 953

allow { 127.0.0.1; 192.168.1.13; 192.168.1.14; } keys { “rndc-key”; };

};

# rndc -s zone-test1 -V -k /etc/rndc.key reload

And try to use rndc from zone-test2 once more:

zone-test2:/root # rndc -V -s zone-test1 reload

Again it fails. This time on zone-test1, the error message in /var/adm/messages is:

zone-test1 named[3290]: [ID 873579 daemon.error] invalid command from 192.168.1.14#41131: bad auth”

Clearly, this “bad authentication” can be attributed to the lack of rndc-key on zone-test2. So let’s transfer the rndc- key to zone-test2 and try again:

# scp /etc/rndc.key zone-test2:/var/tmp/rndc.key

Now from zone-test2:

# rndc -V -k /var/tmp/rndc.key -s zone-test1 reload

Works! Say hallelujah!

6. Configuring DNSsec on the Servers for securing Zone Transfers

Now add a Public / Private Key Pair to the Nameservers in order to configure TranSactionSIGnatures (TSIG) for DNSEC.

This will sign each transaction between servers to ensure authenticity. DNSSEC only supports asymentric cryptography using RSA and DSA, using the HMAC-MD5 algorithm. Which means that the server hashes the messages with a Shared Secret Key and just signs the messages.

The idea here is to prevent DNS spoofs and hence introduce a test for authenticity. With the “allow-transfer” directive and a TSIG key, it is possible to limit those allowed to access data in the server.

The TSIG string consists of a string and a hashing algorithm. The keys needed for a session between communicating nodes needs to be manually distributed as in the example above with rndc.

Let’s first generatethe DNS TSIG key for the server pair. (RFC 2535 DNSSEC and RFC 2845 TSIG)

Here dnssec-keygen is used to generate a base64-encoded random number to use as the secret string in TSIG.

# /usr/sbin/dnssec-keygen -r /dev/urandom -a HMAC-MD5 -b 128 -n HOST mydomain.nl.

Kmydomain.nl.+157+04830

Notice the “-n” option here REALLY uses the word HOST. Explanation:

-n nametype: Specify the owner type of the key. The value of nametype must either be ZONE (for a DNSSEC zone key), HOST or ENTITY (for a key associated with a host), or USER (for a key

associated with a user). These values are case insensitive.

The following files have been produced:

# ls K*

Kmydomain.nl.+157+45901.key Kmydomain.nl.+157+45901.private

The Private Keyfile contains:

# cat Kmydomain.nl.+157+04830.private

Private-key-format: v1.2

Algorithm: 157 (HMAC_MD5)

Key: mTdXvuKuDhcQbXNV4iTFnQ==

    157 is the algorithm used (HMAC-MD5)

    35215 is the finger print, which is useful in DNNSEC because multiple keys per zone are allowed


The public Keyfile contains:

# cat Kmydomain.nl.+157+04830.key

mydomain.nl. IN KEY 512 3 157 mTdXvuKuDhcQbXNV4iTFnQ==

For security reasons, the best procedure here is not to include the Private Key in Kmydomain.nl.+157+45901.private in named.conf directly, but to keep this in the readonly file somewhere in a secured directory:

zone-test1:/root # mkdir -p /etc/dns

zone-test1:/root # mv K* /etc/dns

zone-test1:/root # chmod 400 /etc/dns

zone-test1:/etc/dns # mv /etc/dns/Kmydomain.nl.+157+04830.private /etc/dns/mydomain.nl.private

zone-test1:/etc/dns # vi mydomain.nl.private

key mydomain.nl. {

algorithm hmac-md5;

secret “mTdXvuKuDhcQbXNV4iTFnQ==”;

};

This file contains your “DNS TSIG KEY”. Since this is a private key, it should well be protected using the regular UNIX permissions.

Make sure that the DNS server will now request this shared key for Zone-Transfers from Primary to Secondary Servers:

zone-test1:/root # vi /etc/named.conf

include “/etc/dns/mydomain.nl.private”;

// Contains key directives for communicating with the sec. server

server 192.168.1.14 {

keys { mydomain.nl.; };

};

zone “mydomain.nl” { type master; file “db.mydomain”; allow-transfer { key mydomain.nl.;

}; };

Restart the DNS server on the primary node and check the /var/adm/message file for errors.

NOTICE THE IP ADDRESS OF THE SECONDARY MACHINE IS MENTIONED HERE, AND THE APPROPRIATE KEY!

On the Secondary Server, copy the Private Keyfile mydomain.nl.private from the Master.

zone-test2:/root # mkdir /etc/dns

zone-test2:/root # scp root@zone-test1:/etc/dns/ mydomain.nl.private /etc/dns

First try to see whether the Zone Transfers between Primary and Secondary now fails:

zone-test2:/var/named # rm mydomain.nl

zone-test2:/var/named # svcadm disable dns/server

zone-test2:/var/named # svcadm enable dns/server

The entry in /var/adm/messages on this secondary server reads:

transfer of ‘mydomain.nl/IN’ from 192.168.1.13#53: failed while receiving responses: REFUSED”

Now edit named.conf on the Secondary Server:

zone-test2:/root # vi /etc/named.conf

include “/etc/dns/mydomain.nl.private”;

server 192.168.1.13 {

keys { mydomain.nl.; };

};

Restart the DNS server and check /var/adm/messages for errors.

Hint: to try manual Zone Transfers:

# dig @SERVER DOMAIN.NAME axfr
# dig @192.168.128.34 test1.com axfr

Or the Ultimate test:

# dig -y mydomain.nl.:LtfUaZ8hH3vVr9vtKiKpsg== @zone-test1 mydomain.nl axfr

Here “mydomain.nl” is the name of the Key to Use, LtfUaZ8hH3vVr9vtKiKpsg== is the TSIG key and @zone-test1 is the Server and mydomain.nl the Required Domain Name. AXFR requests a Zone Transfer.

This entry was posted in Solaris / linux, Technical. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *