-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
does Knot have a feature like "rndc stats" in BIND or "nsd-control
stats" that allows you to get some statistics about how many queries
were handled and what their result were (like SERVFAIL etc.)?
Julian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJU8zytAAoJECLcYT6QIdBtLg8P/2wF5gwHQigZ5dI5S2pztM0C
ryKAV5h6mqSuO91S+qA7IAP3GpAlzs5GrNYW9kGXspo+w9mwb/D5+mNhDSOGyoW9
iItT16TATzwpNK89Gw2uRhVJ2BhYTuQTmrp3WwAYHAe6wYGOQdBtZoel5UzSrm5e
I//3DFgmpGHSwITRcxOBl2MYhRpHEhiBQdUjk2MmTcy/L3GF1HMlY2oHuy4sFZk+
lL6x9N/NX/6K5OspF8p8eoNQ7LIBIA6OKNhz08SdsAKSe1F76pL+FPnb8iQUC6Ao
EXkdeFftxOxocL+TTSpAhqEF86IXvRsiNSic8wjYXt9blsMcOAJQFNgU25Bs5+IV
u8EtZgcusq5SbHD0Dp5wYkNV4BYYmjU2omzjxMtqV4MFZG9V8XFlXbfVwC64fsUe
YfYjvK071EK2hVHTrui637tnS8uEcTJa0X8lpCEgYsy+6/EGyQ3H/8eyu77jZT57
yeZnfG4Ai/QrgS6w3jEu3+uk+kwds2wYHqHbIIw3o0GQ8awQ0kPC6tKg0dXI7aFN
tlYBM0mycQv3hFSk7x6jxJ1UPWVxdIOrNg8Vgg8FsgWnXu+JHJJxEV7uoj5DogTJ
PaSFOQccTrVoa1vwJgiHLmOALdY/5FDb9cddN1GBgj2wqcUkS/hR8tSRNXkLShhX
BTijrkJTR8qeiEEFgthp
=bPR2
-----END PGP SIGNATURE-----
Hello everyone,
on behalf of CZ.NIC Labs, I would like to announce Knot DNS 1.6.2. The
patch release contains one new feature and a few small bug fixes.
With the new version, a number of concurrent TCP clients connected to
the server can be limited. The limit is set using the 'max-tcp-clients'
configuration option in the 'system' section. Purpose of this setting is
to avoid resource exhaustion when the server is under a load. And the
default value for the option is 100.
When the limit is hit, new connections are not being accepted for a few
seconds. Active connections are not affected. Please note, that we have
also slightly lowered defaults for TCP idling timeouts.
As for the bug fixes: A possible file descriptor leak when terminating
inactive TCP clients was fixed. Scheduled events for zones switched from
slave mode to master mode are handled correctly. And compilation of
Dnstap features on FreeBSD works now.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/blob/v1.6.2/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-1.6.2.tar.xzhttps://secure.nic.cz/files/knot-dns/knot-1.6.2.tar.gz
GPG signatures:
https://secure.nic.cz/files/knot-dns/knot-1.6.2.tar.xz.aschttps://secure.nic.cz/files/knot-dns/knot-1.6.2.tar.gz.asc
Thank you for using Knot DNS.
Best Regards,
Jan
--
Jan Včelák, Knot DNS
CZ.NIC Labs https://www.knot-dns.cz
--------------------------------------------
Milešovská 5, 130 00 Praha 3, Czech Republic
WWW: https://labs.nic.czhttps://www.nic.cz
Hello everyone!
After months of keeping our secrets, we would like to share with you a preview
of a new DNSSEC implementation in Knot DNS. The new DNSSEC will be one of the
key features for the upcoming Knot DNS 2.0.
If you are watching our source repository, you may have noticed a tag v1.99.0
appearing silently at the end of 2014. At that time, Knot DNS was already
using the newly implemented DNSSEC, but the only visible change was a
different key format. And internally, GnuTLS/Nettle was replaced OpenSSL for
cryptographic operations.
Today, CZ.NIC Labs releases Knot DNS 1.99.1. The next step towards the 2.0.
Knot DNS 1.99.1 adds initial support for DNSSEC KASP (Key And Signature
Policy). This is our vision of real-world DNSSEC deployment. Essentially, you
define a policy (used algorithm, key sizes, key lifetime, signature lifetime,
etc.) and the server will do the heavy lifting. It will generate keys and
publish/roll them correctly, so you don't have to compute and set timing
meta-data on private keys manually.
At the moment, the KASP support is quite limited: Single algorithm, single
KSK, and single ZSK can be specified in the policy. The server is able to
generate initial keys and perform ZSK rollovers (key pre-publish method).
More features are coming soon.
A documentation on KASP [1] is currently available on the project wiki,
including the reference manual for a new management utility keymgr [2].
[1] https://gitlab.labs.nic.cz/labs/knot/wikis/kasp-setup
[2] https://gitlab.labs.nic.cz/labs/knot/wikis/kasp-keymgr-reference
Source archives are available as usual:
https://secure.nic.cz/files/knot-dns/knot-1.99.1.tar.xzhttps://secure.nic.cz/files/knot-dns/knot-1.99.1.tar.gz
Please note, that Knot DNS 1.99.1 is not ready to replace Knot DNS 1.6.x.
We are looking forward to hear some feedback from you. And we are happy to
answer all your questions and concerns.
Best regards,
Jan
--
Jan Včelák, Knot DNS
CZ.NIC Labs https://www.knot-dns.cz
--------------------------------------------
Milešovská 5, 130 00 Praha 3, Czech Republic
WWW: https://labs.nic.czhttps://www.nic.cz
Good evening,
I don't seem to be able to configure Knot 1.6.1 to sign a zone it slaves
in:
example.com {
file "/usr/local/etc/knot/aa/example.com.zone";
xfr-in home;
dnssec-keydir "/usr/local/etc/knot/aa";
dnssec-enable on;
}
If I omit the two 'dnssec-*' parameters, the zone is slaved in. Adding
them, however, results in no transfer; log shows:
notice: [example.com] automatic DNSSEC signing enabled, disabling incoming XFRs
Is it currently possible with Knot to sign a slaved zone?
Regards,
-JP
Hi,
> How would one go about converting from PowerDNS to KnotDNS on an active
> realtime AnyCast DNS network with maximum seamless efficiency or minimal temporary
> disruption of services to existing DNS users?
>
If it's truly anycast it should only be easier, I would simply:
- stop announcing the anycasted prefix at node #1
- once you see no queries anymore: convert and test
- after finishing: switch on routing
- repeat untill node #last
Unless you have bizarre performance complications, above would be more safe than converting an active node.
Did I maybe misunderstand the question? Or did you mean:
"how to convert from pdns with a transactional SQL backend to a conventional DNS setup with Knot" ..?
Leo
Hello All,
I've decided to use Knot DNS as secondary nameserver for my local zone.
I have several subnets connected via VPN and they have their own
nameservers. So, there are records in my zone
zu-gw.vpn.mithril. 3600 IN A 172.19.0.6
zu.mithril. 3600 IN NS zu-gw.vpn.mithril.
and I want to resolve domain in zu.mithril:
BIND (master):
# dig @tessa.mithril melissa.zu.mithril
; <<>> DiG 9.8.3-P4 <<>> @tessa.mithril melissa.zu.mithril
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7626
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;melissa.zu.mithril. IN A
;; ANSWER SECTION:
melissa.zu.mithril. 0 IN A 172.19.3.1
;; AUTHORITY SECTION:
zu.mithril. 3600 IN NS zu-gw.vpn.mithril.
;; ADDITIONAL SECTION:
zu-gw.vpn.mithril. 3600 IN A 172.19.0.6
;; Query time: 143 msec
;; SERVER: 172.19.37.1#53(172.19.37.1)
;; WHEN: Wed Jan 14 19:24:27 2015
;; MSG SIZE rcvd: 92
KNOT (secondary):
# dig @mira.mithril melissa.zu.mithril
; <<>> DiG 9.8.3-P4 <<>> @mira.mithril melissa.zu.mithril
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10182
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;melissa.zu.mithril. IN A
;; AUTHORITY SECTION:
zu.mithril. 3600 IN NS zu-gw.vpn.mithril.
;; ADDITIONAL SECTION:
zu-gw.vpn.mithril. 3600 IN A 172.19.0.6
;; Query time: 0 msec
;; SERVER: 172.19.38.2#53(172.19.38.2)
;; WHEN: Wed Jan 14 19:24:51 2015
;; MSG SIZE rcvd: 76
I understand that it's happening because of recursion in bind, but how
can I solve this problem in knot?
--
With best regards,
Eugene Bolshakoff
How would one go about converting from PowerDNS to KnotDNS on an active realtime AnyCast DNS network with maximum seamless efficiency or minimal temporary disruption of services to existing DNS users?
Hi Knot developers,
I've now installed version 1.6.1 on some servers, and I'm observing some
journal related issues, and I have questions about them. First off,
here's one issue:
2014-12-15T06:00:56 info: [203.in-addr.arpa] NOTIFY, incoming,
193.0.0.198@53535: received serial 3006121318
2014-12-15T06:00:56 info: [203.in-addr.arpa] refresh, outgoing,
193.0.0.198@53: master has newer serial 3006121317 -> 3006121318
2014-12-15T06:00:56 info: [203.in-addr.arpa] IXFR, incoming,
193.0.0.198@53: starting
2014-12-15T06:00:57 warning: [203.in-addr.arpa] IXFR, incoming,
193.0.0.198@53: failed to write changes to journal (not enough space
provided)
2014-12-15T06:00:58 notice: [203.in-addr.arpa] IXFR, incoming,
193.0.0.198@53: fallback to AXFR
2014-12-15T06:00:58 info: [203.in-addr.arpa] AXFR, incoming,
193.0.0.198@53: starting
2014-12-15T06:00:59 info: [203.in-addr.arpa] AXFR, incoming,
193.0.0.198@53: finished, serial 3006121317 -> 3006121318, 0.65 seconds,
171 messages, 7960312 bytes
So it looks like the IXFR is too big, and won't fit into the journal,
and Knot is falling back to AXFR. When I requested this IXFR by hand, I got:
$ dig ixfr=3006121317 203.in-addr.arpa @193.0.0.198
...
...
;; XFR size: 121779 records (messages 170, bytes 7963389)
The size of the IXFR in bytes is below the configured file size limit
(10M), but I suspect that 7963389 bytes probably take up more room in
the journal, so Knot can't write into it, and is falling back to AXFR.
Are you able to tell me (approximately of course), how much disk space
is required for a given number of bytes of IXFR? This will help me tune
the setting of ixfr-fslimit to avoid this unnecessary fallback to AXFR.
Hi Knot developers,
I have another question about journals. I've noticed that for one zone,
the journal size is 9M (with my configured limit at 10M).
Now, I see this each time in the logs:
2014-12-15T07:56:02 notice: [103.in-addr.arpa] journal is full, flushing
2014-12-15T08:13:09 notice: [103.in-addr.arpa] journal is full, flushing
2014-12-15T08:16:35 notice: [103.in-addr.arpa] journal is full, flushing
2014-12-15T08:20:27 notice: [103.in-addr.arpa] journal is full, flushing
It looks like once a journal is close to the maximum size, then it just
remains at that size, with the result that each time an IXFR comes in,
and overflows the journal, Knot wants to flush the changes to disk
immediately. Does Knot discard old records from the journal at this point?
Anand