Alexander Spitzer wrote: > On Links the pages loaded fine but without images. So I figured midori only > renders after everything (or at least most of it) is received. After adding > a few of the wikimedia servers to the /etc/hosts file, midori loads > wikipedia perfectly fine (and fast). > > However, that doesn't really fix the underlying problem, other sites still > have the same trouble. > > On Tue, Mar 19, 2013 at 2:56 PM, Nicholas McCurdy > <mindwarpstud...@aim.com>wrote: > >> Are you using a 64Bit or 32bit kernel? >> > > > I'm using a 64 bit kernel, 3.7.0. Is there a way to check exactly how DNS > lookup is done and hopefully see where it gets stuck? I have tried messing > around with resolv.conf but no luck. What really baffles me is that only > particular websites are giving it trouble. I will do a little more > searching around but I'm glad I can at least go around the problem now.
The way dns works is that it sends a udp packet to the nameserver (specified in resolv.conf) and asks for an IP for a given name. For instance, if you want a.b.c.com, it asks for that. If the sever knows, it tells you in a return udp packet. If not, it either tells you to ask another name server or looks it up for you -- it depends on how it's set up. The server keeps a cache of ip addresses/names for the time-to-live (TTL) that the primary name server for the requested host has specified. Sometimes this process of looking up the IP address can take several tries and it slows up the process. There is a way to set up your own caching name sever with bind, but it's a relatively complex process. I prefer to use google. See https://developers.google.com/speed/public-dns/. They cache a lot of names and are relatively fast. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
