- knot-resolver-users - lists.nic.cz

by Christoph

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

6 let, 4 měsíce

3
6
0 0

trying to use resolver on lan

by B. Cook

I'm new to knot resolver (krsed). Running kresd in runit and logging via svlogd. I'm trying to run kresd on a lan with internal ip addresses and internal domains. I can currently do this with dnsmasq and unbound, but I wanted to see how kresd would do on the client facing edge. I have an Active Directory domain which I've inherited (domain.local) and I've made a building.domain dns infrastructure for the different buildings. (building-red.domain, building-orange.domain, building-green.domain, etc..) There were two AD dns servers doing all the DNS.. There is now a pihole server and dnsmasq helping to offset the queries. I'm looking to put up a kresd on the :53 and move the current dnsmasq installs to :57 and have kresd forward to them. When I do this my building.domain and domain.local are not resolvable. What am I missing? Unbound has a private-address and private-domain which handles this. Does knot resolver have something similar? egrep -v "\-\-" /etc/knot-resolver/config <code> net.listen('10.20.0.43', 53) trust_anchors.remove('.') modules = { 'policy', 'stats', 'predict' } cache.size = 100*MB cache.storage = 'lmdb:///var/cache/knot-resolver/' user( 'knot-resolver', 'knot-resolver' ) predict.config({ window = 20, period = 72 }) policy.add( policy.all( policy.FORWARD( { '10.20.0.43@57', '10.20.0.53@57' } ))) </code> Below is an excerpt from the kresd logs captured via svlogd showing the nxdomain return.. 2019-05-22_18:19:53.06750 [00000.00][plan] plan 'squid.tech.pcsd.' type 'A' uid [35568.00] 2019-05-22_18:19:53.06756 [35568.00][iter] 'squid.tech.pcsd.' type 'A' new uid was assigned .01, parent uid .00 2019-05-22_18:19:53.06758 [35568.01][cach] => trying zone: ., NSEC, hash 0 2019-05-22_18:19:53.06759 [35568.01][cach] => NSEC sname: covered by: pccw. -> pe., new TTL 83379 2019-05-22_18:19:53.06760 [35568.01][cach] => NSEC wildcard: covered by: . -> aaa., new TTL 84454 2019-05-22_18:19:53.06761 [35568.01][cach] => writing RRsets: +++ 2019-05-22_18:19:53.06762 [35568.01][iter] <= rcode: NXDOMAIN 2019-05-22_18:19:53.06768 [35568.01][resl] AD: request NOT classified as SECURE 2019-05-22_18:19:53.06773 [35568.01][resl] finished: 0, queries: 1, mempool: 16400 B and this is another request that worked successfully 2019-05-22_18:19:53.07382 [00000.00][plan] plan 'r6---sn-8xgp1vo-2iae.googlevideo.com.' type 'A' uid [24882.00] 2019-05-22_18:19:53.07384 [24882.00][iter] 'r6---sn-8xgp1vo-2iae.googlevideo.com.' type 'A' new uid was assigned .01, parent uid .00 2019-05-22_18:19:53.07388 [24882.01][cach] => skipping unfit CNAME RR: rank 020, new TTL -144 2019-05-22_18:19:53.07389 [24882.01][cach] => no NSEC* cached for zone: googlevideo.com. 2019-05-22_18:19:53.07389 [24882.01][cach] => skipping zone: googlevideo.com., NSEC, hash 0;new TTL -123456789, ret -2 2019-05-22_18:19:53.07389 [24882.01][cach] => skipping zone: googlevideo.com., NSEC, hash 0;new TTL -123456789, ret -2 2019-05-22_18:19:53.07390 [ ][nsre] score 21 for 10.20.0.43#00057; cached RTT: 19 2019-05-22_18:19:53.07391 [ ][nsre] score 40001 for 10.20.0.53#00057; cached RTT: 12666 2019-05-22_18:19:53.07391 [24882.01][resl] => id: '07414' querying: '10.20.0.43#00057' score: 21 zone cut: '.' qname: 'R6---sN-8Xgp1VO-2iae.goOgLeVIDeO.CoM.' qtype: 'A' proto: 'udp' here is dig showing that the entry does exist.. ; <<>> DiG 9.14.2 <<>> @10.20.0.43 -p 53 -t any squid.tech.pcsd ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17967 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;squid.tech.pcsd. IN ANY ;; ANSWER SECTION: squid.tech.pcsd. 300 IN A 10.20.0.69 ;; Query time: 3 msec ;; SERVER: 10.20.0.43#53(10.20.0.43) ;; MSG SIZE rcvd: 60 As I said I'm still new to kresd and it's logging format so please excuse my ignorance if the answer is obvious.. I've been reading all that I can, and I couldn't find a use case that was like mine in the documentation.. (I did find two things that were causing me problems with upstream providers in unbound because of the docs.. which is why I'm looking to try it on the lan and see what happens.. ) Thank you for taking the time to read this. I'm looking to fortify and make things more resilient with the network so that I can focus on finishing other projects.. and from what I can see.. knot will totally help me with that. Again, thanks for this piece of software - greatly appreciated. After squidguard and pihole this is what I'm sending to the outiside world (thanks to krsed.. https://imgur.com/a/tlcC6Jx -- This message may contain confidential information and is intended only for the individual(s) named. If you are not an intended recipient you are not authorized to disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system.

