DA setting up named differently after update?

[emmanuel]

In the spate of misadventures with suPHP after the last update, I didn't notice this until a customer tried to create a new account/domain.

Previously, when a new domain was setup, DA puts the named config file for the domain in /var/named/chroot/var/named with a link of the same name in /var/named.

e.g. /var/named/placebo.com.db -> /var/named/chroot/var/named/placebo.com.db with owner root:named

However, since the update apparently, DA stores the file itself in /var/named without any linking anymore, and the ownership is root:root

For some reason, it seems that this is causing DNS to fail, as in, the domain cannot be found even after a few days.

I've tried manually to mv the file into the chroot folder, then creating a link and restarting named after that. There was no error with named when restarting. Given the default 86400 seconds, I'm waiting to see if after 24hrs, the domain starts showing up on the Internet.

If so, is there anyway to edit DA to configure it to do the same thing as before?

Also, in the same line, is it possible to configure DA to set up new domain records with lower timings instead of 24hrs, say 4hours and remain that way even when new versions are updated?

 

[nobaloney]

This?

Or the exact opposite?

Jeff

 

[emmanuel]

This?

Or the exact opposite?

Jeff

I'm doing the exact opposite.

I was a bit confused when I saw that set of instructions before this when searching for information. This is because since the first time I had to look at the named files, it had always been chrooted (which I understand is a security feature so A Good Thing) and things had always worked.

So my conclusion was that somehow, mine was set differently (maybe the ELS script did it? I don't know). All I know is that things worked before the update with named files in the chroot folders and I just want to get things to work first before I worry about the why it's different now.

Right now, after more than 24hrs since I did the configuration changes, the new domain names are still not resolving but the old ones are still working fine. Whois information on the new domain names are pointing to my server as their name server so the only thing I can conclude is that my named is not recognizing these new domains as under it's charge.

Is there anyway to check which domains my named actively believes it's in charge of?

Thanks!

 

[emmanuel]

I just tried checking by using nslookup on my Windows box. Setting the "server" to my name server and checking the domain in question produces what I think is the correct response.

i.e. Name: problematicdomain.com
Served by:

followed by a list of A to J ROOT-SERVERS.NET

So I think this means that named on my server is actually working and responding to queries about the problematic domain, or am I mistaken?

 

[emmanuel]

Ok, using this tool here
http://network-tools.com/nslook/Default.asp

I get an non-authoritative response from my own name server when I was expecting an authoritative response. The working domains do, only the non-working domains are giving non-auth. So I suppose this is where the crux of the matter is.

grepping through the /var/log/messages file, I found only one possible clue. The error was " bad zone transfer request: '******.com/IN': non-authoritative zone (NOTAUTH)"

However, that was logged about 6hours ago. Since then, I've restarted named a few times but the error did not recur any more. Although I cannot be sure what was it I did then that stopped the error.

I've copied the .db file of a working domain and changed the names to fit the problem domain, updated the serial and restarted named but it's still not returning an authoritative response.

Is there anyway to find out why named refuses to be authoritative?

 

[emmanuel]

named works if I stop it and run it in su as root using the following command found on the web.

/usr/sbin/named -g named -u

All the problematic domains work, whether they are in a regular file or symbolic links to the chroot folder.

However, setting the permissions on the file to 777 and running named using the usual service named restart/start does not work.

Any ideas why or more importantly, how to fix this apart from permanently having to run a detached named process from command line?

Thanks

 

[nobaloney]

DirectAdmin wasn't designed to work properly with chroot installed.

My opinion is you should

Save your /etc/named.conf file somewhere.

Save all the zone files somewhere.

Remove the chroot if it's currently installed.

Move all the zone files to /var/named

Reinstall the old named.conf file in /etc, making sure the paths in all the zones are set to /var/named/example.com.db (where example.com is replaced with the proper domain name).

Restart the name daemon.

If you don't feel comfortable doing this yourself, then we and others on these forums are able to do the work for you as a commercial service.

Jeff

 

[emmanuel]

DirectAdmin wasn't designed to work properly with chroot installed.

oic, then I'm quite puzzled why my named was working with chroot since DA was installed by DA staff when the server was set up, not by me.

Remove the chroot if it's currently installed.

Does this involves uninstalling chroot or is it just a matter of telling named not to chroot itself? Or simply as you mentioned, moving the files out of chroot?

If you don't feel comfortable doing this yourself, then we and others on these forums are able to do the work for you as a commercial service.

lol, I don't feel comfortable mucking around with a live server at all. However, I also realize if I don't at least try, I'll be forever stuck at being a noob. If I give it a go myself first, at least I might learn what can I handle and what would require somebody else to step in.

Now that you mention it, I just realized we're paying a yearly license for DA, is this considered a DA support problem since it occurred after updating DA?

 

[nobaloney]

I thought I wrote that you need to uninstall chroot after you save the files.

I have no idea whether DirectAdmin staff will consider this a support issue and fix it for you; you might want to ask them; look here.

Jeff

 

[emmanuel]

Thank you very much for the patience and help, jlasman.

I did as you mention and moved the files out of chroot, the domain totally went missing even from the command line running of named. That got me scratching and looking at the files I finally discovered that for some inexplicable reason, the named.conf mv from inside chroot was missing the problem domain.

Once I added the domains into the named.conf, things appeared to work properly with a /sbin/service named start

I guess the last update of DA must have changed things to edit the /etc/named.conf but my named was somehow reading the same old config inside the chroot/etc instead?

Hopefully that's the last I'll hear of this issue, keeping my fingers crossed for the next new domain that get setup

 

[nobaloney]

Thank you very much for the patience and help, jlasman.

You're very welcome.

I guess the last update of DA must have changed things to edit the /etc/named.conf but my named was somehow reading the same old config inside the chroot/etc instead?

If I recall correctly, DA always edits /etc/named.conf, which may or may not be maintained as a link to the chroot's etc/named.conf. The problem occurs when it's a separate file instead of a link.

Why not try setting up a phony domain (i.e., example.com) to see if it's fixed permanently.

And be sure that you don't have any automatic updating in place to switch you back to a chrooted BIND.

Jeff

 

[emmanuel]

If I recall correctly, DA always edits /etc/named.conf, which may or may not be maintained as a link to the chroot's etc/named.conf. The problem occurs when it's a separate file instead of a link.

oic, most probably the link was changed to an actual file then in the last update so ended up with the desync. No way to tell now though

Why not try setting up a phony domain (i.e., example.com) to see if it's fixed permanently.

Didn't realized that would be feasible. Tried it and yeah, it worked! Thanks Jeff!

And be sure that you don't have any automatic updating in place to switch you back to a chrooted BIND.

Well, the noob that is me has no idea if something like that exists. But if named fails again and I find everything back in chroot, then I'll know... but hopefully I won't ever need to see that

 

[nobaloney]

Check your OS Distribution's automatic update system and make sure it's not updating a "chroot" package. Also make sure the package containing chroot isn't installed. However if it is don't just uninstall it; it could completely break your DNS.

Jeff