Domain Name System Security

(1)

Domain Name System Security

Ladislav Hagara

[email protected]

Department of Automated Command Systems and Informatics

Military Academy in Brno

Brno, Czech Republic

Abstract

Domain Name System (DNS) is one of the most important services keeping the Internet communication

running. Its main task is to convert domain names to IP addresses and vice versa. Despite the fact that this

task is really very important, DNS is quite vulnerable.

The paper describes relatively new features of both DNS and the BIND (Berkeley Internet Name Domain)

server. It explains the possibilities to restrict an access to BIND server according to IP addresses or TSIG

(Transaction SIGnatures). The major part of the paper is dedicated to DNSSEC (DNS SECurity extensions),

which is able to ensure authentication and integrity in DNS protocol.

Keywords:

DNS, DNSSEC, TSIG, SIG, KEY, NXT, BIND, ACL, computer security.

1. Introduction

Do you have an e-mail address? Do you surf the Internet? Whatever you want to do on the Internet, the first

thing you usually have to do is to use the domain name to specify the server you want to communicate with.

It is easier for people to take the name (for example www.playboy.com) than an appropriate IP address (it is

possible that one name has even several IP addresses). The name can attract people’s attention more than IP

address, it can be more useful in an advertisement and it looks better on business cards. Internet is however

built on the IP addresses.

After inserting the domain name (for example www.army.mil) into the web browser, the client part of DNS

will start the process, the goal of which is a conversion of the domain name to the corresponding IP address

(in this example to 140.183.234.10). If the conversion is successful, the web browser tries to connect with

the web server running on that IP address. The same mechanism provides reverse conversion from the IP

address to the domain name.

Can we believe this conversion? Unfortunately NOT.

DNS client sends a request for conversion to a local DNS server. If the local DNS server is not able to

com-plete this request, it sends the request through the Internet to other DNS servers according to DNS hierarchy.

If those DNS servers are not able to complete the request, they either inform the previous server about it or

send the request to next DNS servers. If one of the servers is able to complete the request, it sends the

response backward to the DNS client.

The problem is that neither DNS client nor DNS server can authenticate that response. The response can

come from any Internet hosts (IP address can be bogus) and can be falsified by hackers.

For example it is relatively easy to redirect web traffic to fake sites. Hackers can accomplish that after

inserting the domain name www.army.mil into the web browser, the DNS client can obtain for example IP

address 206.251.29.10 instead of IP address 140.183.234.10 and the web browser displays Playmate of the

Month.

(2)

The purpose of this paper is not to describe hackers’ techniques. Their probable first step is to find out

which DNS servers are responsible for the domain army.mil. It is very easy. They can use for example

pro-gram dig. There are three DNS servers: ns01.army.mil, ns02.army.mil and ns03.army.mil.

[hgr@hp07 hgr]$ dig www.army.mil ; <<>> DiG 9.1.1 <<>> www.army.mil ;; global options: printcmd ;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54351

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;www.army.mil. IN A ;; ANSWER SECTION: www.army.mil. 121 IN A 140.183.234.10 ;; AUTHORITY SECTION: army.mil. 1800 IN NS ns01.army.mil. army.mil. 1800 IN NS ns03.army.mil. army.mil. 1800 IN NS ns02.army.mil. ;; ADDITIONAL SECTION: ns01.army.mil. 3554 IN A 140.153.43.44 ns03.army.mil. 3554 IN A 130.114.200.6 ns02.army.mil. 3554 IN A 192.82.113.7 ;; Query time: 181 msec

;; SERVER: 160.216.1.1#53(160.216.1.1) ;; WHEN: Sun Apr 8 21:09:02 2001 ;; MSG SIZE rcvd: 159

2. BIND - Basic configuration

If we want to offer DNS services we need a DNS server. One of the most widespread implementation of the

DNS is BIND (Berkeley Internet Name Domain). BIND consists of a server part (daemon named) and

a client part: a resolver library and several tools for verifying the proper operation of the DNS server. I will

describe the version 9.1.1 of BIND in this paper.

If I want to describe new features I should describe a basic configuration. The configuration file of daemon

