Hello!
This occurs if for some reason the prefill file happens to be empty:
kresd[11812]: [prefill] root zone file valid for 17 hours 01 minutes,
reusing data from disk
kresd[11812]: segfault at 0 ip 00007f9b06017436 sp 00007ffc3142bb58
error 4 in libc-2.28.so[7f9b05fa1000+148000]
Apr 30 20:26:13 scruffy kernel: Code: 0f 1f 40 00 66 0f ef c0 66 0f ef
c9 66 0f ef d2 66 0f ef db 48 89 f8 48 89 f9 48 81 e1 ff 0f 00 00 48 81
f9 cf 0f 00 00 77 6a <f3> 0f 6f 20 66 0f 74 e0 66 0f d7 d4 85 d2 74 04
0f bc c2 c3 48 83
This happens in a loop until systemd gives up trying to start kresd.
Solved by removing /var/cache/knot-resolver/root.zone (0 bytes).
kresd version: 4.0.0
We use your example config from:
https://knot-resolver.readthedocs.io/en/stable/modules.html#cache-prefilling
kind regards,
Christoph
Hi,
we are a non-profit running privacy enhancing services for the public,
among those services are also public DNS resolvers supporting DoH and DoT.
We started the process to migrate our DoH/DoT endpoints to kresd 4
replacing our temporary setup using doh-httpproxy/unbound.
Here are a few questions that came up, the first ones about caching
and safe logging are the most important ones.
- kresd writes the cache to disk by default. Is there an easy way to
disable that and to switch to in-memory cache only without workarounds
like a ramdisk? (we didn't find an answer to this in the documentation
[6]) We want to avoid writing any cache data to disk.
We haven't found much documentation about logging. We would like to
ensure that no sensitive data (IP addresses, domain names) is written to
the logs. If verbose() is false, is that enough to avoid logging any IP
addresses and domains?
- Is the DoH URI configurable? (change /doh to our currently used URI)
or does that require something like
https://knot-resolver.readthedocs.io/en/stable/modules.html#how-to-expose-c…
?
- Is it possible to enable multiple DoH endpoints (URIs)
via a single kresd instance where every endpoint
has a distinct upstream configuration?
- Does kresd 4 (in the client position) support OOOR? [7]
- Are there any known kresd munin plugins
that produce graphs similar to unbound's munin plugin? [1]
- Does kresd need a reload/restart after
the TLS certificate got renewed (by letsencrypt)?
- Is there a recommended way to configure the interaction between
certbot and kresd? (the defaults would not work since kresd - starting
as knot-resolver user will not be able to read certificates owned by root)
- What is the canonical way to report security issues? (if [4] does not
work)
- Do you run a security bug bounty program?
thanks!
Christoph
The documentation under [5] does not cover all fields
in the output of "worker.stats()", it would be great if those
missing fields could be added to the documentation.
[2] links to https:// rocks.moonscript.org but the certificate is for
https://luarocks.org
[3] gives this example:
```
> print(cache.storage)
error occured here (config filename:lineno is at the bottom, if config
is involved):
stack traceback:
[C]: in function 'get'
/usr/lib/knot-resolver/sandbox.lua:265: in function '__index'
[string "return table_print(print(cache.storage))"]:1: in main chunk
ERROR: Function not implemented
```
the document probably meant?
"print(cache.current_storage)"
After solving about 20 reCAPTCHAs and errors like the following we gave
up trying to submit issues via [4].
"There was an error with the reCAPTCHA. Please solve the reCAPTCHA again."
[1] https://angristan.xyz/configure-unbound-plugin-munin/
[2] https://knot-resolver.readthedocs.io/en/stable/daemon.html
[3]
https://knot-resolver.readthedocs.io/en/stable/daemon.html#envvar-cache.cur…
[4] https://gitlab.labs.nic.cz/knot/knot-resolver/issues
[5]
https://knot-resolver.readthedocs.io/en/stable/daemon.html#c.worker.stats
[6]
https://knot-resolver.readthedocs.io/en/stable/daemon.html#cache-configurat…
[7]
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status#DN…
Hi, below is a continuation of a discussion regarding the default port
for DNS-over-HTTPS (DoH) in Knot Resolver. My argument is to use 44353
as a packaging default, since using port 443 by default makes an
unexpected collision likely. The DoH service requires configuration to
be exposed on public interfaces anyway, so users are free to override
this value as they see fit.
On 18/04/2019 15.16, Daniel Kahn Gillmor wrote:> On Thu 2019-04-18
10:01:39 +0200, Tomas Krizek wrote:
>> thanks for these constructive suggestions. I've tried to use port 443
>> for kres-doh.socket and have the socket masked (simply disabling it
>> isn't enough, since kresd(a)*.service requsts it via Sockets=).
>
> I think the answer there is, don't put it in Sockets= -- if it's
> enabled, it will get associated properly because of the Service= line,
> and if it's not enabled, it won't get associated.
Sockets= is required, otherwise the socket won't be passed to any other
instance than kresd@1, which goes against our use-case of scaling up
using multiple independent systemd processes.
>> However, I wasn't able to find a reasonable way to do it across all
>> ditros in a way that would work reliably in all cases (including
>> upgrades).
>
> Do you have a pointer to documentation about what mechanisms you tried,
> and how they failed on different distros? I'd like to understand what
> you ran into, so i can try to help reason about it without having to
> replicate all the work.
No documentation, mostly just trial and error (and a lot of swearing :)
If kresd-doh.service is masked by default, this places a symlink to
/etc/systemd/system, which is where users usually makes their changes
(as opposed to /usr/lib/systemd/system). Is this acceptable with various
packaging policies across distros?
Let's say it is. User unmasks this socket file and the uninstalls the
package. This will issue a warning, since the symlink was part of the
package.
A more problematic case is when you consider package upgrade. If
/etc/systemd/system/kresd-doh.service -> /dev/null is part of the
package, then the user removes this files via unmasking to actually use
the socket, it will get re-masked again during the next package upgrade.
>> I also think that it'd be confusing for users that kresd-doh.socket
>> would require extra command to use, as opposed to kresd-webmgmt.socket
>> (both used by http module).
>
> I don't think that's confusing. These are different interfaces, and
> it's entirely reasonable that they would be controlled separately.
I disagree. knot-resolver-module-http now provides two socket files:
kresd-doh.socket
kresd-webmgmt.socket
Now both are enabled by default after the installation, on localhost
only, and users simply need to load http module in their config.
It seems unnecessarily complicated to require additional handling of
kresd-doh.socket as opposed to kresd-webmgmt.socket (which has no reason
not to be enabled by default).
>> In the end, we've decided to go with 127.0.0.1:44353 as the default for
>> kresd-doh.socket in upstream and Fedora/EPEL packages. The documented
>> use case is how to remove this default and listen on port 443 on all
>> interfaces.
>
> Hm, that makes me sad for a number of reasons (both the ephemeral-range
> port *and* the 127.0.0.1, which doesn't make a lot of sense). I hope we
> can figure out the details together about these tradeoffs, so that we
> can make the default configuration something more useful.
I don't consider the localhost default to be an issue. All other
sockets, i.e. plain DNS and DNS-over-TLS, are configured like this and
I'd like to keep it this way. If a user decides to expose the DNS
service, it should require a manual action.
The port, of course, is a matter of lively debate. However, perhaps the
default port in kresd-doh.socket file doesn't matter all that much. It's
easy to override and documented how to do that.
> happy to talk about this on-list as well, if you prefer (presumably
> knot-resolver-users(a)lists.nic.cz).
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
Dear Knot Resolver users,
Knot Resolver 4.0.0 has been released!
This is a major release with many improvements and also some breaking
changes, please see our upgrading guide:
https://knot-resolver.readthedocs.io/en/stable/upgrading.html
Those interested in DNS-over-HTTPS are welcome to look for unintentional
Easter Bugs we may have accidentally hidden in our experimental
implementation. Upstream packages with DNS-over-HTTPS support are
available for Debian 9, CentOS 7, Ubuntu 18, Fedora and Arch.
Incompatible changes
--------------------
- see upgrading guide:
https://knot-resolver.readthedocs.io/en/stable/upgrading.html
- configuration: trust_anchors aliases .file, .config() and .negative
were removed (!788)
- configuration: trust_anchors.keyfile_default is no longer accessible
(!788)
- daemon: -k/--keyfile and -K/--keyfile-ro options were removed
- meson build system is now used for builds (!771)
- build with embedded LMBD is no longer supported
- default modules dir location has changed
- DNSSEC is enabled by default
- upstream packages for Debian now require systemd
- libknot >= 2.8 is required
- net.list() output format changed (#448)
- net.listen() reports error when address-port pair is in use
- bind to DNS-over-TLS port by default (!792)
- stop versioning libkres library
- default port for web management and APIs changed to 8453
Improvements
------------
- policy.TLS_FORWARD: if hostname is configured, send it on wire (!762)
- hints module: allow configuring the TTL and change default from 0 to 5s
- policy module: policy.rpz() will watch the file for changes by default
- packaging: lua cqueues added to default dependencies where available
- systemd: service is no longer auto-restarted on configuration errors
- always send DO+CD flags upstream, even in insecure zones (#153)
- cache.stats() output is completely new; see docs (!775)
- improve usability of table_print() (!790, !801)
- add DNS-over-HTTPS support (#280)
- docker image supports and exposes DNS-over-HTTPS
Bugfixes
--------
- predict module: load stats module if config didn't specify period (!755)
- trust_anchors: don't do 5011-style updates on anchors from files
that were loaded as unmanaged trust anchors (!753)
- trust_anchors.add(): include these TAs in .summary() (!753)
- policy module: support '#' for separating port numbers, for consistency
- fix startup on macOS+BSD when </dev/null and cqueues installed
- policy.RPZ: log problems from zone-file level of parser as well (#453)
- fix flushing of messages to logs in some cases (notably systemd) (!781)
- fix fallback when SERVFAIL or REFUSED is received from upstream (!784)
- fix crash when dealing with unknown TA key algorhitm (#449)
- go insecure due to algorithm support even if DNSKEY is NODATA (!798)
- fix mac addresses in the output of net.interfaces() command (!804)
- http module: fix too early renewal of ephemeral certificates (!808)
Module API changes
------------------
- kr_straddr_split() changed API a bit (compiler will catch that)
- C modules defining `*_layer` or `*_props` symbols need to change a bit
See the upgrading guide for details. It's detected on module load.
Full changelog:
https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v4.0.0/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-4.0.0.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-4.0.0.tar.xz.asc
Documentation:
https://knot-resolver.readthedocs.io/en/v4.0.0/
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
Hi,
I created new certs with Let's Encrypt and knot-resolver just throws
"invalid argument" when starting. The old one work fine, so first I
thought it's related that they are wildcard certs now, but also new
created certs just for "dns.mydomain.tld" also lead to the error.
Any ideas?
BR
Bjoern
