[Pdns-users] Duplicate RRs in records table

[Klaus Darilion]

On 03.07.2014 16:47, ktm at 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