named is /etc/named.conf. It is a text file and it is possible to edit it with any text editor. In our example the

daemon named is master server for zones “army.sec” and “216.160.in-addr.arpa”.

[root@spider sbin]# cat /etc/named.conf options { directory "/etc"; pid-file "/var/run/named.pid"; }; zone "army.sec" { type master; file "/etc/named.data/army.sec.hosts "; }; zone "216.160.in-addr.arpa" { type master; file "/etc/named.data/army.sec.rev"; };

(3)

The zones contain only three hosts: spider, snail and snake. There are four main RR (Resource Record):

SOA, NS, A and PTR.

[root@spider sbin]# cat /etc/named.data/army.sec.hosts $ttl 38400

army.sec. IN SOA spider.army.sec. hgr.army.sec. (

986758907 10800 3600 432000 38400 ) army.sec. IN NS spider.army.sec. spider.army.sec. IN A 160.216.1.107 snake.army.sec. IN A 160.216.1.114 snail.army.sec. IN A 160.216.1.105 [root@spider sbin]# cat /etc/named.data/army.sec.rev $ttl 38400 216.160.in-addr.arpa. IN SOA spider.army.sec. hgr.army.sec. ( 986759050 10800 3600 432000 38400 ) 216.160.in-addr.arpa. IN NS spider.army.sec. 107.1.216.160.in-addr.arpa. IN PTR spider.army.sec. 114.1.216.160.in-addr.arpa. IN PTR snake.army.sec. 105.1.216.160.in-addr.arpa. IN PTR snail.army.sec.

3. IP restriction

If we want to have a secured server it is necessary to restrict an access to it as much as possible. Primary

restriction is based on IP addresses. To avoid repeated writing of IP addresses, it is possible to use ACL

(Access Control List). There are two ACLs: reliable and unreliable defined in this example.

acl reliable { 160.216.1.105; 160.216.1.107; }; acl unreliable { 160.216.1.114; };

3.1 Restriction of Zone Transfer

The clause allow-transfer specifies which hosts are allowed to receive zone transfers from the server. It is a

good idea to restrict it because by this transfer it is possible to find out a lot of interesting information,

which can be exploited, for example the number of hosts (computers, routers, network printers), type of

hosts, installed operating systems. From the incorrectly appointed names of hosts it is possible to identify

main hosts (mail, ns, router) or deduce the location of the hosts (brno, office-23) or their owner (director,

personnel).

options { directory "/etc"; pid-file "/var/run/named.pid"; allow-transfer { reliable; }; };

(4)

The host snail is allowed to download all content of the zone. The host snake is not a member of ACL

reli-able so it is not allowed to do that.

[hgr@snail sbin]$ dig army.sec axfr ; <<>> DiG 9.1.1 <<>> army.sec axfr ;; global options: printcmd

army.sec. 38400 IN SOA spider.army.sec. hgr.army.sec. 986758907 10800 3600 432000 38400

army.sec. 38400 IN NS spider.army.sec. snail.army.sec. 38400 IN A 160.216.1.105 snake.army.sec. 38400 IN A 160.216.1.114 spider.army.sec. 38400 IN A 160.216.1.107

;; Query time: 3 msec

;; SERVER: 160.216.1.107#53(160.216.1.107) ;; WHEN: Sun Apr 8 22:47:53 2001

;; XFR size: 7 records

[hgr@snake sbin]$ dig army.sec axfr ; <<>> DiG 9.1.1 <<>> army.sec axfr ;; global options: printcmd

; Transfer failed. [hgr@snake sbin]$

Similarly, we can define hosts that can query our DNS server (allow-query). The clause blackhole defines

the hosts queries from these addresses will not be responded to.

options { . . .

allow-query { reliable; }; blackhole { unreliable; }; };

3.2 Restriction of Dynamic Updates

It is possible dynamically delete or add records. It may be very useful with DHCP (Dynamic Host

Configu-ration Protocol). The host after getting its IP address may create corresponding record in DNS database.

Before giving back its IP address, it may delete its record from database. The problem is, that not only its

record, it can delete any records and add bogus ones.

zone "army.sec" { type master;

file "/etc/named.data/army.sec.hosts"; allow-update { reliable; };

};

