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

[Petr Spacek]

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.


Petr^2 Spacek



P.S.: There is a pretty new RFC about zone transfers with "very nice" 
simplification:

http://tools.ietf.org/html/rfc5936#section-3.1
...
Zones for which it is impractical to list the entire zone for a
serial number are not suitable for AXFR retrieval.  A typical (but
not limiting) description of such a zone is a zone consisting of
responses generated via other database lookups ...