diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 568bbea0c5..5924f702e7 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -2725,11 +2725,8 @@ TODO The b10-xfrin process supports both AXFR and - IXFR. Due to some implementation limitations of the current - development release, however, it only tries AXFR by default, - and care should be taken to enable IXFR. + IXFR. -
Configuration for Incoming Zone Transfers @@ -2763,34 +2760,82 @@ TODO > config set Xfrin/zones[0]/tsig_key ""
-
- Enabling IXFR +
+ Control the use of IXFR - As noted above, b10-xfrin uses AXFR for - zone transfers by default. To enable IXFR for zone transfers - for a particular zone, set the use_ixfr - configuration parameter to true. - In the above example of configuration sequence, you'll need - to add the following before performing commit: - > config set Xfrin/zones[0]/use_ixfr true + By default, b10-xfrin uses IXFR for + transferring zones specified in + the Xfrin/zones list of the configuration, + unless it doesn't know the current SOA serial of the zone + (including the case where the zone has never transferred or + locally loaded), in which case it automatically uses AXFR. + If the attempt of IXFR fails, b10-xfrin + automatically retries the transfer using AXFR. + In general, this works for any master server implementations + including those that don't support IXFR and in any local state + of the zone. So there should normally be no need to configure + on whether to use IXFR. - - - One reason why IXFR is disabled by default in the current - release is because it does not support automatic fallback from IXFR to - AXFR when it encounters a primary server that doesn't support - outbound IXFR (and, not many existing implementations support - it). Another, related reason is that it does not use AXFR even - if it has no knowledge about the zone (like at the very first - time the secondary server is set up). IXFR requires the - "current version" of the zone, so obviously it doesn't work - in this situation and AXFR is the only workable choice. - The current release of b10-xfrin does not - make this selection automatically. - These features will be implemented in a near future - version, at which point we will enable IXFR by default. - + + In some cases, however, it may be desirable to specify how and + whether to use IXFR and AXFR. + The request_ixfr configuration item under + Xfrin/zones can be used to control such + policies. + It can take the following values. + + + + yes + + + This is the default behavior as described above. + + + + + no + + + Only use AXFR. Note that this value normally shouldn't + be needed thanks to the automatic fallback from IXFR to IXFR. + A possible case where this value needs to be used is + that the master server has a bug and crashes if it + receives an IXFR request. + + + + + only + + + Only use IXFR except when the current SOA serial is not + known. + This value has a severe drawback, that is, if the master + server does not support IXFR zone transfers never + succeed (except for the very first one, which will use AXFR), + and the zone will eventually expire. + Therefore it should not be used in general. + Still, in some special cases the use of this value may + make sense. For example, if the operator is sure that + the master server supports IXFR and the zone is very + large, they may want to avoid falling back to AXFR as + it can be more expensive. + + + + + + + + There used to be a boolean configuration item named + use_ixfr. + It was deprecated for the finer control described above. + The request_ixfr item should be used instead. + + +