Hi there,
I'm having some issues configuring dnstap. I'm using Knot version 2.5.1,
installed via the `knot` package on Debian 3.16.43-2. As per this
documentation
<https://www.knot-dns.cz/docs/2.5/html/modules.html#dnstap-dnstap-traffic-lo…>,
I've added the following lines to my config file:
mod-dnstap:
- id: capture_all
sink: "/etc/knot/capture"
template:
- id: default
global-module: mod-dnstap/capture_all
But when starting knot (e.g. by `sudo knotc conf-begin`), I get the message:
error: config, file 'etc/knot/knot.conf', line 20, item 'mod-dnstap', value
'' (invalid item)
error: failed to load configuration file '/etc/knot/knot.conf' (invalid
item)
I also have the same setup on an Ubuntu 16.04.1 running Knot version
2.4.0-dev, and it works fine.
Any idea what might be causing the issue here? Did the syntax for
mod-dnstap change or something? Should I have installed from source? I do
remember there being some special option you needed to compile a dependency
with to use dnstap when I did this the first time, but I couldn't find
documentation for it when I looked for it.
Thanks!
-Sarah
Hi,
after upgrade to 2.5.1 the output of knotc zone-status shows strange
timestamps for refresh and expire:
[example.net.] role: slave | serial: 1497359235 | transaction: none |
freeze: no | refresh: in 415936h7m15s | update: not scheduled |
expiration: in 416101h7m15s | journal flush: not scheduled | notify: not
scheduled | DNSSEC resign: not scheduled | NSEC3 resalt: not scheduled |
parent DS query: not schedule
However the zone is refreshed within correct interval, so it seems its
just a display issue. Is this something specific to our setup?
Regards
André
Dear Knot Resolver users,
CZ.NIC is proud to announce the release of Knot Resolver 1.3.0.
The biggest feature of this release is the support for DNSSEC Validation
in the forwarding mode, the feature many people were eagerly awaiting for.
We have also squeezed refactoring of AD flag handling and several other
bugfixes. The 1.3.0 is currently the recommended release to run at your
recursive nameservers.
Here's the 1.3.0 changelog:
Security
--------
- Refactor handling of AD flag and security status of resource records.
In some cases it was possible for secure domains to get cached as
insecure, even for a TLD, leading to disabled validation.
It also fixes answering with non-authoritative data about nameservers.
Improvements
------------
- major feature: support for forwarding with validation (#112).
The old policy.FORWARD action now does that; the previous non-validating
mode is still avaliable as policy.STUB except that also uses caching (#122).
- command line: specify ports via @ but still support # for compatibility
- policy: recognize 100.64.0.0/10 as local addresses
- layer/iterate: *do* retry repeatedly if REFUSED, as we can't yet easily
retry with other NSs while avoiding retrying with those who REFUSED
- modules: allow changing the directory where modules are found,
and do not search the default library path anymore.
Bugfixes
--------
- validate: fix insufficient caching for some cases (relatively rare)
- avoid putting "duplicate" record-sets into the answer (#198)
Full changelog:
https://gitlab.labs.nic.cz/knot/resolver/raw/v1.3.0/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-1.3.0.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-1.3.0.tar.xz.asc
Documentation:
http://knot-resolver.readthedocs.io/en/latest/
Cheers,
--
Ondřej Surý -- Technical Fellow
--------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:ondrej.sury@nic.cz https://nic.cz/
--------------------------------------------
Hi,
we updated knot from 2.4.3 to 2.5.1 and the include statement does not
seem to work anymore:
error: config, file '/etc/knot/zones.conf', line 5, item 'domain', value
'example.net' (duplicate identifier)
error: config, file '/etc/knot/knot.conf', line 73, include ''
(duplicate identifier)
error: failed to load configuration file '/etc/knot/knot.conf'
(duplicate identifier)
cat > /etc/knot/knot.conf << 'EOF'
# THIS CONFIGURATION IS MANAGED BY PUPPET
# see man 5 knot.conf for all available configuration options
server:
user: knot:knot
listen: ["0.0.0.0@53", "::@53"]
version:
log:
- target: syslog
any: info
key:
- id: default
algorithm: hmac-sha512
secret:
pLEG3Z6uvMtKiQsmOp4tMDyyxENLyJGx8kIbud24tfHdY0uRO82Qix8D2opoA/rndcd2fdt9Ba1LhHDefCK1VQ==
remote:
- id: ns1
address: ["xxxx1", "yyyy1"]
key: default
- id: ns2
address: ["xxxx2", "yyyy2"]
key: default
- id: ns3
address: ["xxxx3", "yyyy3"]
key: default
acl:
- id: notify_from_master
action: notify
address: ["xxxx1", "yyyy1"]
key: default
- id: transfer_to_slaves
action: transfer
address: ["xxxx2", "xxxx2", "xxxx3", "yyyy3"]
key: default
policy:
- id: default_rsa
algorithm: RSASHA256
ksk-size: 2048
zsk-size: 1024
template:
- id: default
file: /var/lib/knot/zones/%s.zone
kasp-db: /var/lib/knot/kasp
storage: /var/lib/knot
- id: master_default
acl: ["transfer_to_slaves"]
file: /var/lib/knot/zones/%s.zone
ixfr-from-differences: on
notify: ["ns2", "ns3"]
serial-policy: unixtime
storage: /var/lib/knot
- id: master_dnssec
acl: ["transfer_to_slaves"]
dnssec-policy: default_rsa
dnssec-signing: on
file: /var/lib/knot/zones/%s.zone
notify: ["ns2", "ns3"]
storage: /var/lib/knot
zonefile-sync: -1
- id: slave
acl: ["notify_from_master"]
master: ns1
serial-policy: unixtime
storage: /var/lib/knot
include: "/etc/knot/zones.conf"
EOF
cat > /etc/knot/zones.conf << 'EOF'
# THIS CONFIGURATION IS MANAGED BY PUPPET
# see man 5 knot.conf for all available configuration options
zone:
- domain: example.net
template: slave
- domain: example.com
template: slave
- domain: example.org
template: slave
EOF
If I add the content from zones.conf into knot.conf it works. It seems
like the included file gets parsed twice, when I add a domain twice, it
will fail at the line with the duplicate zone. If there are no duplicate
domains in the file, it always fails at the first domain found.
Is this a bug or something with our setup?
Regards
André
Dear Knot DNS users,
CZ.NIC has released Knot DNS 2.5.1 that fixes issues that some users might
experience when upgrading existing DNSSEC enabled installations of Knot DNS.
Knot DNS 2.5.1 (2017-06-07)
===========================
Bugfixes:
---------
- pykeymgr no longer crash on empty json files in the KASP DB directory
- pykeymgr no longer imports keys in the "removed" state
- Imported keys in the "removed" state no longer makes knotd to crash
- Including an empty configuration directory no longer makes knotd to crash
- pykeymgr is distributed and installed to the distribution tarball
Thank you for using Knot DNS. Feel free to write us, fill an issue or
just say thank you if you are happy with Knot DNS.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/raw/v2.5.1/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-2.5.1.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-dns/knot-2.5.1.tar.xz.asc
Documentation:
https://www.knot-dns.cz/docs/2.x/html/
Cheers,
--
Ondřej Surý -- Technical Fellow
--------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:ondrej.sury@nic.cz https://nic.cz/
--------------------------------------------
Hello Knot DNS users,
CZ.NIC has just released the 2.5.0 version of Knot DNS with the
following features:
- New LMDB-based KASP database, which no longer uses JSON files and
provides
better performance and robustness. With this change, the keymgr syntax
has been
redesigned and new pykeymgr utility was introduced for migration from
the previous version.
- Automatic DNSSEC signing newly supports KSK rollover and optional
shared KSK keys.
During the key submission, CDS and CDNSKEY records are generated. A
periodical checking
for new DS at the masters or a maximum time interval can be configured
for automatic
finalization of the rollover or by manual calling the
zone-ksk-submitted knotc command.
- Completely new query module API with dynamic loading functionality.
So, for example, the dnstap module can be a separate package in a
repository.
- Zone events freeze and thaw knotc operations, which allow reliable
manual zone
modification along with possible automatic modifications.
- Zone journal can be used to store full zone contents beside the
subsequent zone
differences if the zone file synchronization is disabled. This
configuration is especially
interesting on slave servers. Manual zone flush is still possible with
an optional
destination directory parameter.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/raw/v2.5.0/NEWS
Source code:
https://secure.nic.cz/files/knot-dns/knot-2.5.0.tar.xzhttps://secure.nic.cz/files/knot-dns/knot-2.5.0.tar.xz.asc
Documentation:
https://www.knot-dns.cz/docs/2.5/html/
In addition to that, Knot DNS 2.4.4 patch release has been released,
including some
event timing and journal fixes.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/raw/v2.4.4/NEWS
Source code:
https://secure.nic.cz/files/knot-dns/knot-2.4.4.tar.xzhttps://secure.nic.cz/files/knot-dns/knot-2.4.4.tar.xz.asc
Regards,
Daniel
Hi,
I have the following configuration working for unbound, how can I get
the same behavior working in knot-resolver?
server:
do-not-query-localhost: no
domain-insecure: "stubzone"
local-zone: "stubzone" nodefault
stub-zone:
name: "stubzone"
stub-addr: 127.0.0.2
I run this for various testing and what I want is to redirect a zone to
a local DNS server and I also what the resolver to follow any
delegations it receives.
Cheers,
Jerry
Dear all,
I setup knot to do an automatic rollover of the zsk after 180 days
policy:
- id: policy
keystore: keystore
manual: off
single-type-signing: off
algorithm: rsasha256
ksk-size: 4096
zsk-size: 2048
zsk-lifetime: 180d
propagation-delay: 1d
However I can not see on which date this will be.
root@vserver:~# keymgr zone key list yyy.ch
- 28f58xx 6862
- 79fb61b77xx 63816
root@vserver:~# keymgr zone key list yyy.ch
- 28f58xx 6862
- 79fb61b77xx 63816
root@vserver:~# keymgr zone key show yyy.ch
Name of zone and key have to be specified.
root@vserver:~# keymgr zone key show yyy.ch 28f58xx
id 28f58xx
keytag 6862
algorithm 8
size 4096
flags 257
publish 1491505038
active 1491505038
retire 0
remove 0
root@vserver:~# keymgr zone key show yyy.ch 79fb61b77xx
id 79fb61b77xx
keytag 63816
algorithm 8
size 2048
flags 256
publish 1491504999
active 1491504999
retire 0
remove 0
How do I know it is activated and when it will be ?
I imported the keys - can this be the reason ?
Thank you and
best regards
Dirk
Hi all,
I'm currently looking for alternatives which do automatic DNSSEC signing
as a master DNS server. I run a Knot secondary instance and added a
manual and auto signing zone, because I want to understand the
differences and which is better for my needs.
I added this to my knot.conf
policy:
- id: rsa
algorithm: RSASHA256
ksk-size: 2048
zsk-size: 1024
- id: manual
manual: on
zone:
- domain: "auto.test."
file: "/etc/knot/master/auto.test.zone"
dnssec-signing: on
dnssec-policy: default
- domain: "manual.test."
file: "/etc/knot/master/manual.test.zone"
dnssec-signing: on
dnssec-policy: manual
I'm not sure about how some things work, perhaps someone can answer my
questions.
When auto signing is used, the ZSKs are rolled automated? And the KSK
rollover is not possible at all? Even not manual?
For manual mode, I followed these steps to generate the keys:
$ keymgr zone key generate manual.test algorithm RSASHA256 size 1024
$ keymgr zone key generate manual.test algorithm ECDSAP256SHA256 size
256
This results in
dig @localhost DNSKEY manual.test +short
256 3 8 AwEAAbGES3TH8jPCIhcdc93dbDNoUkDn5YmviG2/lkCESDcIvzpRFjsC
ATAZEIEo1LosM6cALS8AVkxKK/BSOpuvLHvhX7O+ny7eX5X/C2PHnGs+
WMieIhbjLJWdIsNCMhSqQ7vTlguFmHbUdyzV+8dnrMl1GSpdSc1P0Fyp vjxDM5+H
256 3 13 H+qtCYv9A0RlqQCOtDyGGEMhVgn92wPdZ+WrqRAqb/MJ3RzdDSyhaX2p
B/TU5F8mQccrVIdiJriT+zmWpoW9sA==
I don't understand why there is no DNSKEY with SEP set. Shouldn't it be
there?
Regards,
Volker
