20 Led
2022
20 Led
'22
14:03
Hi,
For many months now, we've been preparing new signers for our internal
zones and eventually .is.
We've got the first of our test zones live on the production signers,
but some things are troubling us.
This is the config we're using for zones:
template:
- id: default
semantic-checks: on
storage: "/usr/local/etc/knot"
file: "zones/unsigned/%s/%s-soa"
serial-policy: dateserial
zonefile-sync: -1
zonefile-load: difference-no-serial
journal-content: all
notify: hidden_primary
acl: hidden_primary_acl
policy:
- id: isnic
algorithm: RSASHA256
ksk-size: 4096
zsk-size: 2048
ksk-lifetime: 365d
zsk-lifetime: 30d
propagation-delay: 1h
rrsig-lifetime: 14d
rrsig-refresh: 7d
rrsig-pre-refresh: 1h
---
zones/unsigned is stored in a git repo and changes are deployed by an
ansible playbook that checks out the latest revision and reloads the zones.
Someone pointed out that zonefile-load: difference-no-serial was risky
for something as important as a TLD, but what is the alternative when
doing automatic DNSSEC signing on zone data from git? Also, we turned
off zonefile-sync, since our current deployment script overwrites the
zonefile. Is there a way to load initial zone data from one file, but do
zonefile-sync to another?
We're seeing this in our logs:
Jan 20 09:32:06 ht-signer01 knot[49715]: info: [pp.is.] zone file
parsed, serial corrected 1970010100 -> 2022012000
Jan 20 09:32:06 ht-signer01 knot[49715]: info: [pp.is.] loaded, serial
2022011900 -> 2022012000 -> 2022011900, 3830 bytes
Any idea what's happening on the second line? It's like knot wants to
increment the serial, but then changes it's mind :)
.einar
20 Led
20 Led
17:14
Hi Einar,
On 1/20/22 2:03 PM, Einar Bjarni Halldórsson wrote:
Hi,
For many months now, we've been preparing new signers for our internal zones and
eventually .is.
We've got the first of our test zones live on the production signers, but some things
are troubling us.
This is the config we're using for zones:
template:
- id: default
semantic-checks: on
storage: "/usr/local/etc/knot"
file: "zones/unsigned/%s/%s-soa"
serial-policy: dateserial
zonefile-sync: -1
zonefile-load: difference-no-serial
journal-content: all
notify: hidden_primary
acl: hidden_primary_acl
policy:
- id: isnic
algorithm: RSASHA256
ksk-size: 4096
zsk-size: 2048
ksk-lifetime: 365d
zsk-lifetime: 30d
propagation-delay: 1h
rrsig-lifetime: 14d
rrsig-refresh: 7d
rrsig-pre-refresh: 1h
---
zones/unsigned is stored in a git repo and changes are deployed by an ansible playbook
that checks out the latest revision and reloads the zones.
Someone pointed out that zonefile-load: difference-no-serial was risky for something as
important as a TLD, but what is the alternative when doing automatic DNSSEC signing on
zone data from git? Also,
we turned off zonefile-sync, since our current deployment script overwrites the zonefile.
Is there a way to load initial zone data from one file, but do zonefile-sync to another?
"zonefile-load: difference-no-serial" was risky in the past when
"journal-content: all" wasn't required for that. Nowadays we aren't
aware of any issues with this setup.
More zone files per zone aren't supported.
We're seeing this in our logs:
Jan 20 09:32:06 ht-signer01 knot[49715]: info: [pp.is.] zone file parsed, serial
corrected 1970010100 -> 2022012000
Jan 20 09:32:06 ht-signer01 knot[49715]: info: [pp.is.] loaded, serial 2022011900 ->
2022012000 -> 2022011900, 3830 bytes
This log line is correct. It means that there is no change in the zone so it doesn't
make sense to increase the serial only.
Daniel
Any idea what's happening on the second line? It's like knot wants to increment
the serial, but then changes it's mind :)
.einar
--
21 Led
21 Led
10:26
Hi Daniel,
Ok, now I understand.
One question regarding the serial: Is it possible to set or increase the
serial (when using difference-no-serial) in some other way than simply
changing the zone and reloading?
We're using serial-policy: dateserial, and we're running two signers,
one active and one backup. The hidden primaries get updates from the
active signer.
If we need to change from the active to the backup the serial will
probably be out-of-sync and possibly some way off. If the backup signer
has a lower serial then what the prior active signer had, then we'll
need to fix it so the primaries start to accept updates from it.
I think the best way would be to change to serial-policy: unixtime, that
way every zone update is certain to increase the serial, but this will
require working with 3rd parties providing secondaries, to force the
first update after switching to unixtime.
I'd be interested to know if there was some way to do something like
`knotc zone-set-serial pp.is 2022012110` to force a new serial?
(I've combed through knotc man page, I know it's not there....)
.einar
"zonefile-load: difference-no-serial" was risky in the past when
"journal-content: all" wasn't required for that. Nowadays we aren't
aware of any issues with this setup.
That's good to know. We'll stick with difference-no-serial and
journal-content: all
We're seeing this in our logs:
Jan 20 09:32:06 ht-signer01 knot[49715]: info: [pp.is.] zone file parsed, serial
corrected 1970010100 -> 2022012000
Jan 20 09:32:06 ht-signer01 knot[49715]: info: [pp.is.] loaded, serial 2022011900 ->
2022012000 -> 2022011900, 3830 bytes
This log line is correct. It means that there is no change in the zone so it doesn't
make sense to increase the serial only.
19:46
Hi Einar,
One question regarding the serial: Is it possible to
set or increase
the serial (when using difference-no-serial) in some other way than
simply changing the zone and reloading?
Do you need to BUMP the SOA serial without
any other change in the zone?
There might be a trick that would do this, but it's not kind of
supported feature. Why would you need it?
We're using serial-policy: dateserial, and we're running two signers,
one active and one backup. The hidden primaries get updates from the
active signer.
If we need to change from the active to the backup the serial will
probably be out-of-sync and possibly some way off. If the backup
signer has a lower serial then what the prior active signer had, then
we'll need to fix it so the primaries start to accept updates from it.
I
strongly recommend that the two signers are completely in-sync. Could
you imagine that the hidden master runs a zone from signer1, and
suddenly transfers an IXFR with a diff of the zone in signer2, and
applies it on the zone? In that case, it's better when the secondaries
don't transfer automatically, rather by forced AXFR (knotc zone-retransfer).
I think the best way would be to change to serial-policy: unixtime,
that way every zone update is certain to increase the serial, but this
will require working with 3rd parties providing secondaries, to force
the first update after switching to unixtime.
I'd be interested to know if there was some way to do something like
`knotc zone-set-serial pp.is 2022012110` to force a new serial?
(I've combed through knotc man page, I know it's not there....)
.einar
--
Anyway, the setup of redundant signers is still an unexplored field in
DNS overall. You might lead the development here, and my opinion is that
SOA serials are of the smallest problems here.
Looking forward to discuss more next week :)
Cheers,
Libor
20:50
Einar,
One way to change the serial is:
$ knotc zone-read example.com @ SOA
[example.com.] example.com. 3600 SOA dns1.example.com. hostmaster.example.com. 2022012100
10800 3600 1209600 7200
$ knotc zone-begin example.com
OK
$ knotc zone-set example.com @ 3600 SOA "dns1.example.com. hostmaster.example.com.
2022012105 10800 3600 1209600 7200"
OK
$ knotc zone-commit example.com
OK
Verification:
$ kjournalprint -l 1 example.com
;; Changes between zone versions: 2022012100 -> 2022012105, changeset: 1
;; Removed
example.com. 3600 SOA dns1.example.com. hostmaster.example.com. 2022012100 10800
3600 1209600 7200
example.com. 3600 RRSIG SOA 13 2 3600 20220204193156 20220121180156 20522
example.com.
/v6znTSakpL2aJa5p3fcD7tY3vWI/wmQwFADmguy4kl016doOpG4ZAxH3DmhUmV8AKCM7BHp1AfontXHLDeZXQ==
;; Added
example.com. 3600 SOA dns1.example.com. hostmaster.example.com. 2022012105 10800
3600 1209600 7200
example.com. 3600 RRSIG SOA 13 2 3600 20220204194056 20220121181056 20522
example.com.
vdB1SHlfCs24AnqOnruK0J05aXFfMn3DcZTTuDDgqsP9t8AN//J1xX7Gw63gnQsBOmeZam8W/CbAlq4wrRPfyQ==
Daniel
On 1/21/22 7:46 PM, libor.peltan wrote:
Hi Einar,
One question regarding the serial: Is it possible
to set or increase the serial (when using difference-no-serial) in some other way than
simply changing the zone and reloading?
Do you need to BUMP the SOA serial without
any other change in the zone? There might be a trick that would do this, but it's not
kind of supported feature. Why would you need it?
We're using serial-policy: dateserial, and we're running two signers, one active
and one backup. The hidden primaries get updates from the active signer.
If we need to change from the active to the backup the serial will probably be
out-of-sync and possibly some way off. If the backup signer has a lower serial then what
the prior active signer had,
then we'll need to fix it so the primaries start to accept updates from it.
I
strongly recommend that the two signers are completely in-sync. Could you imagine that the
hidden master runs a zone from signer1, and suddenly transfers an IXFR with a diff of the
zone in signer2,
and applies it on the zone? In that case, it's better when the secondaries don't
transfer automatically, rather by forced AXFR (knotc zone-retransfer).
I think the best way would be to change to serial-policy: unixtime, that way every zone
update is certain to increase the serial, but this will require working with 3rd parties
providing
secondaries, to force the first update after switching to unixtime.
I'd be interested to know if there was some way to do something like `knotc
zone-set-serial pp.is 2022012110` to force a new serial?
(I've combed through knotc man page, I know it's not there....)
.einar
--
Anyway, the setup of redundant signers is still an unexplored field in DNS overall. You
might lead the development here, and my opinion is that SOA serials are of the smallest
problems here.
Looking forward to discuss more next week :)
Cheers,
Libor
23:03
Hi Libor,
I strongly recommend that the two signers are
completely in-sync. Could
you imagine that the hidden master runs a zone from signer1, and
suddenly transfers an IXFR with a diff of the zone in signer2, and
applies it on the zone? In that case, it's better when the secondaries
don't transfer automatically, rather by forced AXFR (knotc
zone-retransfer).
That's not a problem, but some of our public secondaries are external
and getting them to force an AXFR is a manual process. I want to find a
way to make sure that after a failover to backup signer, that it uses a
serial that is higher than the public secondaries have. We can deal with
the hidden primaries.
Anyway, the setup of redundant signers is still an unexplored field in
DNS overall. You might lead the development here, and my opinion is that
SOA serials are of the smallest problems here.
Looking forward to discuss more next week :)
Me too! I'm going to do some more tests with signer failover next week,
will be interesting to see how it goes.
.einar
24 Led
24 Led
9:11
Hi Einar,
That's not a problem, but some of our public
secondaries are external
and getting them to force an AXFR is a manual process. I want to find
a way to make sure that after a failover to backup signer, that it
uses a serial that is higher than the public secondaries have. We can
deal with the hidden primaries.
I wonder how it can happen that the SOA serial of the backup signer is
lower than of the default one. If the signers are equivalently
configured and they both run permanently in parallel, they should
usually have the same SOA serial, which depends on how many times has
the upstream (un-signed) zone been changed that day.
/Libor
15:05
Hi Libor,
On 24.1.2022 08:11, libor.peltan wrote:
I wonder how it can happen that the SOA serial of the
backup signer is
lower than of the default one. If the signers are equivalently
configured and they both run permanently in parallel, they should
usually have the same SOA serial, which depends on how many times has
the upstream (un-signed) zone been changed that day.
Both active and backup signers are doing automatic signing, but only the
active signer is doing automatic key rollovers. I guess what we've seen
is that the backup signer has refreshed it's signatures before the
active, thus it's serial going ahead of the active signer.
We've decided to migrate to unixtime serials.
We've tested signer failover and it's resulted in AXFR, since I guess
the backup signer didn't have history from the serial the primaries had.
I wonder what the worst case scenario could be? We're confident that the
backup signer will have the same keys as the active, so in the case of
failover, if the new active has history from the serial the primary has,
an IXFR will result in a valid IXFR and a valid zone?
The only difference in the zone on the active and backup should be
RRSIG, but replacing them all in the case of a failover should be alright.
.einar
845
days inactive
849
days old
7 comments
3 participants
participants (3)
-
Daniel Salzman -
Einar Bjarni Halldórsson -
libor.peltan