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 ...

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to