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

[Simo Sorce]

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.

-- 
Simo Sorce * Red Hat, Inc * New York