Showing posts with label dns. Show all posts
Showing posts with label dns. Show all posts

Wednesday, September 04, 2013

named high CPU usage under Ubuntu resolved

When running Ubuntu you might encounter a strange behaviour where the named process, which is part of BIND, is taking up a large amount of CPU. In my case this was more then 120% due to the fact it was using more then a single core. Normally named would take only a very small amount of the CPU cycles available so this can be seen as strange behaviour. Reason for this behaviour turned out to be a wrongly set permission on the /var/cache/bind directory.

Due to some reason the default Ubuntu distribution is shipping with only root permissions on /var/cache/bind while named is running as the user bind. The named process is trying to write to the /var/cache/bind directory however fails due to the fact that this can only be done by the root user. This in turn results in retries which take a lot of your CPU away from other processes.

To resolve this, one of, the solution is to reset the permissions on /var/cache/bind which can be done with the commands below;

chown root:bind /var/cache/bind
chmod g+w /var/cache/bind

After this you will have to stop and start bind which can be done with the below command.

service bind9 restart

This should result in a lot less CPU usage from the named process.

Monday, January 16, 2012

DNS BIND load-balance setup

I one of my previous blogposts I stated that a method to loadbalance a cluster of (for example) webserver nodes would be using bind DNS and round robin. By using such a method your DNS server would provide you a different IP address evert time you request the IP address of the server based upon the name.

As an example I have created a domain to play with in my own home setup. I have created the domain johanexample.com and I do run a website on it which can be accessed via the www.johanexample.com. Meaning that if I try to access www.johanexample.com my laptop will request the IP address of this webserver by asking it to my DNS bind server for it. The DNS server will tell the ip address is 192.0.2.44. This is a situation which you can see in the example diagram below. 


Now I do think that a lot of people like to see this page and for this reason I have build a cluster of webservers all ready to provide the content of the website www.johanexample.com to the users who want to see it. I have in total 4 webservers up and running and I named them node0, node1, node2 and node3 and the have the IP addresses 192.0.2.20, 192.0.2.21, 192.0.2.22 and 291.0.2.23

So what I would like is that the first user who wants to visit my website would be directed to node0 the second to node1, the third to node2, the fourth to node3 and fifth to node0 etc etc etc. To do this I have to setup my bind server in such a way this will start happening. So I have taken the following steps:

1) Create a zone file for the johanexample.com domain. I have created /etc/bind/zones/johanexample.com

2) Make sure the file johanexample.com is refereed to in the named.conf.local file so it will be picked up in the main configuration of bind.In my case I added:

zone "johanexample.com" {
    type master;
    file "/etc/bind/zones/johanexample.com";
};


3) make sure you create a complete zone file. My zone file looks like the one below. I do make more use of johanexample.com in my home network for testing so not all things in here are needed in this example:
; johanexample.com
$TTL    604800
@       IN      SOA     ns1.johanexample.com. root.johanexample.com. (
                     2012011501 ; Serial
                         604800 ; Refresh
                          86400 ; Retry
                        2419200 ; Expire
                         604800); Negative Cache TTL
;
@       IN      NS      ns1
        IN      MX      10 mail
        IN      A       192.168.1.109 
ns1     IN      A       192.168.1.109 
mail    IN      A       192.0.2.128
www     IN      A       192.0.2.20
 IN A 192.0.2.21
 IN A 192.0.2.22
 IN A 192.0.2.23
node0 IN A 192.0.2.20
node1 IN A 192.0.2.21
node2 IN A 192.0.2.22
node3 IN A 192.0.2.23

What specifically is needed for the load balance part is the records which are associated with www. We use www in combination with johanexample.com and where you see in a "normal" setup only one IP address per server you now see 4 different ones:

www     IN      A       192.0.2.20
 IN A 192.0.2.21
 IN A 192.0.2.22
 IN A 192.0.2.23

I have also created records in the zone file for all the specific nodes so I can acces them by making use of node0.johanexample.com, node1.johanexample.com, etc etc. This is however not needed. You can do without however it can be very handy from time to time. When you do play arround with your zone files and do try some things it is good to know that next to the more known utility named-checkconf you also have a utility to check your zone file: named-checkzone. In this example the way to use it would be:

root@debian-bind:/# named-checkzone johanexample.com /etc/bind/zones/johanexample.com 
zone johanexample.com/IN: loaded serial 2012011501
OK
root@debian-bind:/# 

When you zone file is correct configured and you have configured multiple IP's to one name you should be able to see the loadbalancing happening when you for example do a nslookup command like in the example below:
root@debian-bind:/# nslookup www.johanexample.com
Server:  192.168.1.109
Address: 192.168.1.109#53

Name: www.johanexample.com
Address: 192.0.2.21
Name: www.johanexample.com
Address: 192.0.2.22
Name: www.johanexample.com
Address: 192.0.2.23
Name: www.johanexample.com
Address: 192.0.2.20

root@debian-bind:/# 

A second check could be to do multiple ping commands and you will see the target IP change:
root@debian-bind:/# ping www.johanexample.com
PING www.johanexample.com (192.0.2.23) 56(84) bytes of data.

root@debian-bind:/# ping www.johanexample.com
PING www.johanexample.com (192.0.2.22) 56(84) bytes of data.

root@debian-bind:/# ping www.johanexample.com
PING www.johanexample.com (192.0.2.21) 56(84) bytes of data.

root@debian-bind:/# ping www.johanexample.com
PING www.johanexample.com (192.0.2.20) 56(84) bytes of data.

root@debian-bind:/# ping www.johanexample.com
PING www.johanexample.com (192.0.2.23) 56(84) bytes of data.

Thursday, July 30, 2009

Crash a BIND9 server


Bind is reporting a security flaw in their bind9 distribution. It turns out that you can cause a bind server to crash remote. As bind is one of the most used DNS servers arround the world and DNS is the glue which makes the internet stick together it can be considered quite a high risk. It turns out that you can crash a server by sending it a dynamic update for a zone of which the server is the DNS master. Or as it is stated on isc.org:

Receipt of a specially-crafted dynamic update message to a zone for which the server is the master may cause BIND 9 servers to exit. Testing indicates that the attack packet has to be formulated against a zone for which that machine is a master. Launching the attack against slave zones does not trigger the assert.

This vulnerability affects all servers that are masters for one or more zones – it is not limited to those that are configured to allow dynamic updates. Access controls will not provide an effective workaround.

dns_db_findrdataset() fails when the prerequisite section of the dynamic update message contains a record of type “ANY” and where at least one RRset for this FQDN exists on the server.

db.c:659: REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed
exiting (due to assertion failure).

Now if we take a look at the dynamic update part:

Dynamic Update is a method for adding, replacing or deleting records in a master server by sending it a special form of DNS messages. The format and meaning of these messages is specified in RFC 2136.

Dynamic update is enabled on a zone-by-zone basis, by including an allow-update or update-policy clause in the zone statement.

Updating of secure zones (zones using DNSSEC) follows RFC 3007: RRSIG and NSEC records affected by updates are automatically regenerated by the server using an online zone key. Update authorization is based on transaction signatures and an explicit server policy.

The dynamic update can be done via the nsupdate command. I will not explain on this weblog how you can crash a BIND9 machine however I can confirm the thread is real and with a little understanding of BIND and some research it is possible. I have been using a test environment to check it and if you are running a BIND9 server you might want to do dive a little deeper into this.


Saturday, February 28, 2009

DNSsec for .gov


Already some time ago that Dan Kaminsky published his exploit on DNS, by far this was one of the most shocking events for DNS admins in a long time. For those who like to understand the exploit found by Dan Kaminsky, there is a excelent guide on unixwiz.net which is a very good introduction about the DNS exploit.

To tighten the security the administrators of a .gov domain are now told to implement DNSsec to make sure the .gov domain servers will be more secure. Besides that tightening your security is always a good plan this will also be a boost for the DNSsec project. To get a good view on DNSsec you can review the video below which is a very fast introduction on DNSsec.



In very very short, the steps to create keys for DNSsec on a Linux BIND server are noted below. However, this is a very very short guide and it has a lot of open spots. You might want to look arround to find more details. I might even write a more detailed guide on this, however, for now you will have to do with this.

- Make sure you are running at least BIND 9.3, version 9.3 is the first version where you can sign your zones.
- Review your named.conf file and make sure that dnssec-enable is set to yes.
- Next, create a key for your zone, a ZSK key, (Zone Sign Key): dnssec-keygen -a RSASHA1 -b 1024 -n ZONE somedomain.com
- Create a key to sign your ZSK key: dnssec-keygen -a RSASHA1 -b 2048 -n ZONE -f KSK somedomain.com

To get all up and running you have to take some more steps, however, in this post I only want to show you how to create your keys needed for DNSsec.

Saturday, November 29, 2008

find subdomains of a domain

You might find yourself in a situation that you would like to know all the listed sub-domains in a domain. If you are the administrator of the DNS server you will not have much trouble of finding the information, if you are not the administrator of the server you can have a hard time finding out the sub-domains for a domain.

There is a 'trick' you can use to make the domain server tell you what the sub-domains for a domain are. This 'trick' is however not always working. If the domain server you are talking to allows DNS zone transfer and it is allowing this information to be send to all IP addresses that request is you are in luck. A DNS zone transfer is used to update slave DNS servers from the master DNS server.

