On 05/25/2012 02:41 PM, Adam Tkac wrote:
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

The original RFE reporter is not comfortable with the proposed solution (local SOA serials). Can somebody judge seriousness of these objections?

The latest discussion from BZ https://bugzilla.redhat.com/show_bug.cgi?id=766233 follows:

Comment 18 Brian J. Atkisson 2012-05-25 11:51:26 EDT wrote:

Hrm I replied on 5/9 and don't see the answer posted to bugzilla.  In any case:


Is it acceptable to have SOA serial numbers only locally significant? (I.e.  
each DNS master (= IPA server with DNS) will have different SOA serial number 
for given zone.)

This would cause problems for non-IPA slaves performing zone transfer.
All the serial numbers should be in sync across the IPA masters.

For example, in a corporate environment, where they maybe one department
using plain bind to host lab zones from corporate IT running IPA
Different labs will have different zone versions based upon those labs
pointing to regional IPA servers.

Also, it would be problematic in environments where a plain old Bind server 
does zone transfers from IPA servers in a fail-over/load-balanced config.

Comment 19 Petr Spacek 2012-05-28 06:45:42 EDT wrote:
Comment 18 Brian J. Atkisson 2012-05-25 11:51:26 EDT wrote:
Hrm I replied on 5/9 and don't see the answer posted to bugzilla.  In any
case:


> Is it acceptable to have SOA serial numbers only locally significant? (I.e.  
each DNS master (= IPA server with DNS) will have different SOA serial number for 
given zone.)

This would cause problems for non-IPA slaves performing zone transfer.
All the serial numbers should be in sync across the IPA masters.
Of course, generally you are right. But IPA violates classical single-master DNS model 
and we search for some trade-offs. (For example RFC 5936 
http://tools.ietf.org/html/rfc5936#section-3.1 says "don't do it".)
Question should be: "Is there real configuration where it matters?"


For example, in a corporate environment, where they maybe one department
using plain bind to host lab zones from corporate IT running IPA
Different labs will have different zone versions based upon those labs
pointing to regional IPA servers.
I'm probably missing something, I don't see the problem. Different IPA servers 
will serve same data (when LDAP replication settles down), only SOA serial 
number will be different. Each plain BIND will see and serve exactly same zone 
except serial number.


Also, it would be problematic in environments where a plain old Bind server
does zone transfers from IPA servers in a fail-over/load-balanced config.
Yes, I agree. It's known problem of "local SOA serial" approach. Is described 
configuration deployed anywhere? Probably this problem can be partially alleviated with 
"tree" of DNS slaves or something similar.

Petr^2 Spacek

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

Reply via email to