During a training I gave last week, a student asked whether it is possible to protect an XFR by IP and a TSIG key. I quickly found somebody who'd done this before and have now tested with this configuration: The following (tested with a BIND 9.11.2 server) permits XFR to a client authenticated by IP and by a key (i.e. the slave must appear from a valid IP and must present a correct TSIG key)
$ tsig-keygen xfr.key > xfr.key
acl "xfer" {
127.0.0.1; // this client is permitted
};
acl "not-xfer" {
!xfer;
any;
};
options {
directory ".";
allow-query { any; };
listen-on port 5301 {
127.0.0.1;
192.168.1.115;
};
recursion no;
};
include "xfr.key";
zone "example.net" in {
type master;
file "example.net";
allow-transfer { !not-xfer; key "xfr.key"; };
};
$ dig +noall +answer +onesoa -p 5301 -k xfr.key @127.0.0.1 example.net AXFR
example.net. 30 IN SOA tiggr.example. jp.mens.de. 3 10800 3600 604800 3600
example.net. 30 IN NS tiggr.example.
example.net. 30 IN A 127.0.0.1
$ tail -f named
22-Jul-2019 19:21:52.819 client @0x7f85d201e800 127.0.0.1#52369/key xfr.key (example.net): transfer of 'example.net/IN': AXFR started: TSIG xfr.key (serial 3)
22-Jul-2019 19:21:52.819 client @0x7f85d201e800 127.0.0.1#52369/key xfr.key (example.net): transfer of 'example.net/IN': AXFR ended
$ dig +noall +answer +onesoa -p 5301 -k xfr.key @192.168.1.115 example.net AXFR
; Transfer failed.
$ tail -f named
22-Jul-2019 19:22:20.486 client @0x7f85d1043c00 192.168.1.115#52372/key xfr.key (example.net): zone transfer 'example.net/AXFR/IN' denied
/via Karl Dyson:
@jpmens I typically do:
I tend to protect allow-notify the same way...