I have Charter Pipeline. After installing the cashing DNS applications onto my system to try to speed up DNS lookups and checking the configurations it still takes 30 seconds (that's right!) to resolve the hostname for my bank. Other pages load really quickly, but I notice a delay in DNS lookup quite often. There must be a way to speed this up.

Thanks,
Ted.

which nameserver(s) do you use to resolve domain names?
if you are using one of the roots and if you dont have the most recent root hint-file, get it:

ftp://ftp.rs.internic.net/domain/named.root

hmm...which dns-server are you actually running?

The DNS package I installed was called caching-name-server. My resolv.conf is:

nameserver 66.169.254.29
nameserver 66.169.254.30
nameserver 66.189.219.30
nameserver 66.189.219.29
search rddng.ca.charter.com

I will update my named.ca file and see if that helps.

Thanks,
Ted.

Update: Updating the named.ca file did nothing. I have been working on this all week. If anyone knows what to do next, that would be nice.

Ted.

ok...if you point the nameserver-entries in your resolv.conf to something other than 127.0.0.1 (or equivalent), your caching-structure is unable to do its work.

you will have to let the dns-package do all dns-resolves.

delete (or comment out) the four nameserver-lines, and simply add nameserver 127.0.0.1
since your dns-package is called "caching-name-server", i suppose that its already set up the right way.

if not...well...if not, post again


aah...look if there is a file called named.conf in /etc. maybe you could post its content the next time.

Well yeah, you're not using your caching nameserver at all. Your resolv.conf still points to your ISP's nameservers. As meks pointed out, you need to use nameserver 127.0.0.1 in /etc/resolv.conf. If you want to use your ISP's servers as backups in case your own nameserver gets broken, then just place the entry for 127.0.0.1 above all the other entries (they're tried in order).

Also, if you currently have your ISP's nameservers in the "forwarders" section of /etc/named.conf, it will still be slow when doing the initial lookup for a host (because it isn't cached, so the request will be forwarded to your ISP); however after the first lookup, results will be retrieved from the local cache (until they expire and need refreshed).

That is no the default behavior, though. By default, the caching-nameserver package goes to the root servers for authority delegation.

Okay, my resolv.conf file now only has 127.0.0.1 listed in it but name resolution is not any faster. Here is my named.conf file:

// generated by named-bootconf.pl


// secret must be the same as in /etc/rndc.conf
key "key" {
algorithm hmac-md5;
secret
"c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};

controls {
inet 127.0.0.1 allow { any; } keys { "key"; };
};


options {
pid-file "/var/run/named/named.pid";
directory "/var/named";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
};

//
// a caching only nameserver config
//
zone "." {
type hint;
file "named.ca";
};

zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};

// workaround stupid stuff... (OE: Wed 17 Sep 2003)
zone "ac" { type delegation-only; };
zone "cc" { type delegation-only; };
zone "com" { type delegation-only; };
zone "cx" { type delegation-only; };
zone "museum" { type delegation-only; };
zone "net" { type delegation-only; };
zone "nu" { type delegation-only; };
zone "ph" { type delegation-only; };
zone "sh" { type delegation-only; };
zone "tm" { type delegation-only; };
zone "ws" { type delegation-only; };

Looks fine to me.

Ted.

P.S. Every time I reboot my resolv.conf changes back to its original state. My settings are getting over-written. Something is getting in the way, but I don't have enough experience to know what to look for.

dhcp is causing it to be overwritten.

Try doing this (yes, twice)

$ dig@127.0.0.1 foo.com soa | grep time
$ dig@127.0.0.1 foo.com soa | grep time

The first time it will be just as long as normal, but the second time it should be very fast. If it's slow both times, then there is something wrong with your system (high load, network brokenness, etc).

It is possible, although not likely, that your ISP intercepts all outbound DNS requests and redirects them to their own servers. To test this you could try

$ dig @4.2.2.1 foo.com soa | grep SERVER

