[Freeipa-devel] DNS zone serial number updates [#2554]

[Adam Tkac]

On Wed, Apr 18, 2012 at 11:53:24AM -0400, Simo Sorce wrote:
> On Wed, 2012-04-18 at 17:21 +0200, Petr Spacek wrote:
> 
> > > If this happens, it is possible that on one of the masters the serial
> > > will be updated twice even though no other change was performed on the
> > > entry-set. That is not a big deal though, at most it will cause a
> > > useless zone transfer, but zone transfer should already be somewhat rate
> > > limited anyway, because our zones do change frequently due to DNS
> > > updates from clients.
> > SOA record has also refresh, retry and expiry fields. These define how often 
> > zone transfer should happen. It's nicely described in [8].
> 
> Sure but we have 2 opposing requirements. On one hand we want to avoid
> doing too many transfers too often. On the other we want to reflect
> dynamic Updates fast enough to avoid stale entries in the slaves. So the
> problem is that we need to carefully balance and tradeoff.

Just FYI, BIND has some limits set by default. BIND slaves don't transfer zone
more than once for 5 minutes (the "min-refresh-time" named.conf parameter).
So even when you modify zone often, BIND slave just fetches all updates after
5 minutes. If the SOA's "refresh" attribute is lower than "min-refresh-time"
option, the "min-refresh-time" is used.

> > >> There are still problems to solve without DS plugin (specifically
> > >> mapping/updating NN part from YYYYMMDDNN), but: Sounds this reasonable?
> > >
> > > Well I am not sure we need to use a YYYYMMDDNN convention to start with.
> > > I expect with DYNDNS updates that a 2 digit NN will never be enough,
> > > plus it is never updated by a human so we do not need to keep it
> > > readable. But I do not care eiither way, as long as the serial can
> > > handle thousands of updates per day I am fine (if this is an issue we
> > > need to understand how to update the serial in time intervals).
> > Current BIND implementation handles overflow in one day gracefully:
> > 2012041899 -> 2012041900
> > So SOA# can be in far future, if you changes zone too often :-)
> 
> Sure, but then what's the point of keeping it in date format ? :-)
> 
> > AFAIK this format is traditional, but not required by standard, if arithmetic 
> > works. [9] defines arithmetic for SOA serials, so DS plugin should follow it.
> > 
> > It says "The maximum defined increment is 2147483647 (2^31 - 1)"
> > This limit applies inside to one SOA TTL time window (so it shouldn't be a 
> > problem, I think). I didn't looked into in this RFC deeply. Some practical 
> > recommendations can be found in [10].
> 
> Yeah 2^31 is large enough for practical deployments if you start small,
> if you start close to the top (2012 is not the far from 2147) then you
> have substantially reduced the window.

I think the easiest way is not to use serial in date format. We can simply
create zone with serial "1" and then increment it every time when we modify the
zone.

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.