Hello,
We have a setup where a Knot DNS server is a slave and a DNS
provisioning system acts as a hidden master. The DNS server process in
the hidden master is some vendor specific implementation, not NSD, Bind
or anything well-known. Now, for random zones we see the following
errors in Knot when trying to update the zone:
Jan 31 10:33:23 host knotd[14148]: info: [xxxxx.] notify, incoming,
a:b:c:d::e@51097: received, serial none
Jan 31 10:33:23 host knotd[14148]: info: [xxxxx.] refresh, outgoing,
a:b:c:d::e@8054: remote serial 2017013116, zone is outdated
Jan 31 10:33:23 host knotd[14148]: info: [xxxxx.] IXFR, incoming,
a:b:c:d::e@8054: starting
Jan 31 10:33:23 host knotd[14148]: warning: [xxxxx.] IXFR, incoming,
a:b:c:d::e@8054: failed (malformed data)
Jan 31 10:33:23 host knotd[14148]: warning: [xxxxx.] refresh, outgoing,
a:b:c:d::e@8054: fallback to AXFR
Jan 31 10:33:23 host knotd[14148]: warning: [xxxxx.] refresh, remote
'....' not usable
As we can see, Knot first receives a notify message that triggers IXFR.
For yet unknown reason, IXFR fails due to "malformed data", after which
Knot fallbacks to AXFR. However, from tcpdump capture (I can share the
pcap off-list, if needed) we can see, that Knot reuses the same TCP
socket for AXFR as it used for IXFR, but immediately after sending the
AXFR query Knot sends TCP RST to the hidden master thus closing the TCP
connection, making the remote/master server to be unusable from Knot's
point of view.
The negative thing is that after the failure Knot gives up trying to
update the zone, leaving the zone to its old SOA serial, maybe until it
expires. So far we also don't know, what causes the IXFR to fail in the
first place. From what we can see, the zone data seems to be valid so
it's unclear why Knot fails with "malformed data". However, after
manually running "knotc zone-retransfer <zone>" once, subsequent IXFRs
succeed. Unfortunately we have very limited options to configure the
hidden master, because as said, it is a vendor specific implementation.
So we have two issues here: failing IXFR and then failure in AXFR
fallback due to TCP connection reset on the Knot side. Do you have any
ideas? Oh, forgot to mention that the Knot version is 2.4.0.
Thank you in advance for all help,
Antti
Hello,
after some testing I have deployed Knot DNS to one of our
authoritative servers with almost 90k zones and it looks very well.
I have one small problem with statistics, especiallly with
interpreatation of statistics (mod-stats).
There are some counters, but i cannot find any reliable approach, how
to calculate numbers like queries per second, which is interesting for
future hardware scaling.
Did I missed anything? Or would it be possible to add one simple
counter - something like server.uptime = (seconds from last reload).-
because all counters are reset after reload.
Finally, thanks for Knot DNS - well done!
Best regards,
Frantisek Princ
Hello,
I am trying to use mod-dnstap on Knot DNS 2.4.0, but I am getting this error
root@knot:~# knotc conf-check
error: config, file '/etc/knot/knot.conf', line 27, item 'mod-dnstap',
value '' (invalid item)
error: failed to load configuration file '/etc/knot/knot.conf' (invalid item)
Here is used configuration:
server:
user: knot:knot
listen: [ 0.0.0.0@53, ::@53 ]
log:
- target: stderr
any: warning
- target: syslog
server: info
zone: notice
any: error
acl:
- id: acl_dk-hostmaster
address: [ 193.163.102.6, 2a01:630:0:40:3:4:5:6 ]
action: transfer
- id: acl_hu-hostmaster
address: 193.239.249.0/24
action: transfer
control:
listen: knot.sock
timeout: 30
mod-dnstap:
- id: capture_all
sink: /tmp/capture.tap
template:
- id: default
global-module: mod-dnstap/captuer_all
global-module: mod-stats
include: /var/lib/knot-data/zones/zones_include_knot
Knot DNS is installed on Debian Jessie from package (version
2.4.0-1+0~20170120113157.17+jessie~1.gbp8e34c2)
I found similar topic in archives (
https://lists.nic.cz/pipermail/knot-dns-users/2016-September/000944.html
), but there was no solution.
Regards,
František Princ
Hello,
I've tried to upgrade from knot 2.3.3 to 2.4.0, but ran into a DNSSEC
related error, invalidating my DNSSEC-enabled zones :
2017-01-25T15:33:42 notice: [geekwu.org.] journal, obsolete exists, file '/var/lib/knot/external/geekwu.org.db'
2017-01-25T15:33:42 error: [geekwu.org.] DNSSEC, failed to initialize (not found)
2017-01-25T15:33:42 error: [geekwu.org.] zone event 'load' failed (not found)
stracing the error leads to this :
[pid 16787] open("/var/lib/knot/external/keys/policy_\\x06policy.json", O_RDONLY) = -1 ENOENT (No such file or directory)
I have some policy files in /var/lib/knot/external/keys:
-rw-r--r-- 1 knot knot 320 janv. 26 2016 policy_default.json
-rw-r--r-- 1 knot knot 320 janv. 26 2016 policy_default_rsa.json
-rw-r--r-- 1 knot knot 320 juin 14 2016 policy_ecdsa.json
>From where these \\x06policy may come ?
Thanks,
--
Bastien
Dear Knot Resolver users,
CZ.NIC is proud to release a new release of Knot Resolver.
The team has worked very hard to bring:
- reworked DNSSEC Validation, that fixes several know problems
with less standard DNS configurations, and it is also a solid
base for further improvements
- optional EDNS(0) Padding support for DNS over TLS
- support for debugging DNSSEC with CD bit
- DNS over TLS is now able to create ephemeral certs on the runtime
(Thanks Daniel Kahn Gilmore for contributing to DNS over TLS
implementation in Knot Resolver.)
- configurable minimum and maximum TTL (default 6 days)
- configurable pseudo-random reordering of RR sets
- new module 'version' that can call home and report new versions
and security vulnerabilities to the log file
This release also fixes bugs, most notable ones:
- The resolver was setting AD flag when running in a forwarding
mode. Thanks Stéphane Bortzmeyer for reporting this issue!
- We now correctly return RCODE=NOTIMPL on meta-queries and
non IN class queries
- Fix crash in hints module when hints file was empty
- Fix non-lowercase hints
We also have a new LRU implementation under the hood.
That's it! Thank you for using Knot Resolver. And if you are
not using it yet, please give it a try.
Full changelog:
https://gitlab.labs.nic.cz/knot/resolver/raw/v1.2.0/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.0.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.0.tar.xz.asc
Documentation:
http://knot-resolver.readthedocs.io/en/latest/
--
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/
--------------------------------------------
Dear Knot DNS users,
CZ.NIC is proud to release the 2.4.0 release of Knot DNS. This release
contains many improvements over 2.3.x release of Knot DNS.
The Knot DNS 2.4.x is the new stable branch. Starting from this release
we are going to support current stable (2.4.x) and previous stable (2.3.x)
branches, and at the same time we are deprecating previous Knot DNS 1.6.x
release.
Now the new features we are so excited about!
* We have a new journal to store zone changes, it's key features are:
- all journals for all zones are in a single LMDB database
(defaults to storage/journal; 1G size)
- the occupied space is measured per zone
- old changesets get preserved after zone flush until we run out of space
- if zone flushing is disabled and journal gets full, it tries to free up
space by merging older changesets
- all changes are done by transactions, resulting in always-consistent DB
(but some mutexes still necessary for opening DB && for keeping zone
contents consistent with journal)
- kjournalprint provides a way to list zones in journal
- old journal is automatically imported, but the configuration needs to be
updated manually
* Thanks to qp-trie (originally proposed by Tony Finch) adapted to Knot DNS
we have much lower memory consumption when Knot DNS is used with many
zones
* The zone timers and zone events have been refactored and improved
* The SOA query and transfer now shares the TCP connection
* There's a new statistics module for traffic measurements
There are also several other bugfixes and improvements related to transfers,
timers and other areas.
And that's it! Thank you for using Knot DNS. And we are really looking
forward to your feedback.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/raw/v2.4.0/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-2.4.0.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-dns/knot-2.4.0.tar.xz.asc
Documentation:
https://www.knot-dns.cz/docs/2.x/html/
--
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,
can someone please give me any explanation (or command) how my domain
registrator got from this record what i give him:
liberland.cz. 3600 DNSKEY 257 3 13
ei9T3egqng+nlAHeNfF6BzggGCyvS2lU5ih2BZuvkzFGxkBdUJ0blgSiW5iYIROvAEHQv5Ls3sNPA9JIt8iRjg==
this record:
liberland.cz. 17999 IN DS 21107 13 2
9405F3324FDCE3F0CC4E5D94CBFB5D8A4F211E3010D447B5FD73765F9EEC20EB
???
I want sign child zones but I can't find where i get hash
,,9405F3324FDCE3F0CC4E5D94CBFB5D8A4F211E3010D447B5FD73765F9EEC20EB"
And algorithm in RFC:
https://tools.ietf.org/html/rfc4034#section-5.4
digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
"|" denotes concatenation
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
doesn't help me :-/
Thanks and regards,
Jakub
Dear Knot Resolver users,
CZ.NIC is proud to release a new release candidate of Knot Resolver.
The team has worked very hard to bring:
- reworked DNSSEC Validation, that fixes several know problems
with less standard DNS configurations, and it is also a solid
base for further improvements
- optional EDNS(0) Padding support for DNS over TLS
- support for debugging DNSSEC with CD bit
- DNS over TLS is now able to create ephemeral certs on the runtime
(Thanks Daniel Kahn Gilmore for contributing to DNS over TLS
implementation in Knot Resolver.)
- configurable minimum and maximum TTL (default 6 days)
- configurable pseudo-random reordering of RR sets
- new module 'version' that can call home and report new versions
and security vulnerabilities to the log file
This release also fixes bugs, most notable ones:
- The resolver was setting AD flag when running in a forwarding
mode. Thanks Stéphane Bortzmeyer for reporting this issue!
- We now correctly return RCODE=NOTIMPL on meta-queries and
non IN class queries
- Fix crash in hints module when hints file was empty
- Fix non-lowercase hints
We also have a new LRU implementation under the hood.
That's it! Thank you for using Knot Resolver. And if you are
not using it yet, please give it a try.
Full changelog:
https://gitlab.labs.nic.cz/knot/resolver/raw/v1.2.0-rc1/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.0-rc1.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.0-rc1.tar.xz.asc
Documentation:
http://knot-resolver.readthedocs.io/en/latest/
--
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/
--------------------------------------------
Hola,
As recently a variety of people claimed to me that 'running DNSSEC is
not scary'.... I was like, lets try again after having tried it ~10
years ago and it failing miserably.
DNSSEC auto-maintain style looks to be better; still not as nice as
running dual-nsd's in master mode; but we'll live with those moving parts.
It ran fine for a bit, till I noticed the signatures of the zone had
expired and noticed the master simply did not bother to update the sigs
anymore. So much for 'automatic' mode.
Restarting it caused a nice crash:
Debian provided jessie-backports 2.3.1-1~bpo8:
```
knotd[6679]: *** Error in `/usr/sbin/knotd': double free or corruption
(out): 0x00007f4244042e80 ***
```
Then was like... lets try the latest edition:
Debian provided unstable 2.3.2-1:
```
knotd[11892] general protection ip:7fb8f7f0f218 sp:7fb8ce1cc3b0 error:0
in libc-2.24.so[7fb8f7e98000+195000]
````
yes, that is on a newer libc, hence different style error message it seems.
The 2.3.1 edition was able to report:
```
error: [example.com] changes from journal applied 1 -> 1 (invalid parameter)
````
before crashing out, the 2.3.2 just borks out.
Unfortunately there are no dbgsym packages for those editions, thus
can't easily dig what goes wrong where without having to resort to
manually building it all.
I could also not find a way to signup to:
https://gitlab.labs.nic.cz/users/sign_in
to be able to file a ticket about this.
Any extra details that one should be providing outside of the above
(link to that list is welcome ;) )
Should I attempt knot-nightly?
Greets,
Jeroen
PS: News on https://labs.nic.cz/en/ ends in April 2016...