It is possible to try it by utility “nsupdate”.

[hgr@snail bin]$ nsupdate

> update add fly.army.sec 3600 A 160.216.1.133 >

It is useful to check a log file. We can see suspicious activities there.

Apr 8 22:53:40 spider ./named[2167]: client 160.216.1.114#3498: zone transfer denied Apr 8 22:58:23 spider ./named[2183]: client 160.216.1.114#1026: query denied

(5)

4. TSIG

Because the restriction based on IP addresses is not very reliable, to restrict the access better and to ensure

the authentication and integrity, there has been the cryptography implemented in BIND. It is possible to use

both symmetric keys and asymmetric keys. The symmetric keys are used in TSIG (Transaction SIGnature)

and asymmetric keys are used in DNSSEC (DNS SECurity extensions).

4.1 Working with TSIG

TSIG is based on symmetric cryptography. To generate symmetric key the command dnssec-keygen can be

used. In the next example the command will generate a 128 bit (16 byte) HMAC-MD5 key “key-transfer”

and the result will be in files called “transfer.+157+07701.key” and “

Kkey-transfer.+157+07701.private”

[root@spider sbin]# ./dnssec-keygen -a hmac-md5 -b 128 -n HOST key-transfer Kkey-transfer.+157+07701

The content of “Kkey-transfer.+157+07701.private” file.

[root@spider sbin]# cat Kkey-transfer.+157+07701.private Private-key-format: v1.2

Algorithm: 157 (HMAC_MD5) Key: 02qXAdDrcMC5r3/sYBXYSg==

We must edit the file “/etc/named.conf”. Now we allow the transfer only for a signed request.

key key-transfer { algorithm hmac-md5; secret "02qXAdDrcMC5r3/sYBXYSg=="; }; options { . . .

allow-transfer { key key-transfer; }; };

Similarly we can create keys for update or query.

[root@spider sbin]# ./dnssec-keygen -a hmac-md5 -b 128 -n HOST key-update [root@spider sbin]# ./dnssec-keygen -a hmac-md5 -b 128 -n HOST key-query zone "army.sec" {

. . .

allow-update { key key-update; }; allow-query { key key-query; }; };

The options “-y” of command “dig” makes the request is signed.

[hgr@snake sbin]$ dig -y key-transfer:02qXAdDrcMC5r3/sYBXYSg== army.sec axfr ; <<>> DiG 9.1.1 <<>> -y key-transfer army.sec axfr

;; global options: printcmd

army.sec. 38400 IN SOA spider.army.sec. hgr.army.sec. 986758908 10800 3600 432000 38400 army.sec. 38400 IN NS spider.army.sec. fly.army.sec. 3600 IN A 160.216.1.133 snail.army.sec. 38400 IN A 160.216.1.105 snake.army.sec. 38400 IN A 160.216.1.114 spider.army.sec. 38400 IN A 160.216.1.107

(6)

key-transfer. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 986770742 300 16 Cvm9uMhIIU0T8j7jo/z1XQ== 35005 NOERROR 0

;; SERVER: 160.216.1.107#53(160.216.1.107) ;; WHEN: Mon Apr 9 00:55:20 2001

;; XFR size: 8 records

The command nsupdate has the option “-y” too.

[hgr@snake sbin]$ nsupdate -y key-update:RTawudXxGEJEtZD9SSkP8w== > update delete fly.army.sec A

>

4.2 BIND – remote control

The remote name daemon control (rndc) program allows the system administrator to control the operation of

the nameserver.

[root@spider sbin]# ./dnssec-keygen -a hmac-md5 -b 128 -n HOST key-rndc Kkey-rndc.+157+12742

Configuration file for the command rndc is /etc/rndc.conf.

[root@snake sbin]# cat /etc/rndc.conf key key-rndc { algorithm "hmac-md5"; secret "y5OuyU4GE5q4ep5gYnicdA=="; }; options { default-server spider.army.sec; default-key key-rndc; };

Now it is easy to reload name daemon remotely.

[root@snake sbin]# ./rndc reload rndc: reload command successful

5. DNSSEC

DNSSEC (DNS SECurity extentions) provides data integrity and authentication to security aware resolvers

and applications. It is based on the public key cryptography, so it works identically as other implementations

of public key cryptography. The secured zone owns the pair of unique keys: the private key and the public

key. These keys are generated at the same time according to a mathematical formula. It is impossible to

deduce the private key from the public key. Data that are encrypted using one key may be decrypted only

with corresponding second one. While the private key must be protected, the public key may be opened to

the public.

The encryption with private key is called digital signing. This encryption is very slow and resource-intensive

process, so there are not all the data encrypted but only their hash value. This hash value is like a fingerprint

that exactly represents the source data and it is computed from them by secure hash algorithm.

If the security aware resolver or server receives the encrypted (signed) data, they decrypt them with zone’s

public key to obtain supposed hash value. Then they use the same hash algorithm as the signer used to

com-pute its hash value. If this value matches the supposed one, the data are verified and the security aware

(7)

resolver or server may be guaranteed that data come from the authoritative source (the source which has

corresponding private key) and the data have not been modified since they were signed. If the value does not

match the supposed one, the data are bogus. This process is called verifying digital signature.

5.1 New Types of Resource Records

DNSSEC defines three new types of resouce record (RR). The zone’s public key is stored in a RR called

KEY. This RR can store not only zone’s public key but also keys associated with other zones, hosts or even

users. The zone’s private key is used to sign each RR in the zone. The digital signature for the RR is added

to the zone in a RR called SIG. The KEY RR should be signed too, of course not with zone’s key but with

its parent zone’s key. This allows a name server which knows the parent zone’s public key to discover the

subzone’s public key and verify it.

When the resolver or name server receives a response from the DNSSEC aware name server, this response

includes the SIG record that corresponds to the records in the answer. The security aware resolver or name

server can then retrieve the KEY record for the zone and verify it. Once the resolver or name server has

veri-fied the KEY record, it can decrypt the digital signature in the SIG record to get the hash value, recalculate it

and compare the two.

If queried RR does not exist, the name server must inform about it. This answer must be signed too. There is

a signed RR called NXT. These NXT records are added automatically during the DNS signing process.

The rest of this section describes creation and use of DNSSEC signed zones. It is necessary to pass several

stages to use DNSSEC.

5.2 Generating Keys

The dnssec-keygen program is used to generate keys. Two output files will be produced:

“Karmy.sec.+003+49897.key” and “Karmy.sec.+003+49897private”. The private key (in the .private file) is

used to generate signatures, and the public key (in the .key file) is used for a signature verification.

[root@spider sbin]# ./dnssec-keygen -a DSA -b 768 -n ZONE army.sec Karmy.sec.+003+49897

[root@spider sbin]# cat Karmy.sec.+003+49897.key

army.sec. IN KEY 256 3 3 BLLe7IXZVdk4YNeVmIyCDmogBsHdhNvMVEejJDLHa+yQE8UI1mouVfS7 XdbOlyw+5YCuzo1gzaUvZ1m/7Jq00fpdbsQslpbIAWIoyY1kLVH5xkfp 8lrwJzmZjg13/pR55NrtKcokH2vnzjAOvNtyZ9eVSPDrI6oNVNjkG5KK oUisiXxDcZAaE9uFVm+Apx7t7P2r+EH6qGnDDmg22vZCyMMDQM1Vwa9K ybjkcvDSLhnCaQoyBak0C9ZWkszLiQDS+c1wnlQXnheGlSkmE9SUQWAC SUJuGFr+G9jG1a8y07R8/u0BbJva4dO2ZgmPDkNPxpNJS1vIPrYjRVt+ eRGKuq6symjh9TlFrdVrtTarTieJpAZbo977ymKlco4JQb5PMKmqEIIE Kx8Lngot/gvtHLJAPGvX [root@spider sbin]# cat Karmy.sec.+003+49897.private

