7 Čec
2014
7 Čec
'14
18:46
Well the solution I found was to remove the TSIG key from the BIND
remote for the notify-in option. This is rather inconvenient, because I
do need a key for the transfers from the BIND master. So now I have
something that looks like this in my Knot slave configuration:
remotes {
bind-remote {
address 1.2.3.4;
}
bind-remote-tsig {
address 1.2.3.4;
key bind-key;
}
}
zone {
example.com {
notify-in bind-remote;
xfr-in bind-remote-tsig;
}
}
Basically I have two entries for the same remote, one for transfers
(using a TSIG key) and one for NOTIFY messages (using no key). This
allows the Knot slave to process NOTIFY messages correctly.
Is there a more elegant way around this?
Gonzalo Muñoz
NIC Chile
On 07/07/14 11:35, Gonzalo Muñoz wrote:
Hello everybody,
We're currently testing Knot for a slave server with a BIND master,
and we've noticed that NOTIFY messages from this master are not being
processed by Knot. As I understand, BIND uses a random source port for
NOTIFY messages, as a precaution against attacks. Also, if I
understand correctly, when I add a remote master to a zone in Knot, if
I don't specify a port for it then it defaults to 53-
This leads me to believe that Knot is rejecting NOTIFY messages from
the BIND master, because they come from an unexpected, random port. Is
this correct? Can this situation be rectified to allow NOTIFY messages
from random ports?
Thank you very much in advance.
Gonzalo Muñoz
NIC Chile