Hello Bert,
Any ideas why it takes so long?
Rerun with --trace enabled and check what is happening. With some study, it
should be clear what it is waiting for.
did that already before, but still did not found anything helpful there. Below
is a new trace.
btw, I am using 3.5.1 (package
What about giving the full dig output too? My bet is you're actually
experiencing some sort of huge delay starting up dig or resolving
localhost, use @127.0.0.1 instead and see if the time goes away.
Does your /etc/hosts contain 'localhost'? Have you modified your
nsswitch.conf? (Assuming
Thanks for your answer. The full dig output was in the first posting.
I have not modified nsswitch.conf and /etc/hosts contains only this:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
Hi,
what does your recursor.conf look like? I'm only guessing here but as you
are obviously forwarding all queries to 8.8.8.8 there is one thing that
people tend to get the wrong idea about which is using forward-zones instead
of forward-zones-recurse which does not set the Recursion Desired (RD)
On Sunday, June 23, 2013, Shamus Smith wrote:
Thanks for your answer. The full dig output was in the first posting.
I have not modified nsswitch.conf and /etc/hosts contains only this:
No, only the +short is in any of your responses, when I say full output I
mean without +short - there's a
On Sun, Jun 23, 2013 at 5:40 PM, Michael Loftis mlof...@wgops.com wrote:
I don't think anything other than /etc/hosts should get involved but your
stall pretty clearly appears to be happening during the resolution of the
@localhost and not the round trip to the world and through the pdns
