Re: [Pdns-users] 1 sec delay before DNS-answer at pdns-recursor
Hi Shamus, PowerDNS Recursor not listening at ::1 by default. But localhost resolves (/etc/hosts) to ::1 at the first try. So dig's first query fails. After 1 second (don't know why 1 second because default timeout is 3s), dig tries again at 127.0.0.1 and it works. You have 3 possibilities: 1.) Force the Recursor to listen at ::1 (--local-address=127.0.0.1,::1) 2.) Explicitly dig IPv4 (dig @127.0.0.1 ...) 3.) Delete ::1 from /etc/hosts Winfried Am 26.06.2013 00:26, schrieb Shamus Smith: Hello all, thanks for all your answers, but I'm still stuck. Below is the full output for dig for pdns and dnsmasq. The query time is 2 ms for the first uncached request and 0 ms for pdns and dnsmasq. However, the whole execution of the dig command takes over 1 second for pdns and below 30 ms for dnsmasq. The same for nslookup. ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] 1 sec delay before DNS-answer at pdns-recursor
Hello Winfried, PowerDNS Recursor not listening at ::1 by default. But localhost resolves (/etc/hosts) to ::1 at the first try. So dig's first query fails. After 1 second (don't know why 1 second because default timeout is 3s), dig tries again at 127.0.0.1 and it works. BINGO! You have 3 possibilities: 1.) Force the Recursor to listen at ::1 (--local-address=127.0.0.1,::1) Worked. 2.) Explicitly dig IPv4 (dig @127.0.0.1 ...) Tried that before, worked. 3.) Delete ::1 from /etc/hosts Worked. Thank you very much Winfried! Maybe PowerDNS Recursor should also listen to ::1 by default, Dnsmasq seems to bind to all local interfaces by default. @Michael, tried to use forward-zones-recurse before, but forget to mention it. It had the same delay. Greetings, Shamus___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] 1 sec delay before DNS-answer at pdns-recursor
Hello all, thanks for all your answers, but I'm still stuck. Below is the full output for dig for pdns and dnsmasq. The query time is 2 ms for the first uncached request and 0 ms for pdns and dnsmasq. However, the whole execution of the dig command takes over 1 second for pdns and below 30 ms for dnsmasq. The same for nslookup. For the second request trace just shows: 1 question answered from packet cache from 127.0.0.1 But it still takes more than 1 second. - /etc/pdns-recursor/recursor.conf (default-config from package plus own forward-zone, removed comments) forward-zones=.=8.8.8.8 setgid=pdns-recursor setuid=pdns-recursor - /etc/dnsmasq.conf (default-config from package, removed comments) bogus-priv cache-size=1500 domain-needed no-hosts - /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 /etc/nsswitch.conf was not modified and there is absolutely no load on the machine. I do not have a LDAP user database, this is just a minimum install of CentOS 6.5. Any ideas? Thanks, Shamus # /etc/init.d/pdns-recursor start pdns-recursor starten: [ OK ] # time dig www.google.com @localhost ; DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 www.google.com @localhost ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 48006 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 174 IN A 173.194.35.176 www.google.com. 174 IN A 173.194.35.180 www.google.com. 174 IN A 173.194.35.177 www.google.com. 174 IN A 173.194.35.179 www.google.com. 174 IN A 173.194.35.178 ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Jun 25 23:51:28 2013 ;; MSG SIZE rcvd: 112 real 0m1.026s user 0m0.011s sys 0m0.014s # time dig www.google.com @localhost ; DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 www.google.com @localhost ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 3613 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 84 IN A 173.194.35.176 www.google.com. 84 IN A 173.194.35.180 www.google.com. 84 IN A 173.194.35.177 www.google.com. 84 IN A 173.194.35.179 www.google.com. 84 IN A 173.194.35.178 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Jun 25 23:52:58 2013 ;; MSG SIZE rcvd: 112 real 0m1.024s user 0m0.005s sys 0m0.019s # /etc/init.d/pdns-recursor stop pdns-recursor beenden: [ OK ] # /etc/init.d/dnsmasq start Starting dnsmasq: [ OK ] # time dig www.google.com @localhost ; DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 www.google.com @localhost ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 6269 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 67 IN A 173.194.35.178 www.google.com. 67 IN A 173.194.35.179 www.google.com. 67 IN A 173.194.35.180 www.google.com. 67 IN A 173.194.35.176 www.google.com. 67 IN A 173.194.35.177 ;; AUTHORITY SECTION: google.com. 54608 IN NS ns1.google.com. google.com. 54608 IN NS ns3.google.com. google.com. 54608 IN NS ns2.google.com. google.com. 54608 IN NS ns4.google.com. ;; ADDITIONAL SECTION: ns1.google.com. 54882 IN A 216.239.32.10 ns2.google.com. 54882 IN A 216.239.34.10 ns3.google.com. 54882 IN A 216.239.36.10 ns4.google.com. 54882 IN A 216.239.38.10 ;; Query time: 2 msec ;; SERVER: ::1#53(::1) ;; WHEN: Tue Jun 25 23:53:15 2013 ;; MSG SIZE rcvd: 248 real 0m0.028s user 0m0.008s sys 0m0.019s # time dig www.google.com @localhost ; DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 www.google.com @localhost ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 28137 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 65 IN A 173.194.35.177 www.google.com. 65 IN A
Re: [Pdns-users] 1 sec delay before DNS-answer at pdns-recursor
On Tuesday, June 25, 2013, Shamus Smith wrote: Hello all, thanks for all your answers, but I'm still stuck. Below is the full output for dig for pdns and dnsmasq. The query time is 2 ms for the first uncached request and 0 ms for pdns and dnsmasq. However, the whole execution of the dig command takes over 1 second for pdns and below 30 ms for dnsmasq. The same for nslookup. For the second request trace just shows: 1 question answered from packet cache from 127.0.0.1 But it still takes more than 1 second. - /etc/pdns-recursor/recursor.conf (default-config from package plus own forward-zone, removed comments) forward-zones=.=8.8.8.8 setgid=pdns-recursor setuid=pdns-recursor - /etc/dnsmasq.conf (default-config from package, removed comments) bogus-priv cache-size=1500 domain-needed no-hosts - /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 /etc/nsswitch.conf was not modified and there is absolutely no load on the machine. I do not have a LDAP user database, this is just a minimum install of CentOS 6.5. Any ideas? Someone else mentioned use forward-zones-recurse instead. Try that. There's obviously an issue between your OS resolver and pdns-recursor. That well be the cause. Thanks, Shamus -- Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds. -- Samuel Butler ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] 1 sec delay before DNS-answer at pdns-recursor
Hello Shamus, On Jun 22, 2013, at 1:39 , Shamus Smith wrote: However, a lookup always needs more than 1 second (query-time is 2 ms).: # time dig +short www.google.com @localhost 173.194.40.80 173.194.40.83 173.194.40.84 173.194.40.81 173.194.40.82 real0m1.023s user0m0.007s sys 0m0.017s A tip (other posts in this thread have already proven it relevant): when measuring response time of a DNS server, do not use +short - so dig can tell you the actual response time. Kind regards, -- Peter van Dijk Netherlabs Computer Consulting BV - http://www.netherlabs.nl/ ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] 1 sec delay before DNS-answer at pdns-recursor
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 pdns-recursor-3.5.1-1.el6.x86_64). Thanks, Shamus - /etc/init.d/pdns-recursor start Jun 23 12:30:12 server pdns_recursor[11064]: PowerDNS recursor 3.5.1 (C) 2001-2013 PowerDNS.COM BV (May 3 2013, 20:04:33, gcc 4.4.7 20120313 (Red Hat 4.4.7-3)) starting up Jun 23 12:30:12 server pdns_recursor[11064]: PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it according to the terms of the GPL version 2. Jun 23 12:30:12 server pdns_recursor[11064]: Operating in 64 bits mode Jun 23 12:30:12 server pdns_recursor[11064]: Reading random entropy from '/dev/urandom' Jun 23 12:30:12 server pdns_recursor[11064]: Only allowing queries from: 127.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 169.254.0.0/16, 192.168.0.0/16, 172.16.0.0/12, ::1/128, fe80::/10 Jun 23 12:30:12 server pdns_recursor[11064]: Will not send queries to: 127.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 169.254.0.0/16, 192.168.0.0/16, 172.16.0.0/12, ::1/128, fe80::/10, 0.0.0.0, :: Jun 23 12:30:12 server pdns_recursor[11064]: NOT using IPv6 for outgoing queries - set 'query-local-address6=::' to enable Jun 23 12:30:12 server pdns_recursor[11064]: Redirecting queries for zone '.' to: 8.8.8.8:53 Jun 23 12:30:12 server pdns_recursor[11064]: Inserting rfc 1918 private space zones Jun 23 12:30:12 server pdns_recursor[11064]: Not decreasing socket buffer size from 229376 to 20 Jun 23 12:30:12 server pdns_recursor[11064]: Listening for UDP queries on 127.0.0.1:53 Jun 23 12:30:12 server pdns_recursor[11064]: Enabled TCP data-ready filter for (slight) DoS protection Jun 23 12:30:12 server pdns_recursor[11064]: Listening for TCP queries on 127.0.0.1:53 Jun 23 12:30:12 server pdns_recursor[11064]: Calling daemonize, going to background Jun 23 12:30:12 server pdns_recursor[11065]: Set effective group id to 497 Jun 23 12:30:12 server pdns_recursor[11065]: Set effective user id to 497 Jun 23 12:30:12 server pdns_recursor[11065]: Launching 2 threads Jun 23 12:30:12 server pdns_recursor[11065]: Done priming cache with root hints Jun 23 12:30:12 server pdns_recursor[11065]: Done priming cache with root hints Jun 23 12:30:12 server pdns_recursor[11065]: Enabled 'epoll' multiplexer Jun 23 12:30:12 server pdns_recursor[11065]: .: No cache hit for '.|NS', trying to find an appropriate NS record Jun 23 12:30:12 server pdns_recursor[11065]: .: No cache hit for '.|NS', trying to find an appropriate NS record Jun 23 12:30:12 server pdns_recursor[11065]: .: Cache consultations done, have 1 NS to contact Jun 23 12:30:12 server pdns_recursor[11065]: .: Cache consultations done, have 1 NS to contact Jun 23 12:30:12 server pdns_recursor[11065]: .: Nameservers: -8.8.8.8:53(0.00ms) Jun 23 12:30:12 server pdns_recursor[11065]: .: Trying to resolve NS '-8.8.8.8:53' (1/1) Jun 23 12:30:12 server pdns_recursor[11065]: .: Domain has hardcoded nameserver(s) Jun 23 12:30:12 server pdns_recursor[11065]: .: Resolved '.' NS -8.8.8.8:53 to: 8.8.8.8 Jun 23 12:30:12 server pdns_recursor[11065]: .: Nameservers: -8.8.8.8:53(0.00ms) Jun 23 12:30:12 server pdns_recursor[11065]: .: Trying to resolve NS '-8.8.8.8:53' (1/1) Jun 23 12:30:12 server pdns_recursor[11065]: .: Domain has hardcoded nameserver(s) Jun 23 12:30:12 server pdns_recursor[11065]: .: Resolved '.' NS -8.8.8.8:53 to: 8.8.8.8 Jun 23 12:30:12 server pdns_recursor[11065]: .: Trying IP 8.8.8.8:53, asking '.|NS' Jun 23 12:30:12 server pdns_recursor[11065]: .: Trying IP 8.8.8.8:53, asking '.|NS' Jun 23 12:30:12 server pdns_recursor[11065]: .: Got 13 answers from -8.8.8.8:53 (8.8.8.8), rcode=0, aa=0, in 6ms Jun 23 12:30:12 server pdns_recursor[11065]: .: accept answer '.|NS|d.root-servers.net.' from '.' nameservers? YES! Jun 23 12:30:12 server pdns_recursor[11065]: .: accept answer '.|NS|l.root-servers.net.' from '.' nameservers? YES! Jun 23 12:30:12 server pdns_recursor[11065]: .: accept answer '.|NS|c.root-servers.net.' from '.' nameservers? YES! Jun 23 12:30:12 server pdns_recursor[11065]: .: accept answer '.|NS|g.root-servers.net.' from '.' nameservers? YES! Jun 23 12:30:12 server pdns_recursor[11065]: .: accept answer '.|NS|h.root-servers.net.' from '.' nameservers? YES! Jun 23 12:30:12 server pdns_recursor[11065]: .: accept answer '.|NS|b.root-servers.net.' from '.' nameservers? YES! Jun 23 12:30:12 server pdns_recursor[11065]: .: Got 13 answers from -8.8.8.8:53 (8.8.8.8), rcode=0, aa=0, in 6ms Jun 23 12:30:12 server pdns_recursor[11065]: .: accept answer '.|NS|d.root-servers.net.' from '.' nameservers? YES! Jun 23 12:30:12 server pdns_recursor[11065]: .: accept answer '.|NS|l.root-servers.net.' from '.' nameservers? YES! Jun 23 12:30:12 server pdns_recursor[11065]: .:
Re: [Pdns-users] 1 sec delay before DNS-answer at pdns-recursor
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 standard *nix like system) On Sun, Jun 23, 2013 at 3:58 AM, Shamus Smith smithsha...@yahoo.de wrote: 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 pdns-recursor-3.5.1-1.el6.x86_64). Thanks, Shamus - /etc/init.d/pdns-recursor start Jun 23 12:30:12 server pdns_recursor[11064]: PowerDNS recursor 3.5.1 (C) 2001-2013 PowerDNS.COM BV (May 3 2013, 20:04:33, gcc 4.4.7 20120313 (Red Hat 4.4.7-3)) starting up Jun 23 12:30:12 server pdns_recursor[11064]: PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it according to the terms of the GPL version 2. Jun 23 12:30:12 server pdns_recursor[11064]: Operating in 64 bits mode Jun 23 12:30:12 server pdns_recursor[11064]: Reading random entropy from '/dev/urandom' Jun 23 12:30:12 server pdns_recursor[11064]: Only allowing queries from: 127.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 169.254.0.0/16, 192.168.0.0/16, 172.16.0.0/12, ::1/128, fe80::/10 Jun 23 12:30:12 server pdns_recursor[11064]: Will not send queries to: 127.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 169.254.0.0/16, 192.168.0.0/16, 172.16.0.0/12, ::1/128, fe80::/10, 0.0.0.0, :: Jun 23 12:30:12 server pdns_recursor[11064]: NOT using IPv6 for outgoing queries - set 'query-local-address6=::' to enable Jun 23 12:30:12 server pdns_recursor[11064]: Redirecting queries for zone '.' to: 8.8.8.8:53 Jun 23 12:30:12 server pdns_recursor[11064]: Inserting rfc 1918 private space zones Jun 23 12:30:12 server pdns_recursor[11064]: Not decreasing socket buffer size from 229376 to 20 Jun 23 12:30:12 server pdns_recursor[11064]: Listening for UDP queries on 127.0.0.1:53 Jun 23 12:30:12 server pdns_recursor[11064]: Enabled TCP data-ready filter for (slight) DoS protection Jun 23 12:30:12 server pdns_recursor[11064]: Listening for TCP queries on 127.0.0.1:53 Jun 23 12:30:12 server pdns_recursor[11064]: Calling daemonize, going to background Jun 23 12:30:12 server pdns_recursor[11065]: Set effective group id to 497 Jun 23 12:30:12 server pdns_recursor[11065]: Set effective user id to 497 Jun 23 12:30:12 server pdns_recursor[11065]: Launching 2 threads Jun 23 12:30:12 server pdns_recursor[11065]: Done priming cache with root hints Jun 23 12:30:12 server pdns_recursor[11065]: Done priming cache with root hints Jun 23 12:30:12 server pdns_recursor[11065]: Enabled 'epoll' multiplexer Jun 23 12:30:12 server pdns_recursor[11065]: .: No cache hit for '.|NS', trying to find an appropriate NS record Jun 23 12:30:12 server pdns_recursor[11065]: .: No cache hit for '.|NS', trying to find an appropriate NS record Jun 23 12:30:12 server pdns_recursor[11065]: .: Cache consultations done, have 1 NS to contact Jun 23 12:30:12 server pdns_recursor[11065]: .: Cache consultations done, have 1 NS to contact Jun 23 12:30:12 server pdns_recursor[11065]: .: Nameservers: -8.8.8.8:53(0.00ms) Jun 23 12:30:12 server pdns_recursor[11065]: .: Trying to resolve NS '-8.8.8.8:53' (1/1) Jun 23 12:30:12 server pdns_recursor[11065]: .: Domain has hardcoded nameserver(s) Jun 23 12:30:12 server pdns_recursor[11065]: .: Resolved '.' NS -8.8.8.8:53 to: 8.8.8.8 Jun 23 12:30:12 server pdns_recursor[11065]: .: Nameservers: -8.8.8.8:53(0.00ms) Jun 23 12:30:12 server pdns_recursor[11065]: .: Trying to resolve NS '-8.8.8.8:53' (1/1) Jun 23 12:30:12 server pdns_recursor[11065]: .: Domain has hardcoded nameserver(s) Jun 23 12:30:12 server pdns_recursor[11065]: .: Resolved '.' NS -8.8.8.8:53 to: 8.8.8.8 Jun 23 12:30:12 server pdns_recursor[11065]: .: Trying IP 8.8.8.8:53, asking '.|NS' Jun 23 12:30:12 server pdns_recursor[11065]: .: Trying IP 8.8.8.8:53, asking '.|NS' Jun 23 12:30:12 server pdns_recursor[11065]: .: Got 13 answers from -8.8.8.8:53 (8.8.8.8), rcode=0, aa=0, in 6ms Jun 23 12:30:12 server pdns_recursor[11065]: .: accept answer '.|NS|d.root-servers.net.' from '.' nameservers? YES! Jun 23 12:30:12 server pdns_recursor[11065]: .: accept answer '.|NS|l.root-servers.net.' from '.' nameservers? YES! Jun 23 12:30:12 server pdns_recursor[11065]: .: accept answer '.|NS|c.root-servers.net.' from '.' nameservers? YES! Jun 23 12:30:12 server pdns_recursor[11065]: .: accept answer '.|NS|g.root-servers.net.' from '.' nameservers? YES! Jun 23 12:30:12 server pdns_recursor[11065]: .: accept answer '.|NS|h.root-servers.net.' from '.' nameservers? YES! Jun 23 12:30:12 server pdns_recursor[11065]: .: accept answer
Re: [Pdns-users] 1 sec delay before DNS-answer at pdns-recursor
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 And you were right! When using dig www.google.com @127.0.0.1 it takes just 0.021 seconds. But I still do not have a clue why, do you? When using another recursor (Dnsmasq) there is no time difference when using @localhost or @127.0.0.1. Thanks, Shamus Von: Michael Loftis mlof...@wgops.com An: Shamus Smith smithsha...@yahoo.de CC: bert hubert bert.hub...@netherlabs.nl; pdns-users@mailman.powerdns.com pdns-users@mailman.powerdns.com Gesendet: 18:44 Sonntag, 23.Juni 2013 Betreff: Re: [Pdns-users] 1 sec delay before DNS-answer at pdns-recursor 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 standard *nix like system) On Sun, Jun 23, 2013 at 3:58 AM, Shamus Smith smithsha...@yahoo.de wrote: 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 pdns-recursor-3.5.1-1.el6.x86_64). Thanks, Shamus - /etc/init.d/pdns-recursor start Jun 23 12:30:12 server pdns_recursor[11064]: PowerDNS recursor 3.5.1 (C) 2001-2013 PowerDNS.COM BV (May 3 2013, 20:04:33, gcc 4.4.7 20120313 (Red Hat 4.4.7-3)) starting up Jun 23 12:30:12 server pdns_recursor[11064]: PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it according to the terms of the GPL version 2. Jun 23 12:30:12 server pdns_recursor[11064]: Operating in 64 bits mode Jun 23 12:30:12 server pdns_recursor[11064]: Reading random entropy from '/dev/urandom' Jun 23 12:30:12 server pdns_recursor[11064]: Only allowing queries from: 127.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 169.254.0.0/16, 192.168.0.0/16, 172.16.0.0/12, ::1/128, fe80::/10 Jun 23 12:30:12 server pdns_recursor[11064]: Will not send queries to: 127.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 169.254.0.0/16, 192.168.0.0/16, 172.16.0.0/12, ::1/128, fe80::/10, 0.0.0.0, :: Jun 23 12:30:12 server pdns_recursor[11064]: NOT using IPv6 for outgoing queries - set 'query-local-address6=::' to enable Jun 23 12:30:12 server pdns_recursor[11064]: Redirecting queries for zone '.' to: 8.8.8.8:53 Jun 23 12:30:12 server pdns_recursor[11064]: Inserting rfc 1918 private space zones Jun 23 12:30:12 server pdns_recursor[11064]: Not decreasing socket buffer size from 229376 to 20 Jun 23 12:30:12 server pdns_recursor[11064]: Listening for UDP queries on 127.0.0.1:53 Jun 23 12:30:12 server pdns_recursor[11064]: Enabled TCP data-ready filter for (slight) DoS protection Jun 23 12:30:12 server pdns_recursor[11064]: Listening for TCP queries on 127.0.0.1:53 Jun 23 12:30:12 server pdns_recursor[11064]: Calling daemonize, going to background Jun 23 12:30:12 server pdns_recursor[11065]: Set effective group id to 497 Jun 23 12:30:12 server pdns_recursor[11065]: Set effective user id to 497 Jun 23 12:30:12 server pdns_recursor[11065]: Launching 2 threads Jun 23 12:30:12 server pdns_recursor[11065]: Done priming cache with root hints Jun 23 12:30:12 server pdns_recursor[11065]: Done priming cache with root hints Jun 23 12:30:12 server pdns_recursor[11065]: Enabled 'epoll' multiplexer Jun 23 12:30:12 server pdns_recursor[11065]: .: No cache hit for '.|NS', trying to find an appropriate NS record Jun 23 12:30:12 server pdns_recursor[11065]: .: No cache hit for '.|NS', trying to find an appropriate NS record Jun 23 12:30:12 server pdns_recursor[11065]: .: Cache consultations done, have 1 NS to contact Jun 23 12:30:12 server pdns_recursor[11065]: .: Cache consultations done, have 1 NS to contact Jun 23 12:30:12 server pdns_recursor[11065]: .: Nameservers: -8.8.8.8:53(0.00ms) Jun 23 12:30:12 server pdns_recursor[11065]: .: Trying to resolve NS '-8.8.8.8:53' (1/1) Jun 23 12:30:12 server pdns_recursor[11065]: .: Domain has hardcoded nameserver(s) Jun 23 12:30:12 server pdns_recursor[11065]: .: Resolved '.' NS -8.8.8.8:53 to: 8.8.8.8 Jun 23 12:30:12 server pdns_recursor[11065]: .: Nameservers: -8.8.8.8:53(0.00ms) Jun 23 12:30:12 server pdns_recursor[11065]: .: Trying to resolve NS '-8.8.8.8:53' (1/1) Jun 23 12:30:12 server pdns_recursor[11065]: .: Domain has hardcoded nameserver(s) Jun 23 12:30:12 server pdns_recursor[11065]: .: Resolved '.' NS -8.8.8.8:53 to: 8.8.8.8 Jun 23 12:30:12 server pdns_recursor[11065]: .: Trying IP
Re: [Pdns-users] 1 sec delay before DNS-answer at pdns-recursor
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) bit when forwarding the queries as it is meant to be pointed against authoritative Nameservers instead of recursive ones. Not exactly sure how that would explain a 1s delay though. Stefan ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] 1 sec delay before DNS-answer at pdns-recursor
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 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. 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 And you were right! When using dig www.google.com @127.0.0.1 it takes just 0.021 seconds. But I still do not have a clue why, do you? 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. When using another recursor (Dnsmasq) there is no time difference when using @localhost or @127.0.0.1. Thanks, Shamus 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. 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 standard *nix like system) On Sun, Jun 23, 2013 at 3:58 AM, Shamus Smith smithsha...@yahoo.de wrote: 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 pdns-recursor-3.5.1-1.el6.x86_64). Thanks, Shamus - /etc/init.d/pdns-recursor start Jun 23 12:30:12 server pdns_recursor[11064]: PowerDNS recursor 3.5.1 (C) 2001-2013 PowerDNS.COM BV (May 3 2013, 20:04:33, gcc 4.4.7 20120313 (Red Hat 4.4.7-3)) starting up Jun 23 12:30:12 server pdns_recursor[11064]: PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it according to the terms of the GPL version 2. Jun 23 12:30:12 server pdns_recursor[11064]: Operating in 64 bits mode Jun 23 12:30:12 server pdns_recursor[11064]: Reading random entropy from '/dev/urandom' Jun 23 12:30:12 server pdns_recursor[11064]: Only allowing queries from: 127.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 169.254.0.0/16, 192.168.0.0/16, 172.16.0.0/12, ::1/128, fe80::/10 Jun 23 12:30:12 server pdns_recursor[11064]: Will not send queries to: 127.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 169.254.0.0/16, 192.168.0.0/16, 172.16.0.0/12, ::1/128, fe80::/10, 0.0.0.0, :: Jun 23 12:30:12 server pdns_recursor[11064]: NOT using IPv6 for outgoing queries - set 'query-local-address6=::' to enable Jun 23 12:30:12 server pdns_recursor[11064]: Redirecting queries for zone '.' to: 8.8.8.8:53 Jun 23 12:30:12 server pdns_recursor[11064]: Inserting rfc 1918 private space zones Jun 23 12:30:12 server pdns_recursor[11064]: Not decreasing socket buffer size from 229376 to 20 Jun 23 12:30:12 server pdns_recursor[11064]: Listening for UDP queries on 127.0.0.1:53 Jun 23 12:30:12 server pdns_recursor[11064]: Enabled TCP data-ready filter for (slight) DoS protection Jun 23 12:30:12 server pdns_recursor[11064]: Listening for TCP queries on 127.0.0.1:53 Jun 23 12:30:12 server pdns_recursor[11064]: Calling daemonize, going to background Jun 23 12:30:12 server pdns_recursor[11065]: Set effective group id to 497 Jun 23 12:30:12 server pdns_recursor[11065]: Set effective user id to 497 Jun 23 12:30:12 server pdns_recursor[11065]: Launching 2 threads Jun 23 12:30:12 server pdns_recursor[11065]: Done priming cache with root hints Jun
Re: [Pdns-users] 1 sec delay before DNS-answer at pdns-recursor
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 recursor. Which is to say I don't think that pdns-recursor is at fault for your slow dig resolution time...your OS stack I believe is failing elsewhere. -- Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds. -- Samuel Butler ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] 1 sec delay before DNS-answer at pdns-recursor
On Jun 22, 2013, at 1:39 AM, Shamus Smith wrote: 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. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] 1 sec delay before DNS-answer at pdns-recursor
Hello all, I installed pdns-recursor on my CentOS 6.4 machine with a simple config: forward-zones=.=ISP-DNS-Server setgid=pdns-recursor setuid=pdns-recursor However, a lookup always needs more than 1 second (query-time is 2 ms).: # time dig +short www.google.com @localhost 173.194.40.80 173.194.40.83 173.194.40.84 173.194.40.81 173.194.40.82 real 0m1.023s user 0m0.007s sys 0m0.017s Any ideas why it takes so long? Thanks, Shamus ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
