[arch-general] Problem with powerdns-recursor-4.0.3-1 package
Hello, After a upgrade from powerdns-recursor-3.7.3-3 to powerdns-recursor-4.0.3-1 it does not return any dns queries anymore. In the daemon.log is logged: Oct 23 10:50:18 gateway001 pdns_recursor[3008]: Oct 23 10:50:18 Sending SERVFAIL to 10.3.3.134 during resolve of 'google.nl' because: more than 50 (max-qperq) queries sent while resolving ns1.google.com Oct 23 10:50:19 gateway001 pdns_recursor[3008]: Oct 23 10:50:19 Sending SERVFAIL to 10.3.3.134 during resolve of 'google.nl' because: more than 50 (max-qperq) queries sent while resolving ns2.google.com After a downgrade of powerdns-recursor-4.0.3-1 to 3.7.3-3 it is working again, without making changes to /etc/powerdns/recursor.conf. The customized configuration options in /etc/powerdns/recursor.conf: [root@gateway001 powerdns]# grep -v -e "#.*" recursor.conf | grep -e "..*" allow-from=127.0.0.0/8, 10.0.0.0/8, ::1/64, 2001:470:1f15:a09::/64, 2001:470:7b9a::/48 auth-zones=.=/etc/powerdns/root.zone forward-zones=domain.lan=10.3.0.1,home.lan=10.3.0.21 hint-file=/etc/powerdns/named.root local-address=127.0.0.1,10.3.0.253:53,[::1],[2001:470:7b9a:0a03::fd]:53 local-port=5353 log-common-errors=yes loglevel=9 pdns-distributes-queries=yes query-local-address6=:: Do I need something to change to make it working against 4.0.x? I've searched at powerdns.com to options that have changed in the configuration but nothing helped. Kind regards, Roel de Wildt
On 10/23/2016 03:10 PM, Roel de Wildt via arch-general wrote:
Do I need something to change to make it working against 4.0.x?
After a rough look I can't reproduce your issue by playing around with the config, it just works. Something seems to eat up the responses. A better place for asking would be the powerdns IRC channel or the pdns-users mailinglist [0]. cheers, Levente [0] https://mailman.powerdns.com/mailman/listinfo/pdns-users
On 10/23/2016 06:10 AM, Roel de Wildt via arch-general wrote:
Hello,
After a upgrade from powerdns-recursor-3.7.3-3 to powerdns-recursor-4.0.3-1 it does not return any dns queries anymore.
In the daemon.log is logged:
Oct 23 10:50:18 gateway001 pdns_recursor[3008]: Oct 23 10:50:18 Sending SERVFAIL to 10.3.3.134 during resolve of 'google.nl' because: more than 50 (max-qperq) queries sent while resolving ns1.google.com Oct 23 10:50:19 gateway001 pdns_recursor[3008]: Oct 23 10:50:19 Sending SERVFAIL to 10.3.3.134 during resolve of 'google.nl' because: more than 50 (max-qperq) queries sent while resolving ns2.google.com
After a downgrade of powerdns-recursor-4.0.3-1 to 3.7.3-3 it is working again, without making changes to /etc/powerdns/recursor.conf.
The customized configuration options in /etc/powerdns/recursor.conf:
[root@gateway001 powerdns]# grep -v -e "#.*" recursor.conf | grep -e "..*" allow-from=127.0.0.0/8, 10.0.0.0/8, ::1/64, 2001:470:1f15:a09::/64, 2001:470:7b9a::/48 auth-zones=.=/etc/powerdns/root.zone forward-zones=domain.lan=10.3.0.1,home.lan=10.3.0.21 hint-file=/etc/powerdns/named.root local-address=127.0.0.1,10.3.0.253:53,[::1],[2001:470:7b9a:0a03::fd]:53 local-port=5353 log-common-errors=yes loglevel=9 pdns-distributes-queries=yes query-local-address6=::
Looks like your not getting out to the root name servers and/or their delegations. I find it odd that you are claiming both authority for the root zone and providing a hint file as well. I wonder if it's reasonable to claim authority for the root zone, since they may change it dynamically if there are problems with one of the name servers. I think I would stay with just the hint file, though. Are you doing this for security reasons? You could increase the log level and I believe you will see the lookup chain and where it is failing. You could also watch with tcpdump. Nataraj
Do I need something to change to make it working against 4.0.x?
I've searched at powerdns.com to options that have changed in the configuration but nothing helped.
Kind regards, Roel de Wildt
Op 23-10-2016 om 20:13 schreef Nataraj via arch-general:
Hello,
After a upgrade from powerdns-recursor-3.7.3-3 to powerdns-recursor-4.0.3-1 it does not return any dns queries anymore.
In the daemon.log is logged:
Oct 23 10:50:18 gateway001 pdns_recursor[3008]: Oct 23 10:50:18 Sending SERVFAIL to 10.3.3.134 during resolve of 'google.nl' because: more than 50 (max-qperq) queries sent while resolving ns1.google.com Oct 23 10:50:19 gateway001 pdns_recursor[3008]: Oct 23 10:50:19 Sending SERVFAIL to 10.3.3.134 during resolve of 'google.nl' because: more than 50 (max-qperq) queries sent while resolving ns2.google.com
After a downgrade of powerdns-recursor-4.0.3-1 to 3.7.3-3 it is working again, without making changes to /etc/powerdns/recursor.conf.
The customized configuration options in /etc/powerdns/recursor.conf:
[root@gateway001 powerdns]# grep -v -e "#.*" recursor.conf | grep -e "..*" allow-from=127.0.0.0/8, 10.0.0.0/8, ::1/64, 2001:470:1f15:a09::/64, 2001:470:7b9a::/48 auth-zones=.=/etc/powerdns/root.zone forward-zones=domain.lan=10.3.0.1,home.lan=10.3.0.21 hint-file=/etc/powerdns/named.root local-address=127.0.0.1,10.3.0.253:53,[::1],[2001:470:7b9a:0a03::fd]:53 local-port=5353 log-common-errors=yes loglevel=9 pdns-distributes-queries=yes query-local-address6=:: Looks like your not getting out to the root name servers and/or their delegations. I find it odd that you are claiming both authority for the root zone and providing a hint file as well. I wonder if it's reasonable to claim authority for the root zone, since they may change it dynamically if there are problems with one of the name servers. I
On 10/23/2016 06:10 AM, Roel de Wildt via arch-general wrote: think I would stay with just the hint file, though. Are you doing this for security reasons? You could increase the log level and I believe you will see the lookup chain and where it is failing. You could also watch with tcpdump.
Nataraj
Do I need something to change to make it working against 4.0.x?
I've searched at powerdns.com to options that have changed in the configuration but nothing helped.
Kind regards, Roel de Wildt
I have removed as suggested the auth-zones and hint-file declarations and now the 4.0.3-1 is working. The tcpdump did show me that it could not retrieve dns information from the root servers. I don't know why I added this in the past but they aren't needed anymore for my configuration. Thanks Roel de Wildt
On 10/23/2016 11:13 AM, Nataraj via arch-general wrote:
Hello,
After a upgrade from powerdns-recursor-3.7.3-3 to powerdns-recursor-4.0.3-1 it does not return any dns queries anymore.
In the daemon.log is logged:
Oct 23 10:50:18 gateway001 pdns_recursor[3008]: Oct 23 10:50:18 Sending SERVFAIL to 10.3.3.134 during resolve of 'google.nl' because: more than 50 (max-qperq) queries sent while resolving ns1.google.com Oct 23 10:50:19 gateway001 pdns_recursor[3008]: Oct 23 10:50:19 Sending SERVFAIL to 10.3.3.134 during resolve of 'google.nl' because: more than 50 (max-qperq) queries sent while resolving ns2.google.com
After a downgrade of powerdns-recursor-4.0.3-1 to 3.7.3-3 it is working again, without making changes to /etc/powerdns/recursor.conf.
The customized configuration options in /etc/powerdns/recursor.conf:
[root@gateway001 powerdns]# grep -v -e "#.*" recursor.conf | grep -e "..*" allow-from=127.0.0.0/8, 10.0.0.0/8, ::1/64, 2001:470:1f15:a09::/64, 2001:470:7b9a::/48 auth-zones=.=/etc/powerdns/root.zone forward-zones=domain.lan=10.3.0.1,home.lan=10.3.0.21 hint-file=/etc/powerdns/named.root local-address=127.0.0.1,10.3.0.253:53,[::1],[2001:470:7b9a:0a03::fd]:53 local-port=5353 log-common-errors=yes loglevel=9 pdns-distributes-queries=yes query-local-address6=:: Looks like your not getting out to the root name servers and/or their delegations. I find it odd that you are claiming both authority for the root zone and providing a hint file as well. I wonder if it's reasonable to claim authority for the root zone, since they may change it dynamically if there are problems with one of the name servers. I
On 10/23/2016 06:10 AM, Roel de Wildt via arch-general wrote: think I would stay with just the hint file, though. Are you doing this for security reasons? You could increase the log level and I believe you will see the lookup chain and where it is failing. You could also watch with tcpdump.
Nataraj
Setting trace=on will show you details of the lookups and responses. I am having a problem with 4.0.3-1, but it is not the same as yours. The recursor answers all queries correctly, however, if I try to restart or stop and start the recursor from systemctl, systemctl hangs and then eventually (maybe a minute or so) I get the following error. Note the recursor actually starts and works fine, but systemd seems to think there is a problem. Job for pdns-recursor.service failed because a timeout was exceeded. See "systemctl status pdns-recursor.service" and "journalctl -xe" for details. journalctl shows no unusual errors in the log file, other than the normal startup messages output by pdns-recursor. systemctl then shows the process to still be in the start state. systemctl status pdns-recursor.service * pdns-recursor.service - PowerDNS Recursor Loaded: loaded (/usr/lib/systemd/system/pdns-recursor.service; enabled; vendor preset: disabled) Active: activating (start) since Sun 2016-10-23 15:22:04 MST; 29s ago Docs: man:pdns_recursor(1) man:rec_control(1) https://doc.powerdns.com Main PID: 2165 (pdns_recursor) Memory: 4.4M CPU: 137ms CGroup: /system.slice/pdns-recursor.service `-2165 /usr/bin/pdns_recursor --daemon=no --write-pid=no --disable-syslog I am running archlinux arm on a version 7 freescale (cubox I4), so I haven't ruled out that this could be an architecture specific problem. Nataraj
On 10/23/2016 03:33 PM, Nataraj via arch-general wrote:
Setting trace=on will show you details of the lookups and responses. I am having a problem with 4.0.3-1, but it is not the same as yours. The recursor answers all queries correctly, however, if I try to restart or stop and start the recursor from systemctl, systemctl hangs and then eventually (maybe a minute or so) I get the following error. Note the recursor actually starts and works fine, but systemd seems to think there is a problem Job for pdns-recursor.service failed because a timeout was exceeded.
See "systemctl status pdns-recursor.service" and "journalctl -xe" for details.
journalctl shows no unusual errors in the log file, other than the normal startup messages output by pdns-recursor.
systemctl then shows the process to still be in the start state.
systemctl status pdns-recursor.service * pdns-recursor.service - PowerDNS Recursor Loaded: loaded (/usr/lib/systemd/system/pdns-recursor.service; enabled; vendor preset: disabled) Active: activating (start) since Sun 2016-10-23 15:22:04 MST; 29s ago Docs: man:pdns_recursor(1) man:rec_control(1) https://doc.powerdns.com Main PID: 2165 (pdns_recursor) Memory: 4.4M CPU: 137ms CGroup: /system.slice/pdns-recursor.service `-2165 /usr/bin/pdns_recursor --daemon=no --write-pid=no --disable-syslog
I am running archlinux arm on a version 7 freescale (cubox I4), so I haven't ruled out that this could be an architecture specific problem.
I have found that the issue that I previously reported with systemctl hanging when starting pdns-recursor is due to my pdns_recursor configuration having a chroot in it and it looks like I have to modify the setup for chroot to work under system (though I didn't have any problems with the previous version of pdns_recursor). Nataraj
Op 24-10-2016 om 04:16 schreef Nataraj via arch-general:
Setting trace=on will show you details of the lookups and responses. I am having a problem with 4.0.3-1, but it is not the same as yours. The recursor answers all queries correctly, however, if I try to restart or stop and start the recursor from systemctl, systemctl hangs and then eventually (maybe a minute or so) I get the following error. Note the recursor actually starts and works fine, but systemd seems to think there is a problem Job for pdns-recursor.service failed because a timeout was exceeded.
See "systemctl status pdns-recursor.service" and "journalctl -xe" for details.
journalctl shows no unusual errors in the log file, other than the normal startup messages output by pdns-recursor.
systemctl then shows the process to still be in the start state.
systemctl status pdns-recursor.service * pdns-recursor.service - PowerDNS Recursor Loaded: loaded (/usr/lib/systemd/system/pdns-recursor.service; enabled; vendor preset: disabled) Active: activating (start) since Sun 2016-10-23 15:22:04 MST; 29s ago Docs: man:pdns_recursor(1) man:rec_control(1) https://doc.powerdns.com Main PID: 2165 (pdns_recursor) Memory: 4.4M CPU: 137ms CGroup: /system.slice/pdns-recursor.service `-2165 /usr/bin/pdns_recursor --daemon=no --write-pid=no --disable-syslog
I am running archlinux arm on a version 7 freescale (cubox I4), so I haven't ruled out that this could be an architecture specific problem. I have found that the issue that I previously reported with systemctl hanging when starting pdns-recursor is due to my pdns_recursor configuration having a chroot in it and it looks like I have to modify
On 10/23/2016 03:33 PM, Nataraj via arch-general wrote: the setup for chroot to work under system (though I didn't have any problems with the previous version of pdns_recursor).
Nataraj
Does it work if you comment out the chroot option in the configuration of pdns_recursor? Just to rule out other possible configuration issues. It looks like that systemd is not detecting your pdns_recursor process. I don't know yet how to fix this but in the 'journalctl -r' will properly shows a hint where to look further. Roel de Wildt
On 10/24/2016 09:58 AM, Roel de Wildt via arch-general wrote:
I have found that the issue that I previously reported with systemctl
hanging when starting pdns-recursor is due to my pdns_recursor configuration having a chroot in it and it looks like I have to modify the setup for chroot to work under system (though I didn't have any problems with the previous version of pdns_recursor).
Nataraj
Does it work if you comment out the chroot option in the configuration of pdns_recursor? Just to rule out other possible configuration issues.
Yes, it does run correctly if I remove chroot from the config file.
It looks like that systemd is not detecting your pdns_recursor process. I don't know yet how to fix this but in the 'journalctl -r' will properly shows a hint where to look further.
There are no entries in the log other than the normal output from the recursor which does actually work only that systemd thinks it's still starting. There are these changes in the systemd pdns-recursor.service between 3.7.3-3 and 4.0.3-1: 3.7.3-3 [Unit] Description=PowerDNS resolving DNS server After=network.target [Service] Type=forking ExecStart=/usr/bin/pdns_recursor --daemon [Install] WantedBy=multi-user.target ------------------------------------------ 4.0.3-1 [Unit] Description=PowerDNS Recursor Documentation=man:pdns_recursor(1) man:rec_control(1) Documentation=https://doc.powerdns.com Wants=network-online.target nss-lookup.target Before=nss-lookup.target After=network-online.target [Service] Type=notify ExecStart=/usr/bin/pdns_recursor --daemon=no --write-pid=no --disable-syslog Restart=on-failure StartLimitInterval=0 PrivateTmp=true PrivateDevices=true CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID CAP_CHOWN CA\ P_SYS_CHROOT NoNewPrivileges=true ProtectSystem=full ProtectHome=true RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 LimitNOFILE=4200 [Install] WantedBy=multi-user.target So it looks like the 4.0.3-1 version is interfacing to systemd in a way that the 3.7.3 version was not. I have not yet spent the time to understand the systemd interface and how daemons running under systemd interface too it. I know that pdns-recursor creates a socket for use by the rec_control program, but it does not appear that systemd uses that socket because I tried moving that socket to a different place using the config file directive and it still worked normal (without the chroot) when I did that. Various articles such as these imply that you have to setup chroots differently under systemd: http://superuser.com/questions/688733/start-a-systemd-service-inside-chroot#... https://wiki.archlinux.org/index.php/Arch_systemd_container but I'm open to other suggestions on how to do this. How does systemd determine if a daemon process is running or fully started? Thank You, Nataraj
participants (4)
-
incoming-archlinux＠rjl.com
-
Levente Polyak
-
Nataraj
-
Roel de Wildt