[Pdns-users] Duplicate RRs in records table

[Klaus Darilion]

On 03.07.2014 14:56, ktm at rice.edu wrote:
> On Thu, Jul 03, 2014 at 02:01:49PM +0200, Klaus Darilion wrote:
>> Another workaround (untested) would be to put an explicit lock at the
>> beginning of the "delete-zone-query":
>> delete-zone-query="LOCK;delete from records where domain_id=%d"
>>
>> But (if it is allowed to have multiple statements in the
>> delete-zone-query command) it would lock the whole table also for all
>> zone updates which is probably bad for the performance.
>>
>> regards
>> Klaus
>>
> 
> 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