Os escravos do PowerDNS não atualizam após serem notificados

Question

Estou executando duas máquinas com o PowerDNS, sendo uma delas o mestre (SQL) e uma a escrava (back-end Bind).

Depois que eu modifico um domínio e bato a serial, eu obtenho isso no log:

Sep 30 22:13:20 localhost pdns[6884]: 1 domain for which we are master needs notifications
Sep 30 22:13:20 localhost pdns[6884]: Queued notification of domain 'netly.io' to 146.185.146.149
Sep 30 22:13:20 localhost pdns[6884]: Queued notification of domain 'netly.io' to 146.185.147.74
Sep 30 22:13:20 localhost pdns[6884]: Received NOTIFY for netly.io from 146.185.146.149 but slave support is disabled in the configuration
Sep 30 22:13:21 localhost pdns[6884]: Received unsuccessful notification report for 'netly.io' from 146.185.146.149:53, rcode: 4
Sep 30 22:13:21 localhost pdns[6884]: Removed from notification list: 'netly.io' to 146.185.146.149:53
Sep 30 22:13:23 localhost pdns[6884]: No master domains need notifications

Eu entendo que ele está se notificando (146.185.146.149) porque está configurado como servidor de nomes e que esses erros podem ser ignorados. Ele (parece) notifica o outro servidor (146.185.147.74 ou 162.243.29.199) também.

No entanto, o escravo não mostra nada no log em torno desse período de tempo e, quando cato o arquivo de domínio, posso ver que a serial antiga e o subdomínio não estão sendo atualizados.

dig @ slave-server também mostra as configurações antigas.

dizendo para recarregar também não atualiza o arquivo de zona de vinculação:

slave-server # pdns_control reload
Ok
slave-server # tail -f /var/log/daemon.log 
Sep 30 22:21:28 node-e31401 pdns[2259]: Zone 'netly.io' (/etc/powerdns/bind/netly.io.) needs reloading
Sep 30 22:21:28 node-e31401 pdns[2259]: Zone 'netly.io' (/etc/powerdns/bind/netly.io.) reloaded

No entanto, quando eu reinicio totalmente o PDNS, ele finalmente descobre que está desatualizado e busca corretamente a zona atualizada:

slave-server # /etc/init.d/pdns restart
[ ok ] Restarting PowerDNS Authoritative Name Server: pdns.
slave-server # tail -f /var/log/daemon.log 
Sep 30 22:23:48 node-e31401 pdns[2911]: 2 slave domains need checking, 0 queued for AXFR
Sep 30 22:23:48 node-e31401 pdns[2911]: Received serial number updates for 2 zones, had 0 timeouts
Sep 30 22:23:48 node-e31401 pdns[2911]: Domain netly.io is stale, master serial 2013093004, our serial 2013093003
Sep 30 22:23:48 node-e31401 pdns[2911]: Domain titify.com is fresh (not presigned, no RRSIG check)
Sep 30 22:23:48 node-e31401 pdns[2911]: No master domains need notifications
Sep 30 22:23:48 node-e31401 pdns[2911]: Initiating transfer of 'netly.io' from remote '146.185.146.149'
Sep 30 22:23:48 node-e31401 pdns[2911]: AXFR started for 'netly.io', transaction started
Sep 30 22:23:48 node-e31401 pdns[2911]: Zone 'netly.io' (/etc/powerdns/bind/netly.io.) reloaded
Sep 30 22:23:48 node-e31401 pdns[2911]: AXFR done for 'netly.io', zone committed with serial number 2013093004
Sep 30 22:23:48 node-e31401 pdns[2911]: Done launching threads, ready to distribute questions

O que estou perdendo aqui? O que está causando o mestre para notificar corretamente o escravo, mas o escravo não buscar a nova zona?

Editar:

• Configuração do escravo: link
• Configuração mestre: link

tcpdump:

node-fd1d01 ~ # tcpdump -n 'host 146.185.146.149 and port 53'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:51:38.042713 IP 146.185.146.149.42478 > 162.243.29.199.53: 61745 notify [b2&3=0x2400] SOA? netly.io. (26)
09:51:41.043323 IP 146.185.146.149.42478 > 162.243.29.199.53: 61745 notify [b2&3=0x2400] SOA? netly.io. (26)
09:51:46.044145 IP 146.185.146.149.42478 > 162.243.29.199.53: 61745 notify [b2&3=0x2400] SOA? netly.io. (26)
09:51:52.049533 IP 146.185.146.149.42478 > 162.243.29.199.53: 59408 notify [b2&3=0x2400] SOA? netly.io. (26)
09:51:55.050715 IP 146.185.146.149.42478 > 162.243.29.199.53: 61745 notify [b2&3=0x2400] SOA? netly.io. (26)
09:51:55.050753 IP 146.185.146.149.42478 > 162.243.29.199.53: 59408 notify [b2&3=0x2400] SOA? netly.io. (26)
09:52:00.053327 IP 146.185.146.149.42478 > 162.243.29.199.53: 59408 notify [b2&3=0x2400] SOA? netly.io. (26)
09:52:09.056321 IP 146.185.146.149.42478 > 162.243.29.199.53: 59408 notify [b2&3=0x2400] SOA? netly.io. (26)

O registro não mostra nada de novo (mais recente às 09h48):

