BIND Issues

[PureLoneWolf]

Hi there

I wonder if someone is willing to help. Following a recent disk crash, I have ditched VHCS2 and done a from-scratch installation of ISCP.

Everything has gone perfectly until I realised that my subdomains were not functioning. Checking the Server Status shows me:

89.149.194.232 (Port 53) DNS DOWN

I had a look in the logs and get this:

Code:

named[7438]: starting BIND 9.3.4-P1.1 -u bind
named[7438]: found 1 CPU, using 1 worker thread
named[7438]: loading configuration from '/etc/bind/named.conf'
named[7438]: listening on IPv6 interfaces, port 53
named[7438]: could not listen on UDP socket: permission denied
named[7438]: listening on all IPv6 interfaces failed
named[7438]: listening on IPv4 interface lo, 127.0.0.1#53
named[7438]: could not listen on UDP socket: permission denied
named[7438]: creating IPv4 interface lo failed; interface ignored
named[7438]: listening on IPv4 interface eth0, xx.xxx.xxx.xxx#53
named[7438]: could not listen on UDP socket: permission denied
named[7438]: creating IPv4 interface eth0 failed; interface ignored
named[7438]: not listening on any interfaces
named[7438]: couldn't add command channel 127.0.0.1#953: permission denied
named[7438]: couldn't add command channel ::1#953: permission denied
named[7438]: listening on IPv6 interfaces, port 53
named[7438]: could not listen on UDP socket: permission denied
named[7438]: listening on all IPv6 interfaces failed
named[7438]: additionally listening on IPv4 interface lo, 127.0.0.1#53
named[7438]: could not listen on UDP socket: permission denied
named[7438]: creating IPv4 interface lo failed; interface ignored
named[7438]: additionally listening on IPv4 interface eth0, xx.xxx.xxx.xxx#53
named[7438]: could not listen on UDP socket: permission denied
named[7438]: creating IPv4 interface eth0 failed; interface ignored
named[7438]: zone 0.in-addr.arpa/IN: loaded serial 1
named[7438]: zone 127.in-addr.arpa/IN: loaded serial 1
named[7438]: zone 255.in-addr.arpa/IN: loaded serial 1
named[7438]: zone localhost/IN: loaded serial 1
named[7438]: running

I saw in another thread about specifying listen-on port { any; }; so I did that, but this had no effect unfortunately. I also deleted references to IPv6 in the named.conf.options and based on a different thread changed the option to listen-on { any; };

The server is running Debian Etch and I am running the current version of ISCP from this site and it's installation documentation. Also, I have unrestricted root access to the box as it is my server, sat in a datacenter. No firewalls. I have already (for VHCS2) registered the nameservers ns.domain.com and ns2.domain.com - I edited the Bind templates to account for the ns instead of ns1 (thanks to searching)

Any help anyone could provide would be appreciated, been at this for a few hours now and can't seem to find anything with the Search Tool. Apologies if this has been answered before though and I would appreciate a link if it has.

Many thanks

Dave

[PureLoneWolf]

Slight update, I managed to get bind up and running by fixing issues with it running chrooted.

However, it still doesn't seem to operate correctly and although it seems ok after a reboot of the server, running a restart gives

named: capset failed: Operation not permitted

I have found some information regarding CONFIG_SECURITY_CAPABILITIES on various websites, but am not sure how to go about dealing with this.

Thanks again

[PureLoneWolf]

I can't figure it out - I am reformatting the server and will make sure that I don't upgrade the Kernel this time...fingers crossed.

[PureLoneWolf]

Ok, I still need some help. Complete reformat, careful installation and bind is up and running (seemingly) correctly.

When I view syslog I can see information being sent to bind

Code:

