IXFR fallback to AXFR if diff is bigger than zone

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

IXFR fallback to AXFR if diff is bigger than zone

Klaus Darilion
Hi!

I wonder how Bind as master handles IXFR when the requested IXFR would
be much than the AXFR. (For example: if you change the NSEC3 salt).

Are there some mechanisms to detect such a situation and trigger a
fallback to AXFR or will Bind always perform IXFR?

thanks
Klaus

PS: AFAIK the max journal size is 2 GB. In my case, the IXFR due to
NSEC3 salt changes is around 2.5GB. So actually I am surprised that such
big updates can be handled as IXFR.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: IXFR fallback to AXFR if diff is bigger than zone

Tony Finch
Klaus Darilion <[hidden email]> wrote:
>
> I wonder how Bind as master handles IXFR when the requested IXFR would
> be much than the AXFR. (For example: if you change the NSEC3 salt).
>
> Are there some mechanisms to detect such a situation and trigger a
> fallback to AXFR or will Bind always perform IXFR?

No. It's only relatively recently that BIND has been able to keep track of
the zone size (which is used for the max-records safety limit) and the
IXFR code has not been taught how to use this information to fall back to
AXFR when that would make sense.

> PS: AFAIK the max journal size is 2 GB.

Not since 9.12 :-) I fixed it so that the default journal size limit is 2x
the zone size. The journal is reduced to half size when it is compacted,
so this limit is enough to support IXFR in any case where it might be
beneficial, but it also supports oversize IXFRs.

> In my case, the IXFR due to NSEC3 salt changes is around 2.5GB. So
> actually I am surprised that such big updates can be handled as IXFR.

Yes, that is curious. Are you sure it isn't actually doing an
IXFR-flavoured AXFR of the whole zone, rather than a delta?

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Gibraltar Point to North Foreland: Northerly or northwesterly 3 or 4,
occasionally 5 at first, becoming variable for a time in Thames estuary.
Smooth or slight. Thundery showers at first, fog patches for a time later in
north. Moderate or good, occasionally very poor for a time later in north.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: IXFR fallback to AXFR if diff is bigger than zone

Klaus Darilion
Hi Tony!

Am 12.07.2019 um 13:00 schrieb Tony Finch:
> Yes, that is curious. Are you sure it isn't actually doing an
> IXFR-flavoured AXFR of the whole zone, rather than a delta?

We have a setup with severals Bind in a row:

hidden master
customer
(software unknown)
        |
        |
        V
our incoming nameserver
Bind 9.9.5
        |
        |
        V
our distribution nameserver
Bind 9.9.5
        |
        |
        V
our anycast nameserver
Bind 9.11.3+dfsg-1ubuntu1.8

According to our logs, the was no IXFR-style AXFR. The IXFR from the
customer to us was around 1.87GB (at least on the wire).

From our "incoming" nameserver to our "distribution" nameserver, and
from there to our Anycast node it was around 2.37G.

See log details below.

Thanks
Klaus
       

09:30:55.119017+00:00 incoming: zone example/IN: notify from
1.1.1.18#40718: refresh in progress, refresh check queued
09:30:55.681438+00:00 incoming: zone example/IN: Transfer started.
09:30:55.775361+00:00 incoming: transfer of 'example/IN' from
1.1.1.18#53: connected using 2.2.2.6#58024
09:39:58.568221+00:00 incoming: zone example/IN: transferred serial
2019051621: TSIG 'foo'
09:39:58.568634+00:00 incoming: transfer of 'example/IN' from
1.1.1.18#53: Transfer completed: 117626 messages, 27995004 records,
1873889978 bytes, 542.793 secs (3452310 bytes/sec)
09:39:58.570937+00:00 incoming: zone example/IN: sending notifies
(serial 2019051621)
09:39:59.573796+00:00 incoming: client 2.2.2.4#49520/key foo (example):
transfer of 'example/IN': IXFR started: TSIG foo
09:42:55.240267+00:00 incoming: client 2.2.2.4#49520/key foo (example):
transfer of 'example/IN': IXFR ended


09:39:59.573447+00:00 distribution: transfer of 'example/IN' from
2.2.2.6#53: connected using 2.2.2.4#49520
09:43:02.203543+00:00 distribution: zone example/IN: transferred serial
2019051621: TSIG 'foo'
09:43:02.203646+00:00 distribution: transfer of 'example/IN' from
2.2.2.6#53: Transfer completed: 36596 messages, 12744969 records,
2370686132 bytes, 182.630 secs (12980814 bytes/sec)
09:43:02.205126+00:00 distribution: zone example/IN: sending notifies
(serial 2019051621)
09:43:05.903528+00:00 distribution: client 3.3.3.23#52515 (example):
transfer of 'example/IN': IXFR started
09:49:34.058714+00:00 distribution: client 3.3.3.23#52515 (example):
transfer of 'example/IN': IXFR ended



09:43:04.766583+00:00 anycast: zone example/IN: notify from
2.2.2.4#7332: serial 2019051621
09:43:04.836184+00:00 anycast: zone example/IN: Transfer started.
09:43:05.891331+00:00 anycast: transfer of 'example/IN' from 2.2.2.4#53:
connected using 3.3.3.23#52515
09:49:41.251490+00:00 anycast: zone example/IN: transferred serial
2019051621
09:49:41.251719+00:00 anycast: transfer of 'example/IN' from 2.2.2.4#53:
Transfer status: success
09:49:41.251812+00:00 anycast: transfer of 'example/IN' from 2.2.2.4#53:
Transfer completed: 36573 messages, 12744969 records, 2367460025 bytes,
395.360 secs (5988112 bytes/sec)

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users