On 07/01/2010 10:42 AM, Tom Horsley wrote:
Unfortunately, enabling or disabling IPV6 doesn't seem to have much to do with the library doing V6 DNS lookups. I could swear there was something added to nsswitch.conf or resolv.conf that you could set to disable v6 dns requests, but I can't remember what it was called.
I run bind as a caching nameserver, forwarding lookups to my ISP's server and set the -4 option on the command line to make it stick to ipv4 and all my DNS lookup problems vanished.
bind is too complex to run and maintain. Really, it is a huge overkill for what I need.
I hope nscd authors will fix it soon so it does not purge it's cache every few seconds. I check'ed it's config file and the restart-interval 3600 seems reasonable.
Hi, I think that the default "restart-interval 3600", that is 3600 secs = 1hr, is a low/impractical value. I mean you want to keep your cache for much longer, perhaps a week or more ... It is why one wanted it in the first place.
Btw, there is a very good alternative (to BIND, etc) for DNS caching, namely dnsmasq package. It is simpler, easier on resources. I switched from bind to it and it serves me well. It is part of F13, used in other distros (Slackware, etc).
yum info dnsmasq
Jurek
On 07/01/2010 11:38 AM, Jurek Bajor wrote:
On 07/01/2010 10:42 AM, Tom Horsley wrote:
Unfortunately, enabling or disabling IPV6 doesn't seem to have much to do with the library doing V6 DNS lookups. I could swear there was something added to nsswitch.conf or resolv.conf that you could set to disable v6 dns requests, but I can't remember what it was called.
I run bind as a caching nameserver, forwarding lookups to my ISP's server and set the -4 option on the command line to make it stick to ipv4 and all my DNS lookup problems vanished.
bind is too complex to run and maintain. Really, it is a huge overkill for what I need. I hope nscd authors will fix it soon so it does not purge it's cache every few seconds. I check'ed it's config file and the restart-interval 3600 seems reasonable.
Hi, I think that the default "restart-interval 3600", that is 3600 secs = 1hr, is a low/impractical value. I mean you want to keep your cache for much longer, perhaps a week or more ... It is why one wanted it in the first place.
Btw, there is a very good alternative (to BIND, etc) for DNS caching, namely dnsmasq package. It is simpler, easier on resources. I switched from bind to it and it serves me well. It is part of F13, used in other distros (Slackware, etc).
yum info dnsmasq
Jurek
I had used dnsmasq, but it also suffered from the same problem I am having with nscd. I will try to set the interval to a longer time and see if that helps.
Cheers,
JD
On 07/01/2010 11:45 AM, JD wrote:
On 07/01/2010 11:38 AM, Jurek Bajor wrote:
On 07/01/2010 10:42 AM, Tom Horsley wrote:
Unfortunately, enabling or disabling IPV6 doesn't seem to have much to do with the library doing V6 DNS lookups. I could swear there was something added to nsswitch.conf or resolv.conf that you could set to disable v6 dns requests, but I can't remember what it was called.
I run bind as a caching nameserver, forwarding lookups to my ISP's server and set the -4 option on the command line to make it stick to ipv4 and all my DNS lookup problems vanished.
bind is too complex to run and maintain. Really, it is a huge overkill for what I need. I hope nscd authors will fix it soon so it does not purge it's cache every few seconds. I check'ed it's config file and the restart-interval 3600 seems reasonable.
Hi, I think that the default "restart-interval 3600", that is 3600 secs = 1hr, is a low/impractical value. I mean you want to keep your cache for much longer, perhaps a week or more ... It is why one wanted it in the first place.
Btw, there is a very good alternative (to BIND, etc) for DNS caching, namely dnsmasq package. It is simpler, easier on resources. I switched from bind to it and it serves me well. It is part of F13, used in other distros (Slackware, etc).
yum info dnsmasq
Jurek
I had used dnsmasq, but it also suffered from the same problem I am having with nscd. I will try to set the interval to a longer time and see if that helps.
Cheers,
JD
Well, I have found that setting the interval to a longer time does indeed help a lot! However, the behavior of Firefox in resolving URL's is still strange! If I click on a link, firefox spends almost a full minute to resolve the url, so while it is waiting (spinning), I use the gnome terminal to nslookup whatever-domain-it-was.com and it resolves it in less than a second. I look at firefox, and it is still trying to resolve!! Firefox seems to use some other way to resolve the url's domain - the painfully slow way!! Firefox has no config means of telling it how to resolve - so I'm at a loss as to it's behavior.
JD
On 03/07/10 16:06, JD wrote:
Well, I have found that setting the interval to a longer time does indeed help a lot! However, the behavior of Firefox in resolving URL's is still strange! If I click on a link, firefox spends almost a full minute to resolve the url, so while it is waiting (spinning), I use the gnome terminal to nslookup whatever-domain-it-was.com
... If you install wireshark, and then begin capture just before you make firefox go to a fresh site, ou should be able to see what is happening on the network.
ps. for me its: ff tries ipv6, waits a minute for nonexistent response, request ipv4, and instantly has the answer and the page.
wireshark makes it easy.
On 07/03/2010 12:53 AM, David Timms wrote:
On 03/07/10 16:06, JD wrote:
Well, I have found that setting the interval to a longer time does indeed help a lot! However, the behavior of Firefox in resolving URL's is still strange! If I click on a link, firefox spends almost a full minute to resolve the url, so while it is waiting (spinning), I use the gnome terminal to nslookup whatever-domain-it-was.com
... If you install wireshark, and then begin capture just before you make firefox go to a fresh site, ou should be able to see what is happening on the network.
ps. for me its: ff tries ipv6, waits a minute for nonexistent response, request ipv4, and instantly has the answer and the page.
wireshark makes it easy.
about::config shows that ipv6 is set to false, so that cannot be the cause. But I will try wireshark.
Thanx,
JD
On Fri, 2010-07-02 at 23:06 -0700, JD wrote:
I use the gnome terminal to nslookup whatever-domain-it-was.com and it resolves it in less than a second. I look at firefox, and it is still trying to resolve!! Firefox seems to use some other way to resolve the url's domain - the painfully slow way!!
Two things spring to mind:
Does the browser go through a proxy? If so, that proxy will do the resolving.
Are you using the Firefox features to check for bad websites?
On 07/03/2010 04:04 AM, Tim wrote:
On Fri, 2010-07-02 at 23:06 -0700, JD wrote:
I use the gnome terminal to nslookup whatever-domain-it-was.com and it resolves it in less than a second. I look at firefox, and it is still trying to resolve!! Firefox seems to use some other way to resolve the url's domain - the painfully slow way!!
Two things spring to mind:
Does the browser go through a proxy? If so, that proxy will do the resolving.
Are you using the Firefox features to check for bad websites?
Only add-on which checks for bad web sites is RequestPolicy which checks for cross-site request forgery. However, it is disabled!! And no, I am not using a proxy.
Also, FF seems to use a single socket file descriptor for all the FF windows and tabs. The side effect of it is that when you hit a sluggish site, then all windows/tabs are unavailable. If you switch to another FF window, you see same image of previous window overlaid on every other FF window. I had suggested to FF people to spawn a separate thread for each tab and let each tab open it's own private socket, so it will not tie up other tabs. It fell on deaf ears!
On 07/01/2010 11:38 AM, Jurek Bajor wrote:
On 07/01/2010 10:42 AM, Tom Horsley wrote:
Unfortunately, enabling or disabling IPV6 doesn't seem to have much to do with the library doing V6 DNS lookups. I could swear there was something added to nsswitch.conf or resolv.conf that you could set to disable v6 dns requests, but I can't remember what it was called.
I run bind as a caching nameserver, forwarding lookups to my ISP's server and set the -4 option on the command line to make it stick to ipv4 and all my DNS lookup problems vanished.
bind is too complex to run and maintain. Really, it is a huge overkill for what I need. I hope nscd authors will fix it soon so it does not purge it's cache every few seconds. I check'ed it's config file and the restart-interval 3600 seems reasonable.
Hi, I think that the default "restart-interval 3600", that is 3600 secs = 1hr, is a low/impractical value. I mean you want to keep your cache for much longer, perhaps a week or more ... It is why one wanted it in the first place.
Btw, there is a very good alternative (to BIND, etc) for DNS caching, namely dnsmasq package. It is simpler, easier on resources. I switched from bind to it and it serves me well. It is part of F13, used in other distros (Slackware, etc).
yum info dnsmasq
Jurek
Is there a way to query nscd and ask it what's in it's cache?
-
Development discussions related to Fedora -
JD -
Jurek Bajor -
Tim