6 let, 5 měsíců

2
1
0 0

public nic.cz DoH service using lua-http (was: TLS misconfiguration on odvr.nic.cz (DoH))

by Christoph

(I'm including the mailing list so others can benefit from this discussion as well since we had the proxy/no-proxy topic there before) Vaclav Steiner wrote: > Our KRESd daemons are configured with lua-http module for DoH, not anz reverse proxy. Is this a temporary setup or what is the motivation behind not using any HTTP frontend since knot-resolver developers actively recommend against a "naked" kresd DoH endpoint without any reverse proxy? > And about list [3] we know. We want to be there :-) Great to hear that. kind regards, Christoph > Issue [2] I’ll say guys from knot-resolver team. Probably Firefox doesn’t have problem with it. a _fresh_ firefox 66.0.5 acutally has a problem with it: " Warning: Potential Security Risk Ahead Firefox detected a potential security threat and did not continue to odvr.nic.cz. If you visit this site, attackers could try to steal information like your passwords, emails, or credit card details. [...] " >> 20. 5. 2019 v 19:36, Christoph wrote: >> >> Hi Vaclav, >> >> thanks for running a public DoH service [1]. >> Would be great if you could add your DoH server to the >> public DNS resolver lists [3]. >> >> There is a TLS misconfiguration that results in a TLS error >> because the certificate chain is incomplete [2]. >> >> Is this a kresd without any HTTP reverse proxy like nginx in front of it? >> >> >> kind regards, >> Christoph >> >> >> [1] https://blog.nic.cz/2019/05/20/na-odvr-podporujeme-take-dns-over-https/ >> [2] >> https://www.ssllabs.com/ssltest/analyze.html?d=odvr.nic.cz&hideResults=on >> [3] https://github.com/curl/curl/wiki/DNS-over-HTTPS >> https://github.com/DNSCrypt/dnscrypt-resolvers >> > >

6 let, 5 měsíců

2
6
0 0

cache filesystem size and setting a cache size limit

by Christoph

Hi, how big should the cache filesystem (tmpfs) be relative to the cache.size? If cache.size is N MB is N + 50 MB a fine value? I'm asking because apparently 50 MB additional space is not enough: > SIGBUS received; this is most likely due to filling up the filesystem where cache resides. https://knot-resolver.readthedocs.io/en/stable/daemon.html#envvar-cache.size writes: > Note that this is only a hint to the backend, which may or may not respect it. See cache.open(). If cache.size does not set a maximum size maybe remove "Set the cache maximum size in bytes." from its documentation? :) Does that mean I have to use cache.open() as well to enforce a limit or is "max_size" also just a hint that is not respected/enforced? If so: is there a way to enforce a max_size for the cache? thanks, Christoph

6 let, 5 měsíců

4
16
0 0

OpenBuild Service package repositories update

by Tomas Krizek

Hi, I have a quick update about the upstream package repositories in OpenBuild Service (OBS). New repositories ---------------- - Fedora_30 - x86_64, armv7l - xUbuntu_19.04 - x86_64 - Debian_Next - x86_64 (Debian unstable rolling release) New repositories for Debian 10 and CentOS 8 should be available shortly after these distros are released, depending on their buildroot availability in OBS. Deprecated repositories ----------------------- - Arch - x86_64 Due to many issues with Arch packaging in OBS (invalid package size, incorrect signatures) and the fast pace of Arch updates, please consider this repository deprecated in favor of the AUR package [1] that I keep up-to-date. The Arch OBS repository will most likely be removed in the future. Also, please note I'll be periodically deleting repositories for distros that reach their official end of life. In the coming months, this concerns Ubuntu 18.10 and Fedora 28. [1] - https://aur.archlinux.org/packages/knot-resolver/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

6 let, 5 měsíců

1
0
0 0

segfault when prefill file (RFC7706) is empty

by Christoph

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

6 let, 6 měsíců

2
1
0 0

non-disk cache and safe logging

by 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…

6 let, 6 měsíců

3
7
0 0

Re: [knot-resolver-users] knot-resolver DoH port

by Tomas Krizek

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

6 let, 6 měsíců

2
3
0 0

Knot Resolver 4.0.0

by Tomas Krizek

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

6 let, 6 měsíců

1
0
0 0

TLS with new created LE certs: invalid argument

by Bjoern Franke

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

6 let, 6 měsíců

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

knot-resolver-users