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

Thu May 31 14:05:36 UTC 2012

On Thu, 2012-05-31 at 12:36 +0200, Petr Spacek wrote:
> 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:

Those objections are serious, but I do not think they necessarily have
the weight to turn down the proposed solution.
As you noted in the bugzilla it is a tradeoff, and we are adding
functionality (multi-master DNS servers) not normally available.

Bind servers cannot attach to multiple master servers, bind understand
only a single master so normally slaves will be connected to a specific
IPA server which acts as their master.
For these server the serial does not change arbitrarily, it is always
the same.

The load balancer objection is bogus imo, the reason you add slaves is
to spread the load, and I've never seen load balanced DNS masters, for
the simple reason that Bind does not understand having multiple masters.

So all in all I still think that having a local SOA is the most
effective solution.

If there are major concerns what we can do is to keep using the date
format (we loose a bit of granularity I guess, but that shouldn't be a
big deal), so that on average all masters will be pretty close and at
most you'll have to wait a couple of seconds to have a SOA that is
greater than what a previous master had.

> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

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