Private-key-format: v1.2 Algorithm: 3 (DSA) Prime(p): hNvMVEejJDLHa+yQE8UI1mouVfS7XdbOlyw+5YCuzo1gzaUvZ1m/7Jq00fpdbsQslpbIAWIoyY1kLVH5xkfp8lrwJ zmZjg13/pR55NrtKcokH2vnzjAOvNtyZ9eVSPDr Subprime(q): st7shdlV2Thg15WYjIIOaiAGwd0= Base(g): I6oNVNjkG5KKoUisiXxDcZAaE9uFVm+Apx7t7P2r+EH6qGnDDmg22vZCyMMDQM1Vwa9KybjkcvDSLhnCaQoyBak0C 9ZWkszLiQDS+c1wnlQXnheGlSkmE9SUQWACSUJu Private_value(x): Ls+KPIt9Qc4e2bHh/Njc5292iVw= Public_value(y): GFr+G9jG1a8y07R8/u0BbJva4dO2ZgmPDkNPxpNJS1vIPrYjRVt+eRGKuq6symjh9TlFrdVrtTarTieJpAZbo977y mKlco4JQb5PMKmqEIIEKx8Lngot/gvtHLJAPGvX

(8)

5.3 Creating a Keyset

The dnssec-makekeyset program is used to create a key set from one or more keys. The following command

generates a key set with a TTL of 3600 and a signature validity period of 10 days starting from now. The

key set must be signed by parent zone.

[root@spider sbin]# ./dnssec-makekeyset -t 3600 -e +864000 Karmy.sec.+003+49897 keyset-army.sec.

[root@spider sbin]# cat keyset-army.sec. $ORIGIN . $TTL 3600 ; 1 hour army.sec IN KEY 256 3 3 ( BLLe7IXZVdk4YNeVmIyCDmogBsHdhNvMVEejJDLHa+yQ E8UI1mouVfS7XdbOlyw+5YCuzo1gzaUvZ1m/7Jq00fpd bsQslpbIAWIoyY1kLVH5xkfp8lrwJzmZjg13/pR55Nrt KcokH2vnzjAOvNtyZ9eVSPDrI6oNVNjkG5KKoUisiXxD cZAaE9uFVm+Apx7t7P2r+EH6qGnDDmg22vZCyMMDQM1V wa9KybjkcvDSLhnCaQoyBak0C9ZWkszLiQDS+c1wnlQX nheGlSkmE9SUQWACSUJuGFr+G9jG1a8y07R8/u0BbJva 4dO2ZgmPDkNPxpNJS1vIPrYjRVt+eRGKuq6symjh9TlF rdVrtTarTieJpAZbo977ymKlco4JQb5PMKmqEIIEKx8L ngot/gvtHLJAPGvX ) ; key id = 50924 SIG KEY 3 2 3600 20010418233106 ( 20010408233106 49897 army.sec. BHE34W4NmMMazzG9r6MsHLXshZciU4CpfhIUBPAXbkfx 8Ru6XToX2l8= )

5.4 Signing the Child's Keyset

The dnssec-signkey program is used to sign one child's keyset. One output file is produced:

“signedkey-army.sec”. This file should be transmitted back to the child. It includes child’s key from the keyset file and

signatures generated by its parent’s zone key (Ksec.+003+32266).

[root@spider sbin]# ./dnssec-signkey keyset-army.sec. Ksec.+003+32266 signedkey-army.sec.

[root@spider sbin]# cat signedkey-army.sec. $ORIGIN . $TTL 3600 ; 1 hour army.sec IN KEY 256 3 3 ( BLLe7IXZVdk4YNeVmIyCDmogBsHdhNvMVEejJDLHa+yQ E8UI1mouVfS7XdbOlyw+5YCuzo1gzaUvZ1m/7Jq00fpd bsQslpbIAWIoyY1kLVH5xkfp8lrwJzmZjg13/pR55Nrt KcokH2vnzjAOvNtyZ9eVSPDrI6oNVNjkG5KKoUisiXxD cZAaE9uFVm+Apx7t7P2r+EH6qGnDDmg22vZCyMMDQM1V wa9KybjkcvDSLhnCaQoyBak0C9ZWkszLiQDS+c1wnlQX nheGlSkmE9SUQWACSUJuGFr+G9jG1a8y07R8/u0BbJva 4dO2ZgmPDkNPxpNJS1vIPrYjRVt+eRGKuq6symjh9TlF rdVrtTarTieJpAZbo977ymKlco4JQb5PMKmqEIIEKx8L ngot/gvtHLJAPGvX ) ; key id = 50924 SIG KEY 3 2 3600 20010418233106 ( 20010408233106 32266 sec. BCuu9HgcOKGjcej2kSOXpoymVCzOIqBv+/3u6EFWtwFd ybTW9fUgdCc= )

