> > ...
> > 10s : Query A google.com
> > 12s : Query A google.com
> > 12.01s : Response AAAA google.com : 72.14.207.99
>
> Are you sure the last response has type AAAA ?

No, it has not, I'm sorry. Of course, this is of type A.

> My first idea would be that the problem is at the queried DNS server,
> but you said this server works well with other machines and the same
> happens with other DNS servers. Are all queries aimed at the same DNS
> server ?

No, they alternate between both configured DNS-servers.

> If ipv6 is built in the kernel, there is no module. Check if
> /proc/net/if_inet6 exists, or if ifconfig reports inet6 addresses.
>
> Name resolving is not performed by the kernel, but I thought the
> resolver library sent AAAA queries only when IPv6 was enabled. It even
> seems that some versions of the resolver library send AAAA queries only
> when the system has a "suitable" IPv6 address, i.e. not loopback and
> link-local addresses only.

I'm going to check this, but at the moment I don't have access to the
concerned machine.

Thanks a lot for the response!

> > ...
> > 10s : Query A google.com
> > 12s : Query A google.com
> > 12.01s : Response AAAA google.com : 72.14.207.99

> Are you sure the last response has type AAAA ?

No, it has not, I'm sorry. Of course, this is of type A.

> My first idea would be that the problem is at the queried DNS server,
> but you said this server works well with other machines and the same
> happens with other DNS servers. Are all queries aimed at the same DNS
> server ?

No, they alternate between both configured DNS-servers.

> If ipv6 is built in the kernel, there is no module. Check if
> /proc/net/if_inet6 exists, or if ifconfig reports inet6 addresses.

> Name resolving is not performed by the kernel, but I thought the
> resolver library sent AAAA queries only when IPv6 was enabled. It even
> seems that some versions of the resolver library send AAAA queries only
> when the system has a "suitable" IPv6 address, i.e. not loopback and
> link-local addresses only.

I'm going to check this, but at the moment I don't have access to the
concerned machine.

Thanks a lot for the response!

Edit: Wrong account, changed it...

> > ...
> > 10s : Query A google.com
> > 12s : Query A google.com
> > 12.01s : Response AAAA google.com : 72.14.207.99

> Are you sure the last response has type AAAA ?

No, it has not, I'm sorry. Of course, this is of type A.

> My first idea would be that the problem is at the queried DNS server,
> but you said this server works well with other machines and the same
> happens with other DNS servers. Are all queries aimed at the same DNS
> server ?

No, they alternate between both configured DNS-servers.

> If ipv6 is built in the kernel, there is no module. Check if
> /proc/net/if_inet6 exists, or if ifconfig reports inet6 addresses.

> Name resolving is not performed by the kernel, but I thought the
> resolver library sent AAAA queries only when IPv6 was enabled. It even
> seems that some versions of the resolver library send AAAA queries only
> when the system has a "suitable" IPv6 address, i.e. not loopback and
> link-local addresses only.

I'm going to check this, but at the moment I don't have access to the
concerned machine.

Thanks a lot for the response!

Edit: Wrong account, changed it...

info@cheffestl.de a écrit :
>
>>My first idea would be that the problem is at the queried DNS server,
>>but you said this server works well with other machines and the same
>>happens with other DNS servers. Are all queries aimed at the same DNS
>>server ?
>
> No, they alternate between both configured DNS-servers.

In which order ? It is a pity that you did not mention the server in
queries and replies in the wireshark trace.

info@cheffestl.de wrote:

[putolin]

>> Try putting this into your /etc/modprobe.conf if ipv6 is compiled as a
>> modules and not into the kernel.
>>
>> # disable autoload of ipv6 module
>> alias net-pf-10 off
>
> Already done before. The ipv6-MODULE is definitely switched off. But
> could there be any ipv6-functionality compiled into the kernel? How
> can I check?
>

To see if it is loaded (as root) :

lsmod | grep ipv6

example:
[root@desktop ~]# lsmod | grep ipv6
ipv6 256324 8

To find out if ipv6 is compiled as module:

find /lib -name ipv6.ko -print

Should return the path to kernel module named ipv6.ko

example: /lib/modules/2.6.25-ARCH/kernel/net/ipv6/ipv6.ko

otherwise it was compiled into the kernel.


If you try to load the ipv6 module and you have:

