I have intermittently very fast, slow, and non-existent ability to connect to websites via web browser (FireFox).

I can browse for a couple of hours sometimes (sometimes less, sometimes more), but inevitably, I end up with the browser "waiting" for a response from all websites that I attempt to access.

I have enabled IPv6 and disabled IPv6 by modding hosts, modprobe, FireFox's about:config, etc. However, despite the fact that disabling IPv6 is the stock answer to all things DNS-related, I get essentially the same behavior setting up for one or the other.

So, in other words why do I get extremely fast performance (almost as if the web pages were local) and then at times I get nothing. I have Suse 9.2 installed on the same machine as an XP Pro installation and have never experienced similar behavior using the same DNS servers. At most, I may do a "repair" connection once per month to clear DNS cache if things seem to get a little slow (sometimes less frequently). I also have an XP Home machine on the same LAN with a shared Internet connection, and after SuSE gets stumped, I can go to the XP Home machine and connect just fine.

The only solution I have now with SuSE is to reboot. Once that is done, I'll have fast browsing for a period of time but I will eventually have to reboot.

I have tried doing "ifconfig eth0 down" then "ifconfig eth0 up" in an attempt to simulate the rebooting process without actually rebooting; however, while the commands do bring eth0 down and then up (I can see the eth0 sensor in GKrellM disappear then reappear), I have zero connectivity to the internet until I reboot. I have tried bringing eth0 down and back up even when I otherwise have good connectivity, and it always breaks the connection until I reboot. So, as a side issue, I am wondering if there is some additional step required to make the "up" parameter actually fully restore eth0 once it has been taken down. Seems to me "up" should mean "up with functionality and without reboot"; however, what I find is that "up" means the system can see the adapter, but I have no functionality across the adapter.

Anyway, it is a major annoyance to be happily browsing along, then suddenly be faced with "waiting...." in the browser's status bar. This is probably one of those issues for which a solution will remain elusive, but any thoughts or suggestions will be highly appreciated.

hi there

are u using ur own DNS server??and how do u go about "clearing DNS cache"

regards

No, I am using my ISPs servers (cable connection by the way). But, understanding that external DNS servers can be difficult to reach at times, I still can say that I have never had any trouble using the same servers under XP, thus my conclusion that this is some issue within my Linux installation. I have two servers identified in resolv.conf, and I have additionally added instructions to rotate servers (rotate) and to limit the amount of connection-attempt time before trying another server (retrans:n). Let me say that those additions to the resolv.conf file actually do optimize DNS lookup when things are working (i.e., it seems to make things faster on the whole when everything else is actually working); however, those settings do not prevent the periodic [DNS] failure that I previously described. Furthermore, I have experimented without those options set, and removing them does not help the issue in any way.

As far as what I do to "flush cache", I will repeat that rebooting is the only fix I know that works. I also mentioned that I thought taking down and restoring eth0 with the down / up options of ifconfg would work, but I discovered that even outside the context of my problem, bringing eth0 back up with the "up" option makes the interface visible to the system but only a reboot restores connectivity. Again, shouldn't "ifconfig eth0 up" completely restore functionality of the interface without a reboot; if not what is its purpose? And if not, what will bring back functionality without rebooting?

Furthermore, does Linux even cache DNS names locally? I wasn't sure if that was what was actually happening (flushing cache) when rebooting or whether the "fix" was related to something else that got tweaked during the reboot process. In Win XP, I can manually flush cache with ipconfig or by right-clicking the connection icon in the tray and selecting "repair" (repair does several things, one amongst them is flushing DNS cache); this is rarely necessary. If you are aware that Linux stores DNS cache locally and that there is a command to flush it, that may be a step in the right direction. As a matter of fact, two days ago I might have asked that question in this post directly and from the start, but I believe I was convinced from other sources that Linux did not utilize DNS caching locally.

Thank you for for your response.

hi there

linux uses caching nameserver wth BIND and i think if u are using BIND then DNS will be locally cached

so have u treid usng ur own DNS server
try that too

also i would like to now how do u rotate DNS servers with Linux

regards

Vcore5.0 I 2 am experiencing the exzact same problem! I am running Fedora core 3 and firefox 1.0 the sys seemed to be fine intill I started messing with the extensions and paths. I did this to get JRE up and running so I could use limewire. But now like u said firefox will actully timeout trying to resolve a host, and at best takes forever. OR is blazing fast? I also have a broad band connection (cable) and use a dual boot config, XP connects fine? Would someone be so kind as to post all commands related to a internet connection and its status? I tryed to download the bandwidth tester extension for firefox and when I try to launch it, It crashes?

