7 Čec
2014
7 Čec
'14
19:07
Hello Gonzalo,
there should be no need to use two remotes. You should be able to tell
BIND to only use a specific port, if it really does send NOTIFY from
random ports, it does not improve prevention from any attacks, at least
as far as I know. Also, try out Hauke's suggestion and let us know if
the problem persists.
Have a nice day,
Jan
On Mon, 2014-07-07 at 12:46 -0400, Gonzalo Muñoz wrote:
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
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users