knot-dns-users

knot-dns-users@lists.nic.cz

738 discussions

by Vladimír Čunát

Dear Knot Resolver users, Knot Resolver 1.5.2 is a security release! Security -------- - fix CVE-2018-1000002: insufficient DNSSEC validation, allowing attackers to deny existence of some data by forging packets. Some combinations pointed out in RFC 6840 sections 4.1 and 4.3 were not taken into account. Bugfixes -------- - memcached: fix fallout from module rename in 1.5.1 Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v1.5.2/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.5.2.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.5.2.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v1.5.2/ --Vladimir

7 let, 7 měsíců

Knot serving old zone version

by Rob Tate

Hello all, We had a weird issue with Knot serving an old version of a zone after a server reboot. After the reboot, our monitoring alerted that the zone was out of sync. Knot was then serving an older version of the zone (the zone did not update during the reboot, Knot was serving a version of the zone that was older than what it had before the reboot). The zone file on the disk had the correct serial, and knotc zone-status <zone> showed the current serial as well. However, dig @localhost soa <zone> on that box, showed the old serial. Running knotc zone-refresh <zone> didn't help, as in the logs when it went to do the refresh, it showed 'zone is up-to-date'. Running knotc zone-retransfer also did not resolve the problem, only a restart of the knotd process resolved this issue. While we were able to resolve this ourselves, it is certainly a strange issue and we were wondering if we could get any input on this. Command output: [root@ns02 ~]# knotc knotc> zone-status <zone> [<zone>] role: slave | serial: 2017121812 | transaction: none | freeze: no | refresh: +3h59m42s | update: not scheduled | expiration: +6D23h59m42s | journal flush: not scheduled | notify: not scheduled | DNSSEC re-sign: not scheduled | NSEC3 resalt: not scheduled | parent DS query: not scheduled knotc> exit [root@ns02 ~]# dig @localhost soa <zone> … … 2017090416 … … Logs after retransfer and refresh: Jan 15 16:49:22 ns02 knot[7187]: info: [<zone>] control, received command 'zone-refresh' Jan 15 16:49:22 ns02 knot[7187]: info: [<zone>] refresh, outgoing, <master>@53: remote serial 2017121812, zone is up-to-date Jan 15 16:49:23 ns02 knot[7187]: info: [<zone>] refresh, outgoing, <master>@53: remote serial 2017121812, zone is up-to-date Jan 15 16:49:23 ns02 knot[7187]: info: [<zone>] refresh, outgoing, <master>@53: remote serial 2017121812, zone is up-to-date Jan 15 16:49:23 ns02 knot[7187]: info: [<zone>] refresh, outgoing, <master>@53: remote serial 2017121812, zone is up-to-date Jan 15 16:52:45 ns02 knot[7187]: info: [<zone>] control, received command 'zone-retransfer' Jan 15 16:52:45 ns02 knot[7187]: info: [<zone>] AXFR, incoming, <master>@53: starting Jan 15 16:52:45 ns02 knot[7187]: info: [<zone>] AXFR, incoming, <master>@53: finished, 0.00 seconds, 1 messages, 5119 bytes Jan 15 16:52:45 ns02 knot[7187]: info: [<zone>] refresh, outgoing, <master>@53: zone updated, serial none -> 2017121812 Jan 15 16:52:45 ns02 knot[7187]: info: [<zone>] refresh, outgoing, <master>@53: remote serial 2017121812, zone is up-to-date Jan 15 16:52:45 ns02 knot[7187]: info: [<zone>] refresh, outgoing, <master>@53: remote serial 2017121812, zone is up-to-date Jan 15 16:52:45 ns02 knot[7187]: info: [<zone>] refresh, outgoing, <master>@53: remote serial 2017121812, zone is up-to-date Jan 15 16:53:03 ns02 knot[7187]: info: [<zone>] control, received command 'zone-status' And a dig after that: [root@ns02 ~]# dig @localhost soa crnet.cr … … 2017090416 … … -Rob

7 let, 7 měsíců

Knot collectd plugin

by Julian Brost

Hi, I wrote a collectd plugin which fetches the metrics from "knotc [zone-]status" directly from the control socket. The code is still a bit work in progress but should be mostly done. If you want to try it out, the code is on Github, feedback welcome: https://github.com/julianbrost/collectd/tree/knot-plugin https://github.com/collectd/collectd/pull/2649 Also, I'd really like some feedback on how I use libknot, as I only found very little documentation on it. If you have any questions, just ask. Regards, Julian

7 let, 7 měsíců

Knot on Ubuntu 14.04

by Klaus Darilion

Hi! I installed the Knot 2.6.3 packages from PPA on Ubuntu 14.04. This confuses the syslog logging. I am not sure but as I think the problem is that Knot requires systemd for logging. The problem is, that I do not see any logging of Knot in my syslogserver, only in journald. Is this something special in Knot that the logging is not forwarded to syslog? Is it possible to use your Ubuntu Packages without systemd logging? I think it would be better to build the packages on non-systemd distros (ie Ubuntu 14.04) without systemd dependencies. Thanks Klaus