5.5 Signing the Zone

The dnssec-signzone program is used to sign a zone.

[root@spider sbin]# cp /etc/named.data/army.sec.hosts

[root@spider sbin]# cat signedkey-army.sec. >> army.sec.hosts [root@spider sbin]# ./dnssec-signzone -o army.sec army.sec.hosts army.sec.hosts.signed

(9)

[root@spider sbin]# cat army.sec.hosts.signed ; File written on Mon Apr 9 01:43:18 2001 ; dnssec_signzone version 9.1.1

army.sec. 38400 IN SOA spider.army.sec. hgr.army.sec. ( 986758909 ; serial

10800 ; refresh (3 hours) 3600 ; retry (1 hour) 432000 ; expire (5 days)

38400 ; minimum (10 hours 40 minutes) ) 38400 SIG SOA 3 2 38400 20010508234318 ( 20010408234318 49897 army.sec. BC0VA1dfza4bngbqbxQloO9Kg9AIEHkowiuq 3FoUEGjeBMRN//DoZqc= ) 38400 NS spider.army.sec. 38400 SIG NS 3 2 38400 20010508234318 ( 20010408234318 49897 army.sec. BIip342vp7HCwYlzHEc1kNolmtMCRNiyOm6/ 32c19bS8vne/BB3AI5M= ) 3600 KEY 256 3 3 ( BLLe7IXZVdk4YNeVmIyCDmogBsHdhNvMVEej JDLHa+yQE8UI1mouVfS7XdbOlyw+5YCuzo1g zaUvZ1m/7Jq00fpdbsQslpbIAWIoyY1kLVH5 xkfp8lrwJzmZjg13/pR55NrtKcokH2vnzjAO vNtyZ9eVSPDrI6oNVNjkG5KKoUisiXxDcZAa E9uFVm+Apx7t7P2r+EH6qGnDDmg22vZCyMMD QM1Vwa9KybjkcvDSLhnCaQoyBak0C9ZWkszL iQDS+c1wnlQXnheGlSkmE9SUQWACSUJuGFr+ G9jG1a8y07R8/u0BbJva4dO2ZgmPDkNPxpNJ S1vIPrYjRVt+eRGKuq6symjh9TlFrdVrtTar TieJpAZbo977ymKlco4JQb5PMKmqEIIEKx8L ngot/gvtHLJAPGvX ) ; key id = 50924 3600 SIG KEY 3 2 3600 20010418233106 ( 20010408233106 32266 sec. BCuu9HgcOKGjcej2kSOXpoymVCzOIqBv+/3u 6EFWtwFdybTW9fUgdCc= )

38400 NXT snail.army.sec. NS SOA SIG KEY NXT 38400 SIG NXT 3 2 38400 20010508234318 ( 20010408234318 49897 army.sec. BIgM4PMuBXehahvu2DxBUv4/7UCyF4SVJzej kkRSkL6baD/WAFQ+Wug= ) snail.army.sec. 38400 IN A 160.216.1.105 38400 SIG A 3 3 38400 20010508234318 ( 20010408234318 49897 army.sec. BCAnba/0F4uUy01ujjUgv6wYYztFQehc29vt oYs+zJmZ1w7LS5qtECQ= ) 38400 NXT snake.army.sec. A SIG NXT 38400 SIG NXT 3 3 38400 20010508234318 ( 20010408234318 49897 army.sec. BGIa8BJXRede/G0XukufXxW4j2mQVRF+Nvx8 hzsysSsFdZ6ZuVL2TUo= ) snake.army.sec. 38400 IN A 160.216.1.114 38400 SIG A 3 3 38400 20010508234318 ( 20010408234318 49897 army.sec. BE5TXL1AHjIpmcUo2Epd3ehIPYUnCUAyah3z dhT+TyfHhtWhYP4SYkc= ) 38400 NXT spider.army.sec. A SIG NXT 38400 SIG NXT 3 3 38400 20010508234318 ( 20010408234318 49897 army.sec. BJhEaUJh4mHX95wikOm6ZmKco28gN8YdTM1s v4qpBocjXOuZVVIQWoU= ) spider.army.sec. 38400 IN A 160.216.1.107 38400 SIG A 3 3 38400 20010508234318 ( 20010408234318 49897 army.sec. BCZDzpszafKMTKWlgzDHN8MkqwBOhJxOQmbc +EEi+whi0K2BnC/Bm/M= ) 38400 NXT army.sec. A SIG NXT 38400 SIG NXT 3 3 38400 20010508234318 ( 20010408234318 49897 army.sec. BCXA/bAeLMwKsMPpt+0QQ/9HOv//EDkeqQk2 3uKKdGyz/IceQVAvYc0= )

(10)

5.6 Configuring Servers

This signed file must be referenced by named.conf as the input file for the zone.

zone "army.sec" { type master;

file "/etc/named.data/army.sec.hosts.signed"; allow-update { key key-update; };

};

Finally we try the functions by utility dig. It looks like the output of DNS server, which is not aware of

DNSSEC.

[root@snake sbin]# dig army.sec ; <<>> DiG 9.1.1 <<>> army.sec ;; global options: printcmd ;; Got answer:

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION:

;army.sec. IN A ;; AUTHORITY SECTION:

;; MSG SIZE rcvd: 73

The output of utility dig with argument “any” is significantly different.

[root@snake sbin]# dig army.sec any ;; Truncated, retrying in TCP mode. ;; Got answer:

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION:

;army.sec. IN ANY ;; ANSWER SECTION:

army.sec. 38400 IN SIG SOA 3 2 38400 20010508234318

20010408234318 49897 army.sec. BC0VA1dfza4bngbqbxQloO9Kg9AIEHkowiuq3FoUEGjeBMRN//DoZqc= army.sec. 38400 IN NS spider.army.sec. army.sec. 38400 IN SIG NS 3 2 38400 20010508234318 20010408234318 49897 army.sec. BIip342vp7HCwYlzHEc1kNolmtMCRNiyOm6/32c19bS8vne/BB3AI5M= army.sec. 3600 IN KEY 256 3 3 BLLe7IXZVdk4YNeVmIyCDmogBsHdhNvMVEejJDLHa+yQE8UI1mouVfS7 XdbOlyw+5YCuzo1gzaUvZ1m/7Jq00fpdbsQslpbIAWIoyY1kLVH5xkfp 8lrwJzmZjg13/pR55NrtKcokH2vnzjAOvNtyZ9eVSPDrI6oNVNjkG5KK oUisiXxDcZAaE9uFVm+Apx7t7P2r+EH6qGnDDmg22vZCyMMDQM1Vwa9K ybjkcvDSLhnCaQoyBak0C9ZWkszLiQDS+c1wnlQXnheGlSkmE9SUQWAC SUJuGFr+G9jG1a8y07R8/u0BbJva4dO2ZgmPDkNPxpNJS1vIPrYjRVt+ eRGKuq6symjh9TlFrdVrtTarTieJpAZbo977ymKlco4JQb5PMKmqEIIE Kx8Lngot/gvtHLJAPGvX army.sec. 3600 IN SIG KEY 3 2 3600 20010418233106

20010408233106 32266 sec. BCuu9HgcOKGjcej2kSOXpoymVCzOIqBv+/3u6EFWtwFdybTW9fUgdCc= army.sec. 38400 IN NXT snail.army.sec. NS SOA SIG KEY NXT army.sec. 38400 IN SIG NXT 3 2 38400 20010508234318

(11)

;; AUTHORITY SECTION:

army.sec. 38400 IN NS spider.army.sec. ;; ADDITIONAL SECTION:

spider.army.sec. 38400 IN A 160.216.1.107 ;; Query time: 5 msec

;; MSG SIZE rcvd: 793