[Freeipa-devel] DNS zone serial number updates [#2554]

[Dmitri Pal]

On 04/17/2012 12:13 PM, Simo Sorce wrote:
> On Tue, 2012-04-17 at 17:49 +0200, Petr Spacek wrote:
>> Hello,
>>
>> there is IPA ticket #2554 "DNS zone serial number is not updated" [1], 
>> which is required by RFE "Support zone transfers in bind-dyndb-ldap" [2].
>>
>> I think we need to discuss next steps with this issue:
>>
>> Basic support for zone transfers is already done in bind-dyndb-ldap. We 
>> need second part - correct behaviour during SOA serial number update.
>>
>> Bind-dyndb-ldap plugin handles dynamic update in correct way (each 
>> update increment serial #), so biggest problem lays in IPA for now.
>>
>> Modifying SOA serial number can be pretty hard, because of DS 
>> replication. There are potential race conditions, if records are 
>> modified/added/deleted on two or more places, replication takes some 
>> time (because of network connection latency/problem) and zone transfer 
>> is started in meanwhile.
>>
>> Question is: How consistent we want to be?
> Enough, what we want to do is stop updating the SOA from bind-dyndb-ldap
> and instead update it in a DS plugin. That's because a DS plugin is the
> only thing that can see entries coming in from multiple servers.
> If you update the SOA from bind-dyndb-ldap you can potentially set it
> back in time because last write win in DS.
>
> This will require a persistent sarch so bind-dyndb-ldap can be updated
> with the last SOA serial number, or bind-dyndb-ldap must not cache it
> and always try to fetch it from ldap.
>
>>  Can we accept these 
>> absolutely improbable race conditions? It will be probably corrected by 
>> next SOA update = by (any) next record change. It won't affect normal 
>> operations, only zone transfers.
> Yes and No, the problem is that if 2 servers update the SOA
> independently you may have the serial go backwards on replication. See
> above.
>
>> (IMHO we should consider DNS "nature": In general is not strictly 
>> consistent, because of massive caching at every level.)
> True, but the serial is normally considered monotonically increasing.
>
>> If it's acceptable, we can suppress explicit SOA serial number value in 
>> LDAP and derive actual value from latest modifyTimestamp value from all 
>> objects in cn=dns subtree. This approach saves some hooks in IPA's LDAP 
>> update code and will save problems with manual modifications.
> It will cause a big search though. It also will not take in account when
> there are changes replicated from another replica that are "backdated"
> relative to the last modifyTimestamp.
> Also using modifyTimestamp would needlessly increment the SOA if there
> are changes to the entries that are not relevant to DNS (like admins
> changing ACIs, or other actions like that).
>
>> Persistent search will be (probably) required for effective implementation.
>> I think it's not a problem, because DNSSEC will require (with very high 
>> probability) persistent search for generating NSEC/NSEC3 records.
>>
>> [1] https://fedorahosted.org/freeipa/ticket/2554
>>
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=766233
>>
>>
>> Please, post your opinions about DNS consistency strictness.
> I think we need to try to be more consistent than what we are now. There
> may always be minor races, but the current races are too big to pass on
> IMHO.
>
> Simo.
>

Are you saying that the update should be moved to the DS replication plugin?
Do I get it right?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/