Domain Name System Security

Transcription

1 Abstract Domain Name System Security Ladislav Hagara Department of Automated Command Systems and Informatics Military Academy in Brno Brno, Czech Republic 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 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 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 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 ). 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 complete 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 into the web browser, the DNS client can obtain for example IP address instead of IP address 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 program dig. There are three DNS servers: ns01.army.mil, ns02.army.mil and ns03.army.mil. hgr]$ dig ; <<>> DiG <<>> ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ; IN A ;; ANSWER SECTION: IN A ;; AUTHORITY SECTION: army.mil IN NS ns01.army.mil. army.mil IN NS ns03.army.mil. army.mil IN NS ns02.army.mil. ;; ADDITIONAL SECTION: ns01.army.mil IN A ns03.army.mil IN A ns02.army.mil IN A ;; Query time: 181 msec ;; SERVER: #53( ) ;; WHEN: Sun Apr 8 21:09: ;; MSG SIZE rcvd: 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 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 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 " 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 army.sec. IN SOA spider.army.sec. hgr.army.sec. ( ) army.sec. IN NS spider.army.sec. spider.army.sec. IN A snake.army.sec. IN A snail.army.sec. IN A [root@spider sbin]# cat /etc/named.data/army.sec.rev $ttl in-addr.arpa. IN SOA spider.army.sec. hgr.army.sec. ( ) in-addr.arpa. IN NS spider.army.sec in-addr.arpa. IN PTR spider.army.sec in-addr.arpa. IN PTR snake.army.sec 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 { ; ; acl unreliable { ; 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 reliable so it is not allowed to do that. [hgr@snail sbin]$ dig army.sec axfr ; <<>> DiG <<>> army.sec axfr ;; global options: printcmd army.sec IN SOA spider.army.sec. hgr.army.sec army.sec IN NS spider.army.sec. snail.army.sec IN A snake.army.sec IN A spider.army.sec IN A army.sec IN SOA spider.army.sec. hgr.army.sec ;; Query time: 3 msec ;; SERVER: #53( ) ;; WHEN: Sun Apr 8 22:47: ;; XFR size: 7 records [hgr@snake sbin]$ dig army.sec axfr ; <<>> DiG <<>> 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 Configuration 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 > It is useful to check a log file. We can see suspicious activities there. Apr 8 22:53:40 spider./named[2167]: client #3498: zone transfer denied Apr 8 22:58:23 spider./named[2183]: client #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 Kkey-transfer key and Kkeytransfer private [root@spider sbin]#./dnssec-keygen -a hmac-md5 -b 128 -n HOST key-transfer Kkey-transfer The content of Kkey-transfer private file. [root@spider sbin]# cat Kkey-transfer 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 <<>> -y key-transfer army.sec axfr ;; global options: printcmd army.sec IN SOA spider.army.sec. hgr.army.sec army.sec IN NS spider.army.sec. fly.army.sec IN A snail.army.sec IN A snake.army.sec IN A spider.army.sec IN A

6 army.sec IN SOA spider.army.sec. hgr.army.sec key-transfer. 0 ANY TSIG hmac-md5.sig-alg.reg.int Cvm9uMhIIU0T8j7jo/z1XQ== NOERROR 0 ;; Query time: 3 msec ;; SERVER: #53( ) ;; WHEN: Mon Apr 9 00:55: ;; 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 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 compute 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 verified 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 key and Karmy.sec private. 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 [root@spider sbin]# cat Karmy.sec key army.sec. IN KEY BLLe7IXZVdk4YNeVmIyCDmogBsHdhNvMVEejJDLHa+yQE8UI1mouVfS7 XdbOlyw+5YCuzo1gzaUvZ1m/7Jq00fpdbsQslpbIAWIoyY1kLVH5xkfp 8lrwJzmZjg13/pR55NrtKcokH2vnzjAOvNtyZ9eVSPDrI6oNVNjkG5KK ouisixxdczaae9ufvm+apx7t7p2r+eh6qgnddmg22vzcymmdqm1vwa9k ybjkcvdslhncaqoybak0c9zwkszliqds+c1wnlqxnheglskme9suqwac SUJuGFr+G9jG1a8y07R8/u0BbJva4dO2ZgmPDkNPxpNJS1vIPrYjRVt+ ergkuq6symjh9tlfrdvrttartiejpazbo977ymklco4jqb5pmkmqeiie Kx8Lngot/gvtHLJAPGvX [root@spider sbin]# cat Karmy.sec 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 e Karmy.sec keyset-army.sec. [root@spider sbin]# cat keyset-army.sec. $ORIGIN. $TTL 3600 ; 1 hour army.sec IN KEY ( BLLe7IXZVdk4YNeVmIyCDmogBsHdhNvMVEejJDLHa+yQ E8UI1mouVfS7XdbOlyw+5YCuzo1gzaUvZ1m/7Jq00fpd bsqslpbiawioyy1klvh5xkfp8lrwjzmzjg13/pr55nrt KcokH2vnzjAOvNtyZ9eVSPDrI6oNVNjkG5KKoUisiXxD czaae9ufvm+apx7t7p2r+eh6qgnddmg22vzcymmdqm1v wa9kybjkcvdslhncaqoybak0c9zwkszliqds+c1wnlqx nheglskme9suqwacsujugfr+g9jg1a8y07r8/u0bbjva 4dO2ZgmPDkNPxpNJS1vIPrYjRVt+eRGKuq6symjh9TlF rdvrttartiejpazbo977ymklco4jqb5pmkmqeiiekx8l ngot/gvthljapgvx ) ; key id = SIG KEY ( 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: signedkeyarmy.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 ). [root@spider sbin]#./dnssec-signkey keyset-army.sec. Ksec signedkey-army.sec. [root@spider sbin]# cat signedkey-army.sec. $ORIGIN. $TTL 3600 ; 1 hour army.sec IN KEY ( BLLe7IXZVdk4YNeVmIyCDmogBsHdhNvMVEejJDLHa+yQ E8UI1mouVfS7XdbOlyw+5YCuzo1gzaUvZ1m/7Jq00fpd bsqslpbiawioyy1klvh5xkfp8lrwjzmzjg13/pr55nrt KcokH2vnzjAOvNtyZ9eVSPDrI6oNVNjkG5KKoUisiXxD czaae9ufvm+apx7t7p2r+eh6qgnddmg22vzcymmdqm1v wa9kybjkcvdslhncaqoybak0c9zwkszliqds+c1wnlqx nheglskme9suqwacsujugfr+g9jg1a8y07r8/u0bbjva 4dO2ZgmPDkNPxpNJS1vIPrYjRVt+eRGKuq6symjh9TlF rdvrttartiejpazbo977ymklco4jqb5pmkmqeiiekx8l ngot/gvthljapgvx ) ; key id = SIG KEY ( 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 One output file is produced: army.sec.hosts.signed. This file is several times bigger than the original one

