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

[Dmitri Pal]

On 04/18/2012 09:20 AM, Simo Sorce wrote:
> On Tue, 2012-04-17 at 18:42 -0400, Dmitri Pal wrote:
>> 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?
> not the DS replication plugin per se. But probably the best way to
> handle it is 'a' DS plugin.
>
> Simo.
>
I am not sure I follow. It is not clear to me how a DS plugin (if it is
not a replication plugin) will help with the race condition that might
be caused by changes made on different servers. The entries that were
added on the other servers go only through the replication plugin. To
the best of my knowledge the normal stack of plugins is not invoked for
those entries as this stack is called when the entry is created in the
first place on the other replica.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


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