node-fd1d01 /etc/powerdns/bind # tail -f /var/log/daemon.log 
Oct  2 09:47:59 localhost pdns[2253]: Domain netly.io is fresh (not presigned, no RRSIG check)
Oct  2 09:47:59 localhost pdns[2253]: Domain titify.com is fresh (not presigned, no RRSIG check)
Oct  2 09:47:59 localhost pdns[2253]: No master domains need notifications
Oct  2 09:47:59 localhost pdns[2253]: Done launching threads, ready to distribute questions
Oct  2 09:48:00 localhost ntpd[2144]: Listen normally on 6 tun0 172.17.24.1 UDP 123
Oct  2 09:48:00 localhost ntpd[2144]: Listen normally on 7 tun1 172.17.16.1 UDP 123
Oct  2 09:48:00 localhost ntpd[2144]: peers refreshed
Oct  2 09:48:12 localhost dbus[2093]: [system] Activating service name='org.freedesktop.ConsoleKit' (using servicehelper)
Oct  2 09:48:12 localhost dbus[2093]: [system] Successfully activated service 'org.freedesktop.ConsoleKit'
Oct  2 09:48:59 localhost pdns[2253]: No new unfresh slave domains, 0 queued for AXFR already

Mas quando eu cato o arquivo de zona (no formato Bind) ele não é atualizado.

    

Answer 1

O problema era a porta 53 ser protegida por firewall a partir da porta externa, mas não no localhost ou na interface VPN. Eu não tinha notado porque eu geralmente tentava dig @localhost .

Se bem entendi, mestre envia uma mensagem para UDP / 53 (via Stefan). Isso foi, portanto, parcialmente protegido por firewall e causou o problema.

Mestre:

Oct  3 18:56:25 localhost pdns[6884]: gmysql Connection successful
Oct  3 18:56:25 localhost pdns[6884]: AXFR of domain 'netly.io' initiated by 162.243.25.159
Oct  3 18:56:25 localhost pdns[6884]: AXFR of domain 'netly.io' allowed: client IP 162.243.25.159 is in allow-axfr-ips
Oct  3 18:56:25 localhost pdns[6884]: gmysql Connection successful
Oct  3 18:56:25 localhost pdns[6884]: gmysql Connection successful
Oct  3 18:56:25 localhost pdns[6884]: AXFR of domain 'netly.io' to 162.243.25.159 finished
Oct  3 18:56:25 localhost pdns[6884]: Received unsuccessful notification report for 'netly.io' from 146.185.146.149:53, rcode: 4
Oct  3 18:56:25 localhost pdns[6884]: Removed from notification list: 'netly.io' to 146.185.146.149:53
Oct  3 18:56:25 localhost pdns[6884]: Removed from notification list: 'netly.io' to 162.243.25.159:53 (was acknowledged)
Oct  3 18:56:27 localhost pdns[6884]: No master domains need notifications

Escravo:

Oct  3 18:56:25 localhost pdns[2263]: 1 slave domain needs checking, 0 queued for AXFR
Oct  3 18:56:25 localhost pdns[2263]: Received serial number updates for 1 zones, had 0 timeouts
Oct  3 18:56:25 localhost pdns[2263]: Domain netly.io is stale, master serial 2013100302, our serial 2013100301
Oct  3 18:56:25 localhost pdns[2263]: Initiating transfer of 'netly.io' from remote '146.185.146.149'
Oct  3 18:56:25 localhost pdns[2263]: AXFR started for 'netly.io', transaction started
Oct  3 18:56:25 localhost pdns[2263]: Zone 'netly.io' (/etc/powerdns/bind/netly.io.) reloaded
Oct  3 18:56:25 localhost pdns[2263]: AXFR done for 'netly.io', zone committed with serial number 2013100302

    

Answer 2

Estávamos passando por isso e acontece que o alvo da mensagem de notificação do DNS estava, na verdade, recusando a mensagem.

Observe o "notificar recusado" abaixo. Nomes de servidores e zonas falsificados substitutos.

    # tcpdump -v -r notify.pcap
reading from file notify.pcap, link-type LINUX_SLL (Linux cooked)
00:00:33.210137 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 61) master.dns.server.46861 > slave.dns.server.domain: 49437 notify SOA? zoneinquestion.com. (33)
00:00:33.236488 IP (tos 0x0, ttl 55, id 17352, offset 0, flags [none], proto UDP (17), length 61) slave.dns.server.domain > master.dns.server.46861: 49437 notify Refused- 0/0/0 (33)
00:00:36.244057 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 61) master.dns.server.46861 > slave.dns.server.domain: 48449 notify SOA? zoneinquestion.com. (33)
00:00:36.269682 IP (tos 0x0, ttl 55, id 17353, offset 0, flags [none], proto UDP (17), length 61) slave.dns.server.domain > master.dns.server.46861: 48449 notify Refused- 0/0/0 (33)
00:00:36.519361 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 61) master.dns.server.46861 > slave.dns.server.domain: 65128 notify SOA? zoneinquestion.com. (33)
00:00:36.544391 IP (tos 0x0, ttl 55, id 17354, offset 0, flags [none], proto UDP (17), length 61) slave.dns.server.domain > master.dns.server.46861: 65128 notify Refused- 0/0/0 (33)

Capturou essa saída no mestre com o seguinte:

tcpdump -U -i any -w notify.pcap -s 1600 host slave.dns.server