8 Čen
2018
8 Čen
'18
12:54
Hi!
One of our customers uses Knot 2.6.7 as hidden master which sends
NOTIFYs to our slave service. He reported that Knot can not send the
NOTIFYs, ie:
knotd[10808]: warning: [example.com.] notify, outgoing,
2a02:850:8::6@53: failed (connection reset)
It seems that Knot sometimes tries to send the NOTIFY with TCP (I see
also NOTIFYs via UDP). Unfortunatelly our NOTIFY-receiver only supports UDP.
So, this is the first time seeing a name server sending NOTIFYs over
TCP. Is this a typical behavior in Knot? Can I force Knot to send
NOTIFYs always over UDP?
Thanks
Klaus
8 Čen
8 Čen
14:11
Hi Klaus,
Knot DNS always sends NOTIFY over TCP. It's intentional, because UDP is unreliable.
Unfortunately, it's not possible to easily switch to UDP :-/
Regards,
Daniel
On 06/08/2018 12:54 PM, Klaus Darilion wrote:
Hi!
One of our customers uses Knot 2.6.7 as hidden master which sends
NOTIFYs to our slave service. He reported that Knot can not send the
NOTIFYs, ie:
knotd[10808]: warning: [example.com.] notify, outgoing,
2a02:850:8::6@53: failed (connection reset)
It seems that Knot sometimes tries to send the NOTIFY with TCP (I see
also NOTIFYs via UDP). Unfortunatelly our NOTIFY-receiver only supports UDP.
So, this is the first time seeing a name server sending NOTIFYs over
TCP. Is this a typical behavior in Knot? Can I force Knot to send
NOTIFYs always over UDP?
Thanks
Klaus
14:59
Hi Daniel,
I don't run Knot DNS as a master, so I don't see this issue. Even if I
ran Knot DNS as a master, I'm not terribly bothered with NOTIFY over TCP.
Having said that, I don't think it's very fair to say that UDP is
unreliable, and there are various reasons for it:
1. NOTIFY is a hint, and if it gets lost, it's not the biggest disaster
in the world.
2. NOTIFY is just like any other query, so Knot could send the NOTIFY
over UDP and wait for the response. If the response doesn't arrive, it
could retry the NOTIFY. At least BIND and NSD both do this. They allow
for the fact that one NOTIFY might get lost sometimes.
However, if you can't easily modify Knot to use UDP instead of TCP for
NOTIFY, it doesn't bother me personally, because a NOTIFY receiver
should also be able to accept TCP (TCP is required by DNS). But I can
see Klaus's viewpoint. However, I'll leave him to tell us his opinion on
this matter.
Regards,
Anand
On 08/06/2018 14:11, Daniel Salzman wrote:
Hi Klaus,
Knot DNS always sends NOTIFY over TCP. It's intentional, because UDP is unreliable.
Unfortunately, it's not possible to easily switch to UDP :-/
15:05
Am 08.06.2018 um 14:59 schrieb Anand Buddhdev:
However, if you can't easily modify Knot to use
UDP instead of TCP for
NOTIFY, it doesn't bother me personally, because a NOTIFY receiver
should also be able to accept TCP (TCP is required by DNS). But I can
see Klaus's viewpoint. However, I'll leave him to tell us his opinion on
this matter.
I admit that our NOTIFY-receiver is the bad player. When I built it long
ago I hadn't seen a NOTIFY over TCP (until today) so I was hoping for a
quick workaround without adding TCP do my NOTIFY-receiver. It seem I
have to touch my old code again ....
regards
Klaus
15:06
Hi Anand,
I fully understand your argument, but this was our decision in the past.
Every outgoing DNS message from Knot is over TCP. We didn't want to wait
or deduce whether a slave got the message.
Best,
Daniel
On 06/08/2018 02:59 PM, Anand Buddhdev wrote:
Hi Daniel,
I don't run Knot DNS as a master, so I don't see this issue. Even if I
ran Knot DNS as a master, I'm not terribly bothered with NOTIFY over TCP.
Having said that, I don't think it's very fair to say that UDP is
unreliable, and there are various reasons for it:
1. NOTIFY is a hint, and if it gets lost, it's not the biggest disaster
in the world.
2. NOTIFY is just like any other query, so Knot could send the NOTIFY
over UDP and wait for the response. If the response doesn't arrive, it
could retry the NOTIFY. At least BIND and NSD both do this. They allow
for the fact that one NOTIFY might get lost sometimes.
However, if you can't easily modify Knot to use UDP instead of TCP for
NOTIFY, it doesn't bother me personally, because a NOTIFY receiver
should also be able to accept TCP (TCP is required by DNS). But I can
see Klaus's viewpoint. However, I'll leave him to tell us his opinion on
this matter.
Regards,
Anand
On 08/06/2018 14:11, Daniel Salzman wrote:
> Hi Klaus,
>
> Knot DNS always sends NOTIFY over TCP. It's intentional, because UDP is
unreliable.
> Unfortunately, it's not possible to easily switch to UDP :-/
15:12
On 06/08/2018 03:06 PM, Daniel Salzman wrote:
Hi Anand,
I fully understand your argument, but this was our decision in the past.
Every outgoing DNS message from Knot is over TCP. We didn't want to wait
s/outgoing/knot-initiated
or deduce whether a slave got the message.
Best,
Daniel
On 06/08/2018 02:59 PM, Anand Buddhdev wrote:
> Hi Daniel,
>
> I don't run Knot DNS as a master, so I don't see this issue. Even if I
> ran Knot DNS as a master, I'm not terribly bothered with NOTIFY over TCP.
>
> Having said that, I don't think it's very fair to say that UDP is
> unreliable, and there are various reasons for it:
>
> 1. NOTIFY is a hint, and if it gets lost, it's not the biggest disaster
> in the world.
>
> 2. NOTIFY is just like any other query, so Knot could send the NOTIFY
> over UDP and wait for the response. If the response doesn't arrive, it
> could retry the NOTIFY. At least BIND and NSD both do this. They allow
> for the fact that one NOTIFY might get lost sometimes.
>
> However, if you can't easily modify Knot to use UDP instead of TCP for
> NOTIFY, it doesn't bother me personally, because a NOTIFY receiver
> should also be able to accept TCP (TCP is required by DNS). But I can
> see Klaus's viewpoint. However, I'll leave him to tell us his opinion on
> this matter.
>
> Regards,
> Anand
>
> On 08/06/2018 14:11, Daniel Salzman wrote:
>
>> Hi Klaus,
>>
>> Knot DNS always sends NOTIFY over TCP. It's intentional, because UDP is
unreliable.
>> Unfortunately, it's not possible to easily switch to UDP :-/
15:21
Every outgoing DNS message from Knot is over TCP. We
didn't want to wait
or deduce whether a slave got the message.
I like this approach a lot. We had problems in the past that notifies
got lost in a network which was not on our control. We had to work
around it by lowering the SOA refresh interval. I guess using TCP avoids
this problem completely.
Daniel
16:16
Am 08.06.2018 um 15:21 schrieb Daniel Stirnimann:
Maybe not. Is Knot trying NOTIFYs endlessly? If not, then it just gives
you the knowledge on the master that the NOTIFY did not arrive on the slave.
We also worked around by using eg: max-refresh-time on the slave
regards
Klaus
Every outgoing
DNS message from Knot is over TCP. We didn't want to wait
or deduce whether a slave got the message.
I like this approach a lot. We had problems in the past that notifies
got lost in a network which was not on our control. We had to work
around it by lowering the SOA refresh interval. I guess using TCP avoids
this problem completely.
16:51
On 06/08/2018 04:16 PM, Klaus Darilion wrote:
Am 08.06.2018 um 15:21 schrieb Daniel Stirnimann:
Maybe not. Is Knot trying NOTIFYs endlessly? If not, then it just gives
you the knowledge on the master that the NOTIFY did not arrive on the slave.
You are right. Knot tries to send NOTIFY just ones. IMHO every approach has
some disadvantages.
Every
outgoing DNS message from Knot is over TCP. We didn't want to wait
or deduce whether a slave got the message.
I like this approach a lot. We had problems in the past that notifies
got lost in a network which was not on our control. We had to work
around it by lowering the SOA refresh interval. I guess using TCP avoids
this problem completely. We also worked around by using eg: max-refresh-time on
the slave
regards
Klaus
16:20
kdig notify example.com +tcp
On 06/08/2018 04:18 PM, Klaus Darilion wrote:
btw: does anybody knows a tool for sending NOTIFYs
over TCP?
Thanks
Klaus
16:28
Great: I just noticed that installing knot-dnsutils uninstalls dnsutils.
Is kdig completely backwards-compatible to dig?
Klaus
Am 08.06.2018 um 16:20 schrieb Daniel Salzman:
kdig notify example.com +tcp
On 06/08/2018 04:18 PM, Klaus Darilion wrote:
> btw: does anybody knows a tool for sending NOTIFYs over TCP?
> Thanks
> Klaus
>
16:30
Am 08.06.2018 um 16:28 schrieb Klaus Darilion:
Great: I just noticed that installing knot-dnsutils
uninstalls dnsutils.
Is kdig completely backwards-compatible to dig?
Answering myself: No :-( (e.g +trace is missing)
So, it is bad that kdig and dig can not be installed concurrently (at
least with the Debian 9 package)
regards
Klaus
16:34
On 08/06/2018 16:30, Klaus Darilion wrote:
Am 08.06.2018 um 16:28 schrieb Klaus Darilion:
This seems strange. As far as I know, there is no naming clash between
the BIND utilities and the Knot ones. In fact, this is the reason that
the Knot tools are all prefixed with 'k'. It should be possible to
install both the BIND and Knot tools together.
Perhaps open a bug report with the maintainer of the knot-dnsutils package?
Regards,
Anand
Great: I just noticed that installing
knot-dnsutils uninstalls dnsutils.
Is kdig completely backwards-compatible to dig?
Answering myself: No :-( (e.g +trace is missing)
So, it is bad that kdig and dig can not be installed concurrently (at
least with the Debian 9 package) 
16:42
On 06/08/2018 04:34 PM, Anand Buddhdev wrote:
Perhaps open a bug report with the maintainer of the
knot-dnsutils > package?
IIRC it's just not backported to some Debian <
10.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741645
--Vladimir
16:45
On 06/08/2018 04:30 PM, Klaus Darilion wrote:
Am 08.06.2018 um 16:28 schrieb Klaus Darilion:
> Great: I just noticed that installing knot-dnsutils uninstalls dnsutils.
> Is kdig completely backwards-compatible to dig?
It's quite impossible to be fully compatible with dig, because it is still being
developed
and burdened with its history.
Answering myself: No :-( (e.g +trace is missing)
So, it is bad that kdig and dig can not be installed concurrently (at
least with the Debian 9 package>
regards
Klaus
2158
days inactive
2158
days old
15 comments
5 participants
participants (5)
-
Anand Buddhdev -
Daniel Salzman -
Daniel Stirnimann -
Klaus Darilion -
Vladimír Čunát