When you operate several DNS servers you do not want to update them all when you are making a change. In a ideal situation you update the master server and the slave servers do a request to the master server every X time to be updates in. In some cases the administrator of the DNS servers has not set a limitation to who can request those updates. This will mean that you also can request a update.

A quick example, we take the domain knmi.nl which is the Dutch meteorology institute. First we would like to know the authoritive nameserver of the domain so we do a 'dig knmi.nl' at a linux shell:

jlouwers$ dig knmi.nl

; <<>> DiG 9.4.2-P2 <<>> knmi.nl
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24089 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;knmi.nl. IN A ;; AUTHORITY SECTION: knmi.nl. 4521 IN SOA styx3.knmi.nl. postmaster.styx3.knmi.nl. 2008112601 14400 1800 3600000 86400 ;; Query time: 18 msec ;; SERVER: 212.54.40.25#53(212.54.40.25) ;; WHEN: Sat Nov 29 12:32:55 2008 ;; MSG SIZE rcvd: 78 jlouwers$ jlouwers$ jlouwers$


"dig (domain information groper) is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name server(s) that were queried. Most DNS administrators use dig to troubleshoot DNS problems because of its flexibility, ease of use and clarity of output. Other lookup tools tend to have less functionality than dig."

So now we know the authoritive nameserver of the domain knmi.nl, you can find it under ";; AUTHORITY SECTION:", so we will be asking the styx3.knmi.nl for all the subdomains listed for this domain. This can be done with the a command like 'dig @styx3.knmi.nl knmi.nl axfr'. With this command we ask styx3.knmi.nl for all records for knmi.nl with a axfr command, axfr is the zone transfer command.


jlouwers$
jlouwers$
jlouwers$ dig @styx3.knmi.nl knmi.nl axfr

