# [Solved] Slow DNS lookup with Webkit browsers

## nero37

Webkit based browsers chromiun-bin and midori both take ~20s to do a DNS lookup. Firefox and other apps are unaffected. 

My wireless connection is handled by Network-Manager, which sets my resolve.conf to query my router for DNS lookups. The strange thing is it works fine with my girlfriends router, so it must be something to do with my home setup.Last edited by nero37 on Wed Sep 30, 2009 7:23 pm; edited 1 time in total

----------

## E001754

I had similar problem once with Firefox.

I solved it by changing a parameter, for telling Firefox that he's directly connected to internet rather than being on dial-up connection.

My answer is not really accurate and I'm currently at work so I can't check the exact parameter name in Firefox. I'll can check further if it's usefull for you, just let me know.

----------

## Sadako

To parot E001754, I used to have a similar issue on firefox, too.

It was due to firefox attemping dns lookups via ipv6 rather than ipv4 (despite "-ipv6" in USE, very slow because my adsl modem/router didn't support it, disabling it in about:config solved it.

I know you said it was fine in firefox and the problem is in chromium, but it's something to check, at least, and it could explain why it works fine with your girfriends' router and not your own.

edit: you could try capturing network packets during this long lookups via tcpdump, and then analyse it in wireshark to see wtf is really going on.

----------

## daviessm

Usually the 'problem' with IPv6 support is that the client (Firefox) contacts an available DNS server -- the same as any other program -- and receives some AAAA records for the host you're trying to connect to. By default the system will prefer IPv6 over IPv4, and will only attempt to connect over v6 if it has a valid route over v6 to that host. The issue is that sometimes the kernel believes there is a valid route when there actually isn't, and this causes the slowdowns as the client has to wait for the connection to time out before falling back to v4.

So, the problem isn't usually within the application, it's within the kernel routing table. 'ip -6 route show' (if you have iproute2) should show you whether the kernel thinks it has any valid routes.

----------

## nero37

Thanks everyone for all the help.   :Very Happy: 

I got it fixed, it was ipv6 acting up. I rebuilt my kernel and removed support for ipv6. Midori and Chromium appear to be working correctly now.

Thanks.

----------