and see what the result is. If the SERVER is something other than 4.2.2.1, you have problems out of your control (unless you have some sort of router that is setup to forward DNS requests to your ISP, in which case you need to modify the router).

your configuration looks like a typical caching-ns-config.

do you actually know what a caching nameserver is?
each first lookup done for a domain will take as long as it took before you set up your dns. if you request the ip for a specific domain again, the dns will recognize that it's already cached and will not query again, but instead return the ip to the requesting client immediately.

this means, if you resolve www.google.com once, www.microsoft.com once and www.kernel.org once, your dns will have to send a query to one of the nameservers listed in your root hint-file. if the first root replies, the dns will cache it and send the resolved ip to the client. if the first root doesnt reply, the next will be tried and so on.
its most likely that, in your case, the first root replies, because you mentioned that you updated your root hint-file.

lets assume that your client gets the ip after 250ms and that your local dns cached it. try to access the same domain again - you will notice a speed improvement of about 50-100ms (depending on how long the first resolve took).

do a rndc flush and ping www.google.com afterwards. you will notice that the first icmp takes longer than the following replies.
if this happened, then your caching name server is set up properly.

how long do you have to wait for name-resolves to be completed? does it really take 30 seconds?

dig reports "connection timed out. no servers could be reached." rndc reports "connection refused." I cannot ping anyone but myself.

Yes, it really does take 30 seconds to resolve hostname www.etrade.com. Other DNS resolutions take 10 seconds and others are immediate. If I load the etrade site from my browser a second time it comes up immediately, but I think that is only because it is being loaded from the hard drive. If I close my browser and reopen it, etrade once again takes 30 seconds to resolve the hostname. If I just type in the IP address for etrade it loads immediately.

I have used Shorewall to create rules for IPTABLES. I don't think Shorewall is causing problems but here are my rules:

###############################################################################
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
fw net ACCEPT info
#loc net ACCEPT
net all DROP info
all all REJECT info
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

I will go in and accept "loc" and see if that makes a difference. If it does I'll post back. It's worth a try.

Ted.

Which dig though? dig @127.0.0.1, or dig @4.2.2.1, or both? If dig @127.0.0.1 times-out, then you have a serious misconfiguration, probably of your firewall. If you cannot dig @127.0.0.1, then none of your DNS lookups will be able to use your caching nameserver, so they'll just resolve everything through your ISP (assuming you have 127.0.0.1 listed at the top of resolv.conf and all the other nameservers listed below it).

dig @127.0.0.1 times out dig @4.2.2.1 responds with a list of root servers. I will review my firewall rules again but they look right to me. I'll read the info on the Shorewall site and see if I missed anything.

Thanks,
Ted.

I did a shorewall clear to disable the firewall and tried dig @127.0.0.1 and it again timed out. So it is not the firewall. I am beginning to wonder if Charter is redirecting requests or they put configuration files on my system I know nothing about. I really don't know. It should be working.

Ted.

No, you've done something wrong. If named isn't running, you should just get a connection refused, you may not have a route to the loopback adaptor.

What's the output of the following

$ ps -ef | grep named
$ netstat -rna

Hmm, well I am charting new territory for me with this project. If I get this working I will have learned a thing or two. Thanks for sticking with me.

Here is the output of $ ps -ef | grep named and $ netstat -rna:

root 3960 3920 0 08:34 pts/0 00:00:00 grep named

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
68.118.56.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 68.118.56.1 0.0.0.0 UG 0 0 0 eth0


Ted.

Well, I reinstalled my OS. Didn't set up any firewall. Upgraded to the 2.6.0 kernel then followed the directions for setting up a caching DNS server at TLDP. My config files look exactly like they do in the directions and still no caching is taking place. I will just start putting in IP addresses instead of URLs for problem websites. Either I bit off more than I can chew or it just can't be done with this system. I give.

Thanks for all the help.

Have a good day.

Ted.