[Freeipa-devel] DNS zone serial number updates [#2554]: local SOA approach

[Adam Tkac]

On Mon, May 07, 2012 at 10:29:12PM +0200, Petr Spacek wrote:
> Hello,
> 
> on the last meeting there was another approach to $SUBJ$ discussed:
> 
> Each DNS server will maintain its own serial number value
> independently from other servers.
> 
> Pros:
> Should be simpler to implement; no DS plugin required.
> 
> Cons:
> Slave DNS servers cannot fall-back to other masters, because of SOA
> serial inconsistency.
> 
> 
> Very basic implementation:
> 1) Do not replicate idnsSoaSerial attribute
> 2) Use persistent search to watch for incoming changes
> 3) After each change increment "local" SOA serial number (and write
> it to LDAP - to survive DNS server restart)
> 
> There is a problem with database updates if bind-dyndb-ldap plugin
> is not running, but "its" DS runs. In that case DS can replicate
> changes from other servers but there is no bind-dyndb-ldap plugin to
> modify serial number.
> 
> I think it can happen during startup/shutdown phase or after BIND
> crash. In this case zone content can be changed without appropriate
> SOA serial update.
> 
> Dumb solution:
> Always increment stored SOA serial number after DNS server start. It
> causes unnecessary zone transfer, but we are safe.
> 
> Another solution (IPA+389 specific):
> Remember max(entryUSN) value computed from all records together with
> SOA serial. (Principle is the same as with modifyTimestamp described
> earlier in this thread.) It requires new LDAP object with two
> attributes:
> - assigned value of idnsSOASerial
> - highest entryUSN found
> DNS server after start can check if max(entryUSN) == recorded max
> value. If values do not match plugin bumps idnsSOASerial.
> 
> If entryUSN is not supported by server, we can fall-back to bumping
> idnsSOASerial on every start-up.
> 
> Did I miss anything? :-)
> 
> It requires persistent search, but I resigned already.

After further discussion this seems like the best approach for me as well.

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.