[Pdns-users] strange bevaviour of serial increasing

[Gert van Dijk]

On Thu, Apr 25, 2019 at 4:38 PM Frank Altpeter <frank.altpeter at gmail.com>
wrote:

> Well, first of all, I was indeed thinking that the default-soa-edit value
> has to be set equally on both sides. So after removing this setting from
> the slave part of the problem has been magically removed.
>
> # pdnsutil increase-serial einhorn.bar
>  SOA serial for zone einhorn.bar set to 2019042506
>
> # dig +short +noshort @{master,slave} einhorn.bar SOA
> einhorn.bar. 3600 IN SOA ns1.foxalpha.de. frank.altpeter.de. 2019042508
> 10800 3600 604800 3600
> einhorn.bar. 3600 IN SOA ns1.foxalpha.de. frank.altpeter.de. 2019042508
> 10800 3600 604800 3600
>

That looks good (consistent) to me. :-)


> But they still don't match the value in the database. I also don't get the
> increment of two.
>

You've applied a soa-edit, so of course they don't match the database
backend - that's what the soa-edit setting does in the first place - real
time edits of the serial *on answer*. If you want to serve them unedited,
don *not* use this setting. I'm still confused as to what you're trying to
achieve with this setting (more at the bottom of this reply).

Also, I'm not sure why this happens to unsigned zones, since there are two
> settings "default-soa-edit" and "default-soa-edit-signed", so if this
> increment is something needed for signed zones, why do both settings cause
> it?
>

IIUC, default-soa-edit applies to all zones, default-soa-edit-signed
overrides the default-soa-edit setting for zones which are signed. Apart
from that, zones can be individually configured with a specific soa-edit
configuration, but only one soa-edit transformation is performed by a
single server. Although soa-edit is only required for DNSSEC to trigger a
refresh of the signatures on slaves, it would stop you from unsigning a
zone, because it would decrease the serial by a huge number. In order to
allow you to unsign a zone, you could set default-soa-edit to apply it to
any zone regardless of the sign state, but then you'll have to manually
update the serial once you activate DNSSEC for it. But perhaps there are
more use cases for having a soa-edit setting on multiple levels.
(I'm not sure if that answers your question?)


> The reason for this setting is that I like my serials to be in the format
> YYYYMMDDSS
>

They are already in that format in your backend, so what do you expect from
PowerDNS here?


> - and as long as I got the documentation correct, the increase-serial does
> increase by 1 when there is no soa-edit set (globally or in domain
> metadata).
>

I am unable to find information regarding the pdnsutil subcommand
'increase-serial' - it's not in the manpage at least. What documentation
are you looking at exactly? Anyway, I believe a serial increment by
pdnsutil would be applied as if your serial is an integer, it's not aware
of the format you use IIUC.


> I have set this because I wanted to prevent my zones (for example) to
> update from 2019042508 to 2019042509 tomorrow (because it's supposed to be
> 2019042601 then).
>

But your current soa-edit configuration does exactly what you're trying to
prevent. To quote the example from the docs: "This changes a serial of
2015120810 to 2016010701 on Wednesday 13th of January 2016.". (note the
last part, 13, will be translated to 07)


> I wasn't able to find out how to create this behaviour without having
> soa-edit set to inception-increment.
>

Are you looking for a way to automatically increase the serial for you *on
edit* in the YYYYMMDDSS format? Or even without edits? Or... when? And to
update the serial in the backend?

Either way, although I still don't quite understand what you're expecting
from PowerDNS here I want to point out the following. IIUC, there's only
one use case of the soa-edit setting - using DNSSEC with non-PowerDNS
slaves to keep RRSIGs fresh everywhere and this seems not something that
matches your situation/requirements.

HTH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20190425/56a96bcc/attachment.html>