[Opendnssec-develop] Re: [OpenDNSSEC] #31: keepcounter serial option

[OpenDNSSEC]

#31: keepcounter serial option
----------------------------------------+-----------------------------------
Reporter:  opendnssec.simon at arlott.org  |        Owner:  matthijs
    Type:  enhancement                  |       Status:  closed  
Priority:  minor                        |    Component:  Signer  
 Version:  trunk                        |   Resolution:  fixed   
Keywords:                               |  
----------------------------------------+-----------------------------------

Comment(by matthijs):

 Replying to [comment:5 opendnssec.simon at arlott.org]:
 > I'm only using the keepcounter version, so it won't affect me, but
 counter is distinct from keepcounter.

 notice that the keyword keepcounter will dissappear. The counter will get
 the behavior of keepcounter.

 > If it's not used carefully (e.g. input serial stays at "1" forever),
 then eventually it will change meaning from being behind the output serial
 to being ahead of the output serial. When this happens, the output serial
 will jump forward the maximum possible amount and any slave nameservers
 that miss that update will become out of sync.

 I have added rfc 1982 support to cover that.

 >
 > If the input serial is always 1, then the output serial will be:
 2147483648 (after 1), 2147483649 (equal to 1), 2147483650 (before 1), 1,
 2, 3.

 If the input serial is always one, it is ignored because the output serial
 will always be larger.

 > If a slave nameserver misses the updates when this happens, it'll look
 like the master has an old serial.

 If all the NOTIFY stuff works, the slave nameserver would not miss it. If
 it does miss it (what are the odds?), it will eventually expire and stop
 serving it's old dns data. According to the specification, the secondary
 has to discard the obsoleted zone and do a fresh transfer.

 >
 > The behaviour of "keepcounter" requires that the input and output
 serials will not get too far out of sync. If the zone is going to change
 frequently (perhaps because it has many thousands of RRs that will need to
 be resigned) and the input serial is rarely changed, or is changed at a
 different rate from the output serial (input+1 for every new/changed RR
 will not be the same as the output+1 for every re-signed RR), then this
 could happen... but it does require over 2 billion re-signings of the
 zone.

 As I said, what are the odds. And the impact is imo not that big and will
 restore automatically.

 >
 > The correct serial in this case would of course be "unixtime", but that
 may not be obvious, and a pure "count + 1 on each change" might be
 desired, which is no longer possible.

 If someone wants a pure count + 1, they can do that and leave the input
 serial unchanged.

-- 
Ticket URL: <http://trac.opendnssec.org/ticket/31#comment:6>
OpenDNSSEC <http://www.opendnssec.org/>
OpenDNSSEC