Mar 10 18:46:18 xx-xx-xx-xx named[2366]: listening on IPv6 interfaces, port 53
Mar 10 18:46:18 xx-xx-xx-xx named[2366]: listening on IPv4 interface lo, 127.0.0.1#53
Mar 10 18:46:18 xx-xx-xx-xx named[2366]: listening on IPv4 interface eth0, xx.xx.xx.xx#53
Mar 10 18:46:18 xx-xx-xx-xx named[2366]: listening on IPv4 interface eth0:1, yy.yy.yy.yy#53
Mar 10 18:46:18 xx-xx-xx-xx named[2366]: command channel listening on 127.0.0.1#953
Mar 10 18:46:18 xx-xx-xx-xx named[2366]: command channel listening on ::1#953
Mar 10 18:46:18 xx-xx-xx-xx named[2366]: zone 0.in-addr.arpa/IN: loaded serial 1
Mar 10 18:46:18 xx-xx-xx-xx named[2366]: zone 127.in-addr.arpa/IN: loaded serial 1
Mar 10 18:46:18 xx-xx-xx-xx named[2366]: zone 255.in-addr.arpa/IN: loaded serial 1
Mar 10 18:46:18 xx-xx-xx-xx named[2366]: zone admin.xx-xx-xx-xx.internetserviceteam.com/IN: loaded serial 2009031000
Mar 10 18:46:18 xx-xx-xx-xx named[2366]: dns_master_load: /var/cache/bind/wolflan.com.db:24: ns.wolflan.com: CNAME and other data
Mar 10 18:46:18 xx-xx-xx-xx named[2366]: zone wolflan.com/IN: loading master file /var/cache/bind/wolflan.com.db: CNAME and other data
Mar 10 18:46:18 xx-xx-xx-xx named[2366]: zone localhost/IN: loaded serial 1
Mar 10 18:46:18 xx-xx-xx-xx named[2366]: dns_master_load: /var/cache/bind/laughingwolf.co.uk.db:24: ns.laughingwolf.co.uk: CNAME and other data
Mar 10 18:46:18 xx-xx-xx-xx named[2366]: zone laughingwolf.co.uk/IN: loading master file /var/cache/bind/laughingwolf.co.uk.db: CNAME and other data
Mar 10 18:46:18 xx-xx-xx-xx named[2366]: running
Mar 10 18:46:18 xx-xx-xx-xx named[2366]: zone admin.xx-xx-xx-xx.internetserviceteam.com/IN: sending notifies (serial 2009031000)
Mar 10 18:46:18 xx-xx-xx-xx named[2366]: client yy.yy.yy.yy#54439: received notify for zone 'admin.xx-xx-xx-xx.internetserviceteam.com'

As I said before I have been using VHCS2 up until now and the nameservers are officially registered as valid nameservers. If I add records to my domain control panel (external) then the server reacts correctly, however it does not react correctly to a new domain being setup, even though it is registered to use the correct nameservers (and has been for a long time now).

For example - I added laughingwolf.co.uk into ISCP. The domain is registered and the nameservers are specified as ns.wolflan.com and ns2.wolflan.com. Both of these nameservers are up and running and registered as valid nameservers. Yet, even if I SSH to the server and ping laughingwolf.co.uk, it doesn't resolve correctly.

I thought it could be something to do with resolv.conf and added nameserver xx.xx.xx.xx to the top of that file to be safe.

Any help would be welcomed, I am getting desperate now and really don't want to be forced down the route of my previous (crap) panel.

Many thanks

***EDIT***
My datacenter provides nameservers aswell...could it be that I need to set forwarders?

Thanks again

[kilburn]

Are you sure that the nameservers are up and running?

Code:

Bender:~$ host laughingwolf.co.uk ns.wolflan.com
;; connection timed out; no servers could be reached

[PureLoneWolf]

Right now, they aren't I have been trying all sorts of things and ended up with a different issue now lol

Code:

Stopping domain name service...: bind9rndc: connect failed: 127.0.0.1#953: connection refused
.
Starting domain name service...: bind9named: cap_set_proc failed: Operation not permitted: please ensure that the capset kernel module is loaded.  see insmod(8)
failed!

This is driving me crazy lol

[PureLoneWolf]

Ok - Back to almost working...

Bind9 is giving me the following message:

Code:

Stopping domain name service...: bind.
Starting domain name service...: bindnamed: capset failed: Operation not permitted
named: capset failed: Operation not permitted

I found this article:
http://www.paul.sladen.org/vserver/archi.../0172.html
and the source files (http://www.paul.sladen.org/debian/bind9.nocapset/)

It would appear that Bind needs to be recompiled with ./configure --disable-linux-caps

My issue is that I don't know how I can do this, and unfortunately the articles only seem to have woody versions.

Can anyone help?

Many thanks

[kilburn]

This problem should be more related to bind's chrooting than to some compiling option.

By the way, look at section 7.14 here on how to build a debian package from sources (just change this option prior to compiling). Keep in mind that this "package building" operation can be made on another (non-production) machine and then you just need to transfer the .deb file and dpkg -i it. The bad thing about this is that you will have to repeat the procedure each time the original package is updated...

[PureLoneWolf]

Thanks - I'll give it a go