thanks everyone!!!

did u try the DNS server as we have done in this thread?

regards

I couldn't figure out what you meant by the above because no instructions for setting up a DNS server were given in this thread, so I assumed you meant to attach a link but didn't. The link (perhaps one of many??) that does have you giving another user instructions on setting up Bind (named) for local cache is here:

http://www.linuxquestions.org/questi...hreadid=292374

I did try this, but it presents a compromise, and I haven't determined yet which method is less annoying. For instance, when everything is working perfectly fine otherwise, the setup without using "named" is extremely fast in resolving names (instantaneous seems to describe it well). After introducing "named" into the equation, looking up an address not currently in the local cache is very slow in comparison. Of course, once the name is in cache, the lookup is again extremely fast.

So, the compromise is this:

1. Use a basic setup (without "named" running) and have extremely fast lookups of all names, but with the annoyance of having to deal with periodic (every few hours or so) extremely slow lookup requiring a reboot to rectify;

2. Use a setup with "named" running and have extremely fast lookup if the address has already been stored in cache, but slower lookup if the address isn't in cache. If you frequent the same websites over and over, this may be effective. If you use a wide variety of websites (i.e., if you are doing searches and continually connecting to new sites all the time), this method is not very effective. Plus, I haven't used it long enough to determine if it actually fixes the problem in Item #1 above.

So, thank you very much for supplying an alternative. Even if it ultimately doesn't provide a workable solution, it has enlightened me to some things I hadn't previously had experience with. I will keep experimenting.

PS
For those using SuSE wishing to try the "named" procedure outlined by Masand in the link I provided above, I will supply a couple of tips to at least get you started:

- Use the following commands from root instead of the ones provided by Masand (his instructions work better for Fedora):

rcnamed restart
rcnamed start
rcnamed stop

- Files that will be of main interest when configuring all of this will be:

/etc/hosts
/etc/host.conf
/etc/resolv.conf
/etc/named.conf

Here is a link that explains DNS in general, but specifically gives some of the best details I have seen on the configuration of the first 3 files above (by the way, Masand, you will find on this page under the topic heading, "Configuring your local machine", an answer to your previous question about how to use the "rotate" option in resolv.conf):

http://members.toast.net/art.ross/rute/node32.html

Again, I do not suggest yet that using "named" is the solution to my problem as I haven't experimented with it enough yet; however, I am providing the above info with it in mind that someone may want to try BIND / "named" for other reasons.

thanks for rectifyig me
i forgot to mention the DNS configuring steps.
yes the command "service" is for fedora/redhat /mandrake systems
for
slackware like we do as /etc/rc.d/rc.named start

and for suse u mentioned urself

and the logic behind using caching nameserver is also corect as u mentioned
the local DNS server will query the DNS server above it for any new request

and that tuorial u posted is exhaustive

aslo i wanted to know this that which entry should i put in
/etc/hosts say for

yahoo.com

the nameserver for yahoo.com that i get from nslookup ??

regards

out curiosity can you tell what do you have in /etc/resolv.conf
usually people are pointing nameserver to the router IP address which is wrong.

running DNS server on the workstation may work but that is not right resolution.

hi there
i have my IP addresss and that of my ISp in my /etc/resolv.conf

nameserver 127.0.0.1
nameserver 202.56.XX.XX #kppp temp entry
nameserver 202.56.XX.XX #kppp temp entry


regards

o.k so what you are using for ip addresses assingment? DHCP?

i am not using DHCP

for what do u want to use IP assignment??

regards

Not sure who you were addressing here, but:

I can assure you that my resolv.conf file doesn't point to my router IP. But you couldn't possibly have known that (other than I wouldn't have been able to resolve any addresses at all), so thanks for the suggestion.

I agree with you that running BIND to fix the type of problem I have described is incorrect simply because it is not getting to the cause of the problem. Ultimately, however, I believe that some people (not me) may give up identifying exactly what the problem is and resort to patching the situation with whatever works. Secondarily, running BIND can add a security risk which is not present otherwise and which has to be understood and managed.

On the other hand, using DNS cache may help speed things up in general, and that is something everybody is always looking for (and one that I wouldn't be opposed to, not as a solution to my problem, but as an additional tool to be added to my installation). As such, the DNS cache issue is really an interesting, related side-issue to the topic at hand.

By the way, an alternative to full-blown BIND is "djbdns" which claims to be simpler and more secure (most here will be familiar with at least a little):

http://cr.yp.to/djbdns.html
http://tinydns.org/
http://www.djbdnsrocks.org/single/dnscache.htm