[Pdns-users] strange bevaviour of serial increasing

Thu Apr 25 15:59:35 UTC 2019

Hi,

Am Do., 25. Apr. 2019 um 17:31 Uhr schrieb Gert van Dijk <
gertvdijk+pdns-users at gmail.com>:

> 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).
>
aye.

> 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?)
>

Partially. I understand the setting is mostly interesting when having
signed zones to make sure the dnssec keys are being transferred to the
slaves without having to bother with the zone content (and the serial)
itself.

>
>
>> 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?
>

Well, I was thinking (obviously wrong) that when I set this setting, I make
sure that the "increase-serial" mechanism increases the serial by YYMMDDxx
- so the serial tomorrow would be 2019042601 instead of 2019042512 and so
on, like using the current date plus a two-digit increment instead of a 10
digit increment.

>
>
>> - 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.
>
>
That's funny...

 root at murphy:~ 0# pdnsutil --version
pdnsutil 4.1.8
root at murphy:~ 0# pdnsutil --help|grep -i increase
increase-serial ZONE               Increases the SOA-serial by 1. Uses
SOA-EDIT
secure-all-zones [increase-serial] Secure all zones without keys
root at murphy:~ 0#

I use it to increase the serial by 1 after editing a zone with "pdnsutil
edit-zone" instead of manually editing the SOA while editing the zone. And
so far the serial has been set to the today's date when SOA-EDIT was set to
INCEPTION-INCREMENT. That's why I thought I had to set it. Of course it's
likely possible that I completely misunderstood parts of the documentation
about that topic.

Here as another example what I was doing here:

root at murphy:~ 0# pdnsutil show-zone larpix.de
This is a Master zone
Last SOA serial number we notified: 2018050301 == 2018050301 (serial in the
database)
Zone is not actively secured

As you see the current SOA of this test domain is set to 2018/05/03 with 01
as counter. Now I increment it:

root at murphy:~ 0# pdnsutil increase-serial larpix.de
SOA serial for zone larpix.de set to 2018050302

Counter is up by 1, so far. But still 2018/05/03. This was - in my opinion
- wrong, so I did set SOA-EDIT for the domain:

root at murphy:~ 1# pdnsutil set-meta larpix.de SOA-EDIT INCEPTION-INCREMENT
Set 'larpix.de' meta SOA-EDIT = INCEPTION-INCREMENT

After that, the requested behaviour was in place:

root at murphy:~ 0# pdnsutil increase-serial larpix.de
SOA serial for zone larpix.de set to 2019042501

root at murphy:~ 0# pdnsutil show-zone larpix.de
This is a Master zone
Last SOA serial number we notified: 2019042501 == 2019042501 (serial in the
database)

You see, now the serial gets not just incremented by 1, but reset to the
current day. And not just in the axfr output, but in the database. The real
serial is now 2019/04/25 with 01 as incremental value. That's what I wanted
in the first place.

Because of this behaviour, I came to the decision to set SOA-EDIT globally
because I didn't want that to manually set on every domain. It took some
time to learn that I introduced other problems with that, like the one that
made me start this thread.

And, as I wrote, I assumed that setting SOA-EDIT would tell the
increase-serial command to

> 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?
>

Yep - but as far as I know there's no (or not yet) such a feature :)

> 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.
>

that's correct. For now I disabled that setting on all systems and have a
look how it behaves now the next days. anyway thanks a lot for your time
and help.

Le deagh dhùraghd,

        Frank Altpeter

-- 
FA-RIPE || https://about.me/frank.altpeter/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20190425/80fe326d/attachment-0001.html>