# disable autoload of ipv6 module
alias net-pf-10 off

in the /etc/modprobe.conf you get:

[root@desktop ~]# modprobe net-pf-10
FATAL: Module off not found.

--
Tayo'y mga Pinoy

I think I resolved the issue:

I analyzed the DNS queries of windows (working without problems on the
same machine) and found out that the same effect is happening there as
well: 3 query packets have to be sent until a response is received.
The difference: Windows sends the queries with a much higher frequency
and therefore the whole progress doesn't take as much time and the
user doesn't recognize any delay.

So the problem seemed to be rather the router than the client system.
Maybe the router recognizes an UDP "connection" only after at least 3
packets have been sent from the same port to the same port (as using
UDP the router has no TCP flags signalling new connections). I don't
know, something like this...

Workaround (since I haven't got access to reconfigure the router):
Define the router IP itself as nameserver instead of the nameservers
that it suggests via DHCP. So the UDP packets have to travel only
within the LAN and the problem is avoided. The router is then able to
act as a "DNS-forwarder", asks the nameservers of the ISP for the
result and returns the result to the client.

Anyway: Hard to imagine that this effect doesn't happen all over the
linux world?! What is different in other people's linux systems? Do
they usually have shorter timeouts? Is the configuration of my router
really THAT strange and normally routers forward the DNS packets
properly? Do they ignore the DHCP-given nameservers and use the
gateway-IP as default nameserver??? I didn't reconfigure anything
strangely, the system is an almost-out-of-the-box debian!

Thanks for your help!

I think I resolved the issue:

I analyzed the DNS queries of windows (working without problems on the
same machine) and found out that the same effect is happening there as
well: 3 query packets have to be sent until a response is received.
The difference: Windows sends the queries with a much higher frequency
and therefore the whole progress doesn't take as much time and the
user doesn't recognize any delay.

So the problem seemed to be rather the router than the client system.
Maybe the router recognizes an UDP "connection" only after at least 3
packets have been sent from the same port to the same port (as using
UDP the router has no TCP flags signalling new connections). I don't
know, something like this...

Workaround (since I haven't got access to reconfigure the router):
Define the router IP itself as nameserver instead of the nameservers
that it suggests via DHCP. So the UDP packets have to travel only
within the LAN and the problem is avoided. The router is then able to
act as a "DNS-forwarder", asks the nameservers of the ISP for the
result and returns the result to the client.

Anyway: Hard to imagine that this effect doesn't happen all over the
linux world?! What is different in other people's linux systems? Do
they usually have shorter timeouts? Is the configuration of my router
really THAT strange and normally routers forward the DNS packets
properly? Do they ignore the DHCP-given nameservers and use the
gateway-IP as default nameserver??? I didn't reconfigure anything
strangely, the system is an almost-out-of-the-box debian!

Thanks for your help!

I think I resolved the issue:

I analyzed the DNS queries of windows (working without problems on the
same machine) and found out that the same effect is happening there as
well: 3 query packets have to be sent until a response is received.
The difference: Windows sends the queries with a much higher frequency
and therefore the whole progress doesn't take as much time and the
user doesn't recognize any delay.

So the problem seemed to be rather the router than the client system.
Maybe the router recognizes an UDP "connection" only after at least 3
packets have been sent from the same port to the same port (as using
UDP the router has no TCP flags signalling new connections). I don't
know, something like this...

Workaround (since I haven't got access to reconfigure the router):
Define the router IP itself as nameserver instead of the nameservers
that it suggests via DHCP. So the UDP packets have to travel only
within the LAN and the problem is avoided. The router is then able to
act as a "DNS-forwarder", asks the nameservers of the ISP for the
result and returns the result to the client.

Anyway: Hard to imagine that this effect doesn't happen all over the
linux world?! What is different in other people's linux systems? Do
they usually have shorter timeouts? Is the configuration of my router
really THAT strange and normally routers forward the DNS packets
properly? Do they ignore the DHCP-given nameservers and use the
gateway-IP as default nameserver??? I didn't reconfigure anything
strangely, the system is an almost-out-of-the-box debian!

Thanks for your help!

info@cheffestl.de a écrit :
>
> Is the configuration of my router really THAT strange

It seems so.

> and normally routers forward the DNS packets properly?

Yes, as well as any UDP traffic.