Zone transfer failure

[John W. Blue]

And make sure that all of your servers are sync’d to the same NTP.  That has burned me in the past.

John

From: bind-users [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Bob Harold
Sent: Wednesday, October 17, 2018 9:16 AM
To: ampranti at gmail.com
Cc: bind-users at lists.isc.org
Subject: Re: Zone transfer failure


On Wed, Oct 17, 2018 at 9:56 AM Andreas Brandino <ampranti at gmail.com<mailto:ampranti at gmail.com>> wrote:
Both servers receive the NOTIFY message from NS1. What I see on the logs:

NS3:
17-Oct-2018 16:41:00.688 notify: info: client 1.1.1.1#19513/key ns1ns3_key: view external: received notify for zone 'myzone.com<http://myzone.com>': TSIG 'ns1ns3_key'

Notice the "view external" in the line above, compared to ns5, which got the notify on the internal view.  That appears to be the issue.
Try adding the IP of NS1 to the "match" list for the internal view on NS3.

--
Bob Harold

NS5:
17-Oct-2018 16:40:56.131 notify: info: client 1.1.1.1#32586/key ns1ns5_key: received notify for zone 'myzone.com<http://myzone.com>': TSIG 'ns1ns5_key'
17-Oct-2018 16:40:56.139 notify: info: zone myzone.com/IN<http://myzone.com/IN>: sending notifies (serial 2018101910)

The 2nd line is missing on NS3.
At this point NS5 starts the zone copy (NS1 logs):

17-Oct-2018 16:41:01.233 xfer-out: info: client 5.5.5.5#40909/key ns1ns5_key (myzone.com<http://myzone.com>): view internal: transfer of 'myzone.com/IN<http://myzone.com/IN>': AXFR started: TSIG ns1ns5_key
17-Oct-2018 16:41:01.234 xfer-out: info: client 5.5.5.5#40909/key ns1ns5_key (myzone.com<http://myzone.com>): view internal: transfer of 'myzone.com/IN<http://myzone.com/IN>': AXFR ended

At this point NS3 does nothing.

This is not a firewall or networking problem because I can start the transfer manually.

Best Regards

Στις Τετ, 17 Οκτ 2018 στις 4:35 μ.μ., ο/η Bob Harold <rharolde at umich.edu<mailto:rharolde at umich.edu>> έγραψε:

On Wed, Oct 17, 2018 at 7:23 AM Andreas Brandino <ampranti at gmail.com<mailto:ampranti at gmail.com>> wrote:
Hello all,

I wonder if anyone can help me to find the cause of the problem I am currently having.
All servers are running on Debian and BIND 9.10.3-P4-Debian.

I have a master server and 4 slaves.
The zone is transfered from the master [ns1] to all slaves [ns3,ns4,ns5 and ns6].
I am also using TSIG with a different key for each server.
Moreover, the zone file refers to the internal view.

When I change the myzone.com<http://myzone.com>, I always update the serial and I reload the zone.

The problem:
ns3 and ns4 never get the updated zone file automatically.
On the other hand, ns4 and ns5 always get the updated zone file immediately.

If I initialize the transfer manually from ns3 and ns4, I get no errors.

Here is the config:

NS1 config: (IP 1.1.1.1 - master DNS)

        zone "myzone.com<http://myzone.com>" {
                type master;
                file    "/etc/bind/master/myzone.com.INSIDE";
                allow-transfer { key ns1ns3_key; key ns1ns4_key; key ns1ns5_key; key ns1ns6_key; };
                also-notify {
                        3.3.3.3 port 53 key ns1ns3_key;
                        4.4.4.4 port 53 key ns1ns4_key;
                        5.5.5.5 port 53 key ns1ns5_key;
                        6.6.6.6 port 53 key ns1ns6_key;
                };
                notify explicit;
                notify-source 1.1.1.1 ;
                };


NS3 config: (IP 3.3.3.3 - transfer fails)

       zone " myzone .com" {
                file    "/etc/bind/master/myzone.com.INSIDE";
                type slave;
                allow-update { key ns1ns3_key; };
                masters { 1.1.1.1; };
                allow-notify { 1.1.1.1; };
                notify yes;
                request-ixfr no;
                };

NS5 config: (IP 5.5.5.5, successful transfer)

zone "myzone.com<http://myzone.com>" {
                file    "/etc/bind/master/myzone.com.INSIDE";
                type slave;
                allow-update { key ns1ns5_key; };
                masters { 1.1.1.1; };
                notify yes;
                request-ixfr no;
                };

Do you see any errors in the above configuration that could cause this problem?

Best Regards

What you don't show is the 'match' statement for your views.  Perhaps 1 does not match the internal view on 3, so the notify packet hits the wrong view.  Check the notify messages in the logs on 3, compared to 5.  Here is a typical notify log message:


30-Sep-2018 23:12:37.135 general: info: zone psych.lsa.umich.edu/IN/oncampus<http://psych.lsa.umich.edu/IN/oncampus>: notify from 141.211.147.150#38695: zone is up to date



Note the zone/class/view contains ".../IN/oncampus" - check the view in your logs.



If you cannot find the notify, you might need to turn on logging for category "general".  Or check routing and firewall rules if the packet is not being received.



--

Bob Harold


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20181017/11f2cedd/attachment.html>