Testing transfer of slave zone from master results in connection refused

Question

I'm using bind9 with webmin to try and set up a dns secondary for our primary nameserver. I'm in what I assume should be a very simple situation but I'm not able to get the master to transfer zones to the slave.

I've configured the master to have the slave in the Webmin Server Index then configured it as a slave under Cluster Slave Servers, then configured allow_transfer on the master with the ip of the slave. iptables -nL shows ports 53 and 953 as open on both master and slave. netstat -lnpt shows named listening to 53 (on master and slave), yet when I run test transferring the records to the slave I get:

Testing transfer of slave zone from 10.191.0.2 .. .. from 10.191.0.2 : 
Failed : ;; Connection to 10.191.0.2#53(10.191.0.2) for 
test.example.com failed: connection refused.

Configs for zone on master .2

zone "test.example.com" {
  type master;
  file "/var/lib/bind/test.example.com.hosts";
  notify yes;
  allow-transfer {
    10.191.0.3;
    };
};

Configs for zone on slave .3

zone "test.example.com" {
  type slave;
  masters {
    10.191.0.2;
    };
  file "/var/lib/bind/test.example.com.hosts";
  allow-transfer {
    10.191.0.2;
    };
  allow-update {
    10.191.0.2;
    };
};

I know I'm missing something, but I can't seem to figure it out.

Thanks for any help

Go on the secondary server, and do `dig @primary test.example.com AXFR` and see what happens. If nothing or timeout, you have a network problem between both hosts. If something and an error, you should see more clearly what happens and with details in primary server logfiles. — Patrick Mevzek, Jun 14 '19 at 23:02
DNS lookups typically use UDP:53 and zone transfers are often over TCP:53. Have you checked that both are allowed from primary to secondary? — Jens Ehrich, Jun 15 '19 at 00:07
@JensEhrich That was it, only had udp open. Post it as an answer if you want more magic internet points — Silfheed, Jun 17 '19 at 17:57
@PatrickMevzek Thanks too, that helped narrow down the fact that tcp 53 wasn't responding at all. — Silfheed, Jun 17 '19 at 17:59
`AXFR` uses TCP indeed. You should use any online tool like DNSviz or Zonemaster to verify your nameserver configuration, replying to both UDP and TCP for any query is mandatory for good operations. You can also easily test locally, using `dig +notcp` and `dig +tcp` towards your nameserver. — Patrick Mevzek, Jun 17 '19 at 18:02

score 3 · Accepted Answer · edited Jun 11 '20 at 10:02

Let me summarize and add a reason for the behaviour to the answer for the people who may come to this issue in the future...

DNS system by the definition is utilizing as default UDP protocol on port 53. But the service is designed to prevent fragmentation of the answer so once the answer would be bigger size it "fall" back to TCP protocol.

With UDP (in principle) you cannot guarantee that the answer will arrive fully and that some part is not lost during delivery once TCP is sending the confirmation. As a result once the answer is small enough that it would fit to one piece the UDP is used. Once the answer would be bigger to be safe the system send it out as TCP to not care about the fragmentation and delivery order. The example of bigger answer could be "regular" answer with glue records (where to ask for the next query iteration step - chicken and egg ;-) or DNSSEC stuff) or just mentioned zone transfer.

As rfc5936 - DNS Zone transfer Protocol (AXFR) is stating:

Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests.

...

With the addition of EDNS0 and applications that require many small zones, such as in web hosting and some ENUM scenarios, AXFR sessions on UDP would now seem desirable. However, there are still some aspects of AXFR sessions that are not easily translated to UDP.

Therefore, this document does not update RFC 1035 in this respect: AXFR sessions over UDP transport are not defined.

So based on the citation you see that TCP protocol for zone transfer is mandatory.

In general (so not only because of zone transfer) you should allow both TCP/53 and UDP/53 on the DNS server to have it properly working. Allowing only UDP/53 would allow only partial operability.

-- edit (Thu Jun 20 10:20 UTC 2019) --

adding the actual answer to the question as well (AXFR uses TCP) - thanks to Håkan Lindqvist

Please consider adding the actual answer to the question as well (AXFR uses TCP), not only the additional reasons why you need TCP. — Håkan Lindqvist, Jun 20 '19 at 10:06

Testing transfer of slave zone from master results in connection refused

1 Answers1