29 Srp
2014
29 Srp
'14
9:26
Hello Johan,
On 08/28/2014 09:58 PM, Johan Ihrén wrote:
I think it depends on how one modifies his zone. From BIND 9.9 ARM,
section 4.3:
When acting as a master, BIND 9 supports IXFR for those zones where the
necessary change history information is available. These include master
zones maintained by dynamic update and slave zones whose data was
obtained by IXFR. For manually maintained master zones, and for slave
zones obtained by performing a full zone transfer (AXFR), IXFR is
supported only if the option ixfr-from-differences is set to yes.
So it seems for the manual zone file change + rndc reload combo you
still need ixfr-from-differences enabled, but I'll admit I haven't
tested this. I did not know BIND can create IXFRs from diffs between
AXFRs, that's an interesting feature we might add to Knot.
Hi,
On 20 Aug 2014, at 13:13 , Jan Kadlec <jan.kadlec(a)nic.cz> wrote:
You're definitely right that this should not be treated as error (and
this goes to any error during IXFR I suppose), because indeed there are
cases when AXFR-style IXFR response is valid, Knot sends such responses
as well. Our reasoning here was that this should happen rarely when
things are set up properly, and, more importantly, we did not want to
bloat the IXFR processing code. Nevertheless, we will fix this in the
upcoming update.
this is common when Bind sends AXFR when Knot
asked for IXFR. Does this happen often?
Note that according to protocol the sender is allowed to respond with an AXFR if is so
chooses. This is obviously needed, because the sender can not know in advance how much
history it needs to keep (i.e. when a slave requests an IXFR it could be two versions
behind or two thousand versions behind). Hence the sender keeps as much history as it
feels like / has memory for / is configured to / whatever, and if an IXFR request is for a
larger delta then an AXFR will be sent.
Eg. this is not an error and should not be flagged as such.
It's
been a while since I had to configure Bind, but I think you have to explicitly enable IXFR
(ixfr-from-differences option and journal) or it will just send AXFRs for all requests.
That is not correct. BIND9 will use IXFRs automatically in most cases. The
ixfr-from-differences is only needed in cases like:
PM -- S1 -- S2
Where "PM" (for whatever reason) only provides AXFR (to S1) and S1 then only
will provide AXFR to S2 *unless* configured to do "ixfr-from-differences", in
which case S1 will compute all the IXFR diffs needed.
Regards,
Johan
Thanks for your input.
Regards,
Jan
How does the log file look on Bind's side?
On 08/20/2014 12:58 PM, Jakub Štollmann wrote:
Hello,
I have recently upgraded our knot to 1.5.0. Then I noticed error
messages coming from server
Aug 20 05:50:31 knot-test knot[3723]: Incoming IXFR of 'domain.cz' from
'192.168.122.193@53': Starting.
Aug 20 05:50:31 knot-test knot[3723]: [error] Incoming IXFR of
'domain.cz' from '192.168.122.193@53': Failed - Malformed data.
Aug 20 05:50:31 knot-test knot[3723]: [notice] IXFR of 'domain.cz.' with
'192.168.122.193@53': Fallback to AXFR.
I've done some debugging (I didnt find any more info), I also reproduced
this on 2 virtual servers.
My Configuration:
Bind master (tried 9.8.4, 9.7.3) <-> Knot slave (tried 1.5.0, 1.5.1)
allowed ixfr
I dont know if its an error in knot or bind.
AXFR works fine
Thanks for any advices.
Regards
Jakub Stollmann
LiveSport s.r.o.
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users