That is the solution! It really were the dns timeouts.
First i changed my /etc/rc.d/rc.inet1.conf to keep the /etc/resolv.conf without overwriting it by dhcpcd.
Deleting the domain line out of /etc/resolv.conf did not help but changing the nameserver to google's did the job!
I am really glad for the insight and the patience of all posters!
I have one more question left: What is the cause of this error? Is something wrong with the routers dns server?

Either that, or your dhcp server is advertising the wrong dns server address to use when it gives you a reply, or there's some sort of firewall issue. Are you certain 192.168.2.1 is what the other machines on your net are using for dns lookups?

When you use dig, you can query a nameserver explicitly using the @address option, so give the following a try and see what happens.
dig @192.168.2.1 www.google.com


P.S. My router doesn't do DNS. It's dhcp just forwards my upstream ISPs dns server addresses to the client machines.

So i was looking into this again today. The dig @192.168.2.1 www.google.com does not report anything suspicious. So i decided to change the nameserver in my /etc/resolv.conf again to 192.168.2.1 . I needed a reboot to make things work since i get an error if not doing so. Now things work flawlessly with the router. So i guess your initial thought on a problem with the domain name in /etc/resolv.conf was right. I could be that i deleted the domain name at that time but didn't reboot after i supplied the DHCP_KEEPRESOLV[1]="yes" option to /etc/rc.d/rc.inet1.conf . So there seems to be a problem with dhcpd fetching the wrong domain name.

Is there a possibility to deactivate the domain name autofetch in dhcpd? Since i use more than one WLAN access point i seem to have two options: Keep the global google nameserver for all access points or make the autofetch work for all access points. Or is there a possibility to define several nameservers in /etc/resolv.conf and provide the right one at the corresponding access point? I do not think manually changing the nameserver depending on where i am would be an adequate solution.

You can tell dhcpcd not to ask for the domain name by removing the domain_name option from the options specified in /etc/dhcpcd.conf. If your router offers the domain_name even when you don't ask it to, you can use 'nooption' to ignore it.

You might want to look at your router config though, as you really don't want it offering a domain name that doesn't resolve in dns.

By way of explanation, I think that the problem here has been that the DNS resolver in the Speedport W 303V is broken, in that it does not handle requests for AAAA records. For a fuller explanation, see post #7 at https://bugs.launchpad.net/ubuntu/+s...bc/+bug/417757

You could try disabling ipv6 by booting with the ' ipv6.disable=1' kernel parameter to test this.

1 members found this post helpful.

That's actually 2 questions

But, to answer your second question (which may give you more insight into your first question), your router isn't really a DNS server. It's more of a DNS request forwarder. By that, I mean that any DNS requests that come to your router, will be forwarded on to the DNS servers the router has (which are either retrieved via DHCP from your ISP or manually programmed by you). In my years, with many different ISPs, I've found the ISP's provided DNS servers usually are not that great. They can be slow, but they can also hijack your 404 errors. This means, if you put in a website that doesn't exist, it will pop up with some random landing page (usually a basic search page) from your ISP.

I'm not a fan of that, so I usually change my DNS servers at the router level. This means that any computer that queries the router for DNS resolving, will then get the new DNS servers that I specified. Lately, I've used Google's nameservers (8.8.8.8 and 8.8.4.4) due to the ease in remembering the IP, but in the past, I've had good luck with OpenDNS's nameservers (208.67.222.222 and 208.67.220.220).

1 members found this post helpful.

As mentioned above the removal of the domain name in the resolv.conf already solved the problem, so i do not think that IPv6 lookups are the cause. Nevertheless thank you all for your effort and your great help in resolving this problem!
This absolutely reassures my decision to switch to slackware to have more control over my system.