Dear Knot Resolver users,
a bugfix release of Knot Resolver 1.2.3 has been released.
The release contains following bugfixes:
- Disable storing GLUE records into the cache even in the
(non-default) QUERY_PERMISSIVE mode
- iterate: skip answer RRs that don't match the query
- layer/iterate: some additional processing for referrals
- lib/resolve: zonecut fetching error was fixed
The update from 1.2.2 to 1.2.3 is recommended. The update from 1.1.x
to 1.2.x branch is strongly recommended.
Full changelog:
https://gitlab.labs.nic.cz/knot/resolver/raw/v1.2.3/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.3.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-1.2.3.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/
--------------------------------------------
Hi,
We would like to enable ECS responses in our Knot server in order to
indicate to recursives that they should send it in requests if they can. The
goal is gauge how widespread usage of this feature this is and to collect
some statistics on the client networks being transmitted. We don't have a
way of providing tailored responses yet (not sure how this would be done,
but that's another topic.) Is there a way of enabling ECS so that it's
included in responses, perhaps with a scope prefix-length of 0 (as
described in section 12.1 of draft-ietf-dnsop-edns-client-subnet-08)?
Thanks,
Chuck
Dear Knot DNS users,
CZ.NIC is proud to release the 2.4.1 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.
This is a bugfix release containing small fixes, but the upgrade is
recommended.
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.1/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-2.4.1.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-dns/knot-2.4.1.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/
--------------------------------------------
Hello, all
When using knot DNS resolver, the following error was output.
Feb 06 20:19:43 dns02 kresd[24857]: error: /usr/lib/knot-resolver/predict.lua:34: 'struct rr_type' has no member named 'nil'
$ kresd -V
Knot DNS Resolver, version 1.2.1
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial
Is it related to setting reorder_RR (true)?
Is this a configuration issue in this case? Or is it a known bug?
Thanks.
Hi,
Is there any chance to configure the mod-dnsproxy to forward all requests for only one zone to another dns server?
I have this configuration in bind configuration file:
zone "example.com" IN {
type forward;
forwarders {
1.2.3.4;
};
};
Is there any way to do it in knot?
Best regards,
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
