<div dir="ltr"><br><br>On Sunday, June 23, 2013, Shamus Smith wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:times new roman,new york,times,serif">
<div>Thanks for your answer. The full dig output was in the first posting.<br>I have not modified nsswitch.conf and /etc/hosts contains only this:</div></div></div></blockquote><div><br></div><div>No, only the +short is in any of your responses, when I say full output I mean without +short - there's a hint of timing information in the full dig output. We have teh time it took for the entire command to execute but we don't have the actual RTT of the DNS query. It'll indicate the query time, as well as whom it sent the query too IE what @localhost was resolved to prior to dig starting it's own query - which I think it uses gethostent or one of the other get* calls.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:times new roman,new york,times,serif"><div><br><br>127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4<br>
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6<br><br>And you were right! When using "dig <a href="http://www.google.com" target="_blank">www.google.com</a> @<a href="http://127.0.0.1" target="_blank">127.0.0.1</a>" it takes just<br>
0.021 seconds. But I still do not have a clue why, do you?<br></div></div></div></blockquote><div><br></div><div style>My *guess* or hunch is that your internal OS stack gethostent, getaddrinfo, etc, is failing/falling over somehow or in some form. It shouldn't be talking to anything in resolv.conf but if it is then the later response about correctly having the RD bit set or not because of the configuration could explain the different behavior with dnsmasq. Normally it should be consulting your local files first, finding an answer, and immediately returning. But if there's something funny going on it might not be. Other issues can occur if you have LDAP user databases/etc, or even if you've got some heavy swapping/paging going on it'll take a while to start up any command that isn't already fully in cache/RAM. All that is why I asked for the timing information from dig, which it runs *after* any of that could get into the way.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:times new roman,new york,times,serif"><div><br>When using another recursor (Dnsmasq) there is no time difference when using<br>
@localhost or @<a href="http://127.0.0.1" target="_blank">127.0.0.1</a>.<br>
<br>Thanks,<br>Shamus<br></div></div></div></blockquote><div>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 recursor. <br>
</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:times new roman,new york,times,serif"><div style="font-family:times new roman,new york,times,serif;font-size:12pt">
<div style="font-family:times new roman,new york,times,serif;font-size:12pt"> <div><br>What about giving the full dig output too? My bet is you're actually<br>experiencing some sort of huge delay starting up dig or resolving<br>
"localhost", use @<a href="http://127.0.0.1" target="_blank">127.0.0.1</a> instead and see if the time goes away.<br>Does your /etc/hosts contain 'localhost'? Have you
modified your<br>nsswitch.conf? (Assuming standard *nix like system)<br><br>On Sun, Jun 23, 2013 at 3:58 AM, Shamus Smith <<a>smithshamus@yahoo.de</a>> wrote:<br>> Hello Bert,<br>><br>>> > Any ideas why it takes so long?<br>
>><br>>> Rerun with --trace enabled and check what is happening. With some study,<br>>> it should be clear what it is waiting for.<br>><br>> did that already before, but still did not found anything helpful there.<br>
> Below is a new trace.<br>> btw, I am using 3.5.1 (package pdns-recursor-3.5.1-1.el6.x86_64).<br>><br>> Thanks,<br>> Shamus<br>><br>> - /etc/init.d/pdns-recursor start<br>> Jun 23 12:30:12 server pdns_recursor[11064]: PowerDNS recursor 3.5.1 (C)<br>
> 2001-2013 PowerDNS.COM BV (May 3 2013, 20:04:33, gcc 4.4.7 20120313 (Red<br>> Hat 4.4.7-3)) starting up<br>>
Jun 23 12:30:12 server pdns_recursor[11064]: PowerDNS comes with ABSOLUTELY<br>> NO WARRANTY. This is free software, and you are welcome to redistribute it<br>> according to the terms of the GPL version 2.<br>> Jun 23 12:30:12 server pdns_recursor[11064]: Operating in 64 bits mode<br>
> Jun 23 12:30:12 server pdns_recursor[11064]: Reading random entropy from<br>> '/dev/urandom'<br>> Jun 23 12:30:12 server pdns_recursor[11064]: Only allowing queries from:<br>> <a href="http://127.0.0.0/8" target="_blank">127.0.0.0/8</a>, <a href="http://10.0.0.0/8" target="_blank">10.0.0.0/8</a>, <a href="http://100.64.0.0/10" target="_blank">100.64.0.0/10</a>, <a href="http://169.254.0.0/16" target="_blank">169.254.0.0/16</a>, <a href="http://192.168.0.0/16" target="_blank">192.168.0.0/16</a>,<br>
> <a href="http://172.16.0.0/12" target="_blank">172.16.0.0/12</a>, ::1/128, fe80::/10<br>> Jun 23 12:30:12 server pdns_recursor[11064]: Will not send queries to:<br>> <a href="http://127.0.0.0/8" target="_blank">127.0.0.0/8</a>, <a href="http://10.0.0.0/8" target="_blank">10.0.0.0/8</a>, <a href="http://100.64.0.0/10" target="_blank">100.64.0.0/10</a>, <a href="http://169.254.0.0/16" target="_blank">169.254.0.0/16</a>, <a href="http://192.168.0.0/16" target="_blank">192.168.0.0/16</a>,<br>
> <a href="http://172.16.0.0/12" target="_blank">172.16.0.0/12</a>, ::1/128, fe80::/10, 0.0.0.0, ::<br>> Jun 23 12:30:12 server pdns_recursor[11064]: NOT using IPv6 for outgoing<br>> queries - set 'query-local-address6=::' to enable<br>
> Jun 23
12:30:12 server pdns_recursor[11064]: Redirecting queries for zone<br>> '.' to: <a href="http://8.8.8.8:53" target="_blank">8.8.8.8:53</a><br>> Jun 23 12:30:12 server pdns_recursor[11064]: Inserting rfc 1918 private<br>
> space zones<br>> Jun 23 12:30:12 server pdns_recursor[11064]: Not decreasing socket buffer<br>> size from 229376 to 200000<br>> Jun 23 12:30:12 server pdns_recursor[11064]: Listening for UDP queries on<br>> <a href="http://127.0.0.1:53" target="_blank">127.0.0.1:53</a><br>
> Jun 23 12:30:12 server pdns_recursor[11064]: Enabled TCP data-ready filter<br>> for (slight) DoS protection<br>> Jun 23 12:30:12 server pdns_recursor[11064]: Listening for TCP queries on<br>> <a href="http://127.0.0.1:53" target="_blank">127.0.0.1:53</a><br>
> Jun 23 12:30:12 server pdns_recursor[11064]: Calling daemonize, going to<br>> background<br>> Jun 23 12:30:12 server pdns_recursor[11065]: Set effective group id to 497<br>> Jun 23 12:30:12 server pdns_recursor[11065]: Set effective user id to 497<br>
> Jun 23 12:30:12 server pdns_recursor[11065]: Launching 2
threads<br>> Jun 23 12:30:12 server pdns_recursor[11065]: Done priming cache with root<br>> hints<br>> Jun 23 12:30:12 server pdns_recursor[11065]: Done priming cache with root<br>> hints<br>> Jun 23 12:30:12 server pdns_recursor[11065]: Enabled 'epoll' multiplexer<br>
> Jun 23 12:30:12 server pdns_recursor[11065]: .: No cache hit for '.|NS',<br>> trying to find an appropriate NS record<br>> Jun 23 12:30:12 server pdns_recursor[11065]: .: No cache hit for '.|NS',<br>
> trying to find an appropriate NS record<br>> Jun 23 12:30:12 server pdns_recursor[11065]: .: Cache consultations done,<br>> have 1 NS to contact<br>> Jun 23 12:30:12 server pdns_recursor[11065]: .: Cache consultations done,<br>
> have 1 NS to contact<br>> Jun 23 12:30:12 server pdns_recursor[11065]: .: Nameservers:<br>> -8.8.8.8:53(0.00ms)<br>> Jun 23 12:30:12 server pdns_recursor[11065]: .: Trying to resolve NS<br>> '-<a href="http://8.8.8.8:53" target="_blank">8.8.8.8:53</a>'
(1/1)<br>> Jun 23 12:30:12 server pdns_recurs</div></div> </div> </div></div></blockquote>
</div>