Hello,
I am using knot version 2.7 with automated keyrollover for DNSSEC.
I am trying to understand the rollover process so that I can exactly
predict when a rollover is in progress.
So far I have understood this:
KSK (1) [created and published] ---(progapagtion delay + DNSKEY TTL)-->
KSK (1) [ready]
---(submitted in parent zone)-->
---((KSK-TTL) - (DNSKEY TTL + propagation delay + DS parent TTL + x))->
KSK (2) [created and published]
KSK (2) [ready] ---(submitted in parent zone)-->
KSK (1) [retire-active], KSK (2) [active] ---(propagation delay + DNSKEY
TTL)->
KSK (1) [removed]
My observartions during the rollover:
Knot configuration:
DNSKEY-TTL: 12h
Propagation-delay: 2h
Zone TTL default: 1h
KSK-lifetime: 3d
ZSK lifetime: 0
Parent configuration:
DS-TTL on parent: 1h
KSK (1) [created and published] ---(progapagtion delay + DNSKEY TTL)-->
KSK (1) [ready]
---(submitted in parent zone)-->
---((3d) - (12h + 2h + 1h + x))->
KSK (2) [created and published]
KSK (2) [ready] ---(submitted in parent zone)-->
KSK (1) [retire-active], KSK (2) [active] ---(2h + 12h)->
KSK (1) [removed]
The new key was created 19 hours before the KSK-lifetime ends. When I
substract DNSKEY TTL, propagation delay and DS parent TTL its still 4
hours too early. Somebody knows why?
References:
https://www.knot-dns.cz/docs/2.7/html/reference.htmlhttps://tools.ietf.org/html/rfc6781.html#section-4.1.2
Thanks and Cheers,
Sakirnth
So problem is solved for me, I've tried to start with just one zone which didn’t helped, but removing journal did. Many thanks to Daniel Salzman for kind help, maybe he will post some other details after analyzing our journal records.
--
Lukas Kocourek
> On 2019-10-15, at 12:27, knot-dns-users-request(a)lists.nic.cz wrote:
>
> Message: 5
> Date: Tue, 15 Oct 2019 11:56:26 +0200
> From: Lukáš Kocourek <kocour(a)direcat.net>
> To: knot-dns-users(a)lists.nic.cz
> Subject: [knot-dns-users] 2.9.0 fails to start after upgrade
> Message-ID: <110451DC-3CC1-419D-9066-EF784FDDAC00(a)direcat.net>
> Content-Type: text/plain; charset=utf-8
>
> Hi,
>
> I’ve upgraded from 2.8.4 to 2.9.0 (Ubuntu 18.04, using ppa:cz.nic-labs/knot-dns-latest) and now knotd fail to start.
> After dispatching "service knot start" command knotd process immediately goes to 100% CPU and after 3 minutes it’s killed by systemd because "Start operation timed out”.
>
> Here log from service start...
>
> Oct 15 11:37:04 ns1-u18 knotc[4972]: Configuration is valid
> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: Knot DNS 2.9.0 starting
> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: loaded configuration file '/etc/knot/knot.conf'
> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: using reuseport for UDP
> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: binding to interface X.X.X.X@53
> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: binding to interface ::@53
> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: loading 199 zones
>
> [cut] - info that all zones will be loaded
> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: [xxx.yyy.] zone will be loaded
> [/cut]
>
> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: starting server
> Oct 15 11:38:34 ns1-u18 systemd[1]: knot.service: Start operation timed out. Terminating.
> Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: State 'stop-sigterm' timed out. Killing.
> Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Killing process 4984 (knotd) with signal SIGKILL.
> Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Main process exited, code=killed, status=9/KILL
> Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Failed with result 'timeout'.
>
> Any advice what to do?
>
> Thank very much
>
> --
> Lukas Kocourek
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 15 Oct 2019 12:27:34 +0200
> From: Daniel Salzman <daniel.salzman(a)nic.cz>
> To: knot-dns-users(a)lists.nic.cz
> Subject: Re: [knot-dns-users] 2.9.0 fails to start after upgrade
> Message-ID: <99813b76-c350-442f-35c7-2447cb07acce(a)nic.cz>
> Content-Type: text/plain; charset=utf-8
>
> Hi Lukáš,
>
> Could you try to temporarily disable some zones? We have no idea at the moment :-(
>
> Would it be possible to show me a snippet of your configuration?
>
> Daniel
>
> On 10/15/19 11:56 AM, Lukáš Kocourek wrote:
>> Hi,
>>
>> I’ve upgraded from 2.8.4 to 2.9.0 (Ubuntu 18.04, using ppa:cz.nic-labs/knot-dns-latest) and now knotd fail to start.
>> After dispatching "service knot start" command knotd process immediately goes to 100% CPU and after 3 minutes it’s killed by systemd because "Start operation timed out”.
>>
>> Here log from service start...
>>
>> Oct 15 11:37:04 ns1-u18 knotc[4972]: Configuration is valid
>> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: Knot DNS 2.9.0 starting
>> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: loaded configuration file '/etc/knot/knot.conf'
>> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: using reuseport for UDP
>> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: binding to interface X.X.X.X@53
>> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: binding to interface ::@53
>> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: loading 199 zones
>>
>> [cut] - info that all zones will be loaded
>> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: [xxx.yyy.] zone will be loaded
>> [/cut]
>>
>> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: starting server
>> Oct 15 11:38:34 ns1-u18 systemd[1]: knot.service: Start operation timed out. Terminating.
>> Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: State 'stop-sigterm' timed out. Killing.
>> Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Killing process 4984 (knotd) with signal SIGKILL.
>> Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Main process exited, code=killed, status=9/KILL
>> Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Failed with result 'timeout'.
>>
>> Any advice what to do?
>>
>> Thank very much
>>
>> --
>> Lukas Kocourek
>>
Hi,
I’ve upgraded from 2.8.4 to 2.9.0 (Ubuntu 18.04, using ppa:cz.nic-labs/knot-dns-latest) and now knotd fail to start.
After dispatching "service knot start" command knotd process immediately goes to 100% CPU and after 3 minutes it’s killed by systemd because "Start operation timed out”.
Here log from service start...
Oct 15 11:37:04 ns1-u18 knotc[4972]: Configuration is valid
Oct 15 11:37:04 ns1-u18 knotd[4984]: info: Knot DNS 2.9.0 starting
Oct 15 11:37:04 ns1-u18 knotd[4984]: info: loaded configuration file '/etc/knot/knot.conf'
Oct 15 11:37:04 ns1-u18 knotd[4984]: info: using reuseport for UDP
Oct 15 11:37:04 ns1-u18 knotd[4984]: info: binding to interface X.X.X.X@53
Oct 15 11:37:04 ns1-u18 knotd[4984]: info: binding to interface ::@53
Oct 15 11:37:04 ns1-u18 knotd[4984]: info: loading 199 zones
[cut] - info that all zones will be loaded
Oct 15 11:37:04 ns1-u18 knotd[4984]: info: [xxx.yyy.] zone will be loaded
[/cut]
Oct 15 11:37:04 ns1-u18 knotd[4984]: info: starting server
Oct 15 11:38:34 ns1-u18 systemd[1]: knot.service: Start operation timed out. Terminating.
Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: State 'stop-sigterm' timed out. Killing.
Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Killing process 4984 (knotd) with signal SIGKILL.
Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Main process exited, code=killed, status=9/KILL
Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Failed with result 'timeout'.
Any advice what to do?
Thank very much
--
Lukas Kocourek
Hi. Firstly, a big thank-you for knotd.
I've been writing some code for automatic configuration of DNS
delegations, including dnssec.
It's been very straightforward with knot. The code is very clean, and
the documentation extensive.
Now my request:
Your control programs seem to assume that the user is running knotc or
keymgr and generating commands interactively or via a script.
Would it be possible to expose all of the knotc and the keymgr API
functions into a separate library, like libknotd-ctrl, plus a set of
header files?
At the moment I'm forking off external shell scripts from my program,
and that works fine, but if I could call and link these control
functions direct from my own code it would be great. It's probably
possible already with some automake magic, but it's not easy for someone
of my limited skills level.
The code already exists, it'd just be some additional build steps AFAICS.
--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campai…>
Hiya,
trying to get our knot dns server (FreeBSD pkg, 2.8.1) to export
prometheus statistics.
I found https://github.com/ghedo/knot_exporter, which looks promising
(and I found that knot-resolver has this all built in, but this doesn't
help me :-/ ).
So, I've installed the required python modules, and when I start
the knot_exporter (with the right paths and everything) it complains
to me:
$ /tmp/knot_exporter --web-listen-port 4041 --knot-library-path ...
Traceback (most recent call last):
File "/tmp/knot_exporter", line 489, in <module>
args.knot_socket_timeout,
File "/usr/local/lib/python3.6/site-packages/prometheus_client/registry.py", line 24, in register
names = self._get_names(collector)
File "/usr/local/lib/python3.6/site-packages/prometheus_client/registry.py", line 64, in _get_names
for metric in desc_func():
File "/tmp/knot_exporter", line 434, in collect
for zone, zone_data in zone_stats["zone"].items():
KeyError: 'zone'
so, I read the manual, and it says that this should be sufficient:
template:
- id: default
storage: /usr/local/etc/dnsmgmt/data/CA/knot
disable-any: true
acl: [ acl_transfer, acl_notify ]
global-module: mod-stats
with or without
mod-stats:
- id: default
request-protocol: on
server-operation: on
edns-presence: on
flag-presence: on
response-code: on
reply-nodata: on
query-type: on
... but it does not seem to make a difference.
So - if one of you has a working knot-server knot.conf that exports data
to prometheus, can you share it?
thanks,
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
