21 Čen
2018
21 Čen
'18
13:56
Hello,
I'm trying to use Knot 2.6.7 in a configuration where zone files are
preserved (including comments, ordering and formatting) yet at the same
time Knot performs DNSSEC signing – something similar to inline-signing
feature by BIND. My config file looks like this:
policy:
- id: ecdsa_fast
nsec3: on
ksk-shared: on
zsk-lifetime: 1h
ksk-lifetime: 5h
propagation-delay: 10s
rrsig-lifetime: 2h
rrsig-refresh: 1h
template:
- id: mastersign
file: "/etc/knot/%s.zone"
zonefile-sync: -1
zonefile-load: difference
journal-content: all
dnssec-signing: on
dnssec-policy: ecdsa_fast
serial-policy: unixtime
acl: acl_slave
zone:
- domain: "example.com."
template: mastersign
It seems to work well for the first run, I can see that zone got signed
properly:
# kjournalprint /var/lib/knot/journal/ example.com
;; Zone-in-journal, serial: 1
;;Added
example.com. 60 SOA knot.example.com. hostmaster.example.com. 1 3600
900 1814400 60
example.com. 60 NS knot.example.com.
first.example.com. 60 TXT "first"
;; Changes between zone versions: 1 -> 1529578258
;;Removed
example.com. 60 SOA knot.example.com. hostmaster.example.com. 1 3600
900 1814400 60
;;Added
example.com. 60 SOA knot.example.com. hostmaster.example.com.
1529578258 3600 900 1814400 60
example.com. 0 CDNSKEY 257 3 13
…lots of DNSSEC data.
However, if I try to update the unsigned zone file, strange things
happen. If I just add something to a zone and increase the serial, I get
these errors in the log:
Jun 21 13:00:08 localhost knotd[2412]: warning: [example.com.] zone file changed, but SOA
serial decreased
Jun 21 13:00:08 localhost knotd[2412]: error: [example.com.] zone event 'load'
failed (value is out of range)
If I set the serial to be higher than the serial of last signed zone, I
get a slightly different error:
Jun 21 13:22:36 localhost knotd[3096]: warning: [example.com.] journal, discontinuity in
changes history (1529580085 -> 1529580084), dropping older changesets
Jun 21 13:22:36 localhost knotd[3096]: error: [example.com.] zone event 'load'
failed (value is out of range)
In either case, when I look into the journal after the reload of the
zone, I see just the unsigned zone:
# kjournalprint /var/lib/knot/journal/ example.com
;; Zone-in-journal, serial: 2
;;Added
example.com. 60 SOA knot.example.com. hostmaster.example.com. 2 3600
900 1814400 60
example.com. 60 NS knot.example.com.
first.example.com. 60 TXT "first"
second.example.com. 60 TXT "second"
Yet the server keeps serving the previous signed zone no matter what I
try. The only thing that help is a cold restart of Knot, when the zone
gets signed again.
So this approach is obviously not working as expected. If I comment out
option `zonefile-load: difference`, I get somehow working solution where
zone is completely resigned during each reload and I get this warning to
the log:
Jun 21 13:27:38 localhost knotd[3156]: warning:
[example.com.] with automatic DNSSEC signing and outgoing transfers enabled,
'zonefile-load: difference' should be set to avoid malformed IXFR after manual
zone file update
I guess this should not bother me a lot as log as I keep serial numbers
of unsigned zones significantly different from signed ones. The only
problem is that this completely kills IXFR transfers as well as signing
only differences.
So far the only solution I see is to run two instances of Knot, one
reading the zone file from disk without signing, transferring it to
another instance which would do the signing is slave mode.
Is there anything I'm missing here?
Sorry for such a long e-mail and thank you for reading all the way here.
Best regards,
Ondřej Caletka
21 Čen
21 Čen
15:33
Hello Ondřej,
This is an intended use case, so if it doesn't work, it's a bug :-)
Definitely, you must set "zonefile-load: difference". Otherwise IXFR changes
would be incomplete.
Also I think you should set "journal-content: changes" to store just changes to
the journal.
The biggest problem is that you have to update the SOA serial to a value higher than the
current one
(not to the value higher than is in the zone file, which is not managed by the server).
We will try to reproduce it and consider whether it could be made user friendlier :-)
Best,
Daniel
On 06/21/2018 01:56 PM, Ondřej Caletka wrote:
Hello,
I'm trying to use Knot 2.6.7 in a configuration where zone files are
preserved (including comments, ordering and formatting) yet at the same
time Knot performs DNSSEC signing – something similar to inline-signing
feature by BIND. My config file looks like this:
policy:
- id: ecdsa_fast
nsec3: on
ksk-shared: on
zsk-lifetime: 1h
ksk-lifetime: 5h
propagation-delay: 10s
rrsig-lifetime: 2h
rrsig-refresh: 1h
template:
- id: mastersign
file: "/etc/knot/%s.zone"
zonefile-sync: -1
zonefile-load: difference
journal-content: all
dnssec-signing: on
dnssec-policy: ecdsa_fast
serial-policy: unixtime
acl: acl_slave
zone:
- domain: "example.com."
template: mastersign
It seems to work well for the first run, I can see that zone got signed
properly:
# kjournalprint /var/lib/knot/journal/ example.com
;; Zone-in-journal, serial: 1
;;Added
example.com. 60 SOA knot.example.com. hostmaster.example.com. 1 3600
900 1814400 60
example.com. 60 NS knot.example.com.
first.example.com. 60 TXT "first"
;; Changes between zone versions: 1 -> 1529578258
;;Removed
example.com. 60 SOA knot.example.com. hostmaster.example.com. 1 3600
900 1814400 60
;;Added
example.com. 60 SOA knot.example.com. hostmaster.example.com.
1529578258 3600 900 1814400 60
example.com. 0 CDNSKEY 257 3 13
…lots of DNSSEC data.
However, if I try to update the unsigned zone file, strange things
happen. If I just add something to a zone and increase the serial, I get
these errors in the log:
Jun 21 13:00:08 localhost knotd[2412]: warning: [example.com.] zone file changed, but SOA
serial decreased
Jun 21 13:00:08 localhost knotd[2412]: error: [example.com.] zone event 'load'
failed (value is out of range)
If I set the serial to be higher than the serial of last signed zone, I
get a slightly different error:
Jun 21 13:22:36 localhost knotd[3096]: warning: [example.com.] journal, discontinuity in
changes history (1529580085 -> 1529580084), dropping older changesets
Jun 21 13:22:36 localhost knotd[3096]: error: [example.com.] zone event 'load'
failed (value is out of range)
In either case, when I look into the journal after the reload of the
zone, I see just the unsigned zone:
# kjournalprint /var/lib/knot/journal/
example.com
;; Zone-in-journal, serial: 2
;;Added
example.com. 60 SOA knot.example.com. hostmaster.example.com. 2 3600
900 1814400 60
example.com. 60 NS knot.example.com.
first.example.com. 60 TXT "first"
second.example.com. 60 TXT "second"
Yet the server keeps serving the previous signed zone no matter what I
try. The only thing that help is a cold restart of Knot, when the zone
gets signed again.
So this approach is obviously not working as expected. If I comment out
option `zonefile-load: difference`, I get somehow working solution where
zone is completely resigned during each reload and I get this warning to
the log:
Jun 21 13:27:38 localhost knotd[3156]: warning:
[example.com.] with automatic DNSSEC signing and outgoing transfers enabled,
'zonefile-load: difference' should be set to avoid malformed IXFR after manual
zone file update
I guess this should not bother me a lot as log as I keep serial numbers
of unsigned zones significantly different from signed ones. The only
problem is that this completely kills IXFR transfers as well as signing
only differences.
So far the only solution I see is to run two instances of Knot, one
reading the zone file from disk without signing, transferring it to
another instance which would do the signing is slave mode.
Is there anything I'm missing here?
Sorry for such a long e-mail and thank you for reading all the way here.
Best regards,
Ondřej Caletka
22 Čen
22 Čen
19:56
Dne 21.6.2018 v 15:33 Daniel Salzman napsal(a):
This is an intended use case, so if it doesn't
work, it's a bug :-)
Definitely, you must set "zonefile-load: difference". Otherwise IXFR changes
would be incomplete.
Also I think you should set "journal-content: changes" to store just changes to
the journal.
The biggest problem is that you have to update the SOA serial to a value higher than the
current one
(not to the value higher than is in the zone file, which is not managed by the server).
Hello Daniel,
thank you for response. I can confirm that using `journal-content:
changes` together with `zonefile-load: difference` works properly, that
means:
- when zone file is edited and SOA serial is set to be higher than
current serial of signed zone, the zone is resigned and this is recorded
into the journal as a change (ie. there is still history in the journal)
- when zone file is edited and SOA is not set to be higher than current
serial of signed zone, only warning gets logged and nothing breaks.
So `journal-content: all` was the reason of all the strange behavior I
observed.
Cheers,
Ondřej Caletka
20:35
On 2018-06-22 19:56, Ondřej Caletka wrote:
Dne 21.6.2018 v 15:33 Daniel Salzman napsal(a):
Thank you for verification. However, we have discovered some minor
issues
with this use case. But I hope we will fix them in the next patch
release.
Daniel
This is an intended use case, so if it
doesn't work, it's a bug :-)
Definitely, you must set "zonefile-load: difference". Otherwise IXFR
changes would be incomplete.
Also I think you should set "journal-content: changes" to store just
changes to the journal.
The biggest problem is that you have to update the SOA serial to a
value higher than the current one
(not to the value higher than is in the zone file, which is not
managed by the server).
Hello Daniel,
thank you for response. I can confirm that using `journal-content:
changes` together with `zonefile-load: difference` works properly, that
means:
- when zone file is edited and SOA serial is set to be higher than
current serial of signed zone, the zone is resigned and this is
recorded
into the journal as a change (ie. there is still history in the
journal)
- when zone file is edited and SOA is not set to be higher than
current
serial of signed zone, only warning gets logged and nothing breaks.
So `journal-content: all` was the reason of all the strange behavior I
observed.
Cheers,
Ondřej Caletka
2157
days inactive
2158
days old
3 comments
3 participants
participants (3)
-
Daniel Salzman -
daniel.salzman＠nic.cz
-
Ondřej Caletka