Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have set up local BIND/DNS services on an Ubuntu Server (Linux). It is working properly and lets me receive new domain requests for multiple hostnames set up in our Apache web service. So, I can host sites like example1.com, example2.com, etc., as long as the registrar of those domains point to my nameserver IP on this server.

When I look in /etc/resolv.conf, it says "nameserver 127.0.0.1".

All is well except every once in awhile, my server cannot ping someone else's brand new domain name (created two days ago), while on other computers it can ping just fine. But when I reboot the Ubuntu Server, it comes back up and it can now ping the new domain name just fine.

What's wrong with our BIND config?

share|improve this question

3 Answers 3

Your sysop has not given you a solution, he has given you a work around.

A solution would identify why your local recursive server sometimes don't work, and then fix that. Try the suggestion from @topdog to prove that it's the local DNS server that's playing up. If it is, just restart BIND - not the whole server!

For what it's worth, this sounds like a negative caching effect (see RFC 2308). If (and only if) you've looked up a new name before, BIND will remember that it didn't exist, and return NXDOMAIN from its negative answer cache.

The cache expiry time for negative answers is controlled by two things:

  1. The minttl field from the parent domain's SOA record
  2. The max-ncache-ttl setting from your bind.conf.

The latter setting caps any value received in the SOA to that maximum, and BIND's default is three hours. What's your setting?

In any event, mixing recursive and authoritative DNS on the same server process is not best practice.

If you do want to have recursion and authority on the same system, run them as two separate processes. Have the recursive server only listening on the loopback (127.0.0.1) interface, leaving the public facing authoritative server only serving the domains that it's authoritative for.

share|improve this answer
    
I couldn't find a bind.conf file. On Ubuntu Server 9.10, I found /etc/bind. Inside, I found named.conf, and it loads named.conf.default-zones, named.conf.local, and named.conf.options. In named.conf.default-zones, it works with db.local. I looked in that and found these values: Serial (2), Refresh (604800), Retry (86400), Expire (2419200), Negative Cache TTL (604800). This tiny comment field cannot tell you all that is in these small files. :( –  ServerChecker Aug 24 '10 at 4:06
    
yes, named.conf, not bind.conf - sorry. In any event it's the negative cache time in the parent of the missing zones that matters, not the ones in your zones. And that max-cache-ttl setting, if it's in your named.conf –  Alnitak Aug 24 '10 at 7:43

My sysop finally got up with me and said that all I needed to do was edit my /etc/resolv.conf and add an extra entry in before "nameserver 127.0.0.1", so, my /etc/resolv.conf now looks like this:

# 8.8.8.8 is Google's free DNS
nameserver 8.8.8.8
nameserver 127.0.0.1

This will let my server resolve DNS stuff that it cannot handle itself.

share|improve this answer
1  
Be advised, that by doing that, your system will always check 8.8.8.8 first before it checks 127.0.0.1. Since 8.8.8.8 belongs to Google and is quite reliable, you will rarely ever hit your local system (for local lookups). This will not have an effect though on external domains using your servers as authoritative. –  vmfarms Aug 20 '10 at 19:42
1  
You are better off running with 127.0.0.1 because it will cache results for you, adding dns servers does not fix your problem, you need to find out why your dns server stops responding and only starts responding after you reboot/ –  topdog Aug 20 '10 at 20:06
    
Good comments, @vmfarms and @topdog. I'm having our sysop review this. –  ServerChecker Aug 22 '10 at 16:39

You need to debug that, the next time a host name is not responding check if the issue is actually DNS resolution problem by issuing the command

dig domain_name.ext @127.0.0.1 

From the server, based on the output you will determine whether you get a response or not if not you need to then look at the logs to see if the bind is still running.

share|improve this answer
    
My sysop just connected to me by email and gave me the solution, so I'm typing that right now. However, your advice is useful, so I'll consider it as well. Thanks! :) –  ServerChecker Aug 20 '10 at 19:25

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.