9 sbin]# cat army.sec.hosts.signed ; File written on Mon Apr 9 01:43: ; dnssec_signzone version army.sec IN SOA spider.army.sec. hgr.army.sec. ( ; serial ; refresh (3 hours) 3600 ; retry (1 hour) ; expire (5 days) ; minimum (10 hours 40 minutes) ) SIG SOA ( BC0VA1dfza4bngbqbxQloO9Kg9AIEHkowiuq 3FoUEGjeBMRN//DoZqc= ) NS spider.army.sec SIG NS ( BIip342vp7HCwYlzHEc1kNolmtMCRNiyOm6/ 32c19bS8vne/BB3AI5M= ) 3600 KEY ( BLLe7IXZVdk4YNeVmIyCDmogBsHdhNvMVEej JDLHa+yQE8UI1mouVfS7XdbOlyw+5YCuzo1g zauvz1m/7jq00fpdbsqslpbiawioyy1klvh5 xkfp8lrwjzmzjg13/pr55nrtkcokh2vnzjao vntyz9evspdri6onvnjkg5kkouisixxdczaa E9uFVm+Apx7t7P2r+EH6qGnDDmg22vZCyMMD QM1Vwa9KybjkcvDSLhnCaQoyBak0C9ZWkszL iqds+c1wnlqxnheglskme9suqwacsujugfr+ G9jG1a8y07R8/u0BbJva4dO2ZgmPDkNPxpNJ S1vIPrYjRVt+eRGKuq6symjh9TlFrdVrtTar TieJpAZbo977ymKlco4JQb5PMKmqEIIEKx8L ngot/gvthljapgvx ) ; key id = SIG KEY ( sec. BCuu9HgcOKGjcej2kSOXpoymVCzOIqBv+/3u 6EFWtwFdybTW9fUgdCc= ) NXT snail.army.sec. NS SOA SIG KEY NXT SIG NXT ( BIgM4PMuBXehahvu2DxBUv4/7UCyF4SVJzej kkrskl6bad/wafq+wug= ) snail.army.sec IN A SIG A ( BCAnba/0F4uUy01ujjUgv6wYYztFQehc29vt oys+zjmz1w7ls5qtecq= ) NXT snake.army.sec. A SIG NXT SIG NXT ( BGIa8BJXRede/G0XukufXxW4j2mQVRF+Nvx8 hzsysssfdz6zuvl2tuo= ) snake.army.sec IN A SIG A ( BE5TXL1AHjIpmcUo2Epd3ehIPYUnCUAyah3z dht+tyfhhtwhyp4sykc= ) NXT spider.army.sec. A SIG NXT SIG NXT ( BJhEaUJh4mHX95wikOm6ZmKco28gN8YdTM1s v4qpbocjxouzvviqwou= ) spider.army.sec IN A SIG A ( BCZDzpszafKMTKWlgzDHN8MkqwBOhJxOQmbc +EEi+whi0K2BnC/Bm/M= ) NXT army.sec. A SIG NXT SIG NXT ( 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 <<>> army.sec ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;army.sec. IN A ;; AUTHORITY SECTION: army.sec IN SOA spider.army.sec. hgr.army.sec ;; Query time: 2 msec ;; SERVER: #53( ) ;; WHEN: Mon Apr 9 01:48: ;; 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: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;army.sec. IN ANY ;; ANSWER SECTION: army.sec IN SOA spider.army.sec. hgr.army.sec army.sec IN SIG SOA BC0VA1dfza4bngbqbxQloO9Kg9AIEHkowiuq3FoUEGjeBMRN//DoZqc= army.sec IN NS spider.army.sec. army.sec IN SIG NS BIip342vp7HCwYlzHEc1kNolmtMCRNiyOm6/32c19bS8vne/BB3AI5M= army.sec IN KEY BLLe7IXZVdk4YNeVmIyCDmogBsHdhNvMVEejJDLHa+yQE8UI1mouVfS7 XdbOlyw+5YCuzo1gzaUvZ1m/7Jq00fpdbsQslpbIAWIoyY1kLVH5xkfp 8lrwJzmZjg13/pR55NrtKcokH2vnzjAOvNtyZ9eVSPDrI6oNVNjkG5KK ouisixxdczaae9ufvm+apx7t7p2r+eh6qgnddmg22vzcymmdqm1vwa9k ybjkcvdslhncaqoybak0c9zwkszliqds+c1wnlqxnheglskme9suqwac SUJuGFr+G9jG1a8y07R8/u0BbJva4dO2ZgmPDkNPxpNJS1vIPrYjRVt+ ergkuq6symjh9tlfrdvrttartiejpazbo977ymklco4jqb5pmkmqeiie Kx8Lngot/gvtHLJAPGvX army.sec IN SIG KEY sec. BCuu9HgcOKGjcej2kSOXpoymVCzOIqBv+/3u6EFWtwFdybTW9fUgdCc= army.sec IN NXT snail.army.sec. NS SOA SIG KEY NXT army.sec IN SIG NXT BIgM4PMuBXehahvu2DxBUv4/7UCyF4SVJzejkkRSkL6baD/WAFQ+Wug=

11 ;; AUTHORITY SECTION: army.sec IN NS spider.army.sec. ;; ADDITIONAL SECTION: spider.army.sec IN A ;; Query time: 5 msec ;; SERVER: #53( ) ;; WHEN: Mon Apr 9 01:49: ;; MSG SIZE rcvd: Conclusions Name servers are subjects of plenty of attacks. It is important to protect them. It is a good idea to run the newest version of name server. Of course it does not guarantee its security but surely it minimizes its inclination to be hacked. Moreover, a new version embraces new features which can significantly improve the network security. With cryptography we can de facto guarantee authentication and integrity in DNS. It is possible to adopt these new technologies almost immediately. Why have not they been used yet? 7. References [1] Internet Software Consortium BIND, [2] FAQ about the Domain Name System Security extensions (DNSSEC), [3] The DNSSEC resources, [4] Cricket Liu, Securing an Internet Name Server, [5] Mourani, G.: Securing and Optimizing Linux: DNS and BIND, [6] Cricket Liu, The DNS Security Extensions, [7] DNS Resources Directory, [8] Internet Standards Archive, RFC Domain Name System Security (DNSSEC) Signing Authority RFC Domain Name System Security Extensions RFC Secure Domain Name System (DNS) Dynamic Update RFC Secret Key Transaction Authentication for DNS (TSIG)