BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-01-29T13:18:05Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1515Send AXFR instead of requested IXFR if the size of the incremental transfer i...2021-01-29T13:18:05ZCathy AlmondSend AXFR instead of requested IXFR if the size of the incremental transfer is too large to sensibly IXFRThis perhaps needs to be an option that can be set globally, per view, per zone, and perhaps by allow-transfer ACLs?
Background: [Support ticket #15857](https://support.isc.org/Ticket/Display.html?id=15857) and [Support ticket #15075](...This perhaps needs to be an option that can be set globally, per view, per zone, and perhaps by allow-transfer ACLs?
Background: [Support ticket #15857](https://support.isc.org/Ticket/Display.html?id=15857) and [Support ticket #15075](https://support.isc.org/Ticket/Display.html?id=15075)
Large inbound IXFRs can seriously degrade a BIND slave nameserver's performance when serving clients (not necessarily from the same zones being transferred) at the same time. The slave can't control the size of the IXFR when requesting it - it doesn't know what it is going to be sent. This is therefore something that has to be set on the authoritative server that is sending the zone update.March 2020 (9.11.17, 9.16.1, 9.17.0)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1375Improve zone transfer logging to always include an identifying serial number ...2020-03-06T02:51:21ZCathy AlmondImprove zone transfer logging to always include an identifying serial number so that starts and ends can be matched by log parsersThe problem statement/use case is this
```
...we use Splunk to ingest all transfer logs on the distribution
masters...and neither Splunk nor our "SOA serial Sync" monitoring in
Nagios(icinga) see large spikes when it comes to zone distr...The problem statement/use case is this
```
...we use Splunk to ingest all transfer logs on the distribution
masters...and neither Splunk nor our "SOA serial Sync" monitoring in
Nagios(icinga) see large spikes when it comes to zone distribution times.
(We would, however, like to request that you modify BIND logging to
include the zone serial in the 'IXFR ended' line...as the tokens we're
matching on to link start/end sometimes cause false spikes when the
random port and the random client id match with previous events... :)
```
This is from [Support ticket #15075](https://support.isc.org/Ticket/Display.html?id=15075)
It's possible that some of this difficulty relates to #1009 (now fixed) wherein all endings are logged, but some zone transfer starts are missing. But nevertheless, I don't see that serial numbers are logged on zone transfer endings, just this (from the inbound transfer server's PoV):
```c
/*
* Calculate the length of time the transfer took,
* and print a log message with the bytes and rate.
*/
isc_time_now(&xfr->end);
msecs = isc_time_microdiff(&xfr->end, &xfr->start) / 1000;
if (msecs == 0)
msecs = 1;
persec = (xfr->nbytes * 1000) / msecs;
xfrin_log(xfr, ISC_LOG_INFO,
"Transfer completed: %d messages, %d records, "
"%" PRIu64 " bytes, "
"%u.%03u secs (%u bytes/sec)",
xfr->nmsg, xfr->nrecs, xfr->nbytes,
(unsigned int) (msecs / 1000), (unsigned int) (msecs % 1000),
(unsigned int) persec);
```March 2020 (9.11.17, 9.16.1, 9.17.0)Evan HuntEvan Hunt