Hi all,
Is there a way to reload dynamically the knot-resolver configuration
without stopping knot-resolver ?
e.g I have to add this in the config file
extraTrees = policy.todnames({'foo.example.net'})
policy.add(policy.suffix(policy.FLAGS({'NO_CACHE'}), extraTrees))
policy.add(policy.suffix(policy.FORWARD({'192.168.0.15'}), extraTrees))
Is there a sort of CLI command to take it in account ?
Regards
______________________________
*Pierrick CHOVELON I *Ingénieur système
*Advanced Software I IT*
+33 4 77 43 27 05
pierrick.chovelon(a)savoye.com
*SAVOYE - 8, rue de la Richelandière - 42100 - Saint-Etienne - France*
*Savoye recrute ! <https://careers.savoye.com/#!/fr/index> - *www.savoye.com
Dear Knot Resolver users,
Knot Resolver 5.1.0 has been released!
We also have two important announcements:
1) Ubuntu and Debian repositories
Ubuntu and Debian users have to manually set up the upstream repository
once again by following the instructions at:
https://www.knot-resolver.cz/download/
We apologize for the inconvenience, tests are now in place to prevent
this from happening again.
2) The upcoming major version will contain reworked
hints/policy/prefill/rebinding/view modules and related functionalities.
Please participate in the following survey to ensure we do not forget
about your particular use-case:
https://www.knot-resolver.cz/survey/
It will help us to improve Knot Resolver. Thank you!
Our upstream repositories now also provide packages for CentOS 8,
Ubuntu 20.04 and Fedora 32.
And finally, the release notes for version 5.1.0:
Improvements
------------
- cache garbage collector: reduce filesystem operations when idle (!946)
- policy.DEBUG_ALWAYS and policy.DEBUG_IF for limited verbose logging
(!957)
- daemon: improve TCP query latency under heavy TCP load (!968)
- add policy.ANSWER action (!964, #192)
- policy.rpz support fake A/AAAA (!964, #194)
Bugfixes
--------
- cache: missing filesystem support for pre-allocation is no longer
fatal (#549)
- lua: policy.rpz() no longer watches the file when watch is set to
false (!954)
- fix a strict aliasing problem that might've lead to "miscompilation"
(!962)
- fix handling of DNAMEs, especially signed ones (#234, !965)
- lua resolve(): correctly include EDNS0 in the virtual packet (!963)
Custom modules might have been confused by that.
- do not leak bogus data into SERVFAIL answers (#396)
- improve random Lua number generator initialization (!979)
- cache: fix CNAME caching when validation is disabled (#472, !974)
- cache: fix CNAME caching in policy.STUB mode (!974)
- prefill: fix crash caused by race condition with resolver startup
(!983)
- webmgmt: use javascript scheme detection for websockets' protocol
(#546)
- daf module: fix del(), deny(), drop(), tc(), pass() functions
(#553, !966)
- policy and daf modules: expose initial query when evaluating
postrules (#556)
- cache: fix some cases of caching answers over 4 KiB (!976)
- docs: support sphinx 3.0.0+ (!978)
Incompatible changes
--------------------
- minor changes in module API; see upgrading guide:
https://knot-resolver.readthedocs.io/en/stable/upgrading.html
Full changelog:
https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v5.1.0/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-5.1.0.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-5.1.0.tar.xz.asc
Documentation:
https://knot-resolver.readthedocs.io/en/v5.1.0/
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
Dobrý den,
dnes po mnoha dnech (měsíců) bezproblémového provozu knot-resolveru
4.2.2 najednou přestal vracet odpovědi na dotazy.
Využívá jej několik tisíc klientů, tak nebyl moc čas na experimerny a
reboot celého stroje pomohl... Ale jen asi na 15min. Pak opět přestal
vracet záznamy, jako by je neměl. Opět reboot a to vydrželo fungovat asi
1.5h a opt přestal komunikovat. To už začalo být vážné, takže jsme
spoustu DNS dotazů na routrech přesměrovali na 8.8.8.8. Mezi tím opět
restart a nyní to již téměř 2h funguje bez problémů.
Vím, že nyní již existuje knot-resolver verze 5.0.1, ale zajímá mě, zda
uvedený problém je známy, jen jsem se sním do dnes nesetkal a v další
verzi opraven, nebo se jedná o neevidovanou anomálii. V logách jsem
totiž našel jen toto:
Apr 27 18:17:56 knot-resolver systemd[1]: kresd(a)4.service: Watchdog
timeout (limit 10s)!
Apr 27 18:17:56 knot-resolver systemd[1]: kresd(a)4.service: Killing
process 382 (kresd) with signal SIGABRT.
Apr 27 18:17:56 knot-resolver systemd[1]: kresd(a)4.service: Main process
exited, code=killed, status=6/ABRT
Apr 27 18:17:56 knot-resolver systemd[1]: kresd(a)4.service: Failed with
result 'watchdog'.
Apr 27 18:17:56 knot-resolver systemd[1]: kresd(a)4.service: Service
RestartSec=100ms expired, scheduling restart.
Apr 27 18:17:56 knot-resolver systemd[1]: kresd(a)4.service: Scheduled
restart job, restart counter is at 1.
Předpokládám, že tato nemilá reakce knot-resolveru byla způsobena
nějakým "spatným" dotazem, ať náhodným nebo záměrným.
Nyní jsme opět zrušili přesměrovaní na 8.8.8.8 a téměř okamžitě přestal
odpovídat:
dig @192.168.100.100 -t AAAA www.seZNAm.cz
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @192.168.100.100 -t AAAA www.seZNAm.cz
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64547
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.seZNAm.cz. IN AAAA
;; Query time: 0 msec
;; SERVER: 192.168.100.100#53(192.168.100.100)
;; WHEN: Po dub 27 22:32:04 CEST 2020
;; MSG SIZE rcvd: 42
Děkuji za pomoc
Zdeněk Janiš
Hi,
the package signing key for our upstream repositories has expired and
Debian and Ubuntu users with existing installation need to manually
update the knot-resolver-release package to fix the issue:
wget https://secure.nic.cz/files/knot-resolver/knot-resolver-release.deb
dpkg -i knot-resolver-release.deb
apt update
Otherwise, apt update will report following errors and no new updates
will be installed.
W: GPG error:
http://download.opensuse.org/repositories/home:/CZ-NIC:/knot-resolver-lates…
InRelease: The following signatures were invalid: EXPKEYSIG
74062DB36A1F4009 home:CZ-NIC OBS Project <home:CZ-NIC@build.opensuse.org>
E: The repository
'http://download.opensuse.org/repositories/home:/CZ-NIC:/knot-resolver-lates…
InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is
therefore disabled by default.
I apologize for the inconvenience.
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
Hello,
Would it be possible to maintain the Fedora 29 knot-resolver repo for a few
more months? It recently dropped off the mirrors and it's unclear if some
F29 machines will be updated for a few more months.
Thanks!
R
Dear Knot Resolver users,
Knot Resolver 5.0.0 has been released!
This version has a few backward incompatible changes. Most notably, the
network interface configuration has been moved back to the configuration
file and configuration via systemd sockets is no longer supported.
Unfortunately, this change requires a manual modification of your
configuration file if you've previously configured your network
interfaces via systemd sockets. Please follow the instructions printed
out during package upgrade and check out our upgrading guide:
https://knot-resolver.readthedocs.io/en/stable/upgrading.html
We apologize for the inconvenience.
Incompatible changes
--------------------
- see upgrading guide:
https://knot-resolver.readthedocs.io/en/stable/upgrading.html
- systemd sockets are no longer supported (#485)
- net.listen() throws an error if it fails to bind; use freebind option
if needed
- control socket location has changed (!922)
- -f/--forks is deprecated (#529, !919)
Improvements
------------
- logging: control-socket commands don't log unless --verbose (#528)
- use SO_REUSEPORT_LB if available (FreeBSD 12.0+)
- lua: remove dependency on lua-socket and lua-sec, used lua-http and
cqueues (#512, #521, !894)
- lua: remove dependency on lua-filesystem (#520, !912)
- net.listen(): allow binding to non-local address with freebind
option (!898)
- cache: pre-allocate the file to avoid SIGBUS later (not macOS;
!917, #525)
- lua: be stricter around nonsense returned from modules (!901)
- user documentation was reorganized and extended (!900, !867)
- multiple config files can be used with --config/-c option (!909)
- lua: stop trying to tweak lua's GC (!201)
- systemd: add SYSTEMD_INSTANCE env variable to identify different
instances (!906)
Bugfixes
--------
- correctly use EDNS(0) padding in failed answers (!921)
- policy and daf modules: fix postrules and reroute rules (!901)
- renumber module: don't accidentally zero-out request's .state (!901)
Full changelog:
https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v5.0.0/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-5.0.0.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-5.0.0.tar.xz.asc
Documentation:
https://knot-resolver.readthedocs.io/en/v5.0.0/
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
Hello Petr,
many thanks for your hint regarding modules.unload('bogus_log')
I´m still facing the service kresd@1 crashes without any obvious reasons.
Today I did a second try to upgrade to Knot Resover to version 4.2.2 and the
upgrade seems to be ok, service can start without any difficulties. It runs
as expected more than 3,5 hour, but unfortunately, it starts to write in the
log the same messages as was reported in my previous post and the service
get restart by itself. Every restarts couse a new sevice PID in /var/cache/
knot-resolver/tty, the old one was not correctly finished and the whole
operating system goes to a visible slowdown. I don´t know how to do an
exact sevice crashdump file, but I can provide any log messages if needed.
I unload the bogus_log.
The service runs now just a while. My usual dns queries throughput is around
700qps and I have only one PID in /var/cache/knot-resolver/tty as usual.
Regards,
--
Smil Milan Jeskyňka Kazatel
---------- Původní e-mail ----------
Od: knot-resolver-users-request(a)lists.nic.cz
Komu: knot-resolver-users(a)lists.nic.cz
Datum: 25. 10. 2019 11:53:00
Předmět: knot-resolver-users Digest, Vol 93, Issue 1
"Send knot-resolver-users mailing list submissions to
knot-resolver-users(a)lists.nic.cz
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.nic.cz/mailman/listinfo/knot-resolver-users
or, via email, send a message with subject or body 'help' to
knot-resolver-users-request(a)lists.nic.cz
You can reach the person managing the list at
knot-resolver-users-owner(a)lists.nic.cz
When replying, please edit your Subject line so it is more specific
than "Re: Contents of knot-resolver-users digest..."
Today's Topics:
1. Re: DNSSEC validation failure logging on Centos 7 Knot
Resolver, version 4.2.0 (Milan Jeskynka Kazatel)
2. Re: DNSSEC validation failure logging on Centos 7 Knot
Resolver, version 4.2.0 (Petr Špaček)
3. HTTP module after upgrade from Knot DNS Resolver, version
2.3.0 to Knot Resolver, version 4.2.0 (Milan Jeskynka Kazatel)
----------------------------------------------------------------------
Message: 1
Date: Tue, 22 Oct 2019 14:27:30 +0200 (CEST)
From: "Milan Jeskynka Kazatel" <KazatelM(a)seznam.cz>
To: <knot-resolver-users(a)lists.nic.cz>
Subject: Re: [knot-resolver-users] DNSSEC validation failure logging
on Centos 7 Knot Resolver, version 4.2.0
Message-ID: <1XT.6dmr.1vQ4HW9UcyY.1ThlMo(a)seznam.cz>
Content-Type: text/plain; charset="utf-8"
Hello Team,
I found it, it is described in the Upgrading guide,
DNSSEC validation is now turned on by default. If you need to disable it,
see Trust anchors and DNSSEC
(https://knot-resolver.readthedocs.io/en/stable/daemon.html#dnssec-config).
***
Since version 4.0, DNSSEC validation is enabled by default. This is secure
default and should not be changed unless absolutely necessary.
Options in this section are intended only for expert users and normally
should not be needed.
If you really need to turn DNSSEC off and are okay with lowering security of
your system by doing so, add the following snippet to your configuration
file.
<span style='box-sizing:border-box;color:rgb(64,128,144);font-style:italic'>
-- turns off DNSSEC validation</span>
<span style='box-sizing:border-box'>trust_anchors</span><span style='box-
sizing:border-box'>.</span><span style='box-sizing:border-box'>remove</span>
<span style='box-sizing:border-box'>(</span><span style='box-sizing:border-
box;color:rgb(64,112,160)'>'.'</span><span style='box-sizing:border-box'>)</
span>.
***
Anyway, if it is enabled by default, how to prevent the "DNSSEC validation
failure" spamming in the log and increasing the I/O operation on the
system?
For me now is the service in the unstable condition. My kresd@1 is crashing
and restarting in the row. Please, any advice?
I modify the server name and the domain, but still it is a live log output.
Oct 22 14:02:51 dnstestserver kresd[15877]: DNSSEC validation failure
example.com DNSKEY
Oct 22 14:02:58 dnstestserver kresd[15877]: DNSSEC validation failure
example.com DNSKEY
Oct 22 14:03:08 dnstestserver kresd[15877]: DNSSEC validation failure
example.com DNSKEY
Oct 22 14:03:18 dnstestserver systemd[1]: kresd(a)1.service watchdog timeout
(limit 10s)!
Oct 22 14:03:22 dnstestserver systemd[1]: kresd(a)1.service: main process
exited, code=killed, status=6/ABRT
Oct 22 14:03:22 dnstestserver systemd[1]: Unit kresd(a)1.service entered
failed state.
Oct 22 14:03:22 dnstestserver systemd[1]: kresd(a)1.service failed.
Oct 22 14:03:22 dnstestserver systemd[1]: kresd(a)1.service holdoff time over,
scheduling restart.
Oct 22 14:03:22 dnstestserver systemd[1]: Cannot add dependency job for unit
kresd.service, ignoring: Unit not found.
Oct 22 14:03:22 dnstestserver systemd[1]: Stopped Knot Resolver daemon.
Oct 22 14:03:22 dnstestserver systemd[1]: Starting Knot Resolver daemon...
Oct 22 14:04:07 dnstestserver kresd[16468]: [http] created new ephemeral TLS
certificate
Oct 22 14:04:07 dnstestserver systemd[1]: Started Knot Resolver daemon.
Oct 22 14:04:07 dnstestserver kresd[16468]: [ta_update] refreshing TA for .
Oct 22 14:04:07 dnstestserver kresd[16468]: [ta_update] key: 20326 state:
Valid
Oct 22 14:04:07 dnstestserver kresd[16468]: [ta_update] next refresh for .
in 24 hours
Oct 22 14:04:09 dnstestserver kresd[16468]: DNSSEC validation failure
example.com DNSKEY
...
Best regards.
--
Smil Milan Jeskyňka Kazatel
---------- Původní e-mail ----------
Od: Milan Jeskynka Kazatel <KazatelM(a)seznam.cz>
Komu: knot-resolver-users(a)lists.nic.cz
Datum: 22. 10. 2019 13:33:46
Předmět: DNSSEC validation failure logging on Centos 7 Knot Resolver,
version 4.2.0
"Hello Team,
I would like to know if the "DNSSEC validation failure logging" is enabled
by DEFAULT in version 4.2.0. on Centos 7.
I do not have any explicit call for this module - as is described in the
documentation like this: modules.load('bogus_log'), nevertheless, I´m facing
a huge report in the system log regarding DNSSEC validation failure
somedomainname. DNSKEY
In the configuration, I´m using the 'http' module and module 'stats', can it
be relevant?
kresd.conf
-- Load Useful modules
modules = {
'policy', -- Block queries to local zones/bad sites
'view', -- Handle requests by source IP
'stats', -- Track internal statistics
'hints', -- Add static records to resolver
}
-- load HTTP module with defaults (self-signed TLS cert)
modules.load('http')
http.config()
How can I disable DNSSEC validation failure logging?
best regards,
--
Smil Milan Jeskyňka Kazatel
"
Hello Team,
I would like to ask why my new version of Knot Resolver does many records of
"DNSSEC validation failure szn-broken-dnssec.cz. DNSKEY"
I tried to compare results with my second resolver on Unbound 1.9.4 where I'
m able to receive an answer by command #unbound-control lookup szn-broken-
dnssec.cz
but no answer via dig command #dig szn-broken-dnssec.cz
The same result via dig is on the server with new Knot Resolver 4.2.2
As was mentioned in your documentation https://knot-resolver.readthedocs.io/
en/stable/modules.html#dnssec-validation-failure-logging
(https://knot-resolver.readthedocs.io/en/stable/modules.html#dnssec-validati…)
I tried the https://dnsviz.net/d/szn-broken-dnssec.cz/dnssec/
(https://dnsviz.net/d/szn-broken-dnssec.cz/dnssec/)
and the result is BOGUS,
then should I be worried about this message in my log?
Thanks for any answer,
best regards
--
Smil Milan Jeskyňka Kazatel