Dear Knot Resolver users,
Knot Resolver 4.2.1 has been released!
Note for Debian users: If you have previously installed
knot-resolver-dbgsym package on Debian, please remove it and install
knot-resolver-dbg instead.
Bugfixes
--------
- rebinding module: fix handling some requests, respect ALLOW_LOCAL flag
- fix incorrect SERVFAIL on cached bogus answer for +cd request (!860)
(regression since 4.1.0 release, in less common cases)
- prefill module: allow a different module-loading style (#506)
- validation: trim TTLs by RRSIG's expiration and original TTL (#319,
#504)
- NS choice algorithm: fix a regression since 4.0.0 (#497, !868)
- policy: special domains home.arpa. and local. get NXDOMAIN (!855)
Improvements
------------
- add compatibility with (future) libknot 2.9
Full changelog:
https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v4.2.1/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-4.2.1.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-4.2.1.tar.xz.asc
Documentation:
https://knot-resolver.readthedocs.io/en/v4.2.1/
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
Hello Knot resolver folks, and especially the packagers,
I've noticed that the CentOS 7 packages published by CZNIC ship with
/etc/knot-resolver writable by the "knot-res" user (the directory mode
is 0775).
It seems that the directory is writable, because kresd (running as user
knot-res) runs a lua script to manage the /etc/knot-resolver/root.keys file.
My sysadmin mind is suspicious of this setup. If any other modules of
kresd have a bug, they have the potential to modify config files in
/etc/knot-resolver. My thinking is that the root.keys file should be
installed in /var/cache/knot-resolver, and that is writable by "knot-res".
Could someone please explain to me why the config directory is writable
by an unprivileged user? Is there a good reason I'm not seeing for this
setup?
Regards,
Anand Buddhdev
Hello,
Could someone help me to understand the behavior of Knot Resolver?
Can I somehow process a change in the list of static records for knot
resolver like a command for reloading configuration?
If I have in the kresd.conf file a module
modules = {
'hints> iterate', - Add static records to resolver
...
...
and the list is located
- Load static records
hints.add_hosts ('/ etc / knot-resolver / static_records.txt')
how can I reload the change in the static_records.txt list for the kresd @ 1
service
Or should I always restart the daemon kresd @ 1
systemctl restart Kresd @ 1
Thanks for any advice,
Regadrs,
--
Smil Milan Jeskyňka Kazatel
Hello,
first note the change to the correct mailing-list.
On 7/29/19 10:20 AM, Balakrishnan B wrote:
> I am trying to add wildcard static hints to catch all local domains like
> below. But does not seem to work.
>
> hints['nextcloud.local'] = '127.0.0.1' # This works fine
> hints['*.local'] = '127.0.0.1'
> hints['.local'] = '127.0.0.1'
>
> DNSMasq supports this like https://stackoverflow.com/a/22551303
>
> Is there way to do this in knot?
No, I don't think there's a good way currently. The hints module only
supports exact names with A and AAAA and corresponding PTR, like in
/etc/hosts files. With our [RPZ] you can do wildcards, but there's no
support for positive answers (so you need to do NXDOMAIN or similar
denials).
BTW, note that .local is reserved for [mDNS] protocol, in particular
kresd might never get to such requests because it's "only" a DNS server:
> 3. Name resolution APIs and libraries SHOULD recognize these names as
> special and SHOULD NOT send queries for these names to their
> configured (unicast) caching DNS server(s).
>
[RPZ]
https://knot-resolver.readthedocs.io/en/stable/modules.html#c.policy.rpz
[mDNS] https://tools.ietf.org/html/rfc6762#section-22.1
--Vladimir
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Dear Knot Resolver users,
Knot Resolver 4.1.0 has been released!
This is a minor release with couple improvements and many bugfixes,
including security fixes for CVE-2019-10190 and CVE-2019-10191.
Packages for supported distributions are now available from
https://www.knot-resolver.cz/download/
Highlights
==========
- - security fixes, we encourage all users to upgrade as soon as possible
- - new garbage collector improves cache utilization on busy machines
- - ARM64 (aarch64) is now experimentally supported, please report issues
- - compatibility with non-standard DoH clients was improved
Full release notes:
Knot Resolver 4.1.0 (2019-07-10)
================================
Security
- --------
- - fix CVE-2019-10190: do not pass bogus negative answer to client (!827)
- - fix CVE-2019-10191: do not cache negative answer with forged
QNAME+QTYPE (!839)
Improvements
- ------------
- - new cache garbage collector is available and enabled by default (#257)
This improves cache efficiency on big installations.
- - DNS-over-HTTPS: unknown HTTP parameters are ignored to improve
compatibility with non-standard clients (!832)
- - DNS-over-HTTPS: answers include `access-control-allow-origin: *`
which allows JavaScript to use DoH endpoint (!823).
- - http module: support named AF_UNIX stream sockets (again)
- - aggressive caching is disabled on minimal NSEC* ranges (!826)
This improves cache effectivity with DNSSEC black lies and also
accidentally works around bug in proofs-of-nonexistence from F5 BIG-IP
load-balancers.
- - aarch64 support, even kernels with ARM64_VA_BITS >= 48 (#216, !797)
This is done by working around a LuaJIT incompatibility.
Please report bugs.
- - lua tables for C modules are more strict by default, e.g. `nsid.foo`
will throw an error instead of returning `nil` (!797)
- - systemd: basic watchdog is now available and enabled by default (#275)
Bugfixes
- --------
- - TCP to upstream: fix unlikely case of sending out wrong message length
(!816)
- - http module: fix problems around maintenance of ephemeral certs (!819)
- - http module: also send intermediate TLS certificate to clients,
if available and luaossl >= 20181207 (!819)
- - send EDNS with SERVFAILs, e.g. on validation failures (#180, !827)
- - prefill module: avoid crash on empty zone file (#474, !840)
- - rebinding module: avoid excessive iteration on blocked attempts (!842)
- - rebinding module: fix crash caused by race condition (!842)
- - rebinding module: log each blocked query only in verbose mode (!842)
- - cache: automatically clear stale reader locks (!844)
Module API changes
- ------------------
- - lua modules may omit casting parameters of layer functions (!797)
- --
Petr Špaček @ CZ.NIC
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAl0mBC0ACgkQzo3WoaUK
IeT3uw/9Fqz2PWYmEtF50nlnFIyM44EAClQFVboM8djVQVffN347nZTo4WPI+rsj
exUg5tYKIEC6xrihRLwojbTfFcGVXcEHo0NZsvyv51qIP+lT6yHOVMz+tckmGyPI
qG4JxvF7juUz1oLNCLUJfuZX/rOBgcOID2hga6q8ZXmkE5GFkyPsz7giaxjNWCGY
Hf+uxzR2oezd4GGaOS2bIpqSjBmQwjaLvN3odG0xGZEHQCm+MkblVIbpiKuyR79e
CulWcLNU1KL4V4o/rF5BUXHCnArGP/TM0JoVifPZepZVyB8xMEfBuyew9k1EAuX6
+5oJ9H1JcsftMtBgGUtksltTVK+9Mst9Rc52oiP5RA8ffpc5j0TtQi/lgNSgGnfQ
P10t7fnlotseBYsHeQ0dm54TlGKBgsECuk1/wgjlytbUU9AUQMkmop696xZEcw1w
gVY7FhAq09ciqtNTKuPJLoNTN/uhIdnyvt496Xf15OA3znZlMxdrI+rdVvf3btX/
SV9/bzNyWtJOhiYoN4hIPUqcvq6rFqxBbZpDA3pX9ks/lsWil7Y8sm96GzOjvaSx
EjhDbBaFLBtX4kOPbrREDs8DbCTsxD1rLEruPos+Mp8PfAISEa/RvjyhuI/yyjwE
qpNksYdKNHeniYEcycJ1khJBs1cz+9GlBFdCnSdFG2tFFu4nY4g=
=pAEs
-----END PGP SIGNATURE-----
Hello,
this is pre-release announcement. We are going to release Knot Resolver
4.1.0 with two security fixes on Wednesday 2019-07-10. This release
includes fixes for CVE-2019-10190 and CVE-2019-10191.
We advise all users to upgrade to version 4.1.0 as soon as possible.
Version 4.1.0 is fully is compatible with version 4.0.0 and no manual
steps are required during upgrade.
Pre-built software packages and source code will be made available from
https://www.knot-resolver.cz/download/
during Wednesday 2019-07-10.
Customers with formal support contracts with CZ.NIC can receive fixes
immediatelly.
Software packages provided by Linux distributions (i.e. not supplied by
CZ.NIC) will follow usual release cycle of respective vendors. CZ.NIC
cannot guarantee availability and timeline related to fixes in these
packages. Nevertheless, following vendors received security patches in
advance:
ALT Linux, Amazon Linux AMI, Arch Linux, Chrome OS, CloudLinux, CoreOS,
Debian, Gentoo, Openwall, Oracle, Red Hat, Slackware, SUSE, Ubuntu, Wind
River.
Please send your questions to mailing list
knot-resolver-users(a)lists.nic.cz.
--
Petr Špaček @ CZ.NIC
Hi,
I'd like to ask your opinion about knot-resolver's systemd integration -
in particular, about the network configuration which is currently done
via drop-in files for systemd sockets - kresd.socket, kresd-tls.socket,
kresd-doh.socket and kresd-webmgmt.socket. [network-config-doc]
Have you had any issues while trying to configure network interfaces for
kresd?
Do you find the benefits of socket activation worth the extra complexity
of network configuration? (socket activation enables kresd to be
executed under non-priviledged user and the process doesn't require any
extra capabilities)
All the newtork configuration could take place in kresd.conf via
net.listen() [net-listen-exmaple] if we decided to drop the socket
activation feature. However, this would require we start the service
with the CAP_NET_BIND_SERVICE capability, which could be dropped once
kresd binds to the ports.
Any feedback is welcome!
[network-config-doc] -
https://knot-resolver.readthedocs.io/en/stable/daemon.html#network-configur…
[net-listen-exmaple] -
https://knot-resolver.readthedocs.io/en/stable/daemon.html#c.net.listen
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
Hi,
to see whether kresd 4.0.0 would do a comparable or better job
than doh-httpproxy we analyzed failure rates by looking at HTTP response
codes for each setup and found some significant differences
for HTTP response code 400:
sample size: 1 000 000 HTTP requests for each run
HTTP Code [1] [2] [3]
--------------------------------
200 93.96 97.04 96.33
499 3.28 2.45 3.11
400 2.07 0.18 0.22 <<<
415 0.68 0.32 0.34
408 0.002 0.002 0.002
413 0.001 0 0
Numbers show percent.
setups:
[1] nginx -> (http, no tls) kresd
[2] nginx -> (http, no tls) doh-httpproxy -> (udp/53) unbound
To reduce the likelihood of measuring unrelated issues (like issues
caused by qname minimization differences between unbound and kresd) we
also used kresd as DNS resolver without touching its DoH code path:
[3] nginx -> (http, no tls) doh-httpproxy -> (udp/53) kresd
The HTTP request rate for [1] was slightly lower when compared with [2]
and [3].
To be more precise, doh-httproxy services was configured with two
running instances as described here:
https://facebookexperimental.github.io/doh-proxy/tutorials/nginx-dohhttppro…
version information:
kresd 4.0.0
nginx 1.14.2
unbound 1.9.0
https://github.com/facebookexperimental/doh-proxy @
9f943a4c232bd018ae155b7839a6b4e13181a5fd
This information on its own is not very useful but it might help
motivate further tests in a test-environment with no real end-user
traffic that allows for more verbose logging.
We would also like to hear from other kresd DoH adopters if they
observe similar failure rates on their setups.
Some open questions for further tests:
- How reproducible are these results?
- Does the HTTP method (GET vs. POST) change the error rate?
- Can the error rate be reduced by running multiple kresd backends?
(nginx sending requests to two kresd bakcends)
- Is the DNS transaction ID of always 0 as per RFC8484 an issue when
kresd is not also terminating the initial HTTPS connection from the DoH
client? (from a backend's perspective two distinct queries might look
identical when a reverse proxy sits between the DoH client and kresd)
regards,
Christoph