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/ _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel