29 Oct
2018
29 Oct
'18
4:20 p.m.
Hi Sebastian,
1) that's OK. You don't need to worry about that warning unless you edit
the zonefile on the signer manually. You can also consider zonefile-less
signer, either completely headless (needs AXFR after each daemon start)
or with the zone stored in journal (needs some thoughts regarding
journal capacity policies). Check "zonefile-load", "journal-content",
"max-journal-db-size" and "max-journal-usage" options in config.
2) No, "discontinuity in changes history" is not expected. Could you
please describe what did you do before such warning appeared, with
longer snippets of the log? In any case, there is no need to be scared
of journal getting full, once you read the documentation ;)
https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#journal-behaviour
BR,
Libor
Dne 29.10.18 v 13:07 Sebastian Wiesinger napsal(a):
Right now I have two zone types for my knot test
setup, one where knot
is doing DNSSEC signing as a slave (AXFR in -> sign -> AXFR out) and
one where the knot is the master for the zone and zone data is coming
out of a git repository and gets signed.
Reading older threads on this ML and browsing the configuration has
led me to the following configuration and I wanted to make sure this
is actually supported or if there is a best practice that is
different.
1) Inline DNSSEC signing for slave zone.
zone:
- domain: example.com
serial-policy: unixtime
storage: "/var/lib/knot/slave"
file: "%s.zone"
zonefile-load: difference
dnssec-signing: on
dnssec-policy: rsa-de
master: ns1_signer
notify: ns1
acl: acl_ns1
policy:
- id: rsa-de
algorithm: RSASHA256
ksk-size: 2048
zsk-size: 1024
ksk-submission: tld_de
This seems to work fine, zone gets transferred from master (with low
serial), signed and with a new unixtime serial transferred out again.
I'm not sure if "zonefile-load: difference " makes any difference for
a slave zone but without it I get warnings about possibly malformed
IXFRs...
2) Inline DNSSEC for master zone from git:
zone:
- domain: dnssec-test.intern
serial-policy: unixtime
storage: "/var/lib/knot/master"
file: "%s.zone"
zonefile-sync: -1
dnssec-signing: on
dnssec-policy: rsa
acl: acl_ns1
zonefile-load: difference-no-serial
policy:
- id: rsa
algorithm: RSASHA256
ksk-size: 2048
zsk-size: 1024
This also works but I get warnings like this:
[dnssec-test.intern.] journal, discontinuity in changes history
(1540307365 -> 28), dropping older changesets
Is this expected? Also I read in older threads that this might fill
up the journal. Is that still the case?
Best Regards
Sebastian
29 Oct
29 Oct
4:30 p.m.
New subject: Best practices for knot inline DNSSEC signing and zone loading
* libor.peltan <libor.peltan(a)nic.cz> [2018-10-29 16:20]:
2) No, "discontinuity in changes history" is
not expected. Could you please
describe what did you do before such warning appeared, with longer snippets
of the log? In any case, there is no need to be scared of journal getting
full, once you read the documentation ;)
https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#journal-behaviour
I restarted the server after upgrading it from 2.7.2 to 2.7.3:
Oct 29 10:04:21 alita knotd[8410]: info: stopping server
Oct 29 10:04:21 alita knotd[8410]: info: updating persistent timer DB
Oct 29 10:04:22 alita knotd[8410]: info: shutting down
Oct 29 10:04:22 alita knotd[18283]: info: Knot DNS 2.7.3 starting
Oct 29 10:04:22 alita knotd[18283]: info: binding to interface 127.0.0.1@5354
Oct 29 10:04:22 alita knotd[18283]: info: binding to interface ::1@5354
Oct 29 10:04:22 alita knotd[18283]: info: changing GID to 147
Oct 29 10:04:22 alita knotd[18283]: info: changing UID to 143
Oct 29 10:04:22 alita knotd[18283]: info: process not allowed to set capabilities,
skipping
Oct 29 10:04:22 alita knotd[18283]: info: loading 2 zones
Oct 29 10:04:22 alita knotd[18283]: info: [example.com.] zone will be loaded
Oct 29 10:04:22 alita knotd[18283]: info: [dnssec-test.intern.] zone will be loaded
Oct 29 10:04:22 alita knotd[18283]: info: starting server
Oct 29 10:04:22 alita knotd[18283]: info: [dnssec-test.intern.] DNSSEC, key, tag 41236,
algorithm RSASHA256, KSK, public, active
Oct 29 10:04:22 alita knotd[18283]: info: [dnssec-test.intern.] DNSSEC, key, tag 49126,
algorithm RSASHA256, public, active
Oct 29 10:04:22 alita knotd[18283]: info: [example.com.] DNSSEC, key, tag 38882, algorithm
RSASHA256, KSK, public, active
Oct 29 10:04:22 alita knotd[18283]: info: [example.com.] DNSSEC, key, tag 3505, algorithm
RSASHA256, public, active
Oct 29 10:04:22 alita knotd[18283]: info: [dnssec-test.intern.] DNSSEC, signing started
Oct 29 10:04:22 alita knotd[18283]: info: [dnssec-test.intern.] DNSSEC, successfully
signed
Oct 29 10:04:22 alita knotd[18283]: warning: [dnssec-test.intern.] journal, discontinuity
in changes history (1540307365 -> 28), dropping older changesets
Oct 29 10:04:23 alita knotd[18283]: info: [example.com.] DNSSEC, signing started
Oct 29 10:04:23 alita knotd[18283]: info: [example.com.] DNSSEC, zone is up-to-date
Oct 29 10:04:23 alita knotd[18283]: warning: [example.com.] with automatic DNSSEC signing
and outgoing transfers enabled, 'zonefile-load: difference' should be set to avoid
mal
Oct 29 10:04:23 alita knotd[18283]: info: [example.com.] loaded, serial 1540737051, 4960
bytes
Oct 29 10:04:23 alita knotd[18283]: info: [example.com.] DNSSEC, next signing at
2018-10-31T14:00:50
Oct 29 10:04:24 alita knotd[18283]: info: [dnssec-test.intern.] loaded, serial 1540803862,
2788 bytes
Oct 29 10:04:24 alita knotd[18283]: info: [dnssec-test.intern.] DNSSEC, next signing at
2018-11-05T10:04:22
Serial 28 is the serial from the (unsigned) master file.
Regards
Sebastian
--
GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE
SCYTHE.
-- Terry Pratchett, The Fifth Elephant
30 Oct
30 Oct
3:04 p.m.
New subject: Best practices for knot inline DNSSEC signing and zone loading
Hi Sebastian,
i don't see clearly what happened in your case. It seems for some reason
the history stored in journal (just changes) was no longer appliable on
the zonefile. Nothing terrible, just one annoying warning and a bit more
annoying AXFR from slaves (instead of IXFR). Anyway, I would suggest
trying `journal-content: all`, because it works better together with
`zonefile-load: difference-no-serial` - the server can keep track of
zone serials and changes even during server restart.
For me this is a clear signal to work on some extension of zone load
logging.
Libor
Dne 29.10.18 v 16:30 Sebastian Wiesinger napsal(a):
* libor.peltan <libor.peltan(a)nic.cz> [2018-10-29
16:20]:
2) No, "discontinuity in changes
history" is not expected. Could you please
describe what did you do before such warning appeared, with longer snippets
of the log? In any case, there is no need to be scared of journal getting
full, once you read the documentation ;)
https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#journal-behaviour
I
restarted the server after upgrading it from 2.7.2 to 2.7.3:
Oct 29 10:04:21 alita knotd[8410]: info: stopping server
Oct 29 10:04:21 alita knotd[8410]: info: updating persistent timer DB
Oct 29 10:04:22 alita knotd[8410]: info: shutting down
Oct 29 10:04:22 alita knotd[18283]: info: Knot DNS 2.7.3 starting
Oct 29 10:04:22 alita knotd[18283]: info: binding to interface 127.0.0.1@5354
Oct 29 10:04:22 alita knotd[18283]: info: binding to interface ::1@5354
Oct 29 10:04:22 alita knotd[18283]: info: changing GID to 147
Oct 29 10:04:22 alita knotd[18283]: info: changing UID to 143
Oct 29 10:04:22 alita knotd[18283]: info: process not allowed to set capabilities,
skipping
Oct 29 10:04:22 alita knotd[18283]: info: loading 2 zones
Oct 29 10:04:22 alita knotd[18283]: info: [example.com.] zone will be loaded
Oct 29 10:04:22 alita knotd[18283]: info: [dnssec-test.intern.] zone will be loaded
Oct 29 10:04:22 alita knotd[18283]: info: starting server
Oct 29 10:04:22 alita knotd[18283]: info: [dnssec-test.intern.] DNSSEC, key, tag 41236,
algorithm RSASHA256, KSK, public, active
Oct 29 10:04:22 alita knotd[18283]: info: [dnssec-test.intern.] DNSSEC, key, tag 49126,
algorithm RSASHA256, public, active
Oct 29 10:04:22 alita knotd[18283]: info: [example.com.] DNSSEC, key, tag 38882,
algorithm RSASHA256, KSK, public, active
Oct 29 10:04:22 alita knotd[18283]: info: [example.com.] DNSSEC, key, tag 3505,
algorithm RSASHA256, public, active
Oct 29 10:04:22 alita knotd[18283]: info: [dnssec-test.intern.] DNSSEC, signing started
Oct 29 10:04:22 alita knotd[18283]: info: [dnssec-test.intern.] DNSSEC, successfully
signed
Oct 29 10:04:22 alita knotd[18283]: warning: [dnssec-test.intern.] journal, discontinuity
in changes history (1540307365 -> 28), dropping older changesets
Oct 29 10:04:23 alita knotd[18283]: info: [example.com.] DNSSEC, signing started
Oct 29 10:04:23 alita knotd[18283]: info: [example.com.] DNSSEC, zone is up-to-date
Oct 29 10:04:23 alita knotd[18283]: warning: [example.com.] with automatic DNSSEC signing
and outgoing transfers enabled, 'zonefile-load: difference' should be set to avoid
mal
Oct 29 10:04:23 alita knotd[18283]: info: [example.com.] loaded, serial 1540737051, 4960
bytes
Oct 29 10:04:23 alita knotd[18283]: info: [example.com.] DNSSEC, next signing at
2018-10-31T14:00:50
Oct 29 10:04:24 alita knotd[18283]: info: [dnssec-test.intern.] loaded, serial
1540803862, 2788 bytes
Oct 29 10:04:24 alita knotd[18283]: info: [dnssec-test.intern.] DNSSEC, next signing at
2018-11-05T10:04:22
Serial 28 is the serial from the (unsigned) master file.
Regards
Sebastian
5 p.m.
New subject: Best practices for knot inline DNSSEC signing and zone loading
* libor.peltan <libor.peltan(a)nic.cz> [2018-10-30 15:04]:
Hi Sebastian,
i don't see clearly what happened in your case. It seems for some reason the
history stored in journal (just changes) was no longer appliable on the
zonefile. Nothing terrible, just one annoying warning and a bit more
annoying AXFR from slaves (instead of IXFR). Anyway, I would suggest trying
`journal-content: all`, because it works better together with
`zonefile-load: difference-no-serial` - the server can keep track of zone
serials and changes even during server restart.
I tried changing to journal-content: all which made the zone
unloadable:
Oct 30 16:57:17 alita knotd[16679]: warning: [dnssec-test.intern.] journal, discontinuity
in changes history (1540915037 -> 1540814166), dropping older changesets
Oct 30 16:57:17 alita knotd[16679]: error: [dnssec-test.intern.] zone event 'load'
failed (value is out of range)
I'm trying to figure out how to get out of this state again..
Regards
Sebastian
--
GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE
SCYTHE.
-- Terry Pratchett, The Fifth Elephant
31 Oct
31 Oct
11:03 a.m.
New subject: Best practices for knot inline DNSSEC signing and zone loading
Please try purging the journal (or deleting it directly on the
filesystem) and restarting the server.
Dne 30.10.18 v 17:00 Sebastian Wiesinger napsal(a):
* libor.peltan <libor.peltan(a)nic.cz> [2018-10-30
15:04]:
Hi Sebastian,
i don't see clearly what happened in your case. It seems for some reason the
history stored in journal (just changes) was no longer appliable on the
zonefile. Nothing terrible, just one annoying warning and a bit more
annoying AXFR from slaves (instead of IXFR). Anyway, I would suggest trying
`journal-content: all`, because it works better together with
`zonefile-load: difference-no-serial` - the server can keep track of zone
serials and changes even during server restart.
I tried changing to
journal-content: all which made the zone
unloadable:
Oct 30 16:57:17 alita knotd[16679]: warning: [dnssec-test.intern.] journal, discontinuity
in changes history (1540915037 -> 1540814166), dropping older changesets
Oct 30 16:57:17 alita knotd[16679]: error: [dnssec-test.intern.] zone event
'load' failed (value is out of range)
I'm trying to figure out how to get out of this state again..
Regards
Sebastian
4:26 p.m.
New subject: Best practices for knot inline DNSSEC signing and zone loading
* libor.peltan <libor.peltan(a)nic.cz> [2018-10-31 11:03]:
Please try purging the journal (or deleting it
directly on the filesystem)
and restarting the server.
Yeah, that worked...
Regards
Sebastian
--
GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE
SCYTHE.
-- Terry Pratchett, The Fifth Elephant
29 Oct
29 Oct
4:39 p.m.
New subject: Best practices for knot inline DNSSEC signing and zone loading
* libor.peltan <libor.peltan(a)nic.cz> [2018-10-29 16:20]:
2) No, "discontinuity in changes history" is
not expected. Could you please
describe what did you do before such warning appeared, with longer snippets
of the log? In any case, there is no need to be scared of journal getting
full, once you read the documentation ;)
https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#journal-behaviour
In regards to the journal... well the site states:
"There is also a safety hard limit for overall journal database size,
but it’s strongly recommended to set the per-zone limits in a way to
prevent hitting this one. For LMDB, it’s hard to recover from the
database-full state. "
"Anyway, it’s recommended to carefully tune the journal-size-related
options to avoid surprises of journal getting full."
"Each zone journal has own usage limit on how much DB space it may
occupy. Before hitting the limit, changesets are stored one-by-one and
whole history is linear. While hitting the limit, the zone is flushed
into the zone file, and oldest changesets are deleted as needed to
free some space."
That doesn't sound like the journal can't get full. The only thing
that makes me a bit less anxious is this:
"If zone file flush is disabled, then instead of flushing the zone, the
journal tries to save space by merging older changesets into one. It
works well if the changes rewrite each other, e.g. periodically
changing few zone records, re-signing whole zone... The difference
between the zone file and the zone is thus preserved, even if journal
deletes some older changesets."
So when I have only DNSSEC stuff in the journal it will not grow
because changes are overwritten? Is that what it means?
Regards
Sebastian
--
GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE
SCYTHE.
-- Terry Pratchett, The Fifth Elephant
30 Oct
30 Oct
3:44 p.m.
New subject: Best practices for knot inline DNSSEC signing and zone loading
Well, journal is a complicated piece of stuff to handle. There are many
use-cases (from just IXFR to zone-in-journal) and situations (many small
zones, one big zone, some combination) which behave differently. There
are some more-or-less obvious technical limits. Many users have their
zones by magnitude smaller that their journal can handle; if it's not
your case, you need to think of how it shall behave once it's full, and
configure its tuning accordingly.
This is especially the case with `zonefile-flush: -1`, because journal
needs to save "whole history" of changes, not being able to simply
delete old stuff. It has mechanism to merge older changesets, where most
of the 'added records' and 'removed records' cancel out. I have observed
this works literally infinitely with `journal-content: all`.
You can also check the `kjournalprint` utility, which can tell you much
about what's inside the journal.
/Libor
Dne 29.10.18 v 16:39 Sebastian Wiesinger napsal(a):
* libor.peltan <libor.peltan(a)nic.cz> [2018-10-29
16:20]:
2) No, "discontinuity in changes
history" is not expected. Could you please
describe what did you do before such warning appeared, with longer snippets
of the log? In any case, there is no need to be scared of journal getting
full, once you read the documentation ;)
https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#journal-behaviour
In
regards to the journal... well the site states:
"There is also a safety hard limit for overall journal database size,
but it’s strongly recommended to set the per-zone limits in a way to
prevent hitting this one. For LMDB, it’s hard to recover from the
database-full state. "
"Anyway, it’s recommended to carefully tune the journal-size-related
options to avoid surprises of journal getting full."
"Each zone journal has own usage limit on how much DB space it may
occupy. Before hitting the limit, changesets are stored one-by-one and
whole history is linear. While hitting the limit, the zone is flushed
into the zone file, and oldest changesets are deleted as needed to
free some space."
That doesn't sound like the journal can't get full. The only thing
that makes me a bit less anxious is this:
"If zone file flush is disabled, then instead of flushing the zone, the
journal tries to save space by merging older changesets into one. It
works well if the changes rewrite each other, e.g. periodically
changing few zone records, re-signing whole zone... The difference
between the zone file and the zone is thus preserved, even if journal
deletes some older changesets."
So when I have only DNSSEC stuff in the journal it will not grow
because changes are overwritten? Is that what it means?
Regards
Sebastian
2176
days inactive
2178
days old
7 comments
2 participants
participants (2)
-
libor.peltan -
Sebastian Wiesinger