1st time dns lookup always fails

Asked by Vincent van Adrighem on 2007-06-06

Since the feisty-upgrade, I'm having trouble reaching websites. Whenever I try to reach a server by name for the first time (website, ping, mail). It alsways fails. Firefox says "Connection reset", ping says "Resource temporarily unavailable".

I did a sniffing session with wireshark (udp dns lookups) and got the following result:
http://paste.ubuntu-nl.org/24455/
My laptop name is "janny-laptop" and I'm trying to open the website "www.anwb.nl" with firefox.
Notice the reverse lookups it does. It's not supposed to do that. And they fail (of course).
I'm thinking that's what causes the problems, but why is it doing those in the first place?

P.s. I don't have the libnss-mdns package installed anymore because I found the "slow dns because of mdns" bugreport.
My nsswitch.conf line looks like this:
hosts: files dns

I'm hoping someone will be able to help me with this.

Question information

Language:
English Edit question
Status:
Answered
For:
Ubuntu Edit question
Assignee:
No assignee Edit question
Last query:
2007-08-04
Last reply:
2007-08-04

I've been advised to turn off IPv6, so I edited the /etc/modprobe.d/aliases file. No more IPv6 adresses for me. But this doesn't solve the problem of the phantom reverse lookups.

You might be having some issues with Avahi (the Linux zeroconf system). In particular, those lookups for TXT records look like they might be related to DNS Service discovery. Could you post back your /etc/nsswitch.conf?

Also, try stopping the avahi service (run '/etc/init.d/avahi-daemon stop' as root), and see if firefox still has problems.

Excuse my lack of reading skills on the previous post... You can ignore the part about your /etc/nsswitch.conf. Have you restarted since removing libnss-mdns? Also, are you using nscd (the nameservice caching daemon)? If so, you will need to restart nscd to clear out any cached responses.

Lars Friedrichs (l-friedrichs) said : #4

The reverse lookups are typically a result by using wireshark which tries to lookup every address that comes along. Try using tshark with the option '-n' for no dns lookups. that will clean up everything a bit.
Anyhow this does not explain the above situation.

Vincent,
   Have you tried checking your DNS configuration? I just thought of this today... the way Linux and other UNIX systems hand DNS is different from Windows... Linux and friends search DNS in the order the DNS servers are listed... first the first server, then the second, etc. Windows tries them all at once. If the first DNS server in the list is bad (e.g. incorrect IP), you will see the behavior that you are seeing many times, as your initial DNS lookup fails while waiting for the bad first DNS server to respond, but the resolver continues on, trying to get the name even after your app has given up.

So, if you are using static IP, check in your /etc/resolv.conf, and ensure the DNS servers listed are correct. If they are, try changing the order to see if it makes a difference.

If you are using DHCP, check the settings on the DHCP server to ensure the DNS servers are correct.

Hi again,
My apologies for answering so slowly. This is the first time I have access to the box again since I posted the question. It's my parent's computer.

Thanks for the suggestions so far. I'm afraid the problem still exists. I want to make a correction to my first post. It's not a reverse lookup that's being done. It's a TXT record lookup of my IP-address. Very strange behavior, as I'm on a NAT and thus the TXT lookup will fail. It has nothing to do with a bad DNS server It's the fact that my computer is doing this at all?!? My computer should NEVER do TXT lookups. I guess that the problem is fixed when I know who is doing these lookups.

Jan Claeys (janc) said : #7

TXT lookups are most likely caused bij DNS Service Discovery which is used by more and more programs these days. Could be an application using Avahi if it's a multicast DNS (mDNS) request, or otherwise maybe a Jabber client...?

Can you help with this problem?

Provide an answer of your own, or ask Vincent van Adrighem for more information if necessary.

To post a message you must log in.