[bind10-dev] Is AXFR/IXFR needed for DB-based (especially large) zones?

[Stephen Morris]

On 11/06/2011 01:32, JINMEI Tatuya / 神明達哉 wrote:

> A most straightforward answer would be to implement and use AXFR/IXFR
> on top of these zones, but as I said in a separate thread, AXFR(-out)
> doesn't seem to be realistic for a huge zone:
> 
>  - to ensure the consistency the primary server (the "server" side of
>    AXFR) needs to lock the database (or at least the relevant table)
>    until it gets all records of a particular serial to be transferred.
>  - if the primary server does this while sending AXFR responses, it
>    may take very long time (like tens of minutes), depending on the
>    size of zone, network bandwidth, responsiveness of the secondary
>    server.  During that period no updates can be made on the database.
>  - the primary server could first retrieve all records in-memory, at
>    which point the lock can be released, and then send AXFR responses
>    from the in-memory copy.  This may still take long time (like
>    several minutes), depending on (again) the size of the zone and
>    communication overhead of the DNS and DB servers.  For a huge zone,
>    there's another concern of whether available memory is sufficient.

Another possibility would be to create a duplicate of the relevant table
within the database and do the transfer from that.

It is possible to envisage a system where the transaction that updates
the main table also creates a new duplicate of it.  So when the new
serial is finally published, the duplicate table is immediately
available to handle AXFRs.

Of course, I can imagine all sorts of problems with indexes and the like...

Stephen