7 Čec
2014
7 Čec
'14
17:35
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
7 Čec
7 Čec
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:
22:28
On 07/07/14 13:02, Hauke Lampe wrote:
Thank you, this is much better. Indeed, BIND was sending unsigned
NOTIFY messages, now every message is signed. Interestingly, BIND
slaves will accept unsigned NOTIFY messages from a master even if the
zone statement in the slave requires a key for that master.
Thanks again!
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:
3926
days inactive
3926
days old
4 comments
3 participants
participants (3)
-
Gonzalo Muñoz -
Hauke Lampe -
Jan Kadlec