Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1751
  • Last Modified:

Slow DNS resolve times / time-outs BIND 9 with Active Directory

Small network. One MS Active Directory server and 20 or fewer workstations. We were relying solely on the Windows 2000 server (AD) for DNS, DHCP as well as handling many other tasks. I don't like having all the eggs in one basket, so as a first step, I took one of our older machines - still a PIII 450mHz with 576 RAM - and put Debian Woody on it. The idea is for it to take over the DHCP and share the DNS load. DHCP is going no problems. DNS is BIND 9 and is integrated with AD. Regular updates are happening and the logs look good. All necessary zones exist. Shouldn't be a problem - but there is. While internal addresses are responding faster than ever, external addresses are taking longer. Sometimes even Google times-out. If you try to re-load, you usually get the site in your browser - sometimes it takes a couple of attempts. Once you have resolved a root domain (www.google.com), all other pages in that domain respond very quickly (for example: http://www.google.com/froogle?hl=en&tab=gf&q=) Caching seems to be an issue because 5 minutes later, Google.com will time-out again. All pings inside the network are good but I do get time-outs from both nslookup and dig when testing with some external domains. (dig www.yahoo.com). Dig will usually respond on the 2nd try and nslookup can take up to 4 or 5 attempts. My db.root file seems fine. Not sure what is happening here... I do still consider myself a Linux noob so your patience and any suggestions are appreciated.  
0
DGray
Asked:
DGray
  • 7
  • 4
1 Solution
 
LionBSDCommented:
small suggestion,

in /etc/named.conf put in your ISP's DNS servers as Forwarders, that way your dns server won't do all the work resolving names
let's say your isp has 10.10.10.10 and 10.10.10.11 as DNS servers so you put into your named.conf file this:

options {
    directory "/var/named";
    forwarders {
        10.10.10.10;
        10.10.10.11;
    };
    forward first;
    dialup yes;
    heartbeat-interval 1440;
};

just make sure the linux machine can access these DNS server on UDP port 53 ( in case you have a firewall)
0
 
DGrayAuthor Commented:
Sorry I forgot to mention that I already had both of our the DNS IP's from our ISP in the forwarders section of named.conf. It was already set up that way in the Windows 2000 AD server and I set up named.conf that way for BIND, too. I didn't have the forward first; dialup yes; or heartbeat-interval 1440; in there... I'll have to try those / find out what they do. I will report back the results.
0
 
jlevieCommented:
If you are behind a firewall you'll need:

query-source address * port 53;

in the options {}; section. Lack of that could cause the symptoms you describe.
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
DGrayAuthor Commented:
jlevie - Sorry, I also have query-source in the options already... I'd post my entire named.conf but I'm not at the Debian machine right now. That does just about cover everything I've got in there before the zones except for my "directory=" and the path for the pid file.  

I did some man reading and found out about the suggestions from LionBSD:

forward first; - this means to check the forwarders listed before trying anything else. The default is first, so I wonder if actually specifying this will make a difference?

dialup yes; - tells bind9 that the connection is dialup so all maintenance is performed at once rather than throughout the day. While my connection is not dialup, it couldn't hurt - especially if maintenance is causing the slow response times to external addresses. Again the default is yes, so does specifying this make a difference?

heartbeat-interval; - tells bind9 to when to perform maintenance. The default is one hour (60) - a setting of 1440 is once a day.

Again, I haven't been able to try these yet, but I will and report back.
0
 
DGrayAuthor Commented:
Ok, I added:

forward first;
dialup yes;
heartbeat-interval 1440;

to my named.conf file. I am now avoiding all browser time-outs even though the response time still seems slower than when we relied solely on the DNS in the W2K server. I do still get time-out errors with nslookup and still think something is up with caching because revisiting Google.com can still take a little time to resolve. I am still curious since "first" is the default of forward first - did putting it in there really do anything or am I just getting lucky with my browser time-outs this morning? Any other tips on optimizing resolve times / solving this problem are still appreciated...
0
 
jlevieCommented:
Could we see the options {}; section of your named.conf, please?
0
 
DGrayAuthor Commented:
No problem - here is the options section of my named.conf:

options {
      directory "/etc/bind";

      pid-file "/var/run/named.pid";

      statistics-file "/var/run/named.stats";

      query-source address * port 53;

forwarders {
      68.12.16.229;
      68.12.16.30;
      };

      forward first;
      dialup yes;
      heartbeat-interval 1440;
      auth-nxdomain no;    # conform to RFC1035

};
0
 
jlevieCommented:
From here it looks like 68.12.16.229 isn't working, but 68.12.16.30 is. If you get the same results it would explain the slow response to queries since named would try 68.12.16.229, timeout, ant hen get the data from 68.12.16.30. It would hold that in cache for a while and eventually cycle back through the list of forwarders.

Try 'host -T www.google.com 68.12.16.229' and 'host -T www.google.com 68.12.16.30' and see if both respond in a timely manner.
0
 
DGrayAuthor Commented:
Those $0B's - I didn't even think to check that but you were absolutely right. We have a dedicated business subscription with (nslookup the working server IP in my forwarders above and you'll know who) - I called and they said it had been offline for a couple of weeks... Their phone rep said he had only been there about that long and when we asked why we weren't notified, the reply was "I don't really know how that works." We didn't notice so much in the past because we had the IPs reversed in our gateway and in the forwarders section of the W2K server - so the working DNS server was getting our requests first. Man, talk about poor service. They nearly have a monopoly in our area though, so it is hard to change to anything better.

Ok, jlevie I know you deserve most of the points here. The only unanswered question that developed in the discussion is "Did adding 'forward first;' to the options in my named.conf really accomplish anything? I ask because I read the default is "first" anyway. If it did help, I'm going to increase the total points and throw a few to LionBSD, too. Either way, I do really appreciate everyone who has provided input. Our connection response times - both internal and external - have never been faster.
0
 
DGrayAuthor Commented:
BTW - they gave me the IPs of two of their new DNS servers to use as well as the one that is still working.
0
 
jlevieCommented:
If forwarders are defined in the options {} section of named.conf they'll be tried before named will go to the root servers, so strictly speaking including "forward first" doesn't do anything except to make it more obvious what's going to happen.
0
 
DGrayAuthor Commented:
jlevie - you da man. Thatnks for following thru on my "forward first" question. That's what I assumed (but I never like assuming). I am also still mad at myself for not checking the ISPs DNS before you mentioned it. They had been working for us for 3 years! Oh well... I added another 50 since you answered my last question, too. The points go to you my good man.
0

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

  • 7
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now