Re: [Pdns-users] Slow query and SERVERFAIL from local pdns_recursor
Hi, I set the trace=yes option in the recursor config an redid the tests for pubs.vmware.com. The log can be found here https://paste.debian.net/hidden/07526601/ I found two timeouts in the logs Line 41: Sep 8 10:21:54 rho pdns_recursor[25208]: [3] pubs.vmware.com: Resolved 'vmware.com' NS ns01.vmwdns.com to: 45.54.11.1 Sep 8 10:21:54 rho pdns_recursor[25208]: [3] pubs.vmware.com: Trying IP 45.54.11.1:53, asking 'pubs.vmware.com|A' Sep 8 10:21:56 rho pdns_recursor[25208]: [3] pubs.vmware.com: timeout resolving after 1501.63msec Sep 8 10:21:56 rho pdns_recursor[25208]: [3] pubs.vmware.com: Trying to resolve NS 'ns04.vmwdns.com' (2/8) But a request to the 45.54.11.1 for pubs.vmware.com come back within 11 msec. $ dig -t A @45.54.11.1 pubs.vmware.com ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> -t A @45.54.11.1 pubs.vmware.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24122 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;pubs.vmware.com.INA ;; ANSWER SECTION: pubs.vmware.com.30INCNAME pubs.vmware.com.ds.edgekey.net. ;; Query time: 11 msec ;; SERVER: 45.54.11.1#53(45.54.11.1) ;; WHEN: Tue Sep 08 13:29:57 CEST 2020 ;; MSG SIZE rcvd: 88 and a seconds timeout in line 159: Sep 8 10:21:56 rho pdns_recursor[25208]: [3] e751.dscx.akamaiedge.net: Trying IP 2.16.106.23:53, asking 'e751.dscx.akamaiedge.net|A' Sep 8 10:21:57 rho pdns_recursor[25208]: [3] e751.dscx.akamaiedge.net: timeout resolving after 1501.74msec Sep 8 10:21:57 rho pdns_recursor[25208]: [3] e751.dscx.akamaiedge.net: Trying to resolve NS 'n3dscx.akamaiedge.net' (2/8) Same picture here with a very good response time. $ dig -t A @2.16.106.23 e751.dscx.akamaiedge.net ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> -t A @2.16.106.23 e751.dscx.akamaiedge.net ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7947 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;e751.dscx.akamaiedge.net.INA ;; ANSWER SECTION: e751.dscx.akamaiedge.net. 20INA104.111.214.47 ;; Query time: 5 msec ;; SERVER: 2.16.106.23#53(2.16.106.23) ;; WHEN: Tue Sep 08 13:31:32 CEST 2020 ;; MSG SIZE rcvd: 69 To check that this is not a vmware.com problem I tested some more and got the same timeouts. One more example for $dig nameservers.dnscheck.co @127.0.0.1 ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> nameservers.dnscheck.co @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 23852 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;nameservers.dnscheck.co.INA ;; Query time: 3005 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Sep 08 12:15:29 CEST 2020 ;; MSG SIZE rcvd: 52 can be found here https://paste.debian.net/hidden/b48a78a2/. This time multiple timeout regarding the root name servers, for example g.root-servers.net Sep 8 12:15:21 rho pdns_recursor[25208]: [50] nameservers.dnscheck.co: Resolved '.' NS g.root-servers.net to: 192.112.36.4 Sep 8 12:15:21 rho pdns_recursor[25208]: [50] nameservers.dnscheck.co: Trying IP 192.112.36.4:53, asking 'nameservers.dnscheck.co|A' Sep 8 12:15:22 rho pdns_recursor[25208]: [50] nameservers.dnscheck.co: timeout resolving after 1501.63msec Sep 8 12:15:22 rho pdns_recursor[25208]: [50] nameservers.dnscheck.co: Trying to resolve NS 'j.root-servers.net' (2/13) Where a direct request via dig works like a charm. $ dig -t A @192.112.36.4 nameservers.dnscheck.co ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> -t A @192.112.36.4 nameservers.dnscheck.co ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18641 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 13 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: ce9eaf15bb34977b41354b5f5f576c3841785bfba5901e93 (good) ;; QUESTION SECTION: ;nameservers.dnscheck.co.INA ;; AUTHORITY SECTION: co.172800 INNSns5.cctld.co. co.172800 INNSns1.cctld.co. co.172800 INNSns6.cctld.co. co.172800 INNSns4.cctld.co. co.172800 INNSns3.cctld.co. co.172800 INNSns2.cctld.co. ;; ADDITIONAL SECTION: ns1.cctld.co. 172800 INA156.154.100.25 ns2.cctld.co. 172800 INA156.154.101.25 ns3.cctld.co. 172800 INA156.154.102.25 ns4.cctld.co. 172800 INA156.154.103.25 ns5.cctld.co. 172800 INA156.154.104.25 ns6.cctld.co. 172800 INA156.154.105.25 ns1.cctld.co. 172800 IN2001:502:2eda::21 ns2.cctld.co. 172800
Re: [Pdns-users] PowerDNS Recursor build fails on openSUSE Tumbleweed/Factory (gcc 10)
Hi Michael, On 9/8/20 11:39 AM, Michael Ströder via Pdns-users wrote: > Currently building PowerDNS Recursor fails building on openSUSE > Tumbleweed/Factory: > > https://build.opensuse.org/package/live_build_log/home:stroeder:branches:server:dns/pdns-recursor/openSUSE_Tumbleweed/x86_64 > > Note that openSUSE Tumbleweed/Factory uses > > gcc version 10.2.1 20200825 [revision > c0746a1beb1ba073c7981eb09f55b3d993b32e5c] (SUSE Linux) > > As you can see it builds on openSUSE Leap: > > https://build.opensuse.org/package/show/home:stroeder:branches:server:dns/pdns-recursor > > Is this an issue with newer gcc? It's an issue caused by Boost >= 1.73, see [1]. We should probably backport that patch, at least to 4.3.x, but we have not done so yet. [1]: https://github.com/PowerDNS/pdns/pull/9070 Best regards, -- Remi Gacogne PowerDNS.COM BV - https://www.powerdns.com/ signature.asc Description: OpenPGP digital signature ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] PowerDNS Recursor build fails on openSUSE Tumbleweed/Factory (gcc 10)
HI! Currently building PowerDNS Recursor fails building on openSUSE Tumbleweed/Factory: https://build.opensuse.org/package/live_build_log/home:stroeder:branches:server:dns/pdns-recursor/openSUSE_Tumbleweed/x86_64 Note that openSUSE Tumbleweed/Factory uses gcc version 10.2.1 20200825 [revision c0746a1beb1ba073c7981eb09f55b3d993b32e5c] (SUSE Linux) As you can see it builds on openSUSE Leap: https://build.opensuse.org/package/show/home:stroeder:branches:server:dns/pdns-recursor Is this an issue with newer gcc? Ciao, Michael. ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] PowerDNS Recursor 4.3.4 Released
Hello!, Today we are releasing PowerDNS Recursor 4.3.4. This release: - fixes an issue where certain CNAMEs could lead to resolver failure, - fixes an issue with the hostname reported in Carbon messages, - allows for multiple recursor services to run under systemd. Please refer to the changelog[1] for details. The tarball[2] (signature[3]) is available at the download site[4] and packages for CentOS 6, 7 and 8, Debian Stretch and Buster, Ubuntu Xenial, Bionic and Focal are available from our repository[5]. 4.0 and older releases are EOL, refer to the documentation[6] for details about our release cycles. Please send us all feedback and issues you might have via the mailing list[7], or in case of a bug, via GitHub[8]. -Otto and the PowerDNS team [1] https://doc.powerdns.com/recursor/changelog/4.3.html#change-4.3.4 [2] https://downloads.powerdns.com/releases/pdns-recursor-4.3.4.tar.bz2 [3] https://downloads.powerdns.com/releases/pdns-recursor-4.3.4.tar.bz2.sig [4] https://downloads.powerdns.com/releases/ [5] https://repo.powerdns.com/;>repo.powerdns.com [6] https://docs.powerdns.com/recursor/appendices/EOL.html [7] https://mailman.powerdns.com/mailman/listinfo/pdns-users [8] https://github.com/PowerDNS/pdns/issues/new/choose -- kind regards, Otto Moerbeek Senior PowerDNS Developer Email: otto.moerb...@open-xchange.com signature.asc Description: OpenPGP digital signature ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Slow query and SERVERFAIL from local pdns_recursor
On Tue, Sep 08, 2020 at 09:22:31AM +0200, Christian Degenkolb wrote: > (send again, first answer was not send cc to the ML) > > Hi, > > sorry for not sending any configs. pdns_recursor runs more or less with the > vanilla config with the following changes: > > forward-zones-recurse=zen.spamhaus.org=1.1.1.1;1.0.0.1 (thats why I wanted > to use the local recursor, as mentioned the server is located in the hetzner > IP Range which apparently is blocked for the spamhaus DNSBL) > loglevel=6 > log-common-errors=yes > quiet=no > root-nx-trust=no (found this as a solution for the SERVERFAIL but did not > work) > > and > # rec_control set-carbon-server 37.252.122.50 rho-test (for the grafs) > > > A trace for the same resolves from my last mail: > > $ time dig +trace pubs.vmware.com @127.0.0.1 > ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> +trace pubs.vmware.com > @127.0.0.1 > ;; global options: +cmd > . 86118 IN NS d.root-servers.net. > . 86118 IN NS c.root-servers.net. > . 86118 IN NS l.root-servers.net. > . 86118 IN NS b.root-servers.net. > . 86118 IN NS f.root-servers.net. > . 86118 IN NS m.root-servers.net. > . 86118 IN NS e.root-servers.net. > . 86118 IN NS a.root-servers.net. > . 86118 IN NS i.root-servers.net. > . 86118 IN NS k.root-servers.net. > . 86118 IN NS g.root-servers.net. > . 86118 IN NS h.root-servers.net. > . 86118 IN NS j.root-servers.net. > . 86118 IN RRSIG NS 8 0 518400 2020092105 > 2020090804 46594 . > wgnBz8tKA9hjwIxmMQgTVwnZaiUpAB9a1+oC5T/syHzqNj1e5qhApLQN > NLok43hu5Ykt8RFe/IiDZuYxIdyyzItwk > 4QN8xNgsQsfhVfBbZ26bWRz > fskquwnFn6Gmvq2qI6o42tsBxXUw09X4sNlNYI2zHB3sKaaMu0AbN9WI > Pe14jpX/PwaP3m78+XqMy9CiKmuDon6g3BuyecPhCZL5Pa8ZPC7nrKfV > pfyNSiPoBODsJE96UHGlOCJTFcbu/6Ia4ek3AGOJf+WC84HPrxLT > riyk XHfbPl7EjTbFSPgT8D7jGBfVCTQU3JSfynv29VFAHWZu1gm5VJWNQGaw u5gatA== > ;; Received 540 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms > > com.172800 IN NS a.gtld-servers.net. > com.172800 IN NS b.gtld-servers.net. > com.172800 IN NS c.gtld-servers.net. > com.172800 IN NS d.gtld-servers.net. > com.172800 IN NS e.gtld-servers.net. > com.172800 IN NS f.gtld-servers.net. > com.172800 IN NS g.gtld-servers.net. > com.172800 IN NS h.gtld-servers.net. > com.172800 IN NS i.gtld-servers.net. > com.172800 IN NS j.gtld-servers.net. > com.172800 IN NS k.gtld-servers.net. > com.172800 IN NS l.gtld-servers.net. > com.172800 IN NS m.gtld-servers.net. > com.86400 IN DS 30909 8 2 > E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 > com.86400 IN RRSIG DS 8 1 86400 2020092105 > 2020090804 46594 . > zz85z6R/YUHxyW+ywA6zrgiYILjPo0i248M3wU+2XCRCneBH6yknQfjM > LIcbo3vADVUlkJd0l4W2TLd7NPgC255hr2 > +ALojzzHa07jyFmE203Kdw > ma7XL0C55TdFrCEMhARkZf4EncfJH9JH+fdWRWdMr0EQZd1A+FzMYemO > o7/L/8ZYq4FOt0vz+zheAJNDveGii+QpXAoDyw4xt3HMUVM+40Z/VgD1 > tk9Y3K9e2wwRNISeHdlq21JFVA2SY/gDgPCzBtM1r9Yz7oFZ2ld5W > AD0 P84GPEUMgUceAGofwxlV9+dSawhunskb+yVrpdjpizLageyJRWEu/F9A zDXxew== > ;; Received 1175 bytes from 198.97.190.53#53(h.root-servers.net) in 5 ms > > vmware.com. 172800 IN NS dns1.p05.nsone.net. > vmware.com. 172800 IN NS dns2.p05.nsone.net. > vmware.com. 172800 IN NS dns3.p05.nsone.net. > vmware.com. 172800 IN NS dns4.p05.nsone.net. > vmware.com. 172800 IN NS ns01.vmwdns.com. > vmware.com. 172800 IN NS ns02.vmwdns.com. > vmware.com. 172800 IN NS ns03.vmwdns.com. > vmware.com. 172800 IN NS ns04.vmwdns.com. > vmware.com. 86400 IN DS 48553 13 2 > AA2C697F3990472642AF01509A18224828E403CA8608EC75D5C83002 CE21847E > vmware.com. 86400 IN RRSIG DS 8 2 86400 20200915062203 > 20200908051203 24966 com. > FA2xsJKvT2LLn5UEy7hAE7PaYmds7FBkQB0SGhm8riwJRKnxbHAY0tvv > I1T/k0EzXJ4wy1J5qzNLMjhzFgPxEQB > 6BwBfJm8qo8Cnzxm4YC5Ko1/9 > pDWooVBHoFfMmJgu14Dk+u1AcHobxH9pPs7az16cLK/3YeaFW3dCrIVQ > NK2fZc0d/pc7CY0Zl1LjYQdTq+MsZiL2kbepEHD6A/4J6g== > ;; Received 523 bytes from
Re: [Pdns-users] Slow query and SERVERFAIL from local pdns_recursor
(send again, first answer was not send cc to the ML) Hi, sorry for not sending any configs. pdns_recursor runs more or less with the vanilla config with the following changes: forward-zones-recurse=zen.spamhaus.org=1.1.1.1;1.0.0.1 (thats why I wanted to use the local recursor, as mentioned the server is located in the hetzner IP Range which apparently is blocked for the spamhaus DNSBL) loglevel=6 log-common-errors=yes quiet=no root-nx-trust=no (found this as a solution for the SERVERFAIL but did not work) and # rec_control set-carbon-server 37.252.122.50 rho-test (for the grafs) A trace for the same resolves from my last mail: $ time dig +trace pubs.vmware.com @127.0.0.1 ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> +trace pubs.vmware.com @127.0.0.1 ;; global options: +cmd . 86118 IN NS d.root-servers.net. . 86118 IN NS c.root-servers.net. . 86118 IN NS l.root-servers.net. . 86118 IN NS b.root-servers.net. . 86118 IN NS f.root-servers.net. . 86118 IN NS m.root-servers.net. . 86118 IN NS e.root-servers.net. . 86118 IN NS a.root-servers.net. . 86118 IN NS i.root-servers.net. . 86118 IN NS k.root-servers.net. . 86118 IN NS g.root-servers.net. . 86118 IN NS h.root-servers.net. . 86118 IN NS j.root-servers.net. . 86118 IN RRSIG NS 8 0 518400 2020092105 2020090804 46594 . wgnBz8tKA9hjwIxmMQgTVwnZaiUpAB9a1+oC5T/syHzqNj1e5qhApLQN NLok43hu5Ykt8RFe/IiDZuYxIdyyzItwk 4QN8xNgsQsfhVfBbZ26bWRz fskquwnFn6Gmvq2qI6o42tsBxXUw09X4sNlNYI2zHB3sKaaMu0AbN9WI Pe14jpX/PwaP3m78+XqMy9CiKmuDon6g3BuyecPhCZL5Pa8ZPC7nrKfV pfyNSiPoBODsJE96UHGlOCJTFcbu/6Ia4ek3AGOJf+WC84HPrxLT riyk XHfbPl7EjTbFSPgT8D7jGBfVCTQU3JSfynv29VFAHWZu1gm5VJWNQGaw u5gatA== ;; Received 540 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms com.172800 IN NS a.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. com.172800 IN NS h.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS j.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. com.172800 IN NS l.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com.86400 IN RRSIG DS 8 1 86400 2020092105 2020090804 46594 . zz85z6R/YUHxyW+ywA6zrgiYILjPo0i248M3wU+2XCRCneBH6yknQfjM LIcbo3vADVUlkJd0l4W2TLd7NPgC255hr2 +ALojzzHa07jyFmE203Kdw ma7XL0C55TdFrCEMhARkZf4EncfJH9JH+fdWRWdMr0EQZd1A+FzMYemO o7/L/8ZYq4FOt0vz+zheAJNDveGii+QpXAoDyw4xt3HMUVM+40Z/VgD1 tk9Y3K9e2wwRNISeHdlq21JFVA2SY/gDgPCzBtM1r9Yz7oFZ2ld5W AD0 P84GPEUMgUceAGofwxlV9+dSawhunskb+yVrpdjpizLageyJRWEu/F9A zDXxew== ;; Received 1175 bytes from 198.97.190.53#53(h.root-servers.net) in 5 ms vmware.com. 172800 IN NS dns1.p05.nsone.net. vmware.com. 172800 IN NS dns2.p05.nsone.net. vmware.com. 172800 IN NS dns3.p05.nsone.net. vmware.com. 172800 IN NS dns4.p05.nsone.net. vmware.com. 172800 IN NS ns01.vmwdns.com. vmware.com. 172800 IN NS ns02.vmwdns.com. vmware.com. 172800 IN NS ns03.vmwdns.com. vmware.com. 172800 IN NS ns04.vmwdns.com. vmware.com. 86400 IN DS 48553 13 2 AA2C697F3990472642AF01509A18224828E403CA8608EC75D5C83002 CE21847E vmware.com. 86400 IN RRSIG DS 8 2 86400 20200915062203 20200908051203 24966 com. FA2xsJKvT2LLn5UEy7hAE7PaYmds7FBkQB0SGhm8riwJRKnxbHAY0tvv I1T/k0EzXJ4wy1J5qzNLMjhzFgPxEQB 6BwBfJm8qo8Cnzxm4YC5Ko1/9 pDWooVBHoFfMmJgu14Dk+u1AcHobxH9pPs7az16cLK/3YeaFW3dCrIVQ NK2fZc0d/pc7CY0Zl1LjYQdTq+MsZiL2kbepEHD6A/4J6g== ;; Received 523 bytes from 2001:503:eea3::30#53(g.gtld-servers.net) in 6 ms pubs.vmware.com.30 IN CNAME pubs.vmware.com.ds.edgekey.net. pubs.vmware.com.30 IN RRSIG CNAME 13 3 30 20200909071011 20200907071011 12752
Re: [Pdns-users] questions of understanding pdns-recursor with hosts-file
On Tue, Sep 08, 2020 at 06:05:40AM +, Markus Ehrlicher via Pdns-users wrote: > Hello together, > > can anyone reproduce this problem or should I open a ticket on github? I wanted to look into this, but I did not have time yet. Without looking at the code but knowing some details of the auth zone mechanism, I'm not surprised by what you are seeing. -Otto > > Thanks and best regards, > Markus > > Von: Markus Ehrlicher > Gesendet: Dienstag, 1. September 2020 11:53 > An: pdns-users@mailman.powerdns.com > Betreff: questions of understanding pdns-recursor with hosts-file > > Hello together, > > I'am a little confused about the "export-etc-hosts"-switch. I use latest > pdns-recursor in version 4.3.3 on Ubuntu 20.04. > Because of problems with firewall, NAT and external IPs, we have to redirect > some (not all) DNS-Entries to internal IPs instead of public available IPs. > For this purpose I installed this extra server, to insert the needed entries > in the hosts-file and activated "export-etc-hosts" in pdns-recursor.conf. > > Now my problem: if the root domain (in my example benchmaxx.de) is included > in this hosts-file, the recursor seems to feel authoritative for the whole > domain and trys to answers all other requests for subdomains from > benchmaxx.de (in my example test.benchmaxx.de) with NXDOMAIN. > Here are the logs for this behavior: > > Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: 3 [6/1] question for > 'test.benchmaxx.de|A' from 10.10.2.26:45074 > Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: Wants > DNSSEC processing, auth data in query for A > Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: Looking > for CNAME cache hit of 'test.benchmaxx.de|CNAME' > Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: Looking > for DNAME cache hit of 'test.benchmaxx.de|DNAME' or its ancestors > Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: No CNAME > or DNAME cache hit of 'test.benchmaxx.de' found > Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: No cache > hit for 'test.benchmaxx.de|A', trying to find an appropriate NS record > Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: initial > validation status for test.benchmaxx.de is Indeterminate > Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: Cache > consultations done, have 1 NS to contact > Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: Domain is > out-of-band > Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: auth > storage has data, zone='benchmaxx.de' > Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: accept > answer 'benchmaxx.de|SOA|localhost. root. 1 604800 86400 2419200 604800' from > 'benchmaxx.de' nameservers? ttl=7200, place=2 YES! - This answer was > retrieved from the local auth store. > Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: > determining status after receiving this packet > Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: got > negative caching indication for name 'test.benchmaxx.de' (accept=1), > newtarget='(empty)' > Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: > status=NXDOMAIN, we are done (have negative SOA) > Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: failed > (res=3) > Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: 3 [6/1] answer to question > 'test.benchmaxx.de|A': 0 answers, 0 additional, took 0 packets, 0 netw ms, 0 > tot ms, 0 throttled, 0 timeouts, 0 tcp connections, rcode=3 > > If I comment out benchmaxx.de in the hosts-file, all is fine and the request > for test.benchmaxx.de is answered correctly: > > Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: 3 [1/1] question for > 'test.benchmaxx.de|A' from 10.10.2.26:49295 > Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: Wants > DNSSEC processing, auth data in query for A > Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: Looking > for CNAME cache hit of 'test.benchmaxx.de|CNAME' > Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: Looking > for DNAME cache hit of 'test.benchmaxx.de|DNAME' or its ancestors > Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: No CNAME > or DNAME cache hit of 'test.benchmaxx.de' found > Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: No cache > hit for 'test.benchmaxx.de|A', trying to find an appropriate NS record > Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: initial > validation status for test.benchmaxx.de is Indeterminate > Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: Cache > consultations done, have 1 NS to contact > Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: Domain has > hardcoded nameservers > Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de.: >
Re: [Pdns-users] questions of understanding pdns-recursor with hosts-file
Hello together, can anyone reproduce this problem or should I open a ticket on github? Thanks and best regards, Markus Von: Markus Ehrlicher Gesendet: Dienstag, 1. September 2020 11:53 An: pdns-users@mailman.powerdns.com Betreff: questions of understanding pdns-recursor with hosts-file Hello together, I'am a little confused about the "export-etc-hosts"-switch. I use latest pdns-recursor in version 4.3.3 on Ubuntu 20.04. Because of problems with firewall, NAT and external IPs, we have to redirect some (not all) DNS-Entries to internal IPs instead of public available IPs. For this purpose I installed this extra server, to insert the needed entries in the hosts-file and activated "export-etc-hosts" in pdns-recursor.conf. Now my problem: if the root domain (in my example benchmaxx.de) is included in this hosts-file, the recursor seems to feel authoritative for the whole domain and trys to answers all other requests for subdomains from benchmaxx.de (in my example test.benchmaxx.de) with NXDOMAIN. Here are the logs for this behavior: Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: 3 [6/1] question for 'test.benchmaxx.de|A' from 10.10.2.26:45074 Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: Wants DNSSEC processing, auth data in query for A Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: Looking for CNAME cache hit of 'test.benchmaxx.de|CNAME' Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: Looking for DNAME cache hit of 'test.benchmaxx.de|DNAME' or its ancestors Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: No CNAME or DNAME cache hit of 'test.benchmaxx.de' found Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: No cache hit for 'test.benchmaxx.de|A', trying to find an appropriate NS record Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: initial validation status for test.benchmaxx.de is Indeterminate Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: Cache consultations done, have 1 NS to contact Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: Domain is out-of-band Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: auth storage has data, zone='benchmaxx.de' Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: accept answer 'benchmaxx.de|SOA|localhost. root. 1 604800 86400 2419200 604800' from 'benchmaxx.de' nameservers? ttl=7200, place=2 YES! - This answer was retrieved from the local auth store. Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: determining status after receiving this packet Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: got negative caching indication for name 'test.benchmaxx.de' (accept=1), newtarget='(empty)' Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: status=NXDOMAIN, we are done (have negative SOA) Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: test.benchmaxx.de: failed (res=3) Sep 01 11:37:51 dmz-ns1 pdns_recursor[1454639]: 3 [6/1] answer to question 'test.benchmaxx.de|A': 0 answers, 0 additional, took 0 packets, 0 netw ms, 0 tot ms, 0 throttled, 0 timeouts, 0 tcp connections, rcode=3 If I comment out benchmaxx.de in the hosts-file, all is fine and the request for test.benchmaxx.de is answered correctly: Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: 3 [1/1] question for 'test.benchmaxx.de|A' from 10.10.2.26:49295 Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: Wants DNSSEC processing, auth data in query for A Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: Looking for CNAME cache hit of 'test.benchmaxx.de|CNAME' Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: Looking for DNAME cache hit of 'test.benchmaxx.de|DNAME' or its ancestors Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: No CNAME or DNAME cache hit of 'test.benchmaxx.de' found Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: No cache hit for 'test.benchmaxx.de|A', trying to find an appropriate NS record Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: initial validation status for test.benchmaxx.de is Indeterminate Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: Cache consultations done, have 1 NS to contact Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: Domain has hardcoded nameservers Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de.: Nameservers: +217.119.211.10:53(2.11ms), +217.119.214.10:53(2.93ms) Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: Resolved '.' NS (empty) to: 217.119.211.10, 217.119.214.10 Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: Trying IP 217.119.211.10:53, asking 'test.benchmaxx.de|A' Sep 01 11:38:10 dmz-ns1 pdns_recursor[1454675]: test.benchmaxx.de: Got 2 answers from (empty) (217.119.211.10), rcode=0 (No Error),
