How To create a non-recursive nameserver

Originaly posted by nhouse
Also, I simply followed the link on "how to fix it" that is on the dnsreport.com results page and simply adding recursion no; to the named.conf file corrected the negative output in dnsreports.com... with that said, that was a simple fix but does it have the potential to cause me other issues? Again, I did a clean minimal install of CentOS 4 and then the DA install... not much else.

I have found these issues when using the meathode provided by dnsreport.com

1. Unable to update Installatron
2. Unable to use wget
3. Unable to ping outside hosts
4. Exim will not send mail


-Jason
 
Last edited:
Hi Jeff,

When you mentioned those two files to be backed up, one them being:

/etc/named/conf

did you really mean:

/etc/named.conf

Because the former I cannot find on Redhat 9 - not even a symbollic link.

Cheers,
Nick.

Edit: Thanks Jeff! Works great.
 
Last edited:
jdlitson said:
I have found these issues when using the meathode provided by dnsreports.com

1. Unable to update Installatron
2. Unable to use wget
3. Unable to ping outside hosts
Jason (and everyone),

If your nameserver is not recursive you have to make sure you've got two recursive nameservers in /etc/resolv.conf, and that you don't have any references to your localhost in that same file, as well.

Since the server can't use itself anymore to find DNS resolution, resolv.conf has to list (only) to recursive servers somewhere else (and preferably in the same data center).

Jeff
 
Thanks for the info Jeff :)
When I have more time, I will follow your guide, and post my results.

Thanks again -Jason
 
Few notes for FreeBSD users:

1. named.conf is located in /etc/namedb/ directory.
2. If you are not comfortable editing config files manually, you can just use these commands:


cp -i /etc/namedb/named.conf /etc/namedb/named.conf-`date +%d-%b-%Y`

perl -pi -e 's/^(\s*options\s*{.*)/acl recurseallow { 127.0.0.1; };\n$1/g' /etc/namedb/named.conf

perl -pi -e 's/^(.*?statistics-file.*)/$1\n\tallow-recursion { recurseallow; };/g' /etc/namedb/named.conf

/usr/local/etc/rc.d/named stop

/usr/local/etc/rc.d/named start


Also, on our FreeBSD 4.11 box updated to STABLE before installing DA, I've got the following entries in the logs:
May 27 20:07:11 main named[61047]: couldn't create pid file '/var/run/named/pid'
This can be fixed by

perl -pi -e 's/\/var\/run\/named\/pid/\/var\/run\/named.pid/g' /etc/namedb/named.conf

/usr/local/etc/rc.d/named stop

/usr/local/etc/rc.d/named start
 
Biken said:
How do this in Debian ?

It should be quite similar to setting this up on CentOS/RH, so check the 1st post and let us know if there are any problems :)
 
Hey Jeff,
I followed your instructions and everything worked perfectly. Thanks -Jason
 
I wasn't using my da server as a nameserver so have not had caching-nameserver rpm installed. I'm thinking of turning the da server into a hidden master and would like to know if I turn off recursion on the da server's named.conf will it disrupt any of the mail sent externally to non hosted domains like yahoo.co.uk,etc?

Should I be thinking of adding a caching server for the hidden master for dns lookups locally?


thanks

Jon
 
Last edited:
Do not add the caching-nameserver to your system; it doesn't add a separate nameserver but simply adds the caching capability to your own nameserver.

If you add caching-nameserver and then turn recursion off you've added it, but then disabled it.

I posted a response today in another thread; make sure your /etc/resolv.conf file lists two nameservers, external to your server, but still in your local network, before you turn off recursion.

Your own server uses the nameservers listed in /etc/resolv.conf, and NOT the local nameserver (unless it's listed in that file).

Jeff
 
Sorry to re-open a possibly sore subject but do you think DA can add the feature of recursion on or off and allow for adding recursive-allowed IP's in the control panel if it is turned off? This would be nice.
 
It doesn't matter what I think, and It's not a sore subject at all. But this isn't the right place for the suggestion. You should probably create a thread at Feedback & Feature Requests, and make your request there.

Jeff
 
I'm getting the same ugly message at DNSreports

This is the contents of my res /etc/resolv.conf

; generated by /sbin/dhclient-script
search prov.800hosting.com
#nameserver 192.168.0.1
nameserver 69.41.160.28 #hostnameserver IP
nameserver 69.41.160.29

hostnameserver IP
nameserver 4.3.2.0
nameserver 4.3.2.1

4.3.2.0-1 represent some of my ips on eth0.

How do I prevent the open lookups error?
 
The contents of your resolv.conf file doesn't affect the output of DNSReport.
; generated by /sbin/dhclient-script
search prov.800hosting.com
#nameserver 192.168.0.1
nameserver 69.41.160.28 #hostnameserver IP
nameserver 69.41.160.29

hostnameserver IP
nameserver 4.3.2.0
nameserver 4.3.2.1
There isn't enough information here to give you real help.

My guess is that all the IP#s in your resolv.conf file are on your local server.

If so, then the first thing you need to do is get (from whomever provides your connectivity) the IP#s of two working nameservers, on the same network (or local to the same network) you use, which can be used as recursive nameservers.

Then change your /etc/rsolv.conf file to this:
Code:
nameserver 12.34.56.78
nameserver 12.34.56.79
Replacing the 12.34.56.78 and 12.34.56.79 with the IP#s of those two nameservers.

Once you've done that, then change your local nameserver (change /etc/named.conf) to a nonrecursive server following the instructions at the top of this post.

The restart the nameserver.

If your upstream won't give you the IP#s of two nameservers you can use, then you can follow the instructions in toml's post above, but I don't support that; you can ask him for help if you need it.

Jeff
 
Bad in some folks' opinions. Personally I don't see anything wrong with using an open server as long as it's cache is updated often enough so if it does become poisoned (highly unlikely anyway) the poison will be deleted in a matter of minutes.

Nevertheless, simply that DNSReport doesn't like it is a great reason to not have one :) .

I'll bring the issue to DA staff attention.

Jeff
 
Back
Top