7 let, 7 měsíců

notauth vs. refused

by Klaus Darilion

Hi! Knot 2.6.3: When an incoming NOTIFY does not match any ACL the NOTIFY is replied with "notauth" although the zone is configured. I would have expected that Knot should response with "refused" in such a scenario. Is the notauth intended? From operational view a "refuses" would easy debugging. regards Klaus

7 let, 8 měsíců

acl without tsig-key

by Klaus Darilion

> key > > An ordered list of references to TSIG keys. The query must match one of them. Empty value means that TSIG key is not required. > > Default: not set This is not 100% correct. At least with a notify ACL the behavior is: Empty value means that TSIG keys are not allowed. regards Klaus

7 let, 8 měsíců

Zone sign at knotd reload

by Aleš Rygl

Hi everybody, I would have a question related to zone signing. Whenever I reload knot config using knotc reload it starts to resign all DNSSEC enabled zones. It makes the daemon sometimes unresponsive to knotc utility. root@idunn:# knotc reload error: failed to control (connection timeout) Is it a design intent to sign zones while reloading config? Is it really needed? It invokes zone transfers, consumes resources, etc. Thanks for answer With regards Ales

7 let, 8 měsíců

Knot DNS 2.6.4 and 2.5.7 releases

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.6.4! This version improves the synthrecord module and fixes big zone transfers with a TSIG, structured logging, and DNSSEC re-signing. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.6.4/NEWS Documentation: https://www.knot-dns.cz/docs/2.6/html/ Source code: https://secure.nic.cz/files/knot-dns/knot-2.6.4.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.6.4.tar.xz.asc Some of the bugfixes were backported to Knot DNS 2.5.7. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.5.7/NEWS Documentation: https://www.knot-dns.cz/docs/2.5/html/ Source code: https://secure.nic.cz/files/knot-dns/knot-2.5.7.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.5.7.tar.xz.asc Regards, Daniel

7 let, 8 měsíců

Zone transfer from KNOT (master) to BIND (slave) fails with NAUTH

by Matthias Nagel

Helly everybody, there is a KNOT DNS master name server that I do not manage myself for my domain. I try to setup a BIND DNS server as a slave in-house. BIND fails to do the zone transfer and reports 31-Dec-2017 16:19:02.503 zone whka.de/IN: Transfer started. 31-Dec-2017 16:19:02.504 transfer of 'whka.de/IN' from 2001:7c7:2000:53::#53: connected using 2001:7c7:20e8:18e::2#53509 31-Dec-2017 16:19:02.505 transfer of 'whka.de/IN' from 2001:7c7:2000:53::#53: failed while receiving responses: NOTAUTH 31-Dec-2017 16:19:02.505 transfer of 'whka.de/IN' from 2001:7c7:2000:53::#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.001 secs If try dig (this time using the IPv4 address), I get a failure, too. # dig axfr @141.70.45.160 whka.de. ; <<>> DiG 9.9.5-9+deb8u7-Debian <<>> axfr @141.70.45.160 whka.de. ; (1 server found) ;; global options: +cmd ; Transfer failed. Wireshark tells me that the reply code of the name server is `1001 Server is not an authority for domain`. What is going on here? Especially, if I query the same nameserver for an usual A-record it claims to be authoritative. Moreover, KNOT DNS manual says KNOT is an authoritative-only name server. So there is no way of being non-authoritative. Has anybody already observed something like this? Best regards, Matthias -- Evang. Studentenwohnheim Karlsruhe e.V. – Hermann-Ehlers-Kolleg Matthias Nagel Willy-Andreas-Allee 1, 76131 Karlsruhe, Germany Phone: +49-721-96869289, Mobile: +49-151-15998774 E-Mail: matthias.nagel(a)hermann-ehlers-kolleg.de

7 let, 8 měsíců

Knot Resolver 1.5.1 release

by Vladimír Čunát

Dear Knot Resolver users, Knot Resolver 1.5.1 is released, mainly with bugfixes and cleanups! Incompatible changes -------------------- - script supervisor.py was removed, please migrate to a real process manager - module ketcd was renamed to etcd for consistency - module kmemcached was renamed to memcached for consistency Bugfixes -------- - fix SIGPIPE crashes (#271) - tests: work around out-of-space for platforms with larger memory pages - lua: fix mistakes in bindings affecting 1.4.0 and 1.5.0 (and 1.99.1-alpha), potentially causing problems in dns64 and workarounds modules - predict module: various fixes (!399) Improvements ------------ - add priming module to implement RFC 8109, enabled by default (#220) - add modules helping with system time problems, enabled by default; for details see documentation of detect_time_skew and detect_time_jump Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v1.5.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.5.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-1.5.1.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v1.5.1/ --Vladimir

7 let, 8 měsíců

← Newer
1
...
33
34
35
36
37
38
39
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users