25 Dub
2025
25 Dub
'25
19:09
Hello,
Could you please clarify whether Knot can perform a zone transfer not
from the first master listed, but from the one that sent the NOTIFY? The
masters are configured in the following order:
remote:
- id: master
address: [ "192.168.58.151", "192.168.58.134" ]
When a NOTIFY is sent from |192.168.58.134|, the zone transfer is still
performed from |192.168.58.151|.
Here are the relevant log entries:
Apr 25 19:09:25 ubuntu knotd[2065]: info: [chacha.com.] notify,
incoming, remote 192.168.58.134@32888 TCP, serial 2006
Apr 25 19:09:25 ubuntu knotd[2065]: info: [chacha.com.] refresh, remote
192.168.58.151@53, remote serial 2006, zone is outdated
Apr 25 19:09:25 ubuntu knotd[2065]: info: [chacha.com.] IXFR, incoming,
remote 192.168.58.151@53 TCP, receiving AXFR-style IXFR
Apr 25 19:09:25 ubuntu knotd[2065]: info: [chacha.com.] AXFR, incoming,
remote 192.168.58.151@53 TCP, started
Thank you for your product and for your help!
*Best regards,*
*A.A. Basov*
26 Dub
26 Dub
16:19
On Fri, 25 Apr 2025, Alexandr Basov wrote:
Could you please clarify whether Knot can perform a
zone transfer not from
the first master listed, but from the one that sent the NOTIFY? The masters
are configured in the following order:
remote:
- id: master
address: [ "192.168.58.151", "192.168.58.134" ]
When a NOTIFY is sent from 192.168.58.134, the zone transfer is still
performed from 192.168.58.151.
What version of Knot are you using?
See the documentation change from
https://www.knot-dns.cz/docs/3.0/html/configuration.html
"When the server receives a zone update notification from a listed
remote, that remote will be the most preferred one for the subsequent
transfer."
https://www.knot-dns.cz/docs/3.1/html/configuration.html
"When the server receives a zone change notification from a listed
remote, only that remote is used for a subsequent zone transfer."
I didn't try it, but since this says "remote" maybe define multiple
remotes with one remote for each address.
If you always want to exclude doing zone transfers from one, then remove
the IP from the remotes address and then use acl for the the IP with
action: notify. I didn't try that either though.
18:56
Thanks Jeremy, your description is perfect and correct.
Daniel
On 26. 04. 25 18:19, Jeremy C. Reed wrote:
On Fri, 25 Apr 2025, Alexandr Basov wrote:
Could you please clarify whether Knot can perform
a zone transfer not from
the first master listed, but from the one that sent the NOTIFY? The masters
are configured in the following order:
remote:
- id: master
address: [ "192.168.58.151", "192.168.58.134" ]
When a NOTIFY is sent from 192.168.58.134, the zone transfer is still
performed from 192.168.58.151.
What version of Knot are you using?
See the documentation change from
https://www.knot-dns.cz/docs/3.0/html/configuration.html
"When the server receives a zone update notification from a listed
remote, that remote will be the most preferred one for the subsequent
transfer."
https://www.knot-dns.cz/docs/3.1/html/configuration.html
"When the server receives a zone change notification from a listed
remote, only that remote is used for a subsequent zone transfer."
I didn't try it, but since this says "remote" maybe define multiple
remotes with one remote for each address.
If you always want to exclude doing zone transfers from one, then remove
the IP from the remotes address and then use acl for the the IP with
action: notify. I didn't try that either though.
-- 
19:34
On Sat, Apr 26, 2025 at 12:20 PM Jeremy C. Reed <reed(a)reedmedia.net> wrote:
I didn't try it, but since this says "remote" maybe define multiple
remotes with one remote for each address.
There are a few places where I have found the behaviour to be best if I
treat each remote ID as an individual server. One other example in the
handling of zone transfers is when an upstream IP address is unreachable...
a different remote per server allows Knot to try a different remote, where
clustering them all together causes the entire *XFR to fail. So in our
configs, an individual remote gets at most one each of an IPv4 and IPv6
address, and I might even consider splitting _those_ up (as you suggest
above) if you want to handle the case where a server is reachable in one
protocol but not the other.
19:56
That's the right concept of a remote configuration: a server that can be accessed via
one or more (fallback) addresses.
Daniel
On 26. 04. 25 21:34, Matthew Pounsett wrote:
On Sat, Apr 26, 2025 at 12:20 PM Jeremy C. Reed <reed(a)reedmedia.net
<mailto:reed@reedmedia.net>> wrote:
I didn't try it, but since this says "remote" maybe define multiple
remotes with one remote for each address.
There are a few places where I have found the behaviour to be best if I treat each remote
ID as an individual server. One other example in the handling of zone transfers is when
an upstream IP address is unreachable... a different remote per server allows Knot to try
a different remote, where clustering them all together causes the entire *XFR to fail. So
in our configs, an individual remote gets at most one each of an IPv4 and IPv6 address,
and I might even consider splitting _those_ up (as you suggest above) if you want to
handle the case where a server is reachable in one protocol but not the other.
--
20
days inactive
21
days old
4 comments
4 participants
participants (4)
-
Alexandr Basov -
Daniel Salzman -
Jeremy C. Reed -
Matthew Pounsett