[Pdns-users] Duplicate RRs in records table

[ktm at rice.edu]

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.

Regards,
Ken