; <<>> DiG 9.4.2-P2 <<>> @styx3.knmi.nl knmi.nl axfr
; (1 server found)
;; global options: printcmd
knmi.nl. 86400 IN SOA styx3.knmi.nl. postmaster.styx3.knmi.nl. 2008112601 14400 1800 3600000 86400
knmi.nl. 86400 IN MX 5 birma1.knmi.nl.
knmi.nl. 86400 IN MX 10 birma2.knmi.nl.
knmi.nl. 86400 IN NS ns1.surfnet.nl.
knmi.nl. 86400 IN NS ns3.surfnet.nl.
knmi.nl. 86400 IN NS styx3.knmi.nl.
*.knmi.nl. 86400 IN MX 5 birma1.knmi.nl.
*.knmi.nl. 86400 IN MX 10 birma2.knmi.nl.
adaguc.knmi.nl. 86400 IN CNAME www.knmi.nl.
alvtest.knmi.nl. 86400 IN A 145.23.254.224
bbc.knmi.nl. 86400 IN CNAME bgwcab.knmi.nl.
bcrpwt.knmi.nl. 86400 IN A 145.23.254.127
bdyis1.knmi.nl. 86400 IN CNAME www3.knmi.nl.
bdypwt.knmi.nl. 86400 IN A 145.23.254.159
bemc.knmi.nl. 86400 IN CNAME styx3.knmi.nl.
besarv.knmi.nl. 86400 IN A 145.23.254.219
bgoftp.knmi.nl. 300 IN A 145.23.254.254
bgwcab.knmi.nl. 86400 IN A 145.23.254.228
bhlbpaaa01.knmi.nl. 300 IN A 145.23.253.111
bhlbpaaa02.knmi.nl. 300 IN A 145.23.253.112
birma1.knmi.nl. 86400 IN A 145.23.254.201
birma2.knmi.nl. 86400 IN A 145.23.254.202
bswor1.knmi.nl. 86400 IN A 145.23.4.1
bswor3.knmi.nl. 86400 IN A 145.23.254.243
bswor4.knmi.nl. 86400 IN A 145.23.254.244
bswso1.knmi.nl. 86400 IN A 145.23.16.25
cesar-database.knmi.nl. 86400 IN A 145.23.253.206
charon1.knmi.nl. 86400 IN A 145.23.254.151
charon2.knmi.nl. 86400 IN A 145.23.254.152
charon3.knmi.nl. 86400 IN A 145.23.254.153
climexp.knmi.nl. 300 IN A 145.23.253.225
cloudnet.knmi.nl. 86400 IN CNAME bgwcab.knmi.nl.
codex.knmi.nl. 86400 IN CNAME hades.knmi.nl.
eca.knmi.nl. 300 IN A 145.23.253.211
ecaccess.knmi.nl. 86400 IN CNAME styx1.knmi.nl.
ecad.knmi.nl. 86400 IN CNAME eca.knmi.nl.
ecadev.knmi.nl. 86400 IN A 145.23.254.218
ecearth.knmi.nl. 86400 IN CNAME climexp.knmi.nl.
esr.knmi.nl. 86400 IN A 145.23.254.216
ftp.knmi.nl. 86400 IN CNAME ftpgig.knmi.nl.
ftp2.knmi.nl. 86400 IN A 145.23.253.247
ftpgig.knmi.nl. 300 IN A 145.23.253.248
ftpmeteo.knmi.nl. 86400 IN A 145.23.254.54
ftppro.knmi.nl. 300 IN A 145.23.253.245
gate.knmi.nl. 86400 IN CNAME hades.knmi.nl.
gate1.knmi.nl. 86400 IN CNAME hades.knmi.nl.
gate2.knmi.nl. 86400 IN A 145.23.254.252
gate2p1.knmi.nl. 86400 IN CNAME charon1.knmi.nl.
gate2p2.knmi.nl. 86400 IN CNAME charon2.knmi.nl.
gate2p4.knmi.nl. 86400 IN CNAME webmail.knmi.nl.
gate3.knmi.nl. 86400 IN A 145.23.254.253
gate6.knmi.nl. 86400 IN A 145.23.254.236
geoservices.knmi.nl. 86400 IN A 145.23.253.210
hades.knmi.nl. 86400 IN A 145.23.254.158
hades1.knmi.nl. 86400 IN A 145.23.254.213
hexnet.knmi.nl. 86400 IN A 145.23.254.221
hl.knmi.nl. 86400 IN CNAME hexnet.knmi.nl.
hug.knmi.nl. 86400 IN CNAME hexnet.knmi.nl.
kd.knmi.nl. 300 IN A 145.23.253.193
kodac.knmi.nl. 300 IN A 145.23.253.131
localhost.knmi.nl. 86400 IN A 127.0.0.1
lvxtest.knmi.nl. 86400 IN A 145.23.254.227
maris.knmi.nl. 300 IN A 145.23.253.132
nadc-virt.knmi.nl. 86400 IN A 145.23.254.48
nadc01.knmi.nl. 86400 IN A 145.23.254.50
nadc02.knmi.nl. 86400 IN A 145.23.254.49
nadcorders.knmi.nl. 300 IN A 145.23.240.221
namis.knmi.nl. 86400 IN A 145.23.253.246
neonet.knmi.nl. 86400 IN A 145.23.254.222
neries.knmi.nl. 86400 IN A 145.23.254.250
newalv.knmi.nl. 86400 IN A 145.23.254.24
newhirlam.knmi.nl. 86400 IN A 145.23.254.106
newlvx.knmi.nl. 86400 IN A 145.23.254.25
newshost.knmi.nl. 86400 IN CNAME gate2.knmi.nl.
ns.knmi.nl. 86400 IN CNAME styx3.knmi.nl.
opmet.knmi.nl. 86400 IN CNAME newalv.knmi.nl.
orfeus.knmi.nl. 86400 IN CNAME neries.knmi.nl.
orfeustest.knmi.nl. 86400 IN CNAME bswor4.knmi.nl.
overheid.knmi.nl. 300 IN A 145.23.253.238
overheid-test.knmi.nl. 86400 IN A 145.23.253.237
portal.knmi.nl. 86400 IN A 145.23.254.191
sorry.knmi.nl. 86400 IN A 145.23.253.252
styx1.knmi.nl. 86400 IN A 145.23.254.238
styx2.knmi.nl. 86400 IN A 145.23.254.159
styx3.knmi.nl. 86400 IN A 145.23.254.155
swe.knmi.nl. 86400 IN CNAME styx3.knmi.nl.
test.knmi.nl. 86400 IN CNAME bcrpwt.knmi.nl.
testaccess.knmi.nl. 86400 IN A 145.23.254.195
trajks.knmi.nl. 86400 IN CNAME climexp.knmi.nl.
wap.knmi.nl. 86400 IN CNAME www.knmi.nl.
webaccess.knmi.nl. 86400 IN A 145.23.254.190
webmail.knmi.nl. 86400 IN A 145.23.254.154
www.knmi.nl. 300 IN A 145.23.253.254
www3.knmi.nl. 86400 IN A 145.23.254.200
knmi.nl. 86400 IN SOA styx3.knmi.nl. postmaster.styx3.knmi.nl. 2008112601 14400 1800 3600000 86400
;; Query time: 19 msec
;; SERVER: 145.23.254.155#53(145.23.254.155)
;; WHEN: Sat Nov 29 12:39:04 2008
;; XFR size: 95 records (messages 1, bytes 2169)

jlouwers$
jlouwers$
jlouwers$


This is how you can get a complete list of all subdomains listed at a domain server. However, this will only work in cases that a domain server is allowing you to request a zone transfer.