On 03.07.2014 16:47, k...@rice.edu wrote: > On Thu, Jul 03, 2014 at 04:04:43PM +0200, Klaus Darilion wrote: >>> Hi Klaus, >>> >>> We have observed the same behavior here. When it takes longer to perform >>> a zone transfer than the periodic check interval (60s), a second will be >>> initiated with the results that you have reported. We currently time our >>> transfers to make certain that they are timely (<60s) and also watch the >>> table for duplicate zone information and clean up if it occurs. This really >>> should be in PDNS as a flag that a transfer is in progress so it does not >>> even try a second transfer. As you have noted, DB side solutions are less >>> effective and ruin the concurrency of the backend for updates. In >>> particular, >>> we use temporary tables to stage the zone transfer and then only apply the >>> deltas to the production table. This eliminates the wholesale delete of >>> all of the zone records followed by its complete repopulation for even a >>> single record change. But temporary tables are only seen in the transaction >>> that created them, in our case, so a check in the server code would really >>> help. The comment in the code requires the backend to handle it: >>> >>> - only one backend owns the SOA of a zone >>> - only one AXFR per zone at a time - double startTransaction should fail >>> - backends need to implement transaction semantics >>> >>> with the results already seen if a second transfer is initiated. Yuck, it >>> really needs to be tracked by the server instead. +1 for bug but we have >>> been working around it for years. It is more of a problem with DNSSEC, >>> because of the additional processing needed which slow the transfers and >>> makes them more susceptible to this. >> >> Hi Ken! >> >> Which backend are you using? (we use gpgsql) >> >> If I understand you correct you also have troubles on zone updates. This >> is not the case in our setup: with 2 concurrent transfers/transactions >> the first DELETE will cause a row lock on the old RRs. Thus, the DELETE >> in the second transaction will be delayed until the first transaction is >> committed. Thus, we have the problem only on the very first transfer. >> >> I also think that performing multiple transfers for the same zone should >> be avoided in the application. >> >> regards >> Klaus >> > > Hi Klaus, > > We use gpgsql as well. We only have problems on the initial transfer of > the zone because there are no existing records in the domain. Then if > multiple AXFRs are started, records can be duplicated. Once the zone has > been populated, the delta logic prevents anymore duplication of records.
I think your delta-logic is not needed to prevent duplications. (but there may be other reasons why you need the delta logic) regards Klaus _______________________________________________ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
