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

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.0.12 (early-access) has been released! Security: - DoS: fix rare crashes with either of the lines below (!1682) [system] requirement "h && h->end > h->begin" failed in queue_pop_impl [system] requirement "val == task" failed in session2_tasklist_del Bugfixes: - daemon: fix DoH with multiple "parallel" queries in one connection (#931, !1677) - /management/unix-socket: revert to absolute path (#926, !1664) - fix `tags` when used in /local-data/rules/*/records (!1670) - stats: request latency was very incorrect in some cases (!1676) Improvements: - /local-data/rpz/*/watchdog: new configuration to enable watchdog for RPZ files (!1665) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.12/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.12.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.12.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.0.12/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

1 den, 11 hodin

1
0
0 0

Knot Resolver 5.7.5

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.7.5 (stable) has been released! Please consider using our packages from https://pkg.labs.nic.cz/doc/?project=knot-resolver and https://copr.fedorainfracloud.org/coprs/g/cznic/knot-resolver5 if you're not already using them. Security: - DoS: fix unconfirmed crashes with the line below (!1683) [system] requirement "h && h->end > h->begin" failed in queue_pop_impl Improvements: - tests: disable problematic config.http test (#925, !1678) - validator: accept a confusing NODATA proof with insecure delegation (!1678) Bugfixes: - daemon/http: DoH stream got stuck after returning an error code (!1652) - stats: request latency was very incorrect in some cases (!1678) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.7.5/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.5.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.5.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v5.7.5/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

1 den, 11 hodin

1
0
0 0

Re: Weird memleak since v6.0.9

by Vladimír Čunát

I'm afraid that DoH in 6.0.x is in much worse trouble than just memleaks; see: https://gitlab.nic.cz/knot/knot-resolver/-/issues/931

1 týden, 1 den

1
0
0 0

Is it possible to forward to authoritative servers?

by Stephane Bortzmeyer

I'm trying to set up a resolver with the addition of an invented TLD (this is an experiment, no need to explain to me that it may be a bad idea). I have authoritative name servers for the dummy TLD, which is signed with DNSSEC and I want DNSSEC validation. The documentation says that policy.FORWARD requires to forward to a resolver :-( policy.STUB disables validation so it is a no-no. If I configure with policy.add + policy.FORWARD, and trust_anchors.add for the key of the dummy TLD, it works for the TLD apex, for subdomains of the TLD which are NOT signed but for signed subdomains of the TLD, I get SERVFAIL + "EDE: 12 (NSEC Missing): (AHXI)". Querying directly the authoritative name servers with the DO bit, I get all the RRSIG and NSEC I need. But apparently, Knot cannot get them. Knot-resolver 5.7.4

1 týden, 4 dny

2
2
0 0

Kresd installation

by Ulrich Wisser

Hi, on a fresh debian system I followed this installation guide https://www.knot-resolver.cz/documentation/stable/quickstart-install.html The package installed successfully, but after that things get a bit more difficult The installed gpg key is expired > /etc/apt/trusted.gpg.d/cznic-obs.gpg > ------------------------------------ > pub rsa2048 2018-02-15 [SC] [verfallen: 2024-08-15] > 4573 7F9C 8BC3 F3ED 2791 8182 7406 2DB3 6A1F 4009 > uid [ verfallen ] home:CZ-NIC OBS Project > <home:CZ-NIC@build.opensuse.org> > > "verfallen" means expired. Sorry that system speaks german (german hoster). Makes it kind of hard to install kresd. :-) And while we are at it, why are there no kresd packages for the raspberry pi? Please!!! Kind regards /Ulrich

1 týden, 4 dny

2
2
0 0

Re: Weird memleak since v6.0.9

by Vladimír Čunát

On 02/04/2025 23.19, oui.mages_0w(a)icloud.com wrote: > So knot-resolver 6.0.8 with libknot15 seems to also trigger the memory > leak I was experiencing with knot-resolver 6.0.9+ by the unidentified > traffic pattern (or whatever is causing this). Thanks, this is very interesting. I confirm that (for our Ubuntu 24.04 packages), libknot15 (i.e. knot 3.4) is used exactly since 6.0.9, so the timing checks out, too. That's just a matter of binary builds. Even the latest versions can still be built with libknot14 (3.3.x) Have you looked into which libdnssec and libzscanner you have there? The thing is that these two didn't change soname between knot 3.3 and 3.4, so here I see larger risks than with libknot itself.

2 týdny, 6 dní

3
3
0 0

Knot-resolver stats module per process

by Marcel Adamski

Hello, In short, we do use stats module with http module exposing webmgmt every time SYSTEMD process knot is started (we do have 30 on one machine). Unfortunately each of webmgmt shows the same stats in /stats or /metrics endpoint (prometheus) Checking metrics with socat, going into each process and running stats.list() shows correctly stats per process. Is there any way to have automatically exported per knot process statistics? Regards, _ *Marcel Adamski*DevOps Engineer *M: *+48 882 115 524 *Redge *Technologies Ostrobramska 86 | 04-163 Warsaw *T: *+48 22 255 11 00 | *F: *+48 22 255 15 50 *www.redge.com* <https://redge.com/> [image: RedgeTechnologies] *Redge Technologies Sp. z o.o.* *VAT No:* PL1132687365 | *REGON:* 141103558 | *KRS: *0000287417 District Court for the Capital City of Warsaw, XIV Commercial Division of National Court Register | Share capital: 501 650 PLN We use personal data in accordance with our privacy policy <https://redge.com/privacy-policy/>

4 týdny

2
1
0 0

Kresd - Multiple instances.

by Łukasz Trąbiński

Hello We are using knot-resolver 5.7.4 with multiple independent instances - 32. We also use tmpfs. We starts processes by systemd. the problem we encountered is that when systemd starts 32 processes, they get a timeout and are restarted by systemd. As a result, we have problems starting all processes. The problem does not occur when we do not use tmpfs. How to solve this problem? We shoud add to systemd something like this? ExecStartPre=/bin/sleep $(( RANDOM % 5 )) [Service] StartLimitBurst=5 StartLimitIntervalSec=10 Or we should something to kresd configuration?

1 měsíc

1
0
0 0

root trust anchors

by Mike Wright

Hi, I've found this warning in my journal: ... kresd[1071788]: [taupd ] you need to update package with trust anchors in "/usr/share/dns/root.key" before it breaks I don't know how to do that. I think my system is current but just ran: apt update; apt list --upgradable and it shows nothing regarding knot. Thanks for any pointers, Mike Wright

1 měsíc, 3 týdny

3
3
0 0

Knot Resolver 6.0.10

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.0.10 (early-access) has been released! Improvements: - avoid multiple log lines when IPv6 isn't available (!1633) - manager: fix startup on Linux without libsystemd (!1608) - auto-reload TLS certificate files (!1626) - Can be configured using the /network/tls/files-watchdog option. (!1645) - reload TLS certificate files even if the configuration has not changed (!1644) - kresctl: bash command-line TAB completion (!1622) - add request prioritization (defer) to mitigate DoS attacks (!1641) - views: allow overriding price-factor (!1646) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.10/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.10.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.10.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.0.10/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

1 měsíc, 3 týdny

4
6
0 0

Knot Resolver 6.0.11

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.0.11 (early-access) has been released! Bugfixes: - manager: avoid an uncommon startup race in policy-loader (!1653) [WARN] exited: policy-loader (exit status 0; not expected) - manager: fix processes watchdog errors during shutdown (!1651) - /cache/prefill/*/ca_file: fix setting this attribute (!1655) Improvements: - manager: allow multiple instances with different rundirs (!1656) - tests: disable problematic config.http test (#925, !1662) - /management/unix-socket: allow path relative to rundir (!1657) - validator: accept a confusing NODATA proof with insecure delegation (!1659) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.11/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.11.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.11.tar.xz.asc <https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.11.tar.xz.asc> Documentation: https://www.knot-resolver.cz/documentation/v6.0.11/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

1 měsíc, 4 týdny

1
0
0 0

different forwarder and no cache for specific host

by Mathieu Roy

Hello, On my local network, I have a computer fixed IP that I would like to use a specific TLS FORWARD. Generic TLS_FORWARD is simply configured as such. policy.add(policy.all(policy.TLS_FORWARD({ {'9.9.9.9', hostname='dns9.quad9.net'}, {'1.1.1.1', hostname='cloudflare-dns.com'}, {'1.0.0.1', hostname='cloudflare-dns.com'}, }))) I tried to embed a specific different TLS_FORWARD with a view:addr('10.10.10.10', ... ) but I cannot manage to restrict this TLS_FORWARD and to avoid it poisoning the cache. Is there somewhere an example of such setup, with ACL ending up on two different TLS_FORWARD and one with no cache ? Regards, -- Mathieu Roy

2 měsíce, 3 týdny

2
1
0 0

Knot Resolver 6.0.9

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.0.9 (early-access) has been released! Improvements: - rate-limiting: add these options, mechanism, docs (!1624) - manager: secret for TLS session resumption via ticket (RFC5077) (!1567) The manager creates and sets the secret for all running 'kresd' workers. The secret is created automatically if the user does not configure their own secret in the configuration. This means that the workers will be able to resume each other's TLS sessions, regardless of whether the user has configured it to do so. - answer NOTIMPL for meta-types and non-IN RR classes (!1589) - views: improve interaction with old-style policies (!1576) - stats: add stale answer counter 'answer.stale' (!1591) - extended_errors: answer with EDE in more cases (!1585, !1588, !1590, !1592) - local-data: make DNAMEs work, i.e. generate CNAMEs (!1609) - daemon: use connected UDP sockets by default (#326, !1618) - docker: multiplatform builds (#922, !1623) - docker: shared VOLUMEs are prepared for configuration and cache (!1625, !1627) Configuration path was changed to standard '/etc/knot-resolver/config.yaml'. Bugfixes: - daemon/proxyv2: fix informing the engine about TCP/TLS from the actual client (!1578) - forward: fix wrong pin-sha256 length; also log pins on mismatch (!1601, #813) Incompatible changes: - -f/--forks is removed (#631, !1602) - gnutls < 3.4 support is dropped, released over 9 years ago (!1601) - libuv < 1.27 support is dropped, released over 5 years ago (!1618) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.9/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.9.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.9.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.0.9/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

5 měsíců, 2 týdny

1
0
0 0

Forward DNS Query Based on Specific Answer (Matching IP Address)

by ealireza＠gmail.com

Issue Summary: I need to forward DNS queries to a secondary DNS server if a specific value (IP address) is returned in the DNS response. Specifically, if the answer contains 192.168.1.1, I want the request to be forwarded to 10.10.10.1 for re-resolution. Expected Behavior: A user queries for a domain (e.g., dig alibaba.com). If the result contains the IP address 192.168.1.1, the query should be automatically forwarded to another DNS server (e.g., 10.10.10.1) for further resolution. Current Attempt: lua policy.add(policy.all(function (state, req) log("info Policy function triggered") -- Get the DNS answer section local answer = req:answer() if answer then for _, record in ipairs(answer) do -- Check if the response is an A record and contains the IP 192.168.1.1 if record.stype == kres.type.A and tostring(record.rdata) == '192.168.1.1' then log("info IP is 192.168.1.1, forwarding to 10.10.10.1") -- Forward the query to the specified DNS server return policy.FORWARD({'10.10.10.1'}) end end else log("info No answer found") end return kres.DONE end), true) Issue: The function triggers correctly, but the query is not being forwarded to the specified DNS server when the condition (record.rdata == '192.168.1.1') is met. Steps to Reproduce: Add the above Lua code to the Knot Resolver configuration. Query for a domain (dig alibaba.com). If the result contains the IP 192.168.1.1, the query should be forwarded, but it does not. Environment: Knot Resolver Version: [Include version] Operating System: [Your OS] Configuration: [Any relevant additional configuration] Desired Solution: I would like the query to forward correctly to 10.10.10.1 whenever the answer contains 192.168.1.1. Any guidance on why the forward might not be triggered or if additional configurations are needed would be appreciated.

7 měsíců

2
1
0 0

DNS rebinding protection - issue with apple.com

by Aleš Rygl

Hello, we are observing that Knot-resolver is refusing certain queries because of enabled DNS rebinding protection to subdomains beneath apple.com. IMHO there is no reason for that - they are not pointing to a private addres range. For instance: Unbound: dig init.ess.apple.com @127.0.0.1 -p 53 ; <<>> DiG 9.18.24-1-Debian <<>> init.ess.apple.com @127.0.0.1 -p 53 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38044 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;init.ess.apple.com. IN A ;; ANSWER SECTION: init.ess.apple.com. 81 IN CNAME init-cdn-lb.ess-apple.com.akadns.net. init-cdn-lb.ess-apple.com.akadns.net. 27 IN CNAME init.ess.g.aaplimg.com. init.ess.g.aaplimg.com. 12 IN A 17.253.73.204 init.ess.g.aaplimg.com. 12 IN A 17.253.73.205 init.ess.g.aaplimg.com. 12 IN A 17.253.73.203 init.ess.g.aaplimg.com. 12 IN A 17.253.73.201 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Wed Sep 18 10:42:46 CEST 2024 ;; MSG SIZE rcvd: 194 Knot-resolver 5.7.4-cznic.1 freshly re-installed: dig init.ess.apple.com @127.0.0.1 -p 2053 ; <<>> DiG 9.18.24-1-Debian <<>> init.ess.apple.com @127.0.0.1 -p 2053 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17074 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; EDE: 18 (Prohibited): (EIM4) ;; QUESTION SECTION: ;init.ess.apple.com. IN A ;; ADDITIONAL SECTION: explanation.invalid. 10800 IN TXT "blocked by DNS rebinding protection" ;; Query time: 8 msec ;; SERVER: 127.0.0.1#2053(127.0.0.1) (UDP) ;; WHEN: Wed Sep 18 10:45:40 CEST 2024 ;; MSG SIZE rcvd: 124 I have also tried to remove the cache under /var/cache/knot-resolver but without any effect. There are more domain names with this beavior: query.ess.apple.com comm-cohort.ess.apple.com kt-prod.ess.apple.com Thanks. Ales Rygl

7 měsíců, 1 týden

3
4
0 0

non-persistent cache during system reboot although stored on persistent storage, why?

by Michael Grimm

Hi, I am running knot-resolver-5.7.4 in a FreeBSD service jail (14.1-STABLE). Note: Because I am still pretty new to using knot resolver, I may miss something important besides [1]. MWN> sum /usr/home/jails/test/var/run/kresd/data.mdb 268 10240 /usr/home/jails/test/var/run/kresd/data.mdb MWN> ./_STATS [2] cache('['count_entries']'): 4953 cache('['usage_percent']'): 16.953125 ### stopping jail simulates shutdown server [3]: MWN> service jail stop test Stopping jails: test. MWN> sum /usr/home/jails/test/var/run/kresd/data.mdb 268 10240 /usr/home/jails/test/var/run/kresd/data.mdb ### Thus, data.mdb is preserved after shutdown! ### starting jail simulates booting server: MWN> service jail start test Starting jails: test. MWN> sum /usr/home/jails/test/var/run/kresd/data.mdb 15059 10240 /usr/home/jails/test/var/run/kresd/data.mdb MWN> ./_STATS cache('['count_entries']'): 87 cache('['usage_percent']'): 0.15625 1) After having stopped that jail, data.mdb is still available and hasn't been modified as shown by checksum. 2) After start of the jail including start of kresd data.mdb has been modified (checksum). 3) cache.stats() shows significantly lower numbers. Questions: #) become cache.stats() reset after a reboot? #) what am I missing? Thanks in advance and regards, Michael [1] https://knot-resolver.readthedocs.io/en/stable/daemon-bindings-cache.html#p… [2] _STATS (based on https://knot-resolver.readthedocs.io/en/stable/daemon-bindings-cache.html#c…) echo -n "cache('['count_entries']'): " ; echo "cache.stats()" | nc -NU /var/run/kresd/control/kresd.sock | grep count_entries echo -n "cache('['usage_percent']'): " ; echo "cache.stats()" | nc -NU /var/run/kresd/control/kresd.sock | grep usage_percent [3] a real server reboot shows the same issue with the cache

8 měsíců

2
4
0 0

Moving Knot Resolver release files

by Oto Šťáva

Dear Knot Resolver users, due to an internal infrastructure change, released sources for Knot Resolver have been moved from <https://secure.nic.cz/files/knot-resolver/> to <https://knot-resolver.nic.cz/release/>. Apart from this movement, the rest of the directory structure remains unchanged. Proper redirects (HTTP 301 Moved Permanently) have been put in place to make this change as painless and transparent as possible. These redirects can be expected to stay in place for the foreseeable future. Still, we do recommend to change any of your direct links from the secure.nic.cz server to knot-resolver.nic.cz, to avoid the extra indirection step and/or unforeseen issues in the future. Should any of you run into any issues or have any questions about this change, please do let us know, we will be happy to help you out. Best regards -- Oto Šťáva | Knot Resolver team lead | CZ.NIC z.s.p.o. PGP: 6DC2 B0CB 5935 EA7A 3961 4AA7 32B2 2D20 C9B4 E680

8 měsíců

1
0
0 0

Expired key in upstream repositories

by Vladimír Čunát

Hello. In case you're using our upstream repositories for Debian or Ubuntu, as suggested on https://www.knot-resolver.cz/download/ you'll be running into their signing key expiring since today. As we didn't update it in time, you'll have to update it manually by re-running: wgethttps://secure.nic.cz/files/knot-resolver/knot-resolver-release.deb dpkg -i knot-resolver-release.deb Ticket: https://gitlab.nic.cz/knot/knot-resolver/-/issues/747 We also forgot to add Ubuntu 22.04, so that is fixed now, too. --Vladimir

8 měsíců, 1 týden

2
2
0 0

CNAME resolution across internal STUB zones

by Paul Furtado

Hello, I am attempting to migrate some internal bind servers to knot+knot-resolver. We have knot acting as the authoritative server for internal views of our public zones and we're attempting to use Knot Resolver to forward to Knot to provide recursive resolution on the internal network. In this configuration, when Knot is resolving a CNAME record from an internal stub zone, it doesn't chase the target of the CNAME for the client. To demonstrate, here are two example zones served by knot: # zone1.com test-a 30 IN A 192.168.1.1 # zone2.com test-cname 30 CNAME test-a.zone1.com. With these configured as stubs in Knot Resolver, if you query test-cname.zone2.com, knot resolver won't chase it across zones to get the A record value like it would for non-stub zones. Both Bind9 and Unbound chase this as expected. Is there any way to configure Knot Resolver to do the same? Thanks! - Paul

8 měsíců, 3 týdny

2
2
0 0

Knot Resolver 5.7.4 and 6.0.8 (security release)

by Oto Šťáva

Dear Knot Resolver users, Knot Resolver versions 5.7.4 (stable) and 6.0.8 (early-access) have been released! Both releases include important security fixes, an update is strongly advised! Version 6.0.8 additionally brings some improvements, like faster policy reloads using a new policy-loader process, respecting system-wide crypto policies, JSON metrics, separate IPv6 and IPv4 metrics, and more. --- Knot Resolver 5.7.4: Security: - reduce buffering of transmitted data, especially TCP-based in userspace Also expose some of the new tweaks in lua: (require 'ffi').C.the_worker.engine.net.tcp.user_timeout = 1000 (require 'ffi').C.the_worker.engine.net.listen_{tcp,udp}_buflens.{snd,rcv} Improvements: - add the fresh DNSSEC root key "KSK-2024" already, Key ID 38696 (!1556) Incompatible changes: - libknot 3.0.x support is dropped (!1558) Upstream last maintained 3.0.x in spring 2022. Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.7.4/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.4.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.4.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v5.7.4/ --- Knot Resolver 6.0.8: Security: - reduce buffering of transmitted data, especially TCP-based in userspace Also expose some of the new tweaks in lua: (require 'ffi').C.the_worker.engine.net.tcp.user_timeout = 1000 (require 'ffi').C.the_worker.engine.net.listen_{tcp,udp}_buflens.{snd,rcv} Packaging: - all packages: - remove unused dependency on `libedit` (!1553) - deb packages: - packages ``knot-resolver-core`` and ``knot-resolver-manager`` have been merged into a single ``knot-resolver6`` package. Suffix packages ``knot-resolver-*`` have been renamed to ``knot-resolver6-*``. This change _should_ be transparent, but please do let us know if you encounter any issues while updating. (!1549) - package ``python3-prometheus-client`` is now only an optional dependency - rpm packages: - packages ``knot-resolver-core`` and ``knot-resolver-manager`` have been merged into a single ``knot-resolver`` package. This change _should_ be transparent, but please do let us know if you encounter any issues while updating. (!1549) - bugfix: do not overwrite config.yaml (!1525) - package ``python3-prometheus_client`` is now only an optional dependency - arch package: - fix after they renamed a dependency (!1536) Improvements: - TLS (DoT, DoH): respect crypto policy overrides in OS (!1526) - manager: export metrics to JSON via management HTTP API (!1527) * JSON is the new default metrics output format * the ``prometheus-client`` Python package is now an optional dependency, required only for Prometheus export to work - cache: prefetching records * predict module: prefetching expiring records moved to prefetch module * prefetch module: new module to prefetch expiring records - stats: add separate metrics for IPv6 and IPv4 (!1545) - add the fresh DNSSEC root key "KSK-2024" already, Key ID 38696 (!1556) - manager: policy-loader: new component for separate loading of policy rules (!1540) The ``policy-loader`` ensures that configured policies are loaded into the rules database where they are made available to all running kresd workers. This loading is no longer done by all kresd workers as it was before, so this should significantly improve the resolver's startup/reload time when loading large sets of policy rules, e.g. large RPZs. Incompatible changes: - cache: the ``cache.prediction`` configuration property has been reorganized into ``cache.prefetch.expiring`` and ``cache.prefetch.prediction``, changing the default behaviour as well. See the `relevant documentation section <https://www.knot-resolver.cz/documentation/v6.0.8/config-cache-predict.html>`_ for more. - libknot <=3.2.x support is dropped (!1565) Bugfixes: - arch package: fix after they renamed a dependency (!1536) - fix startup with `dnssec: false` (!1548) - rpm packages: do not overwrite config.yaml (!1525) - fix NSEC3 records missing in answer for positive wildcard expansion with the NSEC3 having over-limit iteration count (#910, !1550) - views: fix a bug in subnet matching (!1562) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.8/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.8.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.8.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.0.8/ -- Oto Šťáva | Knot Resolver team lead | CZ.NIC z.s.p.o. PGP: 6DC2 B0CB 5935 EA7A 3961 4AA7 32B2 2D20 C9B4 E680

9 měsíců

3
2
0 0

Re: KNOT sharing cache or not for different instances (nat64 vs no nat64)

by Vladimír Čunát

On 31/05/2024 19.00, oui.mages_0w(a)icloud.com wrote: > we have different TLS domains/certificates for dns64 and non dns64 Oh, OK. Such a thing hasn't occurred to us, so it's not possible. In that case I expect you'll need to stay on 5.x for now, with separate processes for dns64 and non-dns64 (but they can share the cache). Overall I don't think the current code can support multiple certificates.

10 měsíců

2
3
0 0

Re: KNOT sharing cache or not for different instances (nat64 vs no nat64)

by Vladimír Čunát

On 31/05/2024 13.04, oui.mages_0w(a)icloud.com wrote: > Unless the policy module allows to filter by listened IP, I will still > need to use split instances: we don’t select on the server side which > client is to use dns64 or not, but as an ISP, we leave the choice to > the clients to decide which dns resolver they want to use (one of ours > with or without dns64, or a third party). That is possible, but with 5.x I probably wouldn't recommend it, as it's been left out of documentation (by mistake) and overall I don't have much trust in that part of 5.x policies. But after you migrate to >= 6.x, I would recommend just having a single shared configuration. And in views you can select dst-subnet paired with dns64 options. Such deployments were taken into account when designing 6.x views. https://www.knot-resolver.cz/documentation/latest/config-views.html#config-… In 6.x it would probably also be harder for you to run multiple configurations at once on a single machine, so that's another reason to unify this when you migrate. --Vladimir

10 měsíců, 4 týdny

1
0
0 0

KNOT resolver and NS serverers with CNAME

by Vladimír Čunát

On 14/05/2024 08.10, Josef Karliak via knot-dns-users wrote: > > ISC bind is strict about CNAME of NS server: > > skipping nameserver 'aa.bb.cz' *because it is a CNAME*, while > resolving '9.4/4.3.2.1.in-addr.arpa/PTR'. > > How about Knot resolver ? > Hello. I believe there is neither effort to disallow them nor to make them work. Off the top of my head I'm not sure how it will be in practice; you could just try. Either way, please don't use them. (I replied to the correct mailing-list.) --Vladimir

10 měsíců, 4 týdny

3
3
0 0

Knot Resolver 5.7.3

by Oto Šťáva

Dear Knot Resolver users, Knot Resolver version 5.7.3 (stable) has been released! This maintenance update brings a minor improvement to stats and a bugfix to missing NSEC3 records. An early-access version 6.0.8 including these changes and more will come at a later date - a few more things need to be finalized there before release. Improvements: - stats: add separate metrics for IPv6 and IPv4 (!1544) Bugfixes: - fix NSEC3 records missing in answer for positive wildcard expansion with the NSEC3 having over-limit iteration count (#910, !1550) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.7.3/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.3.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.3.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v5.7.3/ -- Oto Šťáva | Knot Resolver team lead | CZ.NIC z.s.p.o. PGP: 6DC2 B0CB 5935 EA7A 3961 4AA7 32B2 2D20 C9B4 E680

11 měsíců

1
0
0 0

Re: [knot-dns-users] Re: KNOT resolver and NS serverers with CNAME

by Vladimír Čunát

On 17/05/2024 22.43, Peter Thomassen wrote: > I think the question is whether Knot Resolver follows the letter of > the RFC, like BIND, or whether it is less strict. I'm not aware of RFCs saying that resolvers should fail in such situations. My understanding is more like it's allowed not to work. Anyway, it would be better to continue this thread on knot-resolver-users(a)lists.nic.cz (I already have posted there about this a couple days ago.) --Vladimir

11 měsíců, 1 týden

1
0
0 0

Get readable text properties in request/response Lua functions

by boris.kotyrev＠gmail.com

Trying to make Policy Based Routing routing. Looking for HOWTO/snippents of two API features : 1) Tracking Cache TTL for some records and ability to make requests against cache. 2) Printing some text properties in request/response (kres) functions - like domain name, is cached (yes/no), TTL, etc. As I understood docs regarding Lua/C bindings is not finished yes. But I'm not a experienced developer so reading .c files is not an option for me ;-)

1 rok

2
1
0 0

Kresd crashes on raspberry pi

by Ulrich Wisser

Hi, for some time now I have a problem running kresd on my raspberry pi. I am running pihole and use kresd as resolver behind pihole. Everything works fine until some day where kresd "decides" to crash. It is always the same error message (please see below). I then have to manually stop the garbage collector, remove all cache files and restart kresd (which automatically starts the garbage collector). My pi is pxe boot and the root partition is on an nfs mounted volume. The volume has several terra byte of space left. After a restart it will run flawless for tow or three weeks just to crash with the same error again. Any idea how this happens? /Ulrich root@pi-hole1:~# systemctl status kresd ● kresd.service - Knot Resolver daemon Loaded: loaded (/lib/systemd/system/kresd.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2024-04-05 02:31:47 CEST; 6h ago Docs: man:kresd.systemd(7) man:kresd(8) Process: 5106 ExecStart=/usr/sbin/kresd -c /usr/lib/arm-linux-gnueabihf/knot-resolver/distro-preconfig.lua -c /etc/knot-resolver/kresd.conf -n (code=exited, status=1/FAILURE) Process: 5110 ExecStopPost=/usr/bin/env rm -f /run/knot-resolver/control/ (code=exited, status=1/FAILURE) Main PID: 5106 (code=exited, status=1/FAILURE) CPU: 648ms Apr 05 02:31:45 pi-hole1 kresd[5106]: [C]: at 0x0001b2d8 Apr 05 02:31:45 pi-hole1 kresd[5106]: [C]: in function 'pcall' Apr 05 02:31:45 pi-hole1 kresd[5106]: ...b/arm-linux-gnueabihf/knot-resolver/distro-preconfig.lua:9: in main chunk Apr 05 02:31:45 pi-hole1 kresd[5106]: ERROR: net.listen() failed to bind Apr 05 02:31:46 pi-hole1 kresd[5106]: [system] error while loading config: /usr/lib/arm-linux-gnueabihf/knot-resolver/sandbox.lua:402: can't open cache path '/var/cache/knot-resolver'; working directory '/var/lib/knot-resolver'; No space left on device (workdir '/var/lib/knot-resolver') Apr 05 02:31:47 pi-hole1 systemd[1]: kresd.service: Main process exited, code=exited, status=1/FAILURE Apr 05 02:31:47 pi-hole1 env[5110]: rm: cannot remove '/run/knot-resolver/control/': Is a directory Apr 05 02:31:47 pi-hole1 systemd[1]: kresd.service: Control process exited, code=exited, status=1/FAILURE Apr 05 02:31:47 pi-hole1 systemd[1]: kresd.service: Failed with result 'exit-code'. Apr 05 02:31:47 pi-hole1 systemd[1]: Failed to start Knot Resolver daemon. root@pi-hole1:~# ps aux Op | grep kres knot-re+ 569 0.1 0.1 114480 4140 ? Ss Apr02 5:15 /usr/sbin/kres-cache-gc -c /var/cache/knot-resolver -d 1000 root 23835 0.0 0.0 10292 504 pts/0 S+ 09:00 0:00 grep kres root@pi-hole1:~# systemctl status | grep kres │ └─23861 grep kres ├─system-kresd.slice │ └─kres-cache-gc.service │ └─569 /usr/sbin/kres-cache-gc -c /var/cache/knot-resolver -d 1000 root@pi-hole1:~# systemctl stop kres-cache-gc

1 rok

2
2
0 0

Knot Resolver 5.7.2 and 6.0.7

by Oto Šťáva

Dear Knot Resolver users, Knot Resolver versions 5.7.2 (stable) and 6.0.7 (early-access) have been released! Both fix running on 32-bit systems with 64-bit time; 6.0.7 additionally brings fixes to RPZ, cache clearing via kresctl, and more. --- Knot Resolver 5.7.2: Bugfixes: - fix on 32-bit systems with 64-bit time_t (!1510) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.7.2/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.2.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.2.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/artifacts/1056229/index.html --- Knot Resolver 6.0.7: Improvements: - manager: clear the cache via management HTTP API (#876, !1491) - manager: added support for Python 3.12 and removed for 3.7 (!1502) - manager: use build-time install prefix to execute `kresd` instead of PATH (!1511) - docs: documentation is now separated into user and developer parts (!1514) - daemon: ignore UDP requests from ports < 1024 (!1507) - manager: increase startup timeout for processes (!1518, !1520) - local-data: increase default DB size to 2G on 64-bit platforms (!1518) Bugfixes: - fix listening by interface name containing dashes (#900, !1500) - fix kresctl http request timeout (!1505) - fix RPZ if it contains apex NS record (!1516) - fix RPZ if SOA is repated, as usual in AXFR output (!1521) - avoid RPZ overriding the root SOA (!1521) - fix on 32-bit systems with 64-bit time_t (!1510) - fix paths to knot-dns libs if exec_prefix != prefix (!1503) - manager: add missing early check that neither a custom port nor TLS is set for authoritative server forwarding (#902, !1505) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.7/NEWS Documentation: https://www.knot-resolver.cz/documentation/artifacts/1056245/index.html -- Oto Šťáva | Knot Resolver team leader | CZ.NIC z.s.p.o. PGP: 6DC2 B0CB 5935 EA7A 3961 4AA7 32B2 2D20 C9B4 E680

1 rok

1
0
0 0

Newbie questions regarding knot-resolver

by Michael Grimm

Hi, I am in the process to migrate from unbound to knot-resolver. This is on FreeBSD 14-STABLE, knot-resolver 5.7.1, and on a very small instance serving a handful users, around 100 mails a day and such. The resolver is up and running, but I still have some questions left I cannot answer myself after reading the documentation et al. 1) I managed to run 'kres-cache-gc -c /var/run/kresd' but I am unsure whether I do need the garbage collector at all? I read that after filling up of '/var/run/kresd/data.mdb' that file would become reset to 0 bytes, correct? FYI: After 3 days '/var/run/kresd/data.mdb' uses less than 1 MB currently. 2) Does knot-resolver automatically update 'root.hints' and 'root.keys', or do I have to install a script in crontab doing the updates instead? FYI: I didn't unload the modules 'ta_signal_query' and 'ta_sentinel‘ 3) I am still struggeling to understand, how to get access to the statistics produced by the module 'stats'? FYI: If I do try to use knotc (I know, it's experimental), I'll get: |dns> kresc /var/run/kresd/control/17158 |Warning! kresc is highly experimental, use at own risk. |Please tell authors what features you expect from client utility. | FYI: There is no 'kresd>' prompt … I tried to modify that socket's privileges but to no avail. 4) If that socket is the way to get hold on all statistics information, how can one name that socket file? Currently, it is just the PID of kresd. Thanks in advance and regards, Michael

1 rok, 1 měsíc

3
7
0 0

DNS Shotgun v20240219

by Oto Šťáva

Dear Knot Resolver users, DNS Shotgun v20240219, our high-performance realistic benchmarking tool for DNS resolvers, has been released. This new release, amongst a variety of other improvements, brings support for testing DNS-over-QUIC. Incompatible changes: - CMake is now being used to build dnssim instead of Autotools - GnuTLS 3.7.5+ is now required Improvements: - pcap/extract-clients: always reset UDP port numbers to 53 (!56) - pcap/extract-clients: ability to write to stdout (!62) - pcap/filter-dnsq: skip 'special' queries for *.dotnxdomain.net (!58) - pcap/split-clients: new tool to split larger PCAPs into smaller ones (!61) - pcap/merge-chunks: allow disabling randomization (!67) - tools/plot-latency: ability to diversify lines with linestyles (!69) - tools/plot-response-rate: estimate worst-case drop caused by discarded packets (!74) - tools/plot-packet-rate: handle incomplete last sampling period (!71) - tools/plot-response-rate: ability to ignore RCODEs with small response rate (!73) - pcap/filter-dnsq: ability to log malformed queries (!72) - pcap/generate-const-qps: new tool to generate constant QPS (!33) - tools: allow customizing plot charts with `SHOTGUN_MPLSTYLES` (!65) - replay: `--preload` argument, mainly for dnssim debugging with sanitizers (!76) - tools/plot-latency: use fractional values for humans in charts (!78) - pcap/extract-clients: warn if some input packets were skipped (!80) - dnssim: replace Autotools with CMake (!77, !86) - configs: DoH configs with exclusively GET/POST methods (!82) - tools/plot-response-rate: avoid division by zero (!89) - tools/plot-latency: denser labels to improve logarithmic scale readability (!90) - pcap/extract-clients: allow query rewriting - anonymization (!91) - Support for DNS-over-QUIC (!75) Bugfixes: - tools/plot-response-rate: avoid white lines on white background (!55) - tools/plot-client-distribution: properly handle file limit (!59) - pcap: proper PCAP write error handling (!60) - tools/plot-connections: set axis limits properly (!66) - tools/plot-packet-rate: trim chart whitespace (!79) - replay: do not exit silently when dnssim returns non-zero (!87) Full changelog: https://gitlab.nic.cz/knot/shotgun/-/releases/v20240219 Sources: https://gitlab.nic.cz/knot/shotgun/-/archive/v20240219/shotgun-v20240219.ta… Documentation: https://dns-shotgun.readthedocs.io/en/v20240219/ Oto Šťáva Knot Resolver CZ.NIC z.s.p.o.

1 rok, 2 měsíce

1
0
0 0

Why are some names not cached?

by Ondřej Caletka

Hello, I am trying to figure out why some domain names are not resolving on my instance of Knot resolver over DoH with some clients. I was able to reproduce this issue with [doh](https://github.com/curl/doh) client built on libcurl. The problem never manifests with kdig (neither with DoH, nor DoT nor Do53). During this, I noticed something strange. For domain name github.com (which sometimes returns no A record), I always receive an answer with TTL set to 60. It seems like this name does not get cached at all. See the test output below. Interestingly, if I delete cache files and restart the resolver, the TTL starts decreasing as expected. Is this a sign that something was wrong with the cache before? Or is this some sort of cache optimization for low TTL records? Here is the test output: $ for i in `seq 1 5`; do ./doh github.com https://nscache.mtg.ripe.net/dns-query ; echo "----"; kdig +https +noadflag +nocookie +noall +answer github.com A @nscache.mtg.ripe.net ; echo "===="; sleep 1; done [github.com] TTL: 60 seconds AAAA: 0064:ff9b:0000:0000:0000:0000:8c52:7903 ---- github.com. 60 IN A 140.82.121.3 ==== [github.com] TTL: 60 seconds A: 140.82.121.3 AAAA: 0064:ff9b:0000:0000:0000:0000:8c52:7904 ---- github.com. 60 IN A 140.82.121.4 ==== [github.com] TTL: 60 seconds A: 140.82.121.4 AAAA: 0064:ff9b:0000:0000:0000:0000:8c52:7904 ---- github.com. 60 IN A 140.82.121.4 ==== [github.com] TTL: 60 seconds A: 140.82.121.4 AAAA: 0064:ff9b:0000:0000:0000:0000:8c52:7903 ---- github.com. 60 IN A 140.82.121.4 ==== [github.com] TTL: 60 seconds A: 140.82.121.3 AAAA: 0064:ff9b:0000:0000:0000:0000:8c52:7904 ---- github.com. 60 IN A 140.82.121.3 ==== -- Best regards, Ondřej Caletka

1 rok, 2 měsíce

2
1
0 0

LIGA CHAMPIONS

by sachgame570＠gmail.com

Komentator -Liga Champions✔️✔️ Owen Hargreaves mengatakan bahwa “semua orang akan terpukul” oleh penampilan buruk Bayern Munich baru-baru ini, kali ini setelah kalah dari Lazio di leg pertama babak 16 besar Liga Champions. Situs web: https://svipbola.com/liga/liga-champions Pertandingan Liga Champions“Mereka perlu menemukan cara untuk mempercepat permainan dan menjadi sedikit lebih cepat. Mereka melewati fase ini di bawah asuhan Pep dan memainkan sepakbola terindah. Hari ini mereka bahkan tidak memainkan sepakbola indah.” Jadwal Liga Champions - dengan meningkatnya perhatian media terhadap manajer dan pemain, mantan gelandang Manchester United dan pemenang Liga Champions Hargreaves tidak berharap tim tamu mendapat ulasan positif atas penampilan seperti itu. Liga Champions 2023⭐“Ketika Anda bermain untuk tim papan atas, saya tahu orang-orang tidak ingin mendengarnya, namun ketika Anda bermain seperti itu, Anda akan dikritik. Saya pikir akan ada banyak rasa frustrasi di dalam dan di sekitar Bayern saat ini.” Address: Jl Gondosuli 8 Yk Jawa Tengah Indonesia #Liga Champions #pertandingan liga champions #jadwal liga champions #klasemen liga champions #liga champions uefa #liga champions 2023 #hasil liga champions #liga champions 2022

1 rok, 2 měsíce

1
0
0 0

Unable to install kdig utility in Linux fedora 8.8

by Ramakrishnudu MANGALA

Hi Team, I am trying to install kdig utility in Linux fedora 8.8 but not successful. I took the reference from https://www.knot-resolver.cz/download/ Tried below: # yum install -y epel-release Oracle Linux 8 BaseOS Latest (x86_64) 4.7 kB/s | 3.6 kB 00:00 Oracle Linux 8 Application Stream (x86_64) 9.8 kB/s | 3.9 kB 00:00 Oracle Linux 8 CodeReady Builder (x86_64) - Unsupported 3.7 kB/s | 3.3 kB 00:00 ITE 20 kB/s | 1.4 kB 00:00 Package oracle-epel-release-el8-1.0-5.el8.x86_64 is already installed. Dependencies resolved. Nothing to do. Complete! # yum install -y knot-resolver Oracle Linux 8 BaseOS Latest (x86_64) 1.1 kB/s | 3.6 kB 00:03 Oracle Linux 8 Application Stream (x86_64) 10 kB/s | 3.9 kB 00:00 Oracle Linux 8 CodeReady Builder (x86_64) - Unsupported 8.3 kB/s | 3.3 kB 00:00 ITE 22 kB/s | 1.4 kB 00:00 No match for argument: knot-resolver Error: Unable to find a match: knot-resolver # dnf install -y knot-resolver Oracle Linux 8 BaseOS Latest (x86_64) 2.4 kB/s | 3.6 kB 00:01 Oracle Linux 8 BaseOS Latest (x86_64) 15 MB/s | 62 MB 00:04 Oracle Linux 8 Application Stream (x86_64) 10 kB/s | 3.9 kB 00:00 Oracle Linux 8 Application Stream (x86_64) 11 MB/s | 48 MB 00:04 Oracle Linux 8 CodeReady Builder (x86_64) - Unsupported 2.2 kB/s | 3.3 kB 00:01 Oracle Linux 8 CodeReady Builder (x86_64) - Unsupported 4.5 MB/s | 8.6 MB 00:01 ITE 1.1 kB/s | 1.4 kB 00:01 No match for argument: knot-resolver Error: Unable to find a match: knot-resolver But none of the above is successful. Could you help me with kdig utility installation on Fedora 8.8? Regards, Rama.

1 rok, 2 měsíce

2
1
0 0

Knot Resolver 5.7.1 and 6.0.6

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver versions 5.7.1 (stable) and 6.0.6 (early-access) have been released! These releases include important security fixes, an update is strongly advised! Security: - CVE-2023-50868: NSEC3 closest encloser proof can exhaust CPU * validator: lower the NSEC3 iteration limit (150 -> 50) * validator: similarly also limit excessive NSEC3 salt length * cache: limit the amount of work on SHA1 in NSEC3 aggressive cache * validator: limit the amount of work on SHA1 in NSEC3 proofs * validator: refuse to validate answers with more than 8 NSEC3 records - CVE-2023-50387 "KeyTrap": DNSSEC verification complexity could be exploited to exhaust CPU resources and stall DNS resolvers. Solution boils down mainly to limiting crypto-validations per packet. We would like to thank Elias Heftrig, Haya Schulmann, Niklas Vogel and Michael Waidner from the German National Research Center for Applied Cybersecurity ATHENE for bringing this vulnerability to our attention. Improvements: - update addresses of B.root-servers.net (!1478) Bugfixes: - fix potential SERVFAIL deadlocks if net.ipv6 = false (#880) The update affects how some cached records are being treated, which may trip up some sanity checking mechanisms in Knot Resolver if you have advanced debugging options enabled (disabled by default), "debugging.assertion_abort" for version 5 (Lua) and "logging/debugging/assertation-abort" for version 6 (YAML). In case you encounter any issues, please try clearing the cache first. Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.7.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.1.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.7.1/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

1 rok, 2 měsíce

1
0
0 0

Lost e-mails to the mailing list + upcoming security release today

by Oto Šťáva

Dear Knot Resolver users, last week a long-lasting bug in our mailing system has been discovered, which, over the past two years, blocked quite a few e-mails from being delivered to the list <knot-resolver-users(a)lists.nic.cz> and a few others (namely the <knot-dns-users(a)lists.nic.cz>, whose subscriber Juha Suhonen initially brought our attention to the issue - a thank you to Juha is in order!). This week the issue has been resolved and the blocked e-mails came through. Some of these were our own, namely the Knot Resolver 5.5.0 release announcement, which is obviously outdated, as the current stable version is Knot Resolver 5.7.0. We apologize for any confusion this situation may have caused. Some others are still awaiting additional approval, so after we manually identify, which are still relevant, and which are spam, they will also come through during the following weeks. Furthermore, later today we are planning to release new versions of the stable Knot Resolver 5 and the early-access Knot Resolver 6. These important updates will mitigate a few newfound DoS issues, the details of which will soon be revealed globally. We are fully aware that this unfortunate timing may cause further confusion, so we opted to inform you, the subscribers, beforehand, that this next release e-mail is indeed relevant. We once again apologize for the confusion. Best regards Oto Šťáva Knot Resolver team CZ.NIC z.s.p.o.

1 rok, 2 měsíce

1
0
0 0

[SOLVED] Re: [knot-dns-users] Re: kresd not starting with lua error

by Mike Wright

On 2/12/24 01:34, Vladimír Čunát wrote: > On 28/01/2024 02.52, Mike Wright wrote: >> [system] error while loading config: >> ...b/x86_64-linux-gnu/knot-resolver/kres_modules/policy.lua:378: bad >> argument #1 to 'create' (table expected, got nil) (workdir >> '/var/lib/knot-resolver') > > You don't define the `internalDomain` variable. That's correct in lua > and evaluates as nil. > > (and as I already posted, please use the correct mailing-list next time) OK, figured out my mistake. internalDomains MUST APPEAR BEFORE any reference to it. Thanks for your time, Mike Wright

1 rok, 2 měsíce

1
0
0 0

Introducing Knot Resolver 6.x

by Aleš Mrázek

Dear Knot Resolver users, we would like to introduce you to Knot Resolver 6.x! This future version of the resolver is now in the testing phase. An article was published on our blog as part of this introduction. EN: https://en.blog.nic.cz/2023/12/15/knot-resolver-6-x-news CZ: https://blog.nic.cz/2023/12/15/novinky-v-knot-resolver-6-x We will be happy if you try the new version and give us any feedback. -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

1 rok, 4 měsíce

1
0
0 0

Knot Resolver error

by martin.skalicky＠outlook.cz

Hi! I'm pretty new to Knot Resolver, previously i used Bind9 but wanted to try something else. However, i can't really figure out one problem, error: [system] error while loading config: /usr/lib/knot-resolver/kres_modules/policy.lua:43: bad argument #1 to 'kr_straddr_split' (cannot convert 'table' to 'const char *') (workdir '/var/lib/knot-resolver') I don't absolutely know, what am I doing wrong. Can you help me, please? Also, possible communication in Czech if better for someone? Here is my kresd.conf (my actual domains are replaced by domain1.tld, domain2.tld respectively): -- SPDX-License-Identifier: CC0-1.0 -- vim:syntax=lua:set ts=4 sw=4: -- Refer to manual: https://knot-resolver.readthedocs.org/en/stable/ -- Network interface configuration net.listen('127.0.0.1', 53, { kind = 'dns' }) net.listen('127.0.0.1', 853, { kind = 'tls' }) net.listen('::1', 53, { kind = 'dns', freebind = true }) net.listen('::1', 853, { kind = 'tls', freebind = true }) -- Load useful modules modules = { 'hints > iterate', -- Allow loading /etc/hosts or custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } -- Cache size cache.size = 100 * MB -- DNS Rebinding Configuration policy.add(policy.todnames({'domain2.tld', 'domain1.tld'}), policy.PASS) policy.add(policy.todnames({'domain2.tld', 'domain1.tld'}), policy.FORWARD({{'192.168.0.126'}}))

1 rok, 4 měsíce

3
3
0 0

Problems with DNSSEC .CZ

by Martin Doubrava

Hi colleagues, we are using knot-resolver as anycast resolvers for our region wide network. Everything works fine, but from saturday we are experiencing problems with zone .cz on one of our resolvers: lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [plan ][00000.00] plan 'www.seznam.cz.' type 'AAAA' uid [20220.00] lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [iterat][20220.00] 'www.seznam.cz.' type 'AAAA' new uid was assigned .01, parent uid .00 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => skipping exact RR: rank 060 (min. 030), new TTL -16225 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => trying zone: seznam.cz., NSEC3, hash db928b48 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 depth 1: hash 0sil3tll31qpi1iq50o2h3kjrmon169q lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 encloser error for www.seznam.cz.: range search found stale or insecure entry lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 depth 0: hash lg5rgspgqdoqqjko0u7fkpkakk8hgc1s lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 encloser error for seznam.cz.: range search found stale or insecure entry lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => trying zone: seznam.cz., NSEC3, hash f8ba757c lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 depth 1: hash s92e2vuk6k14pvqp4ubga1im9kpgff8a lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 encloser error for www.seznam.cz.: range search found stale or insecure entry lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 depth 0: hash 07u4nbhjigung96jklsqvtf6crqjojp8 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 encloser error for seznam.cz.: range search found stale or insecure entry lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [zoncut][20220.01] found cut: cz. (rank 002 return codes: DS 0, DNSKEY -116) lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [plan ][20220.01] plan 'cz.' type 'DNSKEY' uid [20220.02] lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [iterat][20220.02] 'cz.' type 'DNSKEY' new uid was assigned .03, parent uid .01 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.03] => skipping exact RR: rank 060 (min. 030), new TTL -14979 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.03] => trying zone: cz., NSEC3, hash 20b5ab23 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.03] => NSEC3 depth 0: hash gurgi3ems8m3ts3pvppubu3hhqkivt3l lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.03] => NSEC3 encloser error for cz.: range search found stale or insecure entry lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.03] => skipping zone: cz., NSEC, hash 0;new TTL -123456789, ret -2 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [select][20220.03] => id: '03706' choosing from addresses: 0 v4 + 0 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is OK lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [select][20220.03] => id: '03706' no suitable transport, zone cut: 'cz.' lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [iterat][20220.03] 'cz.' type 'DNSKEY' new uid was assigned .04, parent uid .01 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [select][20220.04] => id: '28359' choosing from addresses: 0 v4 + 0 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is OK lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [select][20220.04] => id: '28359' no suitable transport, zone cut: 'cz.' lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [resolv][20220.04] AD: request NOT classified as SECURE lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [resolv][20220.01] finished in state: 8, queries: 1, mempool: 16400 B Version of knot-resolver: 5.7.0-cznic.1 When i turn off DNSSEC with trust_anchors.remove('.') and then turn it on everything works, but only for day or so. Other machines are working seamlessly. What we are doing here wrong? Thank you! -- Best regards Bc. Martin Doubrava CEO _______________________________ DOUBRAVA.NET s.r.o. Náklo 178, 783 32 Náklo Mobil: +420 771 280 361 Technická podpora: +420 776 778 173 Office: +420 588 884 000 E-mail: martin(a)doubrava.net WWW: http://www.doubrava.net Najdete nás i na facebooku: http://www.facebook.com/doubravanet

1 rok, 4 měsíce

2
3
0 0

Accessing DoH headers in Lua

by Blažej Krajňák

Hi there, please, can anyone move me forward? I want to implement new stats counter for DoH requests with “Chrome” in "user-agent" header. I don’t know how to iterate “query.request.qsource.headers”. I have tried: function count_chrome_doh() return function (state, query) if query.request.qsource.flags.http then for k, v in ipairs(query.request.qsource.headers) do if v.name == 'user-agent' and v.value == 'Chrome' then if stats.get('request.agent.chrome') then stats['request.agent.chrome'] = stats.get('request.agent.chrome') + 1 else stats['request.agent.chrome'] = 1 end return nil end end end return nil end end policy.add(count_chrome_doh()) but it falls with error "'struct 322' has no '__ipairs’ metamethod” Thanks! Blažej

1 rok, 7 měsíců

2
3
0 0

Best way to implement kresd to filter by listening interface

by oui.mages_0w＠icloud.com

Hello, What would be the best way to implement the following with kresd? The device used has a 2 core cpu. It has 3 (listening) ip addresses, for example: 10.2.3.4, 2001:0DB8:123::1 and 2001:0DB8:123::64 I want to have kresd to listen to: – 10.2.3.4 and 2001:0DB8:123::1 and do a dns resolution using UDP (53), TLS and HTTPS (the question is not about these settings). – 2001:0DB8:123::64 and use the same settings as above, but adding the dns64 module and resolution (only for requests made to 2001:0DB8:123::64). Having 2 cores, I have 2 identical instances; should I differentiate them and have one for dns64 and one without? or could I have 2 identical instances with a shared configuration file allowing to use dns64 or not depending on the listening ip? Or 4 instances (2 identical for dns64, 2 identical without, to have a spare of each config)? The options with view: are good to filter or do actions depending on the source ip, the queried domain or even the resolved ip (destination), but nothing about the ip used to reach the resolver (the listening address). Thank you.

1 rok, 7 měsíců

1
0
0 0

Accessing DoH headers in Lua

by Blažej Krajňák

Hi there, please, can anyone move me forward? I want to implement new stats counter for DoH requests with “Chrome” in "user-agent" header. I don’t know how to iterate “query.request.qsource.headers”. I have tried: function count_chrome_doh() return function (state, query) if query.request.qsource.flags.http then for k, v in ipairs(query.request.qsource.headers) do if v.name == 'user-agent' and v.value == 'Chrome' then if stats.get('request.agent.chrome') then stats['request.agent.chrome'] = stats.get('request.agent.chrome') + 1 else stats['request.agent.chrome'] = 1 end return nil end end end return nil end end policy.add(count_chrome_doh()) but it falls with error "'struct 322' has no '__ipairs’ metamethod” Thanks! Blažej

1 rok, 7 měsíců

1
0
0 0

Knot Resolver 5.7.0

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.7.0 has been released! Security - avoid excessive TCP reconnections in a few more cases Like before, the remote server had to behave nonsensically in order to inflict this upon itself, but it might be abusable for DoS. We thank Ivan Jedek from OryxLabs for reporting this. Improvements - forwarding mode: tweak dealing with failures from forwarders, in particular prefer sending CD=0 upstream (!1392) Bugfixes - fix unusual timestamp format in debug dumps of records (!1386) - adjust linker options; it should help less common platforms (!1384) - hints module: fix names inside home.arpa. (!1406) - EDNS padding (RFC 8467) compatibility with knot-dns 3.3 libs (!1422) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.7.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.7.0/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

1 rok, 8 měsíců

1
0
0 0

PID file path

by snowmailer＠gmail.com

Is there any way to write PID file to /var/run or so with knot-resolver? I can't find any info in documentation about it.

1 rok, 9 měsíců

2
1
0 0

Knot Resolver - redirect wildcard domain

by Milan Jeskynka Kazatel

Hello, could you please help me with knot resolver configuration in the case when I need to redirect each variation for the domain to some address. e.g. www.example.com, m.example.com, domain.example.com ... like wildcard record *.example.com 10.0.0.50 In my configuration is it handeled by file with static records -- load static records hints.add_hosts('/etc/knot-resolver/static_records.txt') which contains address to be redirected and the domain. 10.0.0.50 1xbet.com 10.0.0.50 thelotter.com 10.0.0.50 webmoneycasino.com 10.0.0.50 betworld.com 10.0.0.50 bosscasino.eu 10.0.0.50 sportingbull.com But I´m not able to handle the correct syntax for a wildcard domain redirection. Best regards, -- Smil Milan Jeskyňka Kazatel

1 rok, 9 měsíců

3
7
0 0

Setting up to use the OpenNIC root zone

by Ed V.

Hoping someone can help... Built Knot Resolver v5.6.0 from source. It works and resolves correctly for "regular" TLDs. However, I would like to point it to OpenNIC for resolution /forwarding so that I can resolve the expanded /alternative TLDs. Default configuration with: policy.add(policy.all( policy.FORWARD( {'2001:19f0:b001:379:5400:3ff:fe68:1cc6', '138.197.140.189', '2600:3c04::f03c:93ff:febd:be27', '45.61.49.203'}))) and it fails to find "grep.geek" using the standard root zone /hints: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22871 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;grep.geek. IN A ;; AUTHORITY SECTION: . 86077 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2023050902 1800 900 604800 86400 So I checked the Documentation site and found "hints.root" which theoretically will override any other root hints. Using the OpenNIC root zone file (downloads as "db.root") I set: hints.root ({ ['ns13.opennic.glue.'] = { '2a01:4f8:192:43a5::2', '144.76.103.143' } }) in kresd.conf. Still no joy - "grep.geek" is NXDOMAIN from a.root-servers.net again. Any thoughts? Things I might have missed along the way?

1 rok, 11 měsíců

3
5
0 0

DoH connection closed after 10 seconds

by Blažej Krajňák

Hello, it's me again :) I just want to make sure if behaviour of Knot Resolver is correct. I implemented DDR mechanism to discover DoH / DoT DNS servers. My Macbook with Ventura successfully discovered DoH server and started to use it. But: Knot Resolver sends 10 seconds after establishing FIN,ACK packet and connection is correctly closed. From this moment, Macbook starts to use DNS over UDP again and will retry DoH connection after 10-30s later. Then it uses DoH server again for 10 seconds .... Is this behaviour correct? Should Macbook sends some keepalive messages to prevent connection closing? Or should Macbook reopen DoH connection more quickly? Thanks, Blažej

2 roky, 1 měsíc

2
3
0 0

Policy based on destination IP

by Blažej Krajňák

Hello, is there any correct way how to do query policy based on destination IP (IP which processed the query)? Like view:addr but on the dst address. I found that function view.addr(_, subnet, rules, dst) contains DST parameter but I'm not sure how to use it. I also found function view.rule_dst(action, subnet) but still get errors: error: /usr/lib/knot-resolver/kres_modules/view.lua:103: attempt to index local 'req' (a number value) Thanks Blažej

2 roky, 2 měsíce

2
3
0 0

Implementing DDR SVCB record

by Blažej Krajňák

Hi there, I'm trying to implement SVCB record "_dns.resolver.arpa" for DDR mechanism for our AS50242 recursive resolvers. When I look on Cloudflare or Google implementation, they answer with "ADDITIONAL SECTION" also. kdig _dns.resolver.arpa @8.8.8.8 type64 ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 61402 ;; Flags: qr aa rd ra; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 4 ;; QUESTION SECTION: ;; _dns.resolver.arpa. IN SVCB ;; ANSWER SECTION: _dns.resolver.arpa. 86400 IN SVCB 1 dns.google. alpn=dot _dns.resolver.arpa. 86400 IN SVCB 2 dns.google. alpn=h2,h3 key7="/dns-query{?dns}" ;; ADDITIONAL SECTION: dns.google. 86400 IN A 8.8.8.8 dns.google. 86400 IN A 8.8.4.4 dns.google. 86400 IN AAAA 2001:4860:4860::8888 dns.google. 86400 IN AAAA 2001:4860:4860::8844 In Knot Resolver documentation is an example how to answer for SVCB request but without addition section. policy.add( policy.domains( policy.ANSWER( { [kres.type.SVCB] = { rdata=kres.parse_rdata({ 'SVCB 1 resolver.example. alpn=dot ipv4hint=192.0.2.1 ipv6hint=2001:db8::1', 'SVCB 2 resolver.example. mandatory=key65380 alpn=h2 key65380=/dns-query{?dns}', }), ttl=5 } } ), { todname('_testing.domain') })) Can anyone help me, how to add additional section to answer? Do we need to use policy.custom_action(state, request)? Thanks! Blažej

2 roky, 2 měsíce

3
5
0 0

Knot Resolver 5.6.0

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.6.0 has been released! Security - avoid excessive TCP reconnections in some cases (!1380) For example, a DNS server that just closes connections without answer could cause lots of work for the resolver (and itself, too). The number of connections could be up to around 100 per client's query. We thank Xiang Li from NISL Lab, Tsinghua University, and Xuesong Bai and Qifan Zhang from DSP Lab, UCI. Improvements - daemon: feed server selection with more kinds of bad-answer events (!1380) - cache.max_ttl(): lower the default from six days to one day and apply both limits to the first uncached answer already (!1323 #127) - depend on jemalloc, preferably, to improve memory usage (!1353) - no longer accept DNS messages with trailing data (!1365) - policy.STUB: avoid applying aggressive DNSSEC denial proofs (!1364) - policy.STUB: avoid copying +dnssec flag from client to upstream (!1364) Bugfixes - policy.DEBUG_IF: don't print client's packet unconditionally (!1366) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.6.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.6.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.6.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.6.0/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

2 roky, 2 měsíce

1
0
0 0

Knot Resolver 5.5.3

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.5.3 has been released! Security - fix CPU-expensive DoS by malicious domains - CVE-2022-40188 Improvements - fix config_tests on macOS (both HW variants) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.5.3/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.3.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.3.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.5.3/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

2 roky, 7 měsíců

1
0
0 0

Resolving problem connectivity.samsung.com.cn even on dual-stack

by Blažej Krajňák

Hello everyone, at AS50242 we experience problem with resolving connectivity.samsung.com.cn We run two servers, each with 4 instances. Both servers have working dual-stack (v4/v6). knot-dnsutils/unknown,now 3.1.1-cznic.1 amd64 [installed] knot-resolver-module-http/unknown,now 5.5.0-cznic.1 all [installed,automatic] knot-resolver-release/unknown,now 1.9-1 all [installed] knot-resolver/unknown,now 5.5.0-cznic.1 amd64 [installed] Dnsviz shows problem reaching few IPv6 servers of .cn TLD via UDP. I can not understand, why both of our servers response with SERVFAIL. Any ideas how to troubleshoot more? Thank you, Blažej

2 roky, 7 měsíců

3
7
0 0

not resolving CNAME

by Mike Wright

Hello, I am a user, not a developer, of knot-resolver, on ubuntu groovy. When I look up something that has a CNAME and ask for an A record I get a SERVFAIL. If I ask for the CNAME I get the correct answer but then I have to do another search for the A record for that. #------------- # using knot-resolver kdig @127.0.53.1 www.cdc.gov. ;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 44868 #------------- # using google dns kdig 8.8.8.8 www.cdc.gov. www.cdc.gov. 126 IN CNAME www.akam.cdc.gov. www.akam.cdc.gov. 20 IN A 104.100.61.241 #------------- My guess is I don't have a complete configuration. Here's my very simple knot-resolver.conf #------------ -- SPDX-License-Identifier: CC0-1.0 -- Network interface configuration net.listen('127.0.53.1') -- Load useful modules modules = { 'hints > iterate', -- Load /etc/hosts and allow custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } -- Cache size cache.size = 100 * MB -- -- MY STUFF -- internalDomains = policy.todnames({ 'main', '0.1.10.in-addr.arpa', '1.10.in-addr.arpa', '10.in-addr.arpa' }) policy.add(policy.suffix(policy.FLAGS({'NO_CACHE'}), internalDomains)) policy.add(policy.suffix(policy.STUB({'127.53.0.1'}), internalDomains)) #------------- How do I fix this? Thank you, Mike Wright

2 roky, 7 měsíců

2
2
0 0

When knot delete old ksk key ?

by support＠profiwh.eu

Hello, I have problem with ksk rotation keys. I've rotated shared KEY, submit by hand and rotate the key. I did setting of delete-delay, but after reaching time nothing happends. keymgr profivh.cz list 4a32ef440c27342c1aca748e0ff3236c41c9dff0 ksk=yes zsk=no tag=11739 algorithm=13 size=256 public-only=no pre-active=0 publish=1660242640 ready=1660246540 active=1660587842 retire-active=0 retire=0 post-active=0 revoke=0 remove=0 55c0eb5bbc46ffc5b0355311384e32957f369bf3 ksk=no zsk=yes tag=51831 algorithm=13 size=256 public-only=no pre-active=0 publish=1659353890 ready=0 active=1659357790 retire-active=0 retire=0 post-active=0 revoke=0 remove=0 a85ffe2752572a3e057c1dca6f1173e2d4f4a6b7 ksk=yes zsk=no tag=14655 algorithm=13 size=256 public-only=no pre-active=0 publish=1641666021 ready=1641666021 active=1655760727 retire-active=1660587842 retire=0 post-active=0 revoke=0 remove=1660587842 but time is over and knot didnt remove the key, list at current time : date +%s 1660838273 with policy setting : policy: - id: "signing_policy_prod" manual: "off" single-type-signing: "off" algorithm: "ecdsap256sha256" ksk-size: "256" zsk-size: "256" ksk-shared: "on" dnskey-ttl: "7200" ksk-lifetime: "0" zsk-lifetime: "2592000" delete-delay: "86400" propagation-delay: "14400" rrsig-lifetime: "1209600" rrsig-refresh: "604800" rrsig-pre-refresh: "3600" nsec3: "on" cds-cdnskey-publish: "none" with template : - id: "signed-zones" storage: "/var/lib/knot/szones" file: "%s" notify: [ "XXX.XXX.cz", "XXX.XXX.cz" ] acl: [ "sec1-transfer", "sec2-transfer" ] zonefile-sync: "0" zonefile-load: "whole" journal-content: "changes" dnssec-signing: "on" dnssec-policy: "signing_policy_prod" serial-policy: "unixtime" it is any normal behavior or is something wrong ? knotc (Knot DNS), version 3.1.9 Thanks for help.

2 roky, 8 měsíců

2
2
0 0

Knot Resolver 5.5.1

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.5.1 has been released! Improvements - daemon/tls: disable TLS resumption via tickets for TLS <= 1.2 (#742, !1295) - daemon/http: DoH now responds with proper HTTP codes (#728, !1279) - renumber module: allow rewriting subnet to a single IP (!1302) - renumber module: allow arbitrary netmask (!1306) - nameserver selection algorithm: improve IPv6 avoidance if broken (!1298) Bugfixes - modules/dns64: fix incorrect packet writes for cached packets (#727, !1275) - xdp: make it work also with libknot 3.1 (#735, !1276) - prefill module: fix lockup when starting multiple idle instances (!1285) - validator: fix some failing negative NSEC proofs (!1294, #738, #443) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.5.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.1.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.5.1/ Donation: https://donations.nic.cz/en/donate/?project=knot-resolver -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

2 roky, 8 měsíců

1
1
0 0

new user - issues with one domain

by Jürgen Echter

Hi, i installed knot-resolver on my mail server and i see a issue with a specific domain, dovecot.org. Everything is working as expected but this single domain doesn't always resolve. After some time postfix cannot check the domain where mails coming from and doesn't accept them. If i do dig dovecot.org, i get this (SERVFAIL): dig dovecot.org ; <<>> DiG 9.11.26-RedHat-9.11.26-6.el8 <<>> dovecot.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27594 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;dovecot.org. IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fr Apr 29 08:34:55 CEST 2022 ;; MSG SIZE rcvd: 40 it starts working again if do dig +cd, like this: dig +cd dovecot.org ; <<>> DiG 9.11.26-RedHat-9.11.26-6.el8 <<>> +cd dovecot.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56130 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;dovecot.org. IN A ;; ANSWER SECTION: dovecot.org. 300 IN A 94.237.12.234 ;; Query time: 245 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fr Apr 29 08:34:59 CEST 2022 ;; MSG SIZE rcvd: 56 i didn't have this kind of issue using unbound before i switched, so i think here would be the right place to ask. i'm using the knot-resolver 5.5.0 package from epel on rockylinux 8.5 and my kresd config is very simple: net.listen('127.0.0.1', 53, { kind = 'dns' }) net.listen('127.0.0.1', 853, { kind = 'tls' }) --net.listen('127.0.0.1', 443, { kind = 'doh2' }) net.listen('::1', 53, { kind = 'dns', freebind = true }) net.listen('::1', 853, { kind = 'tls', freebind = true }) --net.listen('::1', 443, { kind = 'doh2' }) -- Load useful modules modules = { 'hints > iterate', -- Allow loading /etc/hosts or custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } -- Cache size cache.size = 100 * MB -- use /etc/hosts entries -- hints.add_hosts() net.ipv6 = false Anything i can do to track this down? Thanks in advance for your help. Juergen

2 roky, 11 měsíců

2
3
0 0

kresd segfault

by Aleš Rygl

Hello, I have noticed kresd segfault: [Sun May 15 14:22:47 2022] kresd[1791403]: segfault at 407ce590 ip 00000000407ce590 sp 00007ffc2d192668 error 15 There were also about 1300 lines from the same PID with a message like this: May 15 14:23:45 xxxx kresd[1791403]: [primin] triggered priming query, next in 0 seconds Maybe it is related to the crash maybe not. OS: Debian Linux 11.3 kernel 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) Knot-Resolver: 5.5.0-cznic.1 With regards Ales

2 roky, 11 měsíců

2
1
0 0

100....Error Messages new user

by Günther J. Niederwimmer

Hello List, why i got hundreds of these error messages see below, How can I best determine whether and how knot-resolver is working correctly May 9 13:37:28 bbs kresd[2102]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:28 bbs kresd[2102]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:28 bbs kresd[2107]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:28 bbs kresd[2107]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:28 bbs kresd[2107]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2101]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2100]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Broken pipe) May 9 13:37:37 bbs kresd[2101]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2100]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2100]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2101]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2102]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2102]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2102]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Broken pipe) May 9 13:37:38 bbs kresd[2107]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2107]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2107]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) Thanks for the Help, -- mit freundlichen Grüßen / best Regards, Günther J. Niederwimmer

2 roky, 11 měsíců

2
1
0 0

100....Error Messages new user

by Günther J. Niederwimmer

Hello List why i got hundreds of these error messages see below, How can I best determine whether and how knot-resolver is working correctly May 9 13:37:28 bbs kresd[2102]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:28 bbs kresd[2102]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:28 bbs kresd[2107]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:28 bbs kresd[2107]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:28 bbs kresd[2107]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2101]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2100]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Broken pipe) May 9 13:37:37 bbs kresd[2101]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2100]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2100]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:37 bbs kresd[2101]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2102]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2102]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2102]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Broken pipe) May 9 13:37:38 bbs kresd[2107]: [graphi] reconnecting: 127.0.0.1@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2107]: [graphi] reconnecting: ::1@3000 tcp reason: / usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) May 9 13:37:38 bbs kresd[2107]: [graphi] reconnecting: 192.168.100.200@3000 tcp reason: /usr/share/lua/5.1/cqueues/socket.lua:449: exceeded unchecked error limit (Connection reset by peer) Thanks for the Help, -- mit freundlichen Grüßen / best Regards, Günther J. Niederwimmer

2 roky, 11 měsíců

1
0
0 0

Rebinding protection - how to suppress additional section

by Aleš Rygl

Hello, We are using Knot-Resolver 5.5.0 with rebinding protection: modules.load('rebinding < iterate') We have some complains about an invalid domain name being returned in the additional section of the response to the blocked request: ;; ADDITIONAL SECTION: explanation.invalid. 10800 IN TXT "blocked by DNS rebinding protection" It looks like some windows domain controllers running DNS clients do not like it and log an error: The DNS server encountered an invalid domain name in a packet from <Knot-Resolver IP> The packet will be rejected. The event data contains the DNS packet. Is there a way how to suppress this? Or even better response with SERVFAIL? Thanks Ales Rygl

3 roky

2
1
0 0

Preload module with mutliple instances of kresd

by Aleš Rygl

Hello, I'd would like to ask for help with preload module. The issue is that when running multiple instatnces of kresd under systemd usualy just one of them is able to start correctly. The other hangs and fails to start. The config is just copy/paste from the documentation: modules.load('prefill') prefill.config({ ['.'] = { url = 'https://www.internic.net/domain/root.zone', interval = 86400, -- seconds } }) Starting instances in a sequence does not help, the 2nd one hangs - and only if the 1st one is killed/stopped the 2nd one goes on and processes the root zone. Did I miss something in the documentation? With regards Ales Rygl

3 roky

2
2
0 0

Google Chrome not working with Knot Resolver via DoH

by Blažej Krajňák

Hello, at AS50242 we run two recursive resolvers for our ISP customers. Both resolvers are listening for doh2 with ECDSA SSL certs from Letsencrypt. ns1r.levonet.sk ns2r.levonet.sk kdig +https is working correctly, however I'm unable to use these DoH resolvers with Google Chrome (99.0.4844.74) browser on MacOS (12.2.1). In settings I entered "https://ns2r.levonet.sk" as custom DoH resolver and I got error: Please verify that this is a valid provider or try again. I have enabled Knot debugging for doh and tls and log is flooded with messages about "incomplete, refusing". Does anybody have an idea what's wrong? Has Chrome some specific requirements for DoH servers? Thanks Blažej Mar 15 19:47:44 ns2r kresd[1317767]: [doh ] [0x215d1e0] h2 session created for 2a02:6ca3:800:0:60c4:dcd1:0000:0000#57880 Mar 15 19:47:44 ns2r kresd[1317767]: [tls ] TLS handshake with 2a02:6ca3:800:0:60c4:dcd1:0000:0000#57880 has completed Mar 15 19:47:44 ns2r kresd[1317775]: [doh ] [0x168d620] h2 session created for 2a02:6ca3:800:0:60c4:dcd1:0000:0000#57881 Mar 15 19:47:44 ns2r kresd[1317775]: [tls ] TLS handshake with 2a02:6ca3:800:0:60c4:dcd1:0000:0000#57881 has completed Mar 15 19:47:45 ns2r kresd[1317771]: [doh ] [0x1016940] h2 session created for 2a02:6ca3:800:0:60c4:dcd1:0000:0000#57882 Mar 15 19:47:45 ns2r kresd[1317771]: [tls ] TLS handshake with 2a02:6ca3:800:0:60c4:dcd1:0000:0000#57882 has completed Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (begin_headers_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 7 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (begin_headers_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:45 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 15 incomplete, refusing (header_callback) Mar 15 19:47:46 ns2r kresd[1317767]: [doh ] [0x215d1e0] stream 23 incomplete, refusing (begin_headers_callback)

3 roky, 1 měsíc

3
3
0 0

Survey on DNS resolver operations and DNSSEC

by Moritz Müller

Hi everyone, The DNS Security Extensions (DNSSEC) add integrity and authenticity to the Domain Name System (DNS). Now, more than 17 years after their standardization, we would like to hear from DNS recursive resolver operators about their experience with DNSSEC. For this reason, we have set up a short survey. It’s directed mainly towards organisations that run a recursive resolver. Filling out the survey should take roughly 5 to 10 minutes. https://forms.gle/FxTD9FofaogdvLqcA (link directs to Google Forms) This survey is carried out by SIDN Labs (https://sidnlabs.nl) and by the Swedish Internet Foundation (https://internetstiftelsen.se/en/). You can contact us via email: moritz.muller(a)sidn.nl Please excuse us, if you have received this email via different mailing lists. — Moritz Müller Research Engineer at SIDN Labs

3 roky, 1 měsíc

1
0
0 0

Knot Resolver 5.5.0

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.5.0 has been released! Improvements - extended_errors: module for extended DNS error support, RFC8914 (!1234) - policy: log policy actions; useful for RPZ debugging (!1239) - policy: new action policy.IPTRACE for logging request origin (!1239) - prefill module: prepare for ZONEMD, improve performance (!1225) - validator: conditionally ignore SHA1 DS, as SHOULD by RFC4509 (!1251) - lib/resolve: use EDNS padding for outgoing TLS queries (!1254) - support for PROXYv2 protocol (!1238) - lib/resolve, policy: new NO_ANSWER flag for not responding to clients (!1257) Incompatible changes - libknot >= 3.0.2 is required Bugfixes - doh2: fix CORS by adding `access-control-allow-origin: *` (!1246) - net: fix listen by interface - add interface suffix to link-local IPv6 (!1253) - daemon/tls: fix resumption for outgoing TLS (e.g. TLS_FORWARD) (!1261) - nameserver selection: fix interaction of timeouts with reboots (#722, !1269) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.5.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.5.0/ Donation: https://donations.nic.cz/en/donate/?project=knot-resolver -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

3 roky, 1 měsíc

1
0
0 0

Knot Resolver 5.5.0.

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.5.0 has been released! Improvements - extended_errors: module for extended DNS error support, RFC8914 (!1234) - policy: log policy actions; useful for RPZ debugging (!1239) - policy: new action policy.IPTRACE for logging request origin (!1239) - prefill module: prepare for ZONEMD, improve performance (!1225) - validator: conditionally ignore SHA1 DS, as SHOULD by RFC4509 (!1251) - lib/resolve: use EDNS padding for outgoing TLS queries (!1254) - support for PROXYv2 protocol (!1238) - lib/resolve, policy: new NO_ANSWER flag for not responding to clients (!1257) Incompatible changes - libknot >= 3.0.2 is required Bugfixes - doh2: fix CORS by adding `access-control-allow-origin: *` (!1246) - net: fix listen by interface - add interface suffix to link-local IPv6 (!1253) - daemon/tls: fix resumption for outgoing TLS (e.g. TLS_FORWARD) (!1261) - nameserver selection: fix interaction of timeouts with reboots (#722, !1269) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.5.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.5.0/ Donation: https://donations.nic.cz/en/donate/?project=knot-resolver -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

3 roky, 1 měsíc

1
0
0 0

Knot Resolver 5.5.0

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.5.0 has been released! Improvements - extended_errors: module for extended DNS error support, RFC8914 (!1234) - policy: log policy actions; useful for RPZ debugging (!1239) - policy: new action policy.IPTRACE for logging request origin (!1239) - prefill module: prepare for ZONEMD, improve performance (!1225) - validator: conditionally ignore SHA1 DS, as SHOULD by RFC4509 (!1251) - lib/resolve: use EDNS padding for outgoing TLS queries (!1254) - support for PROXYv2 protocol (!1238) - lib/resolve, policy: new NO_ANSWER flag for not responding to clients (!1257) Incompatible changes - libknot >= 3.0.2 is required Bugfixes - doh2: fix CORS by adding `access-control-allow-origin: *` (!1246) - net: fix listen by interface - add interface suffix to link-local IPv6 (!1253) - daemon/tls: fix resumption for outgoing TLS (e.g. TLS_FORWARD) (!1261) - nameserver selection: fix interaction of timeouts with reboots (#722, !1269) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.5.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.5.0/ Donation: https://donations.nic.cz/en/donate/?project=knot-resolver -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

3 roky, 1 měsíc

1
0
0 0

Knot Resolver 5.5.0

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.5.0 has been released! Improvements - extended_errors: module for extended DNS error support, RFC8914 (!1234) - policy: log policy actions; useful for RPZ debugging (!1239) - policy: new action policy.IPTRACE for logging request origin (!1239) - prefill module: prepare for ZONEMD, improve performance (!1225) - validator: conditionally ignore SHA1 DS, as SHOULD by RFC4509 (!1251) - lib/resolve: use EDNS padding for outgoing TLS queries (!1254) - support for PROXYv2 protocol (!1238) - lib/resolve, policy: new NO_ANSWER flag for not responding to clients (!1257) Incompatible changes - libknot >= 3.0.2 is required Bugfixes - doh2: fix CORS by adding `access-control-allow-origin: *` (!1246) - net: fix listen by interface - add interface suffix to link-local IPv6 (!1253) - daemon/tls: fix resumption for outgoing TLS (e.g. TLS_FORWARD) (!1261) - nameserver selection: fix interaction of timeouts with reboots (#722, !1269) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.5.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.5.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.5.0/ Donation: https://donations.nic.cz/en/donate/?project=knot-resolver -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

3 roky, 1 měsíc

1
0
0 0

Crashless crash

by Łukasz Jarosz

Hello, I recently deployed knot-resolver as main resolver for my network with following config: -- modules modules = { 'policy', 'view', 'workarounds < iterate', 'stats', -- required by predict module 'predict', 'http', } -- network net.ipv6 = false net.listen('0.0.0.0', 53, { kind = 'dns' }) net.listen('0.0.0.0', 8453, { kind = 'webmgmt' }) -- permissions user('knot-resolver','knot-resolver') -- cache, stats, performance optimizations cache.open(950*MB, 'lmdb:///cache/knot-resolver') cache.min_ttl(600) predict.config({ window = 5, period = 1*(60/5) }) -- limit access with ACLs view:addr('127.0.0.0/8', policy.all(policy.PASS)) view:addr('172.16.0.0/12', policy.all(policy.PASS)) view:addr('10.0.0.0/8', policy.all(policy.PASS)) view:addr('redacted', policy.all(policy.PASS)) view:addr('redacted', policy.all(policy.PASS)) view:addr('redacted', policy.all(policy.PASS)) view:addr('0.0.0.0/0', policy.all(policy.DROP)) -- query resolving policies policy.add(policy.rpz(policy.ANSWER, '/run/knot-resolver/custom.rpz', true)) policy.add(policy.all(policy.FORWARD({ "9.9.9.9", "8.8.8.8", }))) Process is started inside docker container with properly attached tmpfs at /cache mountpoint. Setup is monitored through prometheus and I received notification around 21:55 that exporter is down. To be exact context deadline exceeded (scrape_interval: 15s). I grabbed control socket and dumped following stats: > worker.stats() { ['concurrent'] = 1, ['csw'] = 31436648, ['dropped'] = 16081, ['err_http'] = 0, ['err_tcp'] = 0, ['err_tls'] = 0, ['err_udp'] = 0, ['ipv4'] = 9950850, ['ipv6'] = 0, ['pagefaults'] = 1, ['queries'] = 30978879, ['rss'] = 166846464, ['swaps'] = 0, ['systime'] = 2681.109337, ['tcp'] = 232596, ['timeout'] = 139212, ['tls'] = 0, ['udp'] = 9718254, ['usertime'] = 6298.521581, } > cache.stats() { ['clear'] = 1, ['close'] = 1, ['commit'] = 23279836, ['count'] = 20349, ['count_entries'] = 340222, ['match'] = 0, ['match_miss'] = 0, ['open'] = 2, ['read'] = 144512076, ['read_leq'] = 10170653, ['read_leq_miss'] = 4988410, ['read_miss'] = 25166216, ['remove'] = 0, ['remove_miss'] = 0, ['usage_percent'] = 11.396792763158, ['write'] = 25742556, } When I opened web interface I noticed steady decline in requests. [image: image.png] I think this means that clients mostly moved to secondary DNS resolver. Also when reviewing gathered data in grafana dashboard I noticed that slow (250ms+) queries are prevalent from the fast queries. [image: image.png] Any advice what happened here? Best regards, Łukasz Jarosz

3 roky, 1 měsíc

1
0
0 0

Removing a temporary negative trust anchor

by Matthew Richardson

Running 5.4.4, adding an NTA seems very straightforward:- >> trust_anchors.set_insecure( {"fj"} ) > >> trust_anchors.summary() >'fj. is negative trust anchor >. 172800 DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ; Valid: ; KeyTag:20326 >' What is the precise incantation to remove it when it is no longer required? The following do not work:- >> trust_anchors.remove('fj') >false >> trust_anchors.remove('fj.') >false >> trust_anchors.remove( {"fj"} ) >false Any help would be appreciated. Also, does Knot Resolver allow an automatic timeout when setting NTAs as Bind does? --- Best wishes, Matthew

3 roky, 1 měsíc

2
2
0 0

Unicode issue

by Łukasz Jarosz

Hello, I am trying to import custom generated RPZ list into kresd, but daemon fails with following error "[policy] RPZ: invalid domain name character". I am using UTF-8 as encoding for file. Any pointers how to convince kres to ingest these domain names would be greatly appreciated. Best regards, Łukasz Jarosz

3 roky, 1 měsíc

2
2
0 0

Knot Resolver dropping requests

by Aleš Rygl

Hello, I'd like to kindly ask for help with following issue. I am considering to deploy knot-resolver to the DNS solution where it should coexist with other DNS daemons namely Unbound. I am running dnsdist <https://dnsdist.org/> in front of the pool of resolvers where I have just added also the latest release (5.5.4) of knot-resolver. It receives a portion of requests at the rate about 500qps. There are 6 kresd processes on a VM running with cache in tmpfs. Cache size is 2GB (8GB mounted to tmpfs). Resolver is running Debian Bullseye. The solution is serving real customers - the traffic is not artificial. The configuration enables some modules: modules = { 'hints > iterate', -- Load /etc/hosts and allow custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records 'bogus_log', -- DNSSEC validation failure logging 'nsid', 'prefill', 'rebinding < iterate' } cache.size = cache.fssize() - 6*GB modules = { predict = { window = 15, -- 15 minutes sampling window period = 6*(60/15) -- track last 6 hours } } policy.add( policy.rpz(policy.DENY, '/var/cache/unbound/db.rpz.xxx.cz', true) ) And the Carbon protocol reporting is enabled with the sample rate of 5s. The performance in terms of response time is equal or even better when comparing with Unbound. I am measuring the performance of the dnsdist's backend servers (daemons) - the latency, dropped requests and the requests rate using Carbon protocol with sample rate of 5s. The backend servers kresd included are receiving requests from just several clients at the moment (source IPs of the balancers). What is wrong here is some kind of repeated packet drops reported for kresd instance by dnsdist. It appears in about 15 min. interval. When it occurs the drop rate increases from about 0.5 req/s (standard behavior) to 5-10 req/s which causes a positive feedback and increased packet rate. There are such peaks every 15 min. When I restart the kresd instances drops go away and everything is stellar for couple of hours. I have no explanation for that. It is apparently not related to the requests - I have tried to simulate this by replaying the traffic captured when the problem occurs several times without success. kresd can even process 20k qps on this instance with no increase of drop rate from the balancer's point of view. But after a while... The fact that restarting kresd helps immediately shows that there might be something wrong inside. I have tried to increase the number of kresd processes, cache size and disabling the cache persistence. Nothing helps here. I am pretty sure there are no network issues on the VM or surrounding network. I can provide some graphical representations of this behavior of it is needed or a packet capture of the real traffic. Many thanks With best regards Ales Rygl

3 roky, 1 měsíc

2
2
0 0

How to post DNSTAP data to rsyslog

by Martin Zingor

Hello, I'd like to post DNSTAP data to remote syslog. In kresd.conf I have: ... dnstap.config({ socket_path = "/tmp/dnstap.sock", }) ... I try run socat to create and listen on socket but no data I see. What is wrong? Thank you. MZ

3 roky, 2 měsíce

1
0
0 0

Knot Resolver 5.4.4

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.4.4 has been released! Bugfixes -------- - fix bad zone cut update in certain cases (e.g. AWS; !1237) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.4.4/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.4.4.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.4.4.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.4.4/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

3 roky, 3 měsíce

1
0
0 0

Knot Resolver 5.4.3

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.4.3 has been released! Improvements ------------ - lua: add kres.parse_rdata() to parse RDATA from string to wire format (!1233) - lua: add policy.domains() for exact domain name matching (!1228) Bugfixes -------- - policy.rpz: fix origin detection in files without $ORIGIN (!1215) - lua: log() works again; broken in 5.4.2 (!1223) - policy: correctly include EDNS0 previously omitted by some actions (!1230) - edns_keepalive: module is now properly loaded (!1229, thanks Josh Soref!) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.4.3/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.4.3.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.4.3.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.4.3/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

3 roky, 4 měsíce

1
0
0 0

Knot resolver in front of systemd-resolved stub resolver, more issues

by Sergio Callegari

Hi, I am writing looking for some help with a setup where the local lan has a machine with knot resolver and some of the hosts that are connected to the LAN are ubuntu machines that by default use systemd-resolved as a local caching stub resolver. For some reasons this combination appears troublesome and I am trying to undestand all the reasons why. One issue has already been identified as a systemd-resolved, in the ubuntu focal version getting confused by a (correct) answer from kresd (discussion on https://gitlab.nic.cz/knot/knot-resolver/-/issues/686#note_234431). Now, I find another issue in that I do not appear successful in making systemd-resolved talk to kresd over tls. This would be important because most of the ubuntu focal hosts are setup with systemd-resolved using opportunistic tls. If systemd-thinks that there is a problem with contacting the current DNS server via tls then it switches to the fallback server and kresd ends up not being used at all. If I use `resolvectl` to set the DNS of an ubuntu host to point to the machine with kresd and I activate DNSoverTLS, then I get: resolvectl query lwn.net lwn.net: resolve call failed: All attempts to contact name servers or networks failed Similarly, if I user resolvectl to set to use opportunistic DNSoverTLS, things seem to work, but I see on the journal some messages about Using degraded feature set UDP for DNS server Thus, I'd be glad to get some pointer at how to check that DNS over TLS works correctly with kresd and how to verify why systemd-resolved fails. Thanks! Sergio

3 roky, 4 měsíce

2
1
0 0

Knot resolver in front of systemd-resolved stub resolver, more issues

by Sergio Callegari

Hi, I am writing looking for some help with a setup where the local lan has a machine with knot resolver and some of the hosts that are connected to the LAN are ubuntu machines that by default use systemd-resolved as a local caching stub resolver. For some reasons this combination appears troublesome and I am trying to undestand all the reasons why. One issue has already been identified as a systemd-resolved, in the ubuntu focal version getting confused by a (correct) answer from kresd (discussion on https://gitlab.nic.cz/knot/knot-resolver/-/issues/686#note_234431). Now, I find another issue in that I do not appear successful in making systemd-resolved talk to kresd over tls. This would be important because some of the ubuntu focal hosts are setup with systemd-resolved using tls. If I use `resolvectl` to set the DNS of an ubuntu host to point to the machine with kresd and I activate DNSoverTLS, then I get: resolvectl query lwn.net lwn.net: resolve call failed: All attempts to contact name servers or networks failed Similarly, if I user resolvectl to set to use opportunistic DNSoverTLS, things seem to work, but I see on the journal some messages about Using degraded feature set UDP for DNS server Thus, I'd be glad to get some pointer at how to check that DNS over TLS works correctly with kresd and how to verify why systemd-resolved fails. Thanks! Sergio

3 roky, 4 měsíce

1
0
0 0

CNAME resolving knot-resolver vs bind

by tomas tomas

Hello, I have a problem with knot-resolver and resolving CNAME on my domain, but request to bind-resolver is ok. Some configuration parameter (such as --trust_anchors.set_insecure,remove) doesn't solve my problem. Could you help me please? Commands (data is anonymized) : [ ~]$ nslookup elearning.mycompany.sk 192.168.1.53 # kresd -failed Server: 192.168.1.53 Address: 192.168.1.53#53 Non-authoritative answer: elearning.mycompany.sk canonical name = elearning.netcompany.sk. [ ~]$ nslookup elearning.mycompany.sk 192.168.1.33 # bind -ok Server: 192.168.1.33 Address: 192.168.1.33#53 Non-authoritative answer: elearning.mycompany.sk canonical name = elearning.netcompany.sk. Name: elearning.netcompany.sk. Address: 53.53.53.153 [~]$ nslookup elearning.netcompany.sk. 192.168.1.53 # kresd -ok Server: 192.168.1.53 Address: 192.168.1.53#53 Non-authoritative answer: Name: elearning.netcompany.sk Address: 53.53.53.153 Here is trace command from kresd: [ ~]$ curl -s --noproxy "*" http://127.0.0.1:8453/trace/elearning.mycompany.sk [iterat][205086.00] 'elearning.mycompany.sk.' type 'A' new uid was assigned .01, parent uid .00 [cache ][205086.01] => satisfied by exact packet: rank 021, new TTL 7110 [iterat][205086.01] <= answer received: ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 31993 ;; Flags: qr aa rd QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: Unused ;; QUESTION SECTION elearning.mycompany.sk. A ;; ANSWER SECTION elearning.mycompany.sk. 7110 CNAME elearning.netcompany.sk. ;; ADDITIONAL SECTION [resolv][205086.01] AD: request NOT classified as SECURE [resolv][205086.01] finished in state: 4, queries: 1, mempool: 131152 B ;; selected from ANSWER sections: ; ranked rrset to_wire true, rank 021 (omit auth), cached false, qry_uid 1, revalidations 0 elearning.mycompany.sk. 7110 CNAME elearning.netcompany.sk. curl -s --noproxy "*" http://127.0.0.1:8453/trace/elearning.netcompany.sk. [iterat][65580.00] 'elearning.netcompany.sk.' type 'A' new uid was assigned .01, parent uid .00 [cache ][65580.01] => satisfied by exact RRset: rank 030, new TTL 1187 [iterat][65580.01] <= answer received: ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 21817 ;; Flags: qr aa QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0 ;; QUESTION SECTION elearning.netcompany.sk. A ;; ANSWER SECTION elearning.netcompany.sk. 1187 A 53.53.53.153 elearning.netcompany.sk. 1187 RRSIG A 7 3 1800 .... [iterat][65580.01] <= rcode: NOERROR [resolv][65580.01] AD: request NOT classified as SECURE [resolv][65580.01] finished in state: 4, queries: 1, mempool: 147552 B ;; selected from ANSWER sections: ; ranked rrset to_wire true, rank 030 (insecure auth), cached false, qry_uid 1, revalidations 0 elearning.netcompany.sk. 1187 A 53.53.53.153 ; ranked rrset to_wire true, rank 030 (insecure auth), cached false, qry_uid 1, revalidations 0 elearning.netcompany.sk. 1187 RRSIG A 7 3 1800 ..... [ ~]$ journalctl -u kresd@1 kresd[18169]: [iterat][34703.00] 'elearning.mycompany.sk.' type 'A' new uid was assigned .01, parent uid .00 kresd[18169]: [cache ][34703.01] => satisfied by exact packet: rank 021, new TTL 6811 kresd[18169]: [resolv][34703.01] AD: request NOT classified as SECURE kresd[18169]: [resolv][34703.01] finished in state: 4, queries: 1, mempool: 65600 B kresd[18169]: [plan ][00000.00] plan 'elearning.netcompany.sk.' type 'AAAA' uid [17932.00] kresd[18169]: [iterat][17932.00] 'elearning.netcompany.sk.' type 'AAAA' new uid was assigned .01, parent uid .00 kresd[18169]: [cache ][17932.01] => satisfied by exact packet: rank 020, new TTL 1411 kresd[18169]: [iterat][17932.01] <= rcode: NOERROR kresd[18169]: [resolv][17932.01] AD: request NOT classified as SECURE My kresd.conf: log_level('warning') net.listen('192.168.1.53', 53, { kind = 'dns', freebind = true }) net.listen('192.168.1.53', 853, { kind = 'tls', freebind = true }) net.listen('127.0.0.1', 8453, { kind = 'webmgmt' }) user('knot-resolver','knot-resolver') modules = { 'hints > iterate', -- Load /etc/hosts and allow custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records 'policy', 'view', -- view:addr(..) 'prefill', -- Cache prefilling 'http' } internalDomains = policy.todnames({'mycompany.sk'}) externalIP = policy.todnames({'53.53.53.in-addr.arpa.'}) policy.add(policy.suffix(policy.STUB({'192.168.1.3','192.168.1.4'}), internalDomains)) policy.add(policy.suffix(policy.STUB({'192.168.1.3','192.168.1.4'}), externalIP)) view:addr('192.168.0.0/16', policy.all(policy.PASS)) view:addr('172.16.0.0/12', policy.all(policy.PASS)) view:addr('10.0.0.0/8', policy.all(policy.PASS)) view:addr('0.0.0.0/0', policy.all(policy.DROP)) --trust_anchors.set_insecure({ 'mycompany.sk.', 'netcompany.sk.' }) --trust_anchors.remove('.') cache.size = cache.fssize() - 10*MB thanks Tomas

3 roky, 5 měsíců

2
2
0 0

Re: [knot-resolver-users] Error reading TLS certificates

by Vladimír Čunát

On 29/10/2021 16.59, Martin Dosch wrote: > You're right. Although the certs are readable (and other services > successfully read them already) it works after I created a script > which copys the files into kresd's workdir and chowns them to > knot-resolver. Maybe those other services run as root user or something...

3 roky, 5 měsíců

1
0
0 0

Error reading TLS certificates

by Martin Dosch

Dear all, I am using knot-resolver for DNS over TLS (DoT) for a while now. So far I let nginx handle the TLS part on port 853 and proxy the requests to 127.0.0.1:53. I wanted to simplify my setup and let knot-resolver do the whole thing. But I am facing problems on my server (Debian Stable Bullseye). I can enable DoT on 853 successfully using without specifying certs but I want to use my TLS certs created by certbot. Once I add the following line kresd fails to start. > net.tls("/etc/letsencrypt/live/mdosch.de/fullchain.pem", > "/etc/letsencrypt/live/mdosch.de/privkey.pem") Systemd shows me the following error: > Oct 28 19:49:41 v220191283267104968 systemd[1]: Starting Knot Resolver daemon... > Oct 28 19:49:41 v220191283267104968 kresd[22488]: [tls] gnutls_certificate_set_x509_key_file(/etc/letsencrypt/live/md> > Oct 28 19:49:41 v220191283267104968 kresd[22488]: [system] error while loading config: error occurred here (config fi> > Oct 28 19:49:41 v220191283267104968 kresd[22488]: stack traceback: > Oct 28 19:49:41 v220191283267104968 kresd[22488]: [C]: in function 'tls' > Oct 28 19:49:41 v220191283267104968 kresd[22488]: /etc/knot-resolver/kresd.conf:3: in main chunk > Oct 28 19:49:41 v220191283267104968 kresd[22488]: ERROR: Invalid argument (workdir '/var/lib/knot-resolver') > Oct 28 19:49:41 v220191283267104968 systemd[1]: kresd(a)1.service: Main process exited, code=exited, status=1/FAILURE > Oct 28 19:49:41 v220191283267104968 systemd[1]: kresd(a)1.service: Failed with result 'exit-code'. > Oct 28 19:49:41 v220191283267104968 systemd[1]: Failed to start Knot > Resolver daemon. The files are world readable so I don't know what's going on: > ll /etc/letsencrypt/live/mdosch.de/ > total 4.0K > -rw-r--r-- 1 certbot prosody 692 Jun 11 00:30 README > lrwxrwxrwx 1 root root 38 Oct 27 22:07 cert.pem -> ../../archive/mdosch.de-0003/cert9.pem > lrwxrwxrwx 1 root root 39 Oct 27 22:07 chain.pem -> ../../archive/mdosch.de-0003/chain9.pem > lrwxrwxrwx 1 root root 43 Oct 27 22:07 fullchain.pem -> ../../archive/mdosch.de-0003/fullchain9.pem > lrwxrwxrwx 1 root root 41 Oct 27 22:07 privkey.pem -> ../../archive/mdosch.de-0003/privkey9.pem Also I don't understand why it complains about the workdir as I didn't change anything regarding workdir but only pointed to the cert and key file. Do you have any idea what I am doing wrong? Best regards, Martin

3 roky, 5 měsíců

2
3
0 0

DNSSEC failure on insecure subzone with cold cache

by Matthew Richardson

Whilst setting up Knot Resolver (version 5.4.1 on Rocky 8), it fails to resolve 213-133-203-34.newtel.in-addr.itconsult.net with a cold cache, but succeeds if the cache has been specifically warmed. With the cold cache SERVFAIL is returned and it logs:- >Oct 16 18:40:52 dt05 kresd[36140]: [dnssec] validation failure: 213-133-203-34.newtel.in-addr.itconsult.net. PTR The zone cut is between itconsult.net & newtel.in-addr.itconsult.net. Also whilst itconsult.net is DNSSEC signed, newtel.in-addr.itconsult.net is not. Thus, in-addr.itconsult.net is an empty non-terminal. If one asks for NS for newtel.in-addr.itconsult.net, thereafter resolution of the PTR then succeeds:- >[root@dt05 ~]# dig @dt05 -p 533 -t ptr 213-133-203-34.newtel.in-addr.itconsult.net > >; <<>> DiG 9.11.26-RedHat-9.11.26-4.el8_4 <<>> @dt05 -p 533 -t ptr 213-133-203-34.newtel.in-addr.itconsult.net >; (1 server found) >;; global options: +cmd >;; Got answer: >;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39692 >;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > >;; OPT PSEUDOSECTION: >; EDNS: version: 0, flags:; udp: 1232 >;; QUESTION SECTION: >;213-133-203-34.newtel.in-addr.itconsult.net. IN PTR > >;; Query time: 6 msec >;; SERVER: 193.201.42.59#533(193.201.42.59) >;; WHEN: Sat Oct 16 18:40:52 BST 2021 >;; MSG SIZE rcvd: 72 > >[root@dt05 ~]# dig @dt05 -p 533 -t ns newtel.in-addr.itconsult.net > >; <<>> DiG 9.11.26-RedHat-9.11.26-4.el8_4 <<>> @dt05 -p 533 -t ns newtel.in-addr.itconsult.net >; (1 server found) >;; global options: +cmd >;; Got answer: >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2636 >;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 > >;; OPT PSEUDOSECTION: >; EDNS: version: 0, flags:; udp: 1232 >;; QUESTION SECTION: >;newtel.in-addr.itconsult.net. IN NS > >;; ANSWER SECTION: >newtel.in-addr.itconsult.net. 86400 IN NS c.itconsult-dns.je. >newtel.in-addr.itconsult.net. 86400 IN NS d.itconsult-dns.co.uk. >newtel.in-addr.itconsult.net. 86400 IN NS e.itconsult-dns.biz. >newtel.in-addr.itconsult.net. 86400 IN NS a.itconsult-dns.net. >newtel.in-addr.itconsult.net. 86400 IN NS b.itconsult-dns.org. > >;; Query time: 2 msec >;; SERVER: 193.201.42.59#533(193.201.42.59) >;; WHEN: Sat Oct 16 18:41:05 BST 2021 >;; MSG SIZE rcvd: 223 > >[root@dt05 ~]# dig @dt05 -p 533 -t ptr 213-133-203-34.newtel.in-addr.itconsult.net > >; <<>> DiG 9.11.26-RedHat-9.11.26-4.el8_4 <<>> @dt05 -p 533 -t ptr 213-133-203-34.newtel.in-addr.itconsult.net >; (1 server found) >;; global options: +cmd >;; Got answer: >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8992 >;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > >;; OPT PSEUDOSECTION: >; EDNS: version: 0, flags:; udp: 1232 >;; QUESTION SECTION: >;213-133-203-34.newtel.in-addr.itconsult.net. IN PTR > >;; ANSWER SECTION: >213-133-203-34.newtel.in-addr.itconsult.net. 43200 IN PTR eth0-70.qr-r01a.itconsult.net. > >;; Query time: 1 msec >;; SERVER: 193.201.42.59#533(193.201.42.59) >;; WHEN: Sat Oct 16 18:41:08 BST 2021 >;; MSG SIZE rcvd: 102 My suspicion (being new to Knot Resolver) is that this somehow relates to QNAME minimisation. DNSviz is not reporting any problems:- > https://dnsviz.net/d/213-133-203-34.newtel.in-addr.itconsult.net/dnssec/ Is this a bug, or expected behaviour with a slightly odd setup? Best wishes, Matthew

3 roky, 6 měsíců

2
4
0 0

Knot Resolver 5.4.2

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.4.2 has been released! Improvements ------------ - dns64 module: also map the reverse (PTR) subtree (#478, !1201) - dns64 module: allow disabling based on client address (#368, !1201) - dns64 module: allow configuring AAAA subnets not allowed in answer (!1201) - nameserver selection algorithm: improve IPv6 avoidance if broken (!1207) Bugfixes -------- - lua: log() output is visible with default log level again (!1208) - build: fix when knot-dns headers are on non-standard location (!1210) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.4.2/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.4.2.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.4.2.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.4.2/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

3 roky, 6 měsíců

2
2
0 0

Local domain integration

by Günther J. Niederwimmer

Hi there, is it actually possible to import a zone file for a locale zone (yyyyy.xxxx.com.lan) or does it have to be done differently? In any case, I can't figure out how to do it correctly! Can someone help with an example i have had some problems with my local domains since i switched to knot? Can you actually import the domains from knot into the knot resolver? I would like to have a stable DNS system on my servers again with knot & knot- resolver I hope I "think" correctly, a 25 year "bind" damaged person ;-) -- mit freundlichen Grüßen / best regards Günther J. Niederwimmer

3 roky, 6 měsíců

2
1
0 0

KNOT Resolver DNS over TLS Error

by Günther J. Niederwimmer

Hello List, I would like to install KNOT-resolver, first test it with DNS over TLS, but that doesn't work? My system is an oracle Linux 8.4 I have a Letsencrypt certificate for this system and wanted to integrate it into kresd, but I get a GNUTLS error? Sep 22 18:27:30 bbs kresd[446005]: [tls ] gnutls_certificate_set_x509_key_file(/etc/letsencrypt/live/bbs.xxxx.xxxx/ fullchain_ecdsa.pem,/etc/pki/private/xxxx.xxxx_ec.key) failed: -64 (GNUTLS_E_FILE_ERROR) Sep 22 18:27:30 bbs kresd[446005]: [system] error while loading config: error occurred here (config filename:lineno is at the bottom, if config is involved):#012stack traceback:#012#011[C]: in function 'tls'#012#011/etc/knot- resolver/kresd.conf:24: in main chunk#012ERROR: Invalid argument (workdir '/ var/lib/knot-resolver') Sep 22 18:27:30 bbs systemd[1]: kresd(a)1.serbice.service: Main process exited, code=exited, status=1/FAILURE Does this not work with a Letsenkrypt certificate or I have another error in my configuration My config -- SPDX-License-Identifier: CC0-1.0 -- vim:syntax=lua:set ts=4 sw=4: -- Refer to manual: https://knot-resolver.readthedocs.org/en/stable/ -- Uncomment this only if you need to debug problems -- verbose(true) log_level('debug') -- Network interface configuration net.listen('127.0.0.1', 53, { kind = 'dns' }) net.listen('127.0.0.1', 853, { kind = 'tls' }) --net.listen('127.0.0.1', 443, { kind = 'doh2' }) net.listen('::1', 53, { kind = 'dns', freebind = true }) net.listen('::1', 853, { kind = 'tls', freebind = true }) --net.listen('::1', 443, { kind = 'doh2' }) net.listen('xxx.xxx.xxx.1', 53, { kind = 'dns' }) net.listen('xxx.xxx.xxx.1', 853, { kind = 'tls' }) net.listen('192.168.100.200', 53, { kind = 'dns' }) net.listen('192.168.100.200', 853, { kind = 'tls' }) net.listen('xxx:xxxx:xxxx:xxx::200', 53, { kind = 'dns' }) net.listen('xxx:xxxx:xxxx:xxx::200', 853, { kind = 'tls' }) -- DNS over TLS net.tls("/etc/letsencrypt/live/bbs.xxxx.xxx/fullchain_ecdsa.pem", "/etc/pki/ tls/private/xxxx.xxx_ec.key") -- Load useful modules modules = { 'hints > iterate', -- Load /etc/hosts and allow custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } I heard / read from a user that knot resolver must have its own rights for the certificate, but that is not possible, because the key is also intended for other computers and this creates a system risk? Is this a design problem or a bug? Thanks for an answer, -- mit freundlichen Grüßen / best regards Günther J. Niederwimmer

3 roky, 7 měsíců

3
4
0 0

Knot Resolver DNS over TLS Error

by Vladimír Čunát

On 24/09/2021 14.29, Günther J. Niederwimmer wrote: > I mean my cert and key are are equipped with "standard" rights ? > > Knot-resolver can't handle it ? It does not run under "root" user or group (by default), so in your settings it won't be able to read them. --Vladimir

3 roky, 7 měsíců

1
0
0 0

Issuing multiple recursive queries

by Elipsion

Hi, I'm having trouble reading the documentation for Lua modules, is it possible to issue multiple recursive queries and await all of the results? What I'm trying to achieve is a CNAME glue-zone, d.example.com, that searches in several other zones (phy.example.com, vm.example.com, ad.example.com, etc) and returns a CNAME record into the one with the highest priority (configurable, probably just a list) that does not reply with a NXDOMAIN. I'd like to do all the recursions in parallel, to keep users as happy as possible. Configuration might look something like this: local zones = { ["d.example.com"] = { "phy.example.com", "vm.example.com", "ad.example.com" }, ["vm.example.com"] = { "vmware.vm.example.com", "hyperv.vm.example.com" } } /Erik () ascii ribbon - against html e-mail /\ arc.pasp.de - against proprietary attachments

3 roky, 7 měsíců

2
4
0 0

Does KNOT RESOLVER support DNS ANY queries?

by Michal Jerabek

Hello, it seems that Knot Resolver doesn't responde for DNS ANY queries or it does? Unable to found how to set it up in documentaction. Thank you for you help Michal

3 roky, 8 měsíců

2
1
0 0

Does KNOT RESOLVER support DNS ANY queries?

by Michal Jerabek

Hello, it seems that Knot Resolver doesn't responde for DNS ANY queries or it does? Unable to found how to set it up in documentaction. Thank you for your help Michal

3 roky, 8 měsíců

1
0
0 0

Knot Resolver 5.4.1

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.4.1 has been released! Improvements ------------ - docker: base image on Debian 11 (!1203) Bugfixes -------- - fix build without doh2 support after 5.4.0 (!1197) - fix policy.DEBUG* logging and -V/--version after 5.4.0 (!1199) - doh2: ensure memory from unsent streams is freed (!1202) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.4.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.4.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.4.1.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.4.1/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

3 roky, 8 měsíců

1
0
0 0

Knot Resolver 5.4.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.4.0 has been released! It comes with improved logging facilities and new debugging options. Improvements ------------ - fine grained logging and syslog support (!1181) - expose HTTP headers for processing DoH requests (!1165) - improve assertion mechanism for debugging (!1146) - support apkg tool for packaging workflow (!1178) - support Knot DNS 3.1 (!1192, !1194) Bugfixes -------- - trust_anchors.set_insecure: improve precision (#673, !1177) - plug memory leaks related to TCP (!1182) - policy.FLAGS: fix not applying properly in edge cases (!1179) - fix a crash with older libuv inside timer processing (!1195) Incompatible changes -------------------- - see upgrading guide: https://knot-resolver.readthedocs.io/en/stable/upgrading.html#to-5-4 - legacy DoH implementation configuration in net.listen() was renamed from kind="doh" to kind="doh_legacy" (!1180) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.4.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.4.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.4.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.4.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

3 roky, 9 měsíců

1
0
0 0

Plans for FreeBSD support?

by Chris

Hello all, I've recently switched from the unbound resolver to the knot resolver for all outgoing name resolution on one of my FreeBSD servers. It all works pretty much as expected. With one problem; initializing and terminating kresd isn't possible w/o adding some external scripting. Given that the BSDs don't come w/systemd. Are there any plans to better support the sysv init system in the knot resolver? Thanks in advance for any hints/pointers/solutions. :-) --Chris

3 roky, 10 měsíců

2
2
0 0

Knot Resolver 5.3.2

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.3.2 has been released! Security -------- - validator: fix 5.3.1 regression on over-limit NSEC3 edge case (!1169) Assertion might be triggered by query/answer, potentially DoS. Improvements ------------ - cache: improve handling write errors from LMDB (!1159) - doh2: improve handling of stream errors (!1164) Bugfixes -------- - dnstap module: fix repeated configuration (!1168) - validator: fix SERVFAIL for some rare dynamic proofs (!1166) - fix SIGBUS on uncommon ARM machines (unaligned access; !1167, #426) - cache: better resilience on abnormal termination/restarts (!1172) - doh2: fix memleak on stream write failures (!1161) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.3.2/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.3.2.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.3.2.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.3.2/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

3 roky, 11 měsíců

1
0
0 0

Disable qname minimization

by Bjoern Franke

Hi, I recently stumbled about the following issue with postfix: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.smtp-relay-in-s1.neusta.de type=TLSA: Host not found, try again Postfix uses knot-resolver and I found [1] as a possible similar issue with unbound. I would like to test if the issue persists with disabled qname minimization, but it seems to be no configurale option. Kind Regards Bjoern [1] http://postfix.1071664.n5.nabble.com/Mail-deferred-TLSA-lookup-error-td1074…

3 roky, 11 měsíců

2
3
0 0

Writing a module to forward a query to another nameserver if recursive resolution fails

by Paul Furtado

Hello, We operate recursive resolvers in our network in AWS and from within the AWS network there are certain authoritative nameservers that block large swaths of the AWS IP range, causing resolution to fail for us. So I'm attempting to write a module that will handle failures reaching external resolvers and retry the query by forwarding it to a major resolver like cloudflare DNS. We push a ton of DNS query traffic so we do not want to simply forward to a public resolver, we only want to forward if recursion doesn't work for some reason. I've poured through the documentation and source code and tried to hook a variety of places, but I can't seem to find a good spot to hook the request failure. The finish layer allows me to hook the SERVFAIL, but by then it is too late to do anything. Using a simple policy, I was actually able to do something close by calling ensure_answer(), clearing the answer, setting the same forwarding flags as the forward policy, and then calling ensure_answer() again and I could see the query getting sent to cloudflare, so it seems like this is possible, but at the policy level it's too early to know if a query will result in a SERVFAIL. Could anyone point me in the right direction here? Thank you! Paul

3 roky, 11 měsíců

2
3
0 0

Any "gothcas" going from 2.65 to 3.04 I should know about?

by Chris

Hi. Moving a couple of our servers to new hardware, and taking that opportunity to upgrade some of the services at the same time. The main one being knot. Moving from a 2.65 context to 3.04. I've read the upgrade doc, and while there isn't a 2.65 --> 3.04. It appears for our environment that the changed/removed stanzas won't have much of an impact *except* as they relate to the database. That is; it appears that it isn't going to be a smooth transition, as they appear to be incompatible. Is that right? Do I need to rewrite all the keys && serials, and start from scratch? If so, as we have a huge number of domains, this will be an enormous task. Is this avoidable? Thank you for any and all insight into this transition. --Chris

4 roky

1
0
0 0

stats.upstreams() metrics in prometheus /metrics http output?

by Roman Kuzmitskii

hello, is there a way to output metrics about requests sent to upstreams and their information in prometheus /metrics output? been trying to find info and there seem to be no documentation about that functionality. sources mention dedicated /upstreams endpoint https://gitlab.nic.cz/knot/knot-resolver/-/blob/master/modules/http/prometh… but /upstreams returns empty list. currently trying to run this config: modules = { 'hints > iterate', 'stats', 'predict', 'http', } net.listen('0.0.0.0', 53, { kind = 'dns' }) net.listen('0.0.0.0', 9053, { kind = ‘webmgmt' }) cache.size = 256 * MB cache.storage = "lmdb:///dev/shm/knot-resolver” policy.add( policy.all( policy.TLS_FORWARD({ {'1.1.1.1', hostname='cloudflare-dns.com' }, {'1.0.0.1', hostname='cloudflare-dns.com' }, }) ) ) is there a way to get upstreams info? running modules.load('stats’) and then stats.upstreams() from ‘runtime’ configuration returns upstream request details like described here https://knot-resolver.readthedocs.io/en/stable/modules-stats.html thanks

4 roky

3
3
0 0

Knot Resolver 5.3.1

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.3.1 has been released! Improvements ------------ - policy.STUB: try to avoid TCP (compared to 5.3.0; !1155) - validator: downgrade NSEC3 records with too many iterations (>150; !1160) - additional improvements to nameserver selection algorithm (!1154, !1150) Bugfixes -------- - dnstap module: don't break request resolution on dnstap errors (!1147) - cache garbage collector: fix crashes introduced in 5.3.0 (!1153) - policy.TLS_FORWARD: better avoid dead addresses (#671, !1156) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.3.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.3.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.3.1.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.3.1/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

4 roky

1
0
0 0

Knot Resolver in front of Knot DNS

by Alex JOST

Apologies if this has been asked before, but I was unable to find informative resources about this topic except this[1]. What are the downsides of having a recursive DNS server in front of an authoritative DNS Server? I'm wondering if all the points listed in the linked article are relevant for small scale installations. Is anyone running such a setup and can share some advice with regards to rate limiting? [1]: https://www.whalebone.io/separate-dns-servers/ -- Alex JOST

4 roky, 1 měsíc

5
14
0 0

The "better" algorithm for choosing nameservers explained?

by Josef Vybíhal

Hey list, new here. Could someone please try explain to me, what's better about the new algorithm for choosing nameservers? I feel like it totally broke my use case. I use knot-resolver as local resolver and have configured this: acme = policy.todnames({'acme.cz', 'acme2.cz'}) policy.add(policy.suffix(policy.FLAGS({'NO_CACHE'}), acme)) policy.add(policy.suffix(policy.STUB({'172.16.21.93','172.16.21.94','8.8.8.8'}), acme)) Until the "better" algo, it worked exactly as I wanted it to. When I was in the network where the 172.16.21.9{3,4} DNS servers were available, they were selected. And when they were not available, google DNS was used to resolve those domains. Now, even when the internal nameservers are available, they are rarely used: $ for i in `seq 1 20`; do dig intranet.acme.cz +short; done 193.165.208.153 172.16.21.1 172.16.21.1 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 $ for i in `seq 1 20`; do dig intranet.acme.cz +short; done 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 193.165.208.153 172.16.21.1 193.165.208.153 When I remove the google DNS and leave just 172... # systemctl restart kresd@{1..4}.service && for i in `seq 1 20`; do dig intranet.acme.cz +short; done 172.16.21.1 172.16.21.1 172.16.21.1 172.16.21.1 172.16.21.1 172.16.21.1 172.16.21.1 172.16.21.1 172.16.21.1 172.16.21.1 172.16.21.1 172.16.21.1 172.16.21.1 172.16.21.1 172.16.21.1 172.16.21.1 172.16.21.1 172.16.21.1 172.16.21.1 172.16.21.1 Can I somehow switch back to the old algorithm via configuration? Thanks Josef

4 roky, 1 měsíc

2
4
0 0

Knot Resolver 5.3.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.3.0 has been released! Note regarding CentOS 8 packages: Due to the Red Hat's hostile decision to exclude devel packages from their distribution, we won't be providing upstream packages or maintaining knot-resolver package in EPEL8 until libuv-devel has been included in official RHEL8 release [rhbz#1895872]. If you depend on these, we can find a solution for your use-case as part of the paid support we offer [1]. [rhbz#1895872] - https://bugzilla.redhat.com/show_bug.cgi?id=1895872 [1] - https://www.knot-resolver.cz/support/pro/ Improvements ------------ - more consistency in using parent-side records for NS addresses (!1097) - better algorithm for choosing nameservers (!1030, !1126, !1140, !1141, !1143) - daf module: add daf.clear() (!1114) - dnstap module: more features and don't log internal requests (!1103) - dnstap module: include in upstream packages and Docker image (!1110, !1118) - randomize record order by default, i.e. reorder_RR(true) (!1124) - prometheus module: transform graphite tags into prometheus labels (!1109) - avoid excessive logging of UDP replies with sendmmsg (!1138) Bugfixes -------- - view: fail config if bad subnet is specified (!1112) - doh2: fix memory leak (!1117) - policy.ANSWER: minor fixes, mainly around NODATA answers (!1129) - http, watchdog modules: fix stability problems (!1136) Incompatible changes -------------------- - dnstap module: `log_responses` option gets nested under `client`; see new docs for config example (!1103) - libknot >= 2.9 is required Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.3.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.3.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.3.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.3.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

4 roky, 1 měsíc

1
0
0 0

Knot Resolver: Upcoming Debian 9 & Ubuntu 16.04 EOL

by Tomas Krizek

Dear Knot Resolver users, I have an early notification for those who rely on our upstream package repositories for Debian 9 and Ubuntu 16.04. Ubuntu 16.04: We'll no longer provide packages after April 2021 when the distribution reaches end of life. Debian 9: Knot Resolver 5.x is the last supported major version for Debian 9. Once we release a new major version, we'll no longer provide packages for Debian 9. We expect to release our next major version in the second half of 2021. Packages for other distributions remain unaffected and are supported as usual. Thanks for understanding. -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

4 roky, 2 měsíce

1
0
0 0

Re: [knot-resolver-users] Is policy.rpz a non-chain action?

by Urueña-Pascual Manuel

Hello Tomas, You are right, it was just those silly configuration mistakes. Everything works now :) Thank you so much! Best regards, --Manuel ________________________________ De: Tomas Krizek Enviado: Viernes, 11 de Diciembre de 2020 13:25 Para: Knot Resolver Users List; Urueña-Pascual Manuel Asunto: Re: [knot-resolver-users] Is policy.rpz a non-chain action? Hi, the use-case you're trying to achieve is possible, but there are some issues with your configuration. On 10/12/2020 17.29, Urueña-Pascual Manuel wrote:> policy.add(policy.rpz(policy.DENY_MSG('domain blocked'), '/etc/knot-resolver/blocklist.rpz', true)) > policy.add(policy.rpz(policy.PASS(), '/etc/knot-resolver/allowlist.rpz', true)) You want to specify "policy.PASS" without the brackets. > and these are the RPZ zones: > > $ cat '/etc/knot-resolver/allowlist.rpz': > www.google.com<http://www.google.com> 600 IN CNAME rpz-passthrough. > www.bing.com<http://www.bing.com> 600 IN CNAME rpz-passthrough. When you provide kresd these RPZ zones, it will complain: [poli] RPZ /tmp/kr_dev/etc/knot-resolver/allowlist.rpz:1: CNAME with custom target in RPZ is not supported yet (ignored) It's because you're trying to use unsupported CNAME. See the table in our docs [1]. What you're probably looking for is "rpz-passthru." instead. However, if you're using a separate allowlist with policy.PASS action (which is your case) "." would also work here. You should also be able to combine the blocklist and allowlist into just a single rpz file, using policy.DENY_MSG("...") and controlling whether domain is blocked ("CNAME .") or allowed ("CNAME rpz-passthru.") with the RPZ rules themselves. [1] - https://knot-resolver.readthedocs.io/en/stable/modules-policy.html#response… -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

4 roky, 4 měsíce

1
0
0 0

Is policy.rpz a non-chain action?

by Urueña-Pascual Manuel

Hello, I'm trying to setup a knot-resolver 5.2.0-1 instance where all DNS queries should return a fixed IPv4 address, but the domains on an allow list that should return the real IPv4 address instead (by using a policy.PASS action), and the ones on a block list that should return a SRVFAIL response (by using a policy.DROP action). I'm using Response Policy Zones (RPZ), and with an explicit list of domains to redirect the traffic to (plus the explicit allow and block lists) everything works fine. However, when trying to redirect all queries by default by using a policy.all rule, the allow list does not longer work and all queries (but blocked ones) are responded with the fixed IPv4 address. This is my '/etc/knot-resolver/kresd.conf': -- turns off DNSSEC validation trust_anchors.remove('.') -- Network interface configuration net.listen('127.0.0.1', 53, { kind = 'dns' }) net.listen('10.127.0.20', 53, { kind = 'dns' }) net.ipv6 = false net.listen('/tmp/kres.control', nil, { kind = 'control'}) -- Load useful modules modules = { 'hints > iterate', -- Load /etc/hosts and allow custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } -- Cache size cache.size = 100 * MB policy.add(policy.rpz(policy.DENY_MSG('domain blocked'), '/etc/knot-resolver/blocklist.rpz', true)) --policy.add(policy.rpz(policy.ANSWER(), '/etc/knot-resolver/redirectlist.rpz', true)) policy.add(policy.rpz(policy.PASS(), '/etc/knot-resolver/allowlist.rpz', true)) policy.add(policy.all(policy.ANSWER({ [kres.type.A] = { rdata=kres.str2ip('10.127.0.10'), ttl=300 } }))) and these are the RPZ zones: $ cat '/etc/knot-resolver/allowlist.rpz': www.google.com 600 IN CNAME rpz-passthrough. www.bing.com 600 IN CNAME rpz-passthrough. $ cat /etc/knot-resolver/blocklist.rpz examplemalwaredomain.com 600 IN CNAME . *.examplemalwaredomain.com 600 IN CNAME . Thus, www.examplemalwaredomain.com is blocked: $ dig www.examplemalwaredomain.com @127.0.0.1 ; <<>> DiG 9.16.1-Ubuntu <<>> www.examplemalwaredomain.com @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26657 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;www.examplemalwaredomain.com. IN A ;; AUTHORITY SECTION: www.examplemalwaredomain.com. 10800 IN SOA www.examplemalwaredomain.com. nobody.invalid. 1 3600 1200 604800 10800 ;; ADDITIONAL SECTION: explanation.invalid. 10800 IN TXT "domain blocked" And any other domain is redirected: $ dig nic.cz @127.0.0.1 ; <<>> DiG 9.16.1-Ubuntu <<>> nic.cz @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60891 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;nic.cz. IN A ;; ANSWER SECTION: nic.cz. 300 IN A 10.127.0.10 But the domains in the allow list are also redirected :( $ dig www.google.com @127.0.0.1 ; <<>> DiG 9.16.1-Ubuntu <<>> www.google.com @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49284 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 300 IN A 10.127.0.10 Interestingly, if I add a policy.PASS rule with a list of explicit domains before the policy.all one, it does work properly: policy.add(policy.suffix(policy.PASS, policy.todnames({'example.com', 'example.net'}))) $ dig www.example.com @127.0.0.1 ; <<>> DiG 9.16.1-Ubuntu <<>> www.example.com @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59322 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 120 IN A 93.184.216.34 Thus, it looks as if the allowed domains first hit the allow RPZ list, but then they hit the policy.ANSWER policy anyway. Is this the expected behaviour? Is there any way to implement such a default redirect but for a list of allowed or blocked domains? Regards, --Manuel

4 roky, 4 měsíce

2
1
0 0

Knot Resolver 5.2.1

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.2.1 has been released! Improvements ------------ - doh2: send Cache-Control header with TTL (#617, !1095) Bugfixes -------- - fix map() command on 32-bit platforms; regressed in 5.2.0 (!1093) - doh2: restrict endpoints to doh and dns-query (#636, !1104) - renumber: map to correct subnet when using multiple rules (!1107) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.2.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.2.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.2.1.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.2.1/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

4 roky, 4 měsíce

1
0
0 0

Not able to resolve all domains successfully

by Mike Michalakis

I’ve setup knot-resolver and it working for the best part. However, I’ve found that a specific external domain that is important to us isn’t able to resolve successfully. I’m not sure if there might be other domain with the same problem. Any suggestions would be awesome. “MTN.com” [root@localhost ~]# whois mtn.com Domain Name: MTN.COM Registry Domain ID: 63727_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.lexsynergy.com Registrar URL: http://www.lexsynergy.com Updated Date: 2020-01-21T23:41:38Z Creation Date: 1993-02-19T05:00:00Z Registry Expiry Date: 2021-02-20T05:00:00Z Registrar: LEXSYNERGY LIMITED Registrar IANA ID: 1466 Registrar Abuse Contact Email: abuse(a)lexsynergy.com Registrar Abuse Contact Phone: +442031370459 Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited Name Server: NS1.IAFRICA.COM Name Server: NS2.IAFRICA.COM DNSSEC: unsigned URL of the ICANN Whois I [root@localhost ~]# dig mtn.com ; <<>> DiG 9.11.13-RedHat-9.11.13-6.el8_2.1 <<>> mtn.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44242 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;mtn.com. IN A ;; Query time: 2810 msec ;; SERVER: 172.24.5.131#53(172.24.5.131) ;; WHEN: Sun Nov 15 06:53:23 EET 2020 ;; MSG SIZE rcvd: 36 [root@localhost ~]# [root@localhost ~]# dig @8.8.8.8 mtn.com ; <<>> DiG 9.11.13-RedHat-9.11.13-6.el8_2.1 <<>> @8.8.8.8 mtn.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21571 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;mtn.com. IN A ;; ANSWER SECTION: mtn.com. 1389 IN A 192.0.66.2 ;; Query time: 64 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sun Nov 15 06:54:18 EET 2020 ;; MSG SIZE rcvd: 52 [root@localhost ~]# Rrds, Mike

4 roky, 5 měsíců

2
1
0 0

Is it possible to use the resolver on more than just Linux?

by Chris

The knot-resolver documentation only appears to support Linux. Any plans to make the resolver available, or useful on systems other than Linux? While I could put Linux in a VM, or BE, and use the resolver from there. It wouldn't really be very effective. Any insight to using this on any of the BSD's would be greatly appreciated (I'm currently using unbound along side knot authoritative). Thanks! --Chris

4 roky, 5 měsíců

2
1
0 0

blacklist.rpz

by Mike Michalakis

Hi, I’ve stumbled across knot-resolver because I have an issue with my current DNS solution. What is the best way to block a large number of domains. I’ve trying to work with the below by it’s not functioning Part of /etc/knot-resolver/kresd.conf -- Domain Blocking policy.add( policy.rpz(policy.DENY_MSG('domain blocked by your IT department'),'/etc/knot-resolver/blacklist.rpz', true)) policy.add ( policy.rpz(policy.DENY, '/etc/knot-resolver/blacklist.rpz')) /etc/knot-resolver/backlist.rpz 007bets.com, Rrds, Mike

4 roky, 5 měsíců

1
1
0 0

blacklist.rpz

by Mike Michalakis

Hi, I’ve stumbled across knot-resolver because I have an issue with my current DNS solution. What is the best way to block a large number of domains. I’ve trying to work with the below by it’s not functioning Part of /etc/knot-resolver/kresd.conf -- Domain Blocking policy.add( policy.rpz(policy.DENY_MSG('domain blocked by your IT department'),'/etc/knot-resolver/blacklist.rpz', true)) policy.add ( policy.rpz(policy.DENY, '/etc/knot-resolver/blacklist.rpz')) /etc/knot-resolver/backlist.rpz 007bets.com, Rrds, Mike

4 roky, 5 měsíců

1
0
0 0

knot-resolver 5.2.0 - metrics issue - map() error while connecting to control socket

by Petr Kyselák

Hello, recently we upgraded from 5.1 to 5.2 few servers (CentOS7 and Raspbian) and all seems to be working fine, but I can see on (yes I know, not recommend and supported) rasbian issue with metrics and in the log I can issue this error: Nov 13 10:21:33 dns-cache-2 kresd[15232]: map() error while connecting to control socket /run/knot-resolver/control/H#003: socket:connect: No such file or directory (ignoring this socket) Nov 13 10:21:33 dns-cache-2 kresd[15232]: map() error while connecting to control socket /run/knot-resolver/control/H: socket:connect: No such file or directory (ignoring this socket) Nov 13 10:21:33 dns-cache-2 kresd[15232]: map() error while connecting to control socket /run/knot-resolver/control/: socket:connect: Connection refused (ignoring this socket) the error is triggered by opening "ip:8453/metrics" and it show almost empty response: # TYPE resolver_latency histogram resolver_latency_count 0.000000 resolver_latency_sum 0.000000 root@dns-cache-2:/# apt -qq list knot* --installed knot-resolver-module-http/unknown,now 5.2.0-1 all [installed] knot-resolver-release/unknown,now 1.7-1 all [installed] knot-resolver/unknown,now 5.2.0-1 armhf [installed] root@dns-cache-2:/# root@dns-cache-2:/# uname -a Linux dns-cache-2 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux Could it be a bug or something related to mix armv7l and armhf? I know of the limitation as we discussed this setup on raspberry some time ago. I just want to share my experience as it can be useful and if you will have any tip I will appreciate it.

4 roky, 5 měsíců

4
6
0 0

Knot Resolver 5.2.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.2.0 has been released! One of the notable features is a new DNS-over-HTTTPS implementation which is more scalable and stable than the old one. It also has less dependencies and simpler configuration. Another new feature is experimental eXpress Data Path (XDP) support for UDP. With support from both the network card and the kernel, it can provide superior performance and lower latency for UDP answers. Some of the improvements and bugfixes required a few backward incompatible changes, mainly regarding control sockets or module API. Please refer to our upgrading guide for details: https://knot-resolver.readthedocs.io/en/v5.2.0/upgrading.html#to-5-2 Improvements ------------ - doh2: add native C module for DNS-over-HTTPS (#600, !997) - xdp: add server-side XDP support for higher UDP performance (#533, !1083) - lower default EDNS buffer size to 1232 bytes (#538, #300, !920); see https://dnsflagday.net/2020/ - net: split the EDNS buffer size into upstream and downstream (!1026) - lua-http doh: answer to /dns-query endpoint as well as /doh (!1069) - improve resiliency against UDP fragmentation attacks (disable PMTUD) (!1061) - ta_update: warn if there are differences between statically configured keys and upstream (#251, !1051) - human readable output in interactive mode was improved (!1020) - doc: generate info page (!1079) - packaging: improve sysusers and tmpfiles support (!1080) Bugfixes -------- - avoid an assert() error in stash_rrset() (!1072) - fix emergency cache locking bug introduced in 5.1.3 (!1078) - migrate map() command to control sockets; fix systemd integration (!1000) - fix crash when sending back errors over control socket (!1000) - fix SERVFAIL while processing forwarded CNAME to a sibling zone (#614, !1070) Incompatible changes -------------------- - see upgrading guide: https://knot-resolver.readthedocs.io/en/v5.2.0/upgrading.html#to-5-2 - minor changes in module API - control socket API commands have to be terminated by "\n" - graphite: default prefix now contains instance identifier (!1000) - build: meson >= 0.49 is required (!1082) - planned changes in future versions: https://knot-resolver.readthedocs.io/en/v5.2.0/upgrading.html#upcoming-chan… Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.2.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.2.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.2.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.2.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

4 roky, 5 měsíců

1
0
0 0

5.2.0 - release date - fix SERVFAIL in *FORWARD modes with certain CNAME setup

by Petr Kyselák

Hello team, most probably we hit the issue !1070 "fix SERVFAIL in *FORWARD modes with certain CNAME setup" and I would like to ask when we can expect release of knot-resolver 5.2.0 (with the fix) or if there will be "hot fix" in 5.1.x? example of affected domain: www.action.foundation.total Thank you.

4 roky, 6 měsíců

2
2
0 0

[PATCH 0/2] Generate Info manual

by Simon South

These two patches modify Knot Resolver's build process to check for Texinfo utilities during configuration and, if they're found, to build and install documentation in Info format (the standard for GNU distributions such as Guix[0]) as well as HTML. (If the Texinfo utilities aren't found, the build works as before.) The first patch implements these changes and additionally updates the manual to list Texinfo as an optional dependency. The second patch isn't required but genericizes a few references within the manual to documentation in specific formats, in the interest of readability. Note I've left unchanged the "build-html-doc" ref-ID to help ensure external links to the documentation continue to function. [0] https://guix.gnu.org/ ---------- With these patches applied you'll find makeinfo generates a large number of warnings of the form knotresolver.texi:11811: warning: @anchor should not appear in @deffn These warnings are harmless but result from the way Breathe processes C declarations. It generates output with this structure (here for the "kr_request_selected" macro): <desc_signature ids="c.kr_request_selected" is_multiline="True"> <desc_signature_line add_permalink="True" xml:space="preserve"> <target ids="resolve_8h_1a9ba8c6cef807cdf580e3249675a2589c" names="resolve_8h_1a9ba8c6cef807cdf580e3249675a2589c"></target> <desc_name xml:space="preserve">kr_request_selected</desc_name> <desc_parameterlist xml:space="preserve"> <desc_parameter noemph="True" xml:space="preserve"><emphasis>req</emphasis></desc_parameter> </desc_parameterlist> </desc_signature_line> </desc_signature> The issue is the "target" node's being placed within desc_signature_line. I assume this is done for convenience when generating HTML, but it also leads to this Texinfo output: @deffn {Define} @anchor{lib resolve_8h_1a9ba8c6cef807cdf580e3249675a2589c}@anchor{25f}kr_request_selected (req) which is invalid, since (as the warning says) @anchor is not supposed to appear within @deffn. Sphinx's Texinfo writer doesn't account for this, since there's no way (that I can see) for normal ReST input to generate a "target" tag in this position. However it's not clear Breathe is at fault here either, since I can't find anything that defines where target is allowed to appear or which tags desc_signature_line is meant to contain. A straightforward approach to fixing this is implemented by this patch to Sphinx, which causes its Texinfo writer to reorder target nodes embedded within function descriptions: diff --git a/sphinx/writers/texinfo.py b/sphinx/writers/texinfo.py index 5ad2831dd..bd76acdc3 100644 --- a/sphinx/writers/texinfo.py +++ b/sphinx/writers/texinfo.py @@ -1383,6 +1383,11 @@ class TexinfoTranslator(SphinxTranslator): if objtype != 'describe': for id in node.get('ids'): self.add_anchor(id, node) + # embedded anchors need to go in front + for n in node.traverse(nodes.target, include_self=False): + if isinstance(n, nodes.target): + n.walkabout(self) + n.parent.remove(n) # use the full name of the objtype for the category try: domain = self.builder.env.get_domain(node.parent['domain']) However, whether this is the correct approach or if a fix would better be applied to Breathe isn't clear to me. Engaging with the community of either project means signing up for services I'd rather not use, so there's little I can do to carry this forward. Perhaps someone else is interested? --- Simon South simon(a)simonsouth.net Simon South (2): doc: generate Info manual doc: use non-format-specific references to documentation doc/build.rst | 11 +++++++---- doc/meson.build | 7 +++++++ scripts/install-doc-info.sh | 8 ++++++++ scripts/make-doc.sh | 6 ++++++ 4 files changed, 28 insertions(+), 4 deletions(-) create mode 100644 scripts/install-doc-info.sh -- 2.28.0

4 roky, 6 měsíců

2
13
0 0

Unable to resolve some domains

by Balakrishnan Balasubramanian

Hi, I am using knot-resolver with default configuration in arch linux. I am not able to resolve some domains (like costco.ca). It works fine with other resolvers like cloudflare/google. Is there way to debug this? Thanks, Bala

4 roky, 6 měsíců

3
8
0 0

socat stats in shell script

by pioruns2019＠gmx.com

Hello, I'd like to have output of socat commands in my shell script. Currently, I log in to socat by using, for example: socat - UNIX-CONNECT:/run/knot-resolver/control/1 There, I can issue cache.stats() and read it. How can I have output these commands in shell script? Appreciate your help.

4 roky, 6 měsíců

2
2
0 0

Upcoming changes in Knot Resolver 5.2.0

by Petr Špaček

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear Knot Resolver users, we would like to inform you about certain changes in upcoming Knot Resolver 5.2.0: - - Users of Control sockets API need to terminate each command sent to resolver with newline character (ASCII \n). Correct usage: "cache.stats()\n". Newline terminated commands are accepted by all resolver versions >= 1.0.0. - - Human readable output from Control sockets is not stable and changes from time to time. Users who need machine readable output for scripts should use Lua function "tojson()" to convert Lua values into standard JSON format instead of attempting to parse the human readable output. For example API call "tojson(cache.stats())\n" will return JSON string with "cache.stats()" results represented as dictionary. Function "tojson()" is available in all resolver versions >= 1.0.0. - - DoH served with http module DNS-over-HTTP (DoH) will be marked as legacy and won’t receive any more bugfixes. A more reliable and scalable DoH module will be available instead. The new DoH module will only support HTTP/2 over TLS. - - New releases since October 2020 will contain changes for DNS Flag Day 2020. Please double-check your firewall, it has to allow DNS traffic on UDP and also TCP port 53. See https://dnsflagday.net/2020/ for more information. This text with links to further documentation can be found here: https://knot-resolver.readthedocs.io/en/latest/upgrading.html#upcoming-chan… We plan to use the same URL to publish planned changes in not-yet-released versions. To make our version numbers easier to understand we have documented how we version new releases: https://knot-resolver.readthedocs.io/en/latest/NEWS.html#version-numbering Feedback is more than welcome. Do not hesitate to reach out on the usual channels: https://www.knot-resolver.cz/support/ - -- Petr Špaček @ CZ.NIC -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAl9+9kcACgkQzo3WoaUK IeR7Jg/5AT4QLP1ZJBR8Vkoa5DirCnTBrBx3GPkiW+hVEXZPl55AXWMu54i9ZTuY 4R38+I1PypAM924n5xk98AaX7iRbISVZ87kOEfeJOKR2tzB8TiYwzufl2Y3PUYo8 IlazzcUyNFcQw4ARE3BqiQF6DLKl/s8U812XMEUlRdryE7lURWVEJyo711XNLPPy 6PWuGpsNboMR2V6z/7yrX/i+/0XGpxoSL8S9Fv4hQrOJB3c0lIZNSfaj23GywDao ZgkqlxwBgPkOGAhSIq3r5Xqitl9fTh2Gb1565Lrbj+4OY5WbL8YqaNArZMp3poUD T2QCH1bUypa0EP+smzdcriuFDWwl3L0zwODsnH2ofLAnosWeGfxtHXHI5W7rwskF gAAZJJe+UhxSeBzwr01r6YwZbDYlHiDA9+AkGkYGjYwQmfLCTftXRhlqmJ3BvpeR Nr97D8lSuct9XugIN2pUJfR1cVIr40ViiO3TG4m2eL2dHExELB4OOf/ZCOTX5dQk KJuQSspz5zQvVFWZZh17L6iT9WUdgwmi0TkvR8aMmPlr75vokFvioQMAOHfHgGtq 7s10W9TtRGX5o9ioHtTLrDaqEC/0P79bMTVU5HCap1dSCzgk1AYXtUDu4AVc0pWC Aui8tih9ykESC8rPUaEBc6wpR3wgKSPclfIWgiJira4xB8eRCUs= =9lwy -----END PGP SIGNATURE-----

4 roky, 6 měsíců

1
0
0 0

Set default domain suffix

by Ken Moini

Trying to use Knot DNS + Knot Resolver for a small business network. So far it's working great, however there's one function that's still needed: short hostname resolution suffixing. Meaning for 'server.example.com' I can `dig server.example.com` and get the desired result, but wondering how to attach the 'example.com' suffix so I can simply query `dig server` and have Knot auto-append 'example.com' suffix. I believe I saw it in the documentation but I can't find it again for the life of me... Thanks in advance, -KM

4 roky, 7 měsíců

3
3
0 0

Knot Resolver 5.1.3

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.1.3 has been released! Improvements ------------ - capabilities are no longer constrained when running as root (!1012) - cache: add percentage usage to cache.stats() (#580, !1025) - cache: add number of cache entries to cache.stats() (#510, !1028) - aarch64 support again, as some systems still didn't work (!1033) - support building against Knot DNS 3.0 (!1053) Bugfixes -------- - tls: fix compilation to support net.tls_sticket_secret() (!1021) - validator: ignore bogus RRSIGs present in insecure domains (!1022, #587) - build if libsystemd version isn't detected as integer (#592, !1029) - validator: more robust reaction on missing RRSIGs (#390, !1020) - ta_update module: fix broken RFC5011 rollover (!1035) - garbage collector: avoid keeping multiple copies of cache (!1042) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.1.3/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.1.3.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.1.3.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.1.3/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

4 roky, 7 měsíců

1
0
0 0

policy.ANSWER AAAA

by None

I am newby in kresd and lua ipv4 format in documentation 127.0.0.1 as "\127\0\0\1" is new for me i meen "fe80::56e6::f188:75d6" as "\fe80\\56e6\f188\75d6" is no right way (no work for me) i will try kres.str2ip('........')

4 roky, 8 měsíců

1
0
0 0

Re: [knot-resolver-users] policy.ANSWER AAAA

by Petr Špaček

On 13. 08. 20 8:35, knot-resolver-users-bounces(a)lists.nic.cz wrote: > how is correct syntax for ipv6 address in policy.ANSWER ? Hello, and thank you for pointing out our insufficient documentation. I've attempted to clarify it in the following change: https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1037/diffs?view=p… Does the text on right side (green part) answer your question? If not, what is unclear? -- Petr Špaček @ CZ.NIC

4 roky, 8 měsíců

1
0
0 0

policy.ANSWER AAAA

by None

how is correct syntax for ipv6 address in policy.ANSWER ?

4 roky, 8 měsíců

1
0
0 0

cache size / full / kresd crash

by Petr Kyselák

Hello all, I have a question regarding cache size and it’s using. We are running knot-resolver on RaspberryPI 4 (as secondary cache). Previously we had 256MB cache as tmpfs and hit issue that process crashed due to “No space left on device (workdir '/var/lib/knot-resolver')” I doubled the site to 512MB, but same issue occurs. My question is why it crash even from the logs the usage of cache is about 80 percent (same in the case with 256MB). I taught that kres-cache-gc is taking care about its size and it does not allow to full the cache and prevent writing to it in the way that main process crash. Should we increase the cache size or we hit a some bug? Any other suggestion what could cause that cache is full and not “cleared”? Thank you for tip and have a nice day. Petr Kyselak Config: /etc/fstab tmpfs /var/cache/knot-resolver tmpfs rw,size=512m,uid=knot-resolver,gid=knot-resolver,nosuid,nodev,noexec,mode=0700 0 00 -- Cache size cache.size = cache.fssize() - 10*MB Logs: Jun 4 16:32:05 dns-cache-2 kres-cache-gc[548]: Cache analyzed in 1.41 secs, 1038386 records, limit category is 100. Jun 4 16:32:05 dns-cache-2 kres-cache-gc[548]: 0 records to be deleted using 0.00 MBytes of temporary memory, 0 records skipped due to memory limit. Jun 4 16:32:05 dns-cache-2 kres-cache-gc[548]: Deleted 0 records (0 already gone) types Jun 4 16:32:05 dns-cache-2 kres-cache-gc[548]: It took 0.00 secs, 0 transactions (OK) Jun 4 16:32:05 dns-cache-2 kres-cache-gc[548]: Usage: 81.32% (428077056 / 526385152) Jun 4 16:32:05 dns-cache-2 kres-cache-gc[548]: Cache analyzed in 1.41 secs, 1038420 records, limit category is 100. Jun 4 16:32:05 dns-cache-2 kres-cache-gc[548]: 0 records to be deleted using 0.00 MBytes of temporary memory, 0 records skipped due to memory limit. Jun 4 16:32:05 dns-cache-2 kres-cache-gc[548]: Deleted 0 records (0 already gone) types Jun 4 16:32:05 dns-cache-2 kres-cache-gc[548]: It took 0.00 secs, 0 transactions (OK) Jun 4 16:32:05 dns-cache-2 kres-cache-gc[548]: Usage: 81.32% (428077056 / 526385152) Jun 4 16:32:05 dns-cache-2 kres-cache-gc[548]: Cache analyzed in 1.41 secs, 1038420 records, limit category is 100. Jun 4 16:32:05 dns-cache-2 kres-cache-gc[548]: 0 records to be deleted using 0.00 MBytes of temporary memory, 0 records skipped due to memory limit. Jun 4 16:32:05 dns-cache-2 kres-cache-gc[548]: Deleted 0 records (0 already gone) types Jun 4 16:32:05 dns-cache-2 kres-cache-gc[548]: It took 0.00 secs, 0 transactions (OK) Jun 4 16:32:05 dns-cache-2 kres-cache-gc[548]: Usage: 81.32% (428077056 / 526385152) Jun 4 16:32:05 dns-cache-2 kres-cache-gc[548]: Cache analyzed in 1.41 secs, 1038421 records, limit category is 100. Jun 4 16:32:32 dns-cache-2 kresd[672]: [cache] MDB_BAD_TXN, probably overfull Jun 4 16:32:32 dns-cache-2 kresd[672]: [cache] clearing error, falling back Jun 4 16:32:32 dns-cache-2 kresd[672]: [cache] MDB_BAD_TXN, probably overfull Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] MDB_BAD_TXN, probably overfull Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing error, falling back Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] MDB_BAD_TXN, probably overfull Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing failed to get ./.cachelock; retry later Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing because overfull, ret = -17 Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] MDB_BAD_TXN, probably overfull Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing error, falling back Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] MDB_BAD_TXN, probably overfull Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing failed to get ./.cachelock; retry later Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing because overfull, ret = -17 Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] MDB_BAD_TXN, probably overfull Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing error, falling back Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] MDB_BAD_TXN, probably overfull Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing failed to get ./.cachelock; retry later Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing because overfull, ret = -17 … Jun 4 16:32:32 dns-cache-2 systemd[1]: kresd(a)1.service: Main process exited, code=killed, status=11/SEGV Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing failed to get ./.cachelock; retry later Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing because overfull, ret = -17 Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] MDB_BAD_TXN, probably overfull Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing error, falling back Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] MDB_BAD_TXN, probably overfull Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing failed to get ./.cachelock; retry later Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing because overfull, ret = -17 … Jun 4 16:32:32 dns-cache-2 systemd[1]: kresd(a)1.service: Failed with result 'signal'. … Jun 4 16:32:32 dns-cache-2 systemd[1]: kresd(a)2.service: Main process exited, code=killed, status=11/SEGV Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing failed to get ./.cachelock; retry later Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing because overfull, ret = -17 Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] MDB_BAD_TXN, probably overfull Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing error, falling back … Jun 4 16:32:32 dns-cache-2 systemd[1]: kresd(a)2.service: Failed with result 'signal'. Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing because overfull, ret = -17 Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] MDB_BAD_TXN, probably overfull Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing error, falling back … Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] MDB_BAD_TXN, probably overfull Jun 4 16:32:32 dns-cache-2 kresd[675]: [cache] clearing because overfull, ret = -28 Jun 4 16:32:32 dns-cache-2 systemd[1]: kresd(a)1.service: Service RestartSec=100ms expired, scheduling restart. Jun 4 16:32:32 dns-cache-2 systemd[1]: kresd(a)1.service: Scheduled restart job, restart counter is at 1. Jun 4 16:32:32 dns-cache-2 systemd[1]: kresd(a)2.service: Service RestartSec=100ms expired, scheduling restart. Jun 4 16:32:32 dns-cache-2 systemd[1]: kresd(a)2.service: Scheduled restart job, restart counter is at 1. Jun 4 16:32:32 dns-cache-2 kresd[30052]: [system] error while loading config: /usr/lib/knot-resolver/sandbox.lua:400: can't open cache path '/var/cache/knot-resolver'; working directory '/var/lib/knot-resolver'; No space left on device (workdir '/var/lib/knot-resolver') Jun 4 16:32:32 dns-cache-2 systemd[1]: kresd(a)1.service: Main process exited, code=exited, status=1/FAILURE Jun 4 16:32:32 dns-cache-2 systemd[1]: kresd(a)1.service: Failed with result 'exit-code'. Jun 4 16:32:32 dns-cache-2 kresd[30051]: [system] error while loading config: /usr/lib/knot-resolver/sandbox.lua:400: can't open cache path '/var/cache/knot-resolver'; working directory '/var/lib/knot-resolver'; No space left on device (workdir '/var/lib/knot-resolver') Jun 4 16:32:32 dns-cache-2 systemd[1]: kresd(a)2.service: Main process exited, code=exited, status=1/FAILURE Jun 4 16:32:32 dns-cache-2 systemd[1]: kresd(a)2.service: Failed with result 'exit-code'.

4 roky, 9 měsíců

3
7
0 0

Knot Resolver 5.1.2

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.1.2 has been released! Bugfixes -------- - hints module: NODATA answers also for non-address queries (!1005) - tls: send alert to peer if handshake fails (!1007) - cache: fix interaction between LMDB locks and preallocation (!1013) - cache garbage collector: fix flushing of messages to logs (!1009) - cache garbage collector: fix insufficient GC on 32-bit systems (!1009) - graphite module: do not block resolver on TCP failures (!1014) - policy.rpz various fixes (!1016): $ORIGIN issues, precision of warnings, allow answering with multi-RR sets Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.1.2/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.1.2.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.1.2.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.1.2/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

4 roky, 9 měsíců

1
0
0 0

Configure knot-resolver to serve LAN?

by pioruns2019＠gmx.com

Hello all, I am trying to configure my local PC (always on server), to serve DNS resolving all other computers in my LAN. I installed and enabled the service. I've attempted configuration. Knot-resolver correctly resolves DNS querier on localhost machine, but fails to reply to queries from other LAN machines. Can someone please share configuration which I should use to have LAN resolving? I've tried various net.listen(), net() in config file, to no avail. I've studied this page https://knot-resolver.readthedocs.io/en/stable/daemon-bindings-net_server.h… but I have no idea which option I should put in config to enable my server PC (192.168.1.44) to allow all PCs in LAN (192.168.1.xxx) to use knot-resolver. I'd appreciate if someone with knowledge would help a newbie like me. Thank you! pioruns

4 roky, 10 měsíců

3
5
0 0

Dynamic configuration reload

by Pierrick CHOVELON

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

4 roky, 11 měsíců

2
2
0 0

Knot Resolver 5.1.1

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.1.1 has been released! This is a security release and all users are are advised to upgrade immediately to get mitigation for CVE-2020-12667. Release notes: Security -------- - fix CVE-2020-12667: mitigation for NXNSAttack DNS protocol vulnerability Bugfixes -------- - control sockets: recognize newline as command boundary More information about the vulnerability: https://en.blog.nic.cz/2020/05/19/nxnsattack-upgrade-resolvers-to-stop-new-… Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v5.1.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.1.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.1.1.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.1.1/ Early notification: 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! -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

4 roky, 11 měsíců

1
0
0 0

Knot Resolver 5.1.0

by Tomas Krizek

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

4 roky, 12 měsíců

1
0
0 0

knot-resolver 4.2.2 - náhle přestane vracet odpovědi (status: SERVFAIL)

by Zdenek Janis

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š

4 roky, 12 měsíců

3
4
0 0

upstream package repositories - signing key update

by Tomas Krizek

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

4 roky, 12 měsíců

1
0
0 0

Maintain Fedora 29 Repo for a few more months?

by Richard Graham

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

5 let

2
1
0 0

Knot Resolver 5.0.1

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.0.1 has been released! Bugfixes -------- - systemd: use correct cache location for garbage collector (#543) Improvements ------------ - cache: add cache.fssize() lua function to configure entire free disk space on dedicated cache partition (#524, !932) Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v5.0.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.0.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.0.1.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.0.1/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

5 let, 2 měsíce

1
0
0 0

Knot Resolver 5.0.0

by Tomas Krizek

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

5 let, 2 měsíce

2
1
0 0

Re: [knot-resolver-users] knot-resolver-users Digest, Vol 93, Issue 1

by Milan Jeskynka Kazatel

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. -- turns off DNSSEC validation trust_anchors.remove ('.'). *** 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 "

5 let, 4 měsíce

3
3
0 0

Knot Resolver 4.2.2

by Milan Jeskynka 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

5 let, 4 měsíce

2
1
0 0

Knot Resolver 4.3.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 4.3.0 has been released! Security - CVE-2019-19331 ------------------------- - fix speed of processing large RRsets (DoS, #518) - improve CNAME chain length accounting (DoS, !899) Bugfixes -------- - http module: use SO_REUSEPORT (!879) - systemd: kresd@.service now properly starts after network interfaces have been configured with IP addresses after reboot (!884) - sendmmsg: improve reliability (!704) - cache: fix crash on insertion via lua for NS and CNAME (!889) - rpm package: move root.keys to /var/lib/knot-resolver (#513, !888) Improvements ------------ - increase file-descriptor count limit to maximum allowed value (hard limit; !876) - watchdog module: support testing a DNS query (and switch C -> lua; !878, !881) - performance: use sendmmsg syscall towards clients by default (!877) - performance: avoid excessive getsockname() syscalls (!854) - performance: lua-related improvements (!874) - daemon now attempts to drop all capabilities (!896) - reduce CNAME chain length limit - now <= 12 (!899) Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v4.3.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-4.3.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-4.3.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v4.3.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

5 let, 4 měsíce

1
0
0 0

Configuring kresd to query multiple nameservers and return the first affirmative response?

by Bernd Wechner

I wonder if this is possible. The Knot Resolver certainly looks powerful, and I use it on my Omnia Router of course. But the documentation <https://knot-resolver.readthedocs.io/en/stable/index.html>which I have perused and read quickly, hasn't helped me understand this alas. It leaves me with a couple of interesting questions: 1. How are nameservers configured? Interestingly my running instance of kresd is on the Omnia and it receives nameservers via a dhcp request on my ISP I imagine, though I don't see them in /etc/resolv.conf 2. Is it possible configure a number of nameservers on a the basis of query them all (akin to dnsmasq's --all-servers) and return the first affirmative response? My interest is acutely related to: https://superuser.com/questions/1505755/can-one-configure-name-resolution-t… And I'd happily use kresd on my local machine(s) as well as on my LAN DNS (The Omnia) to help resolve names on my .lan while on a VPN! Regards, Bernd.

5 let, 4 měsíce

3
4
0 0

policy.DENY during a CNAME chain

by Stephane Bortzmeyer

Now that Firefox blocks 3rd-party cookies by default, many sites try to hide the fact that a cookie is 3rd-party by using CNAMEs. % kdig +short A ftn.fortuneo.fr ftn-fr.eulerian.net. ftn.eulerian.net. 109.232.194.56 I want to block all the requests to *.eulerian.net. policy.add(policy.suffix(policy.DENY, {todname('eulerian.net.')})) Does not work since, to quote the documentation "The policy module currently only looks at whole DNS requests. The rules won’t be re-applied e.g. when following CNAMEs." % kdig A ftn.eulerian.net ;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 42477 ... ftn.eulerian.net. 10800 IN SOA ftn.eulerian.net. nobody.invalid. 1 3600 1200 604800 10800 % kdig A ftn.fortuneo.fr ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 59262 ... ftn.fortuneo.fr. 600 IN CNAME ftn-fr.eulerian.net. ftn-fr.eulerian.net. 5799 IN CNAME ftn.eulerian.net. ftn.eulerian.net. 5799 IN A 109.232.194.56 This seriously limits the usefulness of policy.DENY. What are the possible solutions?

5 let, 4 měsíce

3
6
0 0

Re: [knot-resolver-users] DNSSEC validation failure logging on Centos 7 Knot Resolver, version 4.2.0

by Milan Jeskynka Kazatel

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. -- turns off DNSSEC validation trust_anchors.remove('.'). *** 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 "

5 let, 6 měsíců

2
1
0 0

DNSSEC validation failure logging on Centos 7 Knot Resolver, version 4.2.0

by Milan Jeskynka Kazatel

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

5 let, 6 měsíců

1
0
0 0

HTTP module after upgrade from Knot DNS Resolver, version 2.3.0 to Knot Resolver, version 4.2.0

by Milan Jeskynka Kazatel

Hello Knot Resolver team, I tried to upgrade to the latest stable version of Knot Resolver on Centos7, where I'm facing with a configuration issue with the module HTTP. I used it in version 2.3.0 with configuration -- 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 http = { host = '10.0.0.1', port = 8053, cert = false, } } and it works as expected, I reached a /stats/ from the browser. Unfortunately after upgrade to version 4.2.0 I'm not able to correctly start the module even if I follow the migration hints on documentation websites. I still receive a startup fail message Oct 04 11:32:09 dns systemd[1]: Starting Knot Resolver daemon... Oct 04 11:32:54 dns kresd[9540]: error: /usr/lib64/knot-resolver/kres_ modules/http.lua:35: attempt to call global 'moduledir' (a nil value) Oct 04 11:32:54 dns kresd[9540]: [system] failed to load module 'http' Oct 04 11:32:54 dns kresd[9540]: error occured here (config filename:lineno is at the bottom, if config is involved): Oct 04 11:32:54 dns kresd[9540]: stack traceback: Oct 04 11:32:54 dns kresd[9540]: [C]: in function 'load' Oct 04 11:32:54 dns kresd[9540]: /etc/knot-resolver/kresd.conf:14: in main chunk Oct 04 11:32:54 dns kresd[9540]: ERROR: No such file or directory Oct 04 11:32:54 dns systemd[1]: kresd(a)1.service: main process exited, code= exited, status=1/FAILURE Oct 04 11:32:54 dns systemd[1]: Failed to start Knot Resolver daemon. Current configuration is: -- interfaces ... net.listen('10.0.0.1', 8453, { kind = 'webmgmt' }) -- load HTTP module with defaults (self-signed TLS cert) modules.load('http') http.config() -- 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 } Where should be written the path to module http? What I did wrong? Regards, -- Smil Milan Jeskyňka Kazatel

5 let, 6 měsíců

2
4
0 0

Knot Resolver 4.2.2

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 4.2.2 has been released! Bugfixes -------- - lua bindings: fix a 4.2.1 regression on 32-bit systems (#514) which also fixes libknot 2.9 support on all systems Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v4.2.2/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-4.2.2.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-4.2.2.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v4.2.2/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

5 let, 6 měsíců

1
0
0 0

HTTP module after upgrade from Knot DNS Resolver, version 2.3.0 to Knot Resolver, version 4.2.0

by Milan Jeskynka Kazatel

Hello Knot Resolver team, I tried to upgrade to the latest stable version of Knot Resolver on Centos7, where I'm facing with a configuration issue with the module HTTP. I used it in version 2.3.0 with configuration -- 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 http = { host = '10.0.0.1', port = 8053, cert = false, } } and it works as expected, I reached a /stats/ from the browser. Unfortunately after upgrade to version 4.2.0 I'm not able to correctly start the module even if I follow the migration hints on documentation websites. I still receive a startup fail message Oct 04 11:32:09 dns systemd[1]: Starting Knot Resolver daemon... Oct 04 11:32:54 dns kresd[9540]: error: /usr/lib64/knot-resolver/kres_ modules/http.lua:35: attempt to call global 'moduledir' (a nil value) Oct 04 11:32:54 dns kresd[9540]: [system] failed to load module 'http' Oct 04 11:32:54 dns kresd[9540]: error occured here (config filename:lineno is at the bottom, if config is involved): Oct 04 11:32:54 dns kresd[9540]: stack traceback: Oct 04 11:32:54 dns kresd[9540]: [C]: in function 'load' Oct 04 11:32:54 dns kresd[9540]: /etc/knot-resolver/kresd.conf:14: in main chunk Oct 04 11:32:54 dns kresd[9540]: ERROR: No such file or directory Oct 04 11:32:54 dns systemd[1]: kresd(a)1.service: main process exited, code= exited, status=1/FAILURE Oct 04 11:32:54 dns systemd[1]: Failed to start Knot Resolver daemon. Current configuration is: -- interfaces ... net.listen('10.0.0.1', 8453, { kind = 'webmgmt' }) -- load HTTP module with defaults (self-signed TLS cert) modules.load('http') http.config() -- 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 } Where should be written the path to module http? What I did wrong? -- Smil Milan Jeskyňka Kazatel

5 let, 6 měsíců

1
0
0 0

Knot Resolver 4.2.1

by Tomas Krizek

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

5 let, 7 měsíců

1
0
0 0

CentOS 7 package ships writable /etc/knot-resolver

by Anand Buddhdev

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

5 let, 7 měsíců

2
4
0 0

Knot Resolver - module hints - reload?

by Milan Jeskynka Kazatel

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

5 let, 7 měsíců

3
7
0 0

Knot Resolver 4.2.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 4.2.0 has been released! Improvements ------------ - queries without RD bit set are REFUSED by default (!838) - support forwarding to multiple targets (!825) Bugfixes -------- - tls_client: fix issue with TLS session resumption (#489) - rebinding module: fix another false-positive assertion case (!851) Module API changes ------------------ - kr_request::add_selected is now really put into answer, instead of the "duplicate" ::additional field (#490) Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v4.2.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-4.2.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-4.2.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v4.2.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

5 let, 8 měsíců

1
0
0 0

Re: [knot-resolver-users] Specify wildcard subdomain static hints

by Vladimír Čunát

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

5 let, 8 měsíců

2
2
0 0

debian repo: http -> https

by Christoph

The instructions on: https://www.knot-resolver.cz/download/ read: " wget https://secure.nic.cz/files/knot-resolver/knot-resolver-release.deb dpkg -i knot-resolver-release.deb apt update && apt install -y knot-resolver " these instructions result in an http://.. URL in: /etc/apt/sources.list.d/knot-resolver-latest.list I'd suggest to change it to https://..

5 let, 9 měsíců

2
3
0 0

Knot Resolver 4.1.0

by Petr Špaček

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

5 let, 9 měsíců

1
0
0 0

Pre-release announcement: 4.1.0 security release on Wednesday 2019-07-10

by Petr Špaček

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

5 let, 9 měsíců

1
0
0 0

network configuration via systemd sockets - feedback?

by Tomas Krizek

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

5 let, 10 měsíců

3
3
0 0

some early kresd 4.0.0 DoH observations

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

5 let, 10 měsíců

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.

5 let, 11 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 >> > >

5 let, 11 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

5 let, 11 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

5 let, 11 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

5 let, 11 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…

5 let, 12 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

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

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

1
1
0 0

Running knot-resolver with only kresd-tls.socket

by Vladimír Čunát

Message "moved" from [knot-dns-users] to [knot-resolver-users]: -------- Forwarded Message -------- Subject: [knot-dns-users] running knot-resolver with only kresd-tls.socket Date: Sat, 16 Mar 2019 13:36:50 -0000 (UTC) From: Daniel Lublin <daniel(a)lublin.se> To: knot-dns-users(a)lists.nic.cz Ahoj, I'm tinkering with running knot-resolver for DNS-over-TLS (only). My kresd@1 is listening on the public interface by using a drop-in override file, following kresd.systemd(7) (kresd-tls.socket.d/override.conf). Thing is, I would like knot to not listen on port 53 on any interface, not even localhost. But this is precisely what it does. I naively tried to stop it from doing so, first with a kresd.socket.d/override.conf with: [Socket] ListenStream= But that failed with journalctl -u kresd.socket containing `kresd.socket: Unit has no Listen setting (ListenStream=, ListenDatagram=, ListenFIFO=, ...). Refusing.` And also by trying to disable that "socket-unit", with a kresd(a)1.service.d/override.conf containing: [Service] Sockets= Sockets=kresd-tls.socket Sockets=kresd-control(a)%i.socket But that did nothing. Finally, using `systemctl mask kresd.socket` I get it to stop listening on (localhost) port 53. But then instead systemd find itself in "degraded" mode... Any tip on how to accomplish this cleanly?

6 let, 1 měsíc

3
2
0 0

Knot Resolver is not affected by compromised Knot DNS repositories

by Petr Špaček

Hello Knot Resolver users, please let me clarify that Knot Resolver repositories linked from https://www.knot-resolver.cz/download/ are independent and are not affected by compromised Knot DNS repositories [1]. Users who use only Knot Resolver packages from our repositories [2] do not need to take any action. If you have any questions do not hesistate to ask here. [1] https://lists.nic.cz/pipermail/knot-dns-users/2019-March/001630.html [2] https://www.knot-resolver.cz/download/ -- Petr Špaček @ CZ.NIC

6 let, 1 měsíc

1
0
0 0

Re: [knot-resolver-users] Knot DNS 2.8.0 release

by Vladimír Čunát

Hello, Knot * users! Please note that Knot DNS 2.8.x breaks all Knot Resolver versions released so far (<=3.2.1). The breakage is a bit subtle, and build system won't detect it. We plan to release an update soon. If you don't want to wait, you can apply a simple patch: https://gitlab.labs.nic.cz/knot/knot-resolver/commit/186f2639 --Vladimir

6 let, 1 měsíc

2
3
0 0

why random conversion uppercase and lowercase letters

by Champion Xie

Hi， When I request a domain name to the knot-resolver server, I will see that the uppercase and lowercase letters are randomly converted to log records. -- Best Regards!! champion_xie

6 let, 1 měsíc

2
1
0 0

how to dump cache detail

by Champion Xie

Knot-resolver Is there a tool like BIND rndc dumpdb? I want to see the specific cached domain name entry kresc> stats.list() [answer.nxdomain] => 0 [answer.100ms] => 0 [answer.1500ms] => 0 [answer.slow] => 0 [answer.servfail] => 0 [answer.250ms] => 0 *[answer.cached] => 622* [answer.nodata] => 0 [query.dnssec] => 1 [answer.1ms] => 34 [predict.epoch] => 19 [query.edns] => 624 [predict.queue] => 0 [answer.total] => 624 [answer.10ms] => 498 [answer.noerror] => 624 [answer.50ms] => 92 [answer.500ms] => 0 [answer.1000ms] => 0 [predict.learned] => 1 -- Best Regards!! champion_xie

6 let, 1 měsíc

2
1
0 0

which one cache hit count

by Champion Xie

*kresc> cache.stats()* [hit] => 0 [delete] => 0 [miss] => 0 *[insert] => 280* *kresc> stats.list()* [answer.nxdomain] => 0 [answer.100ms] => 0 [answer.1500ms] => 0 [answer.slow] => 0 [answer.servfail] => 0 [answer.250ms] => 0 *[answer.cached] => 2430* [answer.nodata] => 0 [query.edns] => 2710 [query.dnssec] => 1 [answer.total] => 2710 [answer.10ms] => 272 [answer.noerror] => 2710 [answer.50ms] => 8 [answer.500ms] => 0 [answer.1000ms] => 0 [answer.1ms] => 2430 *kresc> cache.count()* *372* -- Best Regards!! champion_xie

6 let, 1 měsíc

2
1
0 0

forward policy stub kind of round robin

by Thomas Belián

Hello, I have at the moment a network with 3 DNS servers. They do recursive/caching as well as authorative zones (Bind 9). I want to build a structure with 2 authorative Servers using Knot-DNS and 3 resolvers using Knot-Resolver. As our authorative servers are in our network and as I want to get any changes in their zones as fast as possible to our users I use from the documentation: Replacing part of the DNS tree Interesting is this line: policy.add(policy.suffix(policy.STUB({'$our ip'}), extraTrees)) Can I put more than one IP at this line to forward the queries? We have 2 authorative servers, so I want ask both of them round robin like. In my config I have comma separated two servers, kresd is running with it, but it seems it uses only the first. Is there a way to get my desired behavior? Regards Thomas P.S.: Versions are Knot-Resolver 3.2.1 and OS is Ubuntu 18.04.02 -- Thomas Belián Fachhochschule Erfurt Fak. GTI / FR AI & Hochschulrechenzentrum Postfach 45 01 55, 99051 Erfurt Telefon: +49361 6700 - 647 E-Mail: thomas.belian(a)fh-erfurt.de

6 let, 2 měsíce

2
2
0 0

Knot Resolver 3.2.1

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 3.2.1 has been released. Bugfixes -------- - trust_anchors: respect validity time range during TA bootstrap (!748) - fix TLS rehandshake handling (!739) - make TLS_FORWARD compatible with GnuTLS 3.3 (!741) - special thanks to Grigorii Demidov for his long-term work on Knot Resolver! Improvements ------------ - improve handling of timeouted outgoing TCP connections (!734) - trust_anchors: check syntax of public keys in DNSKEY RRs (!748) - validator: clarify message about bogus non-authoritative data (!735) - dnssec validation failures contain more verbose reasoning (!735) - new function trust_anchors.summary() describes state of DNSSEC TAs (!737), and logs new state of trust anchors after start up and automatic changes - trust anchors: refuse revoked DNSKEY even if specified explicitly, and downgrade missing the SEP bit to a warning Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v3.2.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-3.2.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-3.2.1.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v3.2.1/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

6 let, 3 měsíce

1
0
0 0

knot-resolver 2.4.1 centos 7 aborts

by Harry Hoffman

Hi Folks, Pretty new to knot-resolver and I've been searching around but haven't found anyone with the same error. I'm running CentOS 7 with knot-resolver 2.4.1 from the EPEL repository. I believe that my config is only slightly modified from an example config. [root@usher knot-resolver]# cat kresd.conf -- Config file example useable for personal resolver. -- The goal is to have a validating resolver with tiny memory footprint, -- while actively tracking and refreshing frequent records to lower user latency. -- Refer to manual: https://knot-resolver.readthedocs.io/en/latest/daemon.html#configuration -- Listen on localhost (default) -- net = { '127.0.0.1', '::1' } -- Drop root privileges -- user('knot-resolver', 'knot-resolver') -- Auto-maintain root TA trust_anchors.file = 'root.keys' -- Load Useful modules modules = { 'policy', -- Block queries to local zones/bad sites 'hints', -- Load /etc/hosts and allow custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } -- Smaller cache size cache.size = 10 * MB verbose(true) policy.add(policy.all(policy.TLS_FORWARD({ {'9.9.9.9', hostname='dns.quad9.net'}, {'1.1.1.1', hostname='cloudflare-dns.com'}, {'149.112.112.112', hostname='dns.quad9.net'}, {'1.0.0.1', hostname='cloudflare-dns.com'}, }))) When running (either via systemd or at a command line) kresd aborts. Below are the verbose logs: [root@usher knot-resolver]# /usr/sbin/kresd --config=/etc/knot-resolver/kresd.conf --forks=1 [gnutls] (2) Initializing PKCS #11 modules [gnutls] (2) p11: Initializing module: p11-kit-trust [gnutls] (3) ASSERT: pkcs11.c:665 [gnutls] (2) p11: No login requested. [gnutls] (2) p11: No login requested. [gnutls] (3) ASSERT: pkcs11.c:2664 [gnutls] (3) ASSERT: pkcs11.c:2993 [tls_client] imported 151 certs from system store [gnutls] (2) p11: No login requested. [gnutls] (2) p11: No login requested. [gnutls] (3) ASSERT: pkcs11.c:2664 [gnutls] (3) ASSERT: pkcs11.c:2993 [tls_client] imported 151 certs from system store [gnutls] (2) p11: No login requested. [gnutls] (2) p11: No login requested. [gnutls] (3) ASSERT: pkcs11.c:2664 [gnutls] (3) ASSERT: pkcs11.c:2993 [tls_client] imported 151 certs from system store [gnutls] (2) p11: No login requested. [gnutls] (2) p11: No login requested. [gnutls] (3) ASSERT: pkcs11.c:2664 [gnutls] (3) ASSERT: pkcs11.c:2993 [tls_client] imported 151 certs from system store [gnutls] (2) p11: No login requested. [gnutls] (2) p11: No login requested. [gnutls] (3) ASSERT: pkcs11.c:2664 [gnutls] (3) ASSERT: pkcs11.c:2993 [tls_client] imported 151 certs from system store [gnutls] (2) p11: No login requested. [gnutls] (2) p11: No login requested. [gnutls] (3) ASSERT: pkcs11.c:2664 [gnutls] (3) ASSERT: pkcs11.c:2993 [tls_client] imported 151 certs from system store [gnutls] (2) p11: No login requested. [gnutls] (2) p11: No login requested. [gnutls] (3) ASSERT: pkcs11.c:2664 [gnutls] (3) ASSERT: pkcs11.c:2993 [tls_client] imported 151 certs from system store [gnutls] (2) p11: No login requested. [gnutls] (2) p11: No login requested. [gnutls] (3) ASSERT: pkcs11.c:2664 [gnutls] (3) ASSERT: pkcs11.c:2993 [tls_client] imported 151 certs from system store [tls_client] error: hostname 'dns.quad9.net' for address '9.9.9.9#00853' already was set, ignoring [tls_client] error: system ca for address '9.9.9.9#00853' already was set, ignoring [tls_client] error: hostname 'cloudflare-dns.com' for address '1.0.0.1#00853' already was set, ignoring [tls_client] error: system ca for address '1.0.0.1#00853' already was set, ignoring [tls_client] error: hostname 'dns.quad9.net' for address '149.112.112.112#00853' already was set, ignoring [tls_client] error: system ca for address '149.112.112.112#00853' already was set, ignoring [tls_client] error: hostname 'cloudflare-dns.com' for address '1.1.1.1#00853' already was set, ignoring [tls_client] error: system ca for address '1.1.1.1#00853' already was set, ignoring [ 0][plan] plan '.' type 'NS' [50114][iter] '.' type 'NS' id was assigned, parent id 0 [50114][plan] plan '.' type 'DNSKEY' [26197][iter] '.' type 'DNSKEY' id was assigned, parent id 50114 [ ][nsre] score 1 for 9.9.9.9; cached RTT: -1 [ ][nsre] score 1 for 1.1.1.1; cached RTT: -1 [ ][nsre] score 1 for 149.112.112.112; cached RTT: -1 [ ][nsre] score 1 for 1.0.0.1; cached RTT: -1 [gnutls] (5) REC[0x55801d4242b0]: Allocating epoch #0 [26197][wrkr] => connecting to: '9.9.9.9' [ 0][plan] plan '.' type 'NS' [38655][iter] '.' type 'NS' id was assigned, parent id 0 [ ][nsre] score 1 for 9.9.9.9; cached RTT: -1 [ ][nsre] score 1 for 1.1.1.1; cached RTT: -1 [ ][nsre] score 1 for 149.112.112.112; cached RTT: -1 [ ][nsre] score 1 for 1.0.0.1; cached RTT: -1 [26197][wrkr] => connected to '9.9.9.9' [gnutls] (3) ASSERT: gnutls_constate.c:586 [gnutls] (5) REC[0x55801d4242b0]: Allocating epoch #1 [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_GCM_SHA256 (C0.2B) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_GCM_SHA384 (C0.2C) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_ECDSA_CAMELLIA_128_GCM_SHA256 (C0.86) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_ECDSA_CAMELLIA_256_GCM_SHA384 (C0.87) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA1 (C0.09) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA256 (C0.23) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA1 (C0.0A) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_ECDSA_CAMELLIA_128_CBC_SHA256 (C0.72) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_ECDSA_3DES_EDE_CBC_SHA1 (C0.08) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256 (C0.2F) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384 (C0.30) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_128_GCM_SHA256 (C0.8A) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_256_GCM_SHA384 (C0.8B) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 (C0.13) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256 (C0.27) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 (C0.14) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_128_CBC_SHA256 (C0.76) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1 (C0.12) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_AES_128_GCM_SHA256 (00.9C) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_AES_256_GCM_SHA384 (00.9D) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_CAMELLIA_128_GCM_SHA256 (C0.7A) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_CAMELLIA_256_GCM_SHA384 (C0.7B) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 (00.2F) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256 (00.3C) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 (00.35) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256 (00.3D) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 (00.41) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA256 (00.BA) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 (00.84) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA256 (00.C0) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 (00.0A) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_AES_128_GCM_SHA256 (00.9E) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_AES_256_GCM_SHA384 (00.9F) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_GCM_SHA256 (C0.7C) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_GCM_SHA384 (C0.7D) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 (00.33) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256 (00.67) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 (00.39) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256 (00.6B) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 (00.45) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA256 (00.BE) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 (00.88) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA256 (00.C4) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 (00.16) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_AES_128_GCM_SHA256 (00.A2) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_AES_256_GCM_SHA384 (00.A3) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_GCM_SHA256 (C0.80) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_GCM_SHA384 (C0.81) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1 (00.32) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA256 (00.40) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1 (00.38) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA256 (00.6A) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 (00.44) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA256 (00.BD) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 (00.87) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA256 (00.C3) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 (00.13) [gnutls] (4) EXT[0x55801d4242b0]: Sending extension STATUS REQUEST (5 bytes) [gnutls] (4) EXT[0x55801d4242b0]: Sending extension SAFE RENEGOTIATION (1 bytes) [gnutls] (4) EXT[0x55801d4242b0]: Sending extension SESSION TICKET (0 bytes) [gnutls] (4) EXT[0x55801d4242b0]: Sending extension SUPPORTED ECC (8 bytes) [gnutls] (4) EXT[0x55801d4242b0]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes) [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (4.1) RSA-SHA256 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (4.2) DSA-SHA256 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (4.3) ECDSA-SHA256 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (5.1) RSA-SHA384 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (5.3) ECDSA-SHA384 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (6.1) RSA-SHA512 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (6.3) ECDSA-SHA512 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (3.1) RSA-SHA224 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (3.2) DSA-SHA224 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (3.3) ECDSA-SHA224 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (2.1) RSA-SHA1 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (2.2) DSA-SHA1 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (2.3) ECDSA-SHA1 [gnutls] (4) EXT[0x55801d4242b0]: Sending extension SIGNATURE ALGORITHMS (28 bytes) [gnutls] (4) HSK[0x55801d4242b0]: CLIENT HELLO was queued [227 bytes] [gnutls] (5) REC[0x55801d4242b0]: Preparing Packet Handshake(22) with length: 227 and min pad: 0 [gnutls] (5) REC[0x55801d4242b0]: Sent Packet[1] Handshake(22) in epoch 0 and length: 232 [ 0][wrkr] [tls_client] push 232 <0x55801d3f4400> [gnutls] (3) ASSERT: gnutls_buffers.c:1139 [gnutls] (2) The pull function has been replaced but not the pull timeout.[gnutls] (3) ASSERT: gnutls_buffers.c:731 [gnutls] (3) ASSERT: gnutls_buffers.c:332 [gnutls] (3) ASSERT: gnutls_buffers.c:572 [gnutls] (3) ASSERT: gnutls_record.c:1063 [gnutls] (3) ASSERT: gnutls_record.c:1184 [gnutls] (3) ASSERT: gnutls_buffers.c:1393 [gnutls] (3) ASSERT: gnutls_handshake.c:1440 [gnutls] (3) ASSERT: gnutls_handshake.c:2739 [tls_client] handshake failed (Error in the pull function.) [ 0][resl] AD: request NOT classified as SECURE [26197][resl] finished: 0, queries: 0, mempool: 81952 B [priming] cannot resolve '.' NS, next priming query in 10 seconds [ 0][resl] AD: request NOT classified as SECURE [38655][resl] finished: 0, queries: 0, mempool: 81952 B [detect_time_skew] cannot resolve '.' NS [gnutls] (5) REC[0x55801d4242b0]: Start of epoch cleanup [gnutls] (5) REC[0x55801d4242b0]: End of epoch cleanup [gnutls] (5) REC[0x55801d4242b0]: Epoch #0 freed [gnutls] (5) REC[0x55801d4242b0]: Epoch #1 freed [ 0][plan] plan '.' type 'DNSKEY' [35791][iter] '.' type 'DNSKEY' id was assigned, parent id 0 [ ][nsre] score 1 for 9.9.9.9; cached RTT: -1 [ ][nsre] score 1 for 1.1.1.1; cached RTT: -1 [ ][nsre] score 1 for 149.112.112.112; cached RTT: -1 [ ][nsre] score 1 for 1.0.0.1; cached RTT: -1 kresd: daemon/worker.c:1691: qr_task_step: Assertion `session->outgoing' failed. Aborted

6 let, 3 měsíce

2
6
0 0

Knot Resolver 3.2.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 3.2.0 has been released. New features ------------ - module edns_keepalive to implement server side of RFC 7828 (#408) - module nsid to implement server side of RFC 5001 (#289) - module bogus_log provides .frequent() table (!629, credit Ulrich Wisser) - module stats collects flags from answer messages (!629, credit Ulrich Wisser) - module view supports multiple rules with identical address/TSIG specification and keeps trying rules until a "non-chain" action is executed (!678) - module experimental_dot_auth implements an DNS-over-TLS to auth protocol (!711, credit Manu Bretelle) - net.bpf bindings allow advanced users to use eBPF socket filters Bugfixes -------- - http module: only run prometheus in parent process if using --forks=N, as the submodule collects metrics from all sub-processes as well. - TLS fixes for corner cases (!700, !714, !716, !721, !728) - fix build with -DNOVERBOSELOG (#424) - policy.{FORWARD,TLS_FORWARD,STUB}: respect net.ipv{4,6} setting (!710) - avoid SERVFAILs due to certain kind of NS dependency cycles, again (#374) this time seen as 'circular dependency' in verbose logs - policy and view modules do not overwrite result finished requests (!678) Improvements ------------ - Dockerfile: rework, basing on Debian instead of Alpine - policy.{FORWARD,TLS_FORWARD,STUB}: give advantage to IPv6 when choosing whom to ask, just as for iteration - use pseudo-randomness from gnutls instead of internal ISAAC (#233) - tune the way we deal with non-responsive servers (!716, !723) - documentation clarifies interaction between policy and view modules (!678, !730) Module API changes ------------------ - new layer is added: answer_finalize - kr_request keeps ::qsource.packet beyond the begin layer - kr_request::qsource.tcp renamed to ::qsource.flags.tcp - kr_request::has_tls renamed to ::qsource.flags.tls - kr_zonecut_add(), kr_zonecut_del() and kr_nsrep_sort() changed parameters slightly Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v3.2.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-3.2.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-3.2.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v3.2.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

6 let, 4 měsíce

1
0
0 0

knot-resolver 3.1.0 nevrací A záznam pro www.cezdistribuce.cz

by Zdeněk Janiš

Dobrý den, používám knot-resolver ver. 3.1.0 a zjistil, že nevrací A záznamy pro: www.cezdistribuce.cz když vymažu cache: cache.clear('cezdistribuce.cz') tak se knot-resolver na nedefinovanou dobu umoudří a A záznamy normálně vrací. Přitom google DNS 8.8.8.8 záznamy vrací v pořádku. Jinou anomálii jsem nezjistil. V čem může být problém? Konfigurace? Nefunkční výpis: $ dig @192.168.100.100 -t A www.cezdistribuce.cz ; <<>> DiG 9.11.4-P2-3~bpo9+1-Debian <<>> @192.168.100.100 -t A www.cezdistribuce.cz ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26696 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.cezdistribuce.cz. IN A ;; AUTHORITY SECTION: cezdistribuce.cz. 41952 IN SOA ns10.cez.cz. netmaster.cezdata.cz. 2018112701 28800 7200 864000 86400 ;; Query time: 1 msec ;; SERVER: 192.168.100.100#53(192.168.100.100) ;; WHEN: Po pro 10 07:58:55 CET 2018 ;; MSG SIZE rcvd: 112 Funkční, po vymazaní z cache: $ dig @192.168.100.100 -t A www.cezdistribuce.cz ; <<>> DiG 9.11.4-P2-3~bpo9+1-Debian <<>> @192.168.100.100 -t A www.cezdistribuce.cz ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 89 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.cezdistribuce.cz. IN A ;; ANSWER SECTION: www.cezdistribuce.cz. 24 IN A 89.111.76.140 ;; Query time: 0 msec ;; SERVER: 192.168.100.100#53(192.168.100.100) ;; WHEN: Po pro 10 08:09:59 CET 2018 ;; MSG SIZE rcvd: 65 Děkuji za pomoc. -- Zdeněk Janiš

6 let, 4 měsíce

3
2
0 0

not able to configure kresd

by Ján Boroš

hi My idea is to use knot resolver as dns forwarder / cache instead using dnsmasq. I am using old PC with archlinux as router. I did change dnsmasq config so it listen on port 5353. following steps here https://wiki.archlinux.org/index.php/Knot_Resolver I did change systemd unit so my kresd is listening on both local interfaces. I am checking that with ss command and it is ok. here is my config of kresd cat /etc/knot-resolver/kresd.conf -- vim:syntax=lua: -- Refer to manual: http://knot-resolver.readthedocs.org/en/latest/daemon.html#configuration -- Load useful modules modules = { 'policy', -- Block queries to local zones/bad sites 'hints > iterate', -- Load /etc/hosts and allow custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } -- See kresd.systemd(7) about configuring network interfaces when using systemd -- Listen on localhost (default) -- net = { '127.0.0.1', '::1'} -- Enable DNSSEC validation -- trust_anchors.file = '/etc/knot-resolver/root.keys' hints.root_file = '/etc/knot-resolver/root.hints' -- Cache size cache.size = 100 * MB After start I can see following errors in journal Nov 08 22:49:43 skriatok systemd[1]: Starting Knot Resolver daemon... Nov 08 22:49:43 skriatok systemd[1]: Started Knot Resolver daemon. Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'b.root- servers.net.', type: 1 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'b.root- servers.net.', type: 28 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'h.root- servers.net.', type: 28 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'j.root- servers.net.', type: 1 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'm.root- servers.net.', type: 1 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'l.root- servers.net.', type: 1 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'j.root- servers.net.', type: 28 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'i.root- servers.net.', type: 28 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'g.root- servers.net.', type: 28 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'f.root- servers.net.', type: 28 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'e.root- servers.net.', type: 28 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'd.root- servers.net.', type: 28 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'a.root- servers.net.', type: 28 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'h.root- servers.net.', type: 1 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'c.root- servers.net.', type: 1 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'k.root- servers.net.', type: 1 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'e.root- servers.net.', type: 1 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'f.root- servers.net.', type: 1 ... thank you for help

6 let, 5 měsíců

3
6
0 0

Status of DNS over HTTPS in knot resolver

by Arsen STASIC

Hi, What is the current status for DoH (DNS over HTTPS) in knot resolver? There is an open issue #280 https://gitlab.labs.nic.cz/knot/knot-resolver/issues/280 Marek Vavrusa from Cloudflare offers a patch for this, but I haven't found it so far and dnsprivacy.org also mentions (probably) this patch. https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status Is this patch available? cheers -arsen

6 let, 5 měsíců

2
1
0 0

forward for given zones

by Ivo Panáček

Hi, I am not able to force knot-resolver to forward some queries. I have real DNS zone and in internal network I have few 3rd level subzones. For them I would like to make my kresd forward queries to our internal DNS server (bind9). My computer is not inside company nework - connected via openvpn. System is ubuntu 18.04.1 (up-to-date) and knot-resolver 3.0.0. Relevant part of kresd.conf is: policy.add(policy.suffix( policy.FORWARD('10.0.0.1'),{ todname('sub1.company.cz'), todname('sub2.company.cz') } )) dig machine.sub1.company.cz @127.0.0.53 does NOT work, dig machine.sub1.company.cz @10.0.0.1 DOES work I have set verbose(true) but with no help. kresd queries 10.0.0.1 for 'company.cz' only, but that's all. I am just working on it on my ubuntu workstation, but real target will be turris omnia with its kresd, which connects via openvpn to company network. -- Sincerely Ivo Panacek

6 let, 5 měsíců

3
8
0 0

Knot Resolver 3.1.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 3.1.0 has been released. Incompatible changes -------------------- - hints.use_nodata(true) by default; that's what most users want - libknot >= 2.7.2 is required Improvements ------------ - cache: handle out-of-space SIGBUS slightly better (#197) - daemon: improve TCP timeout handling (!686) Bugfixes -------- - cache.clear('name'): fix some edge cases in API (#401) - fix error handling from TLS writes (!669) - avoid SERVFAILs due to certain kind of NS dependency cycles (#374) Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v3.1.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-3.1.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-3.1.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v3.1.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

6 let, 5 měsíců

1
0
0 0

views with more than one policy

by Bratislav ILIC

Dear Knot Resolver users, Is it possible to create a view with more than one policie? If I do for example something like this: view:addr('192.168.1.0/24', policy.suffix( policy.PASS, policy.todnames({'good.com','better.com','best.com'}) ) ) view:addr('192.168.1.0/24', policy.suffix( policy.REFUSE,{todname('bad.com')} ) ) Knot resolver will obey only the first view and users will be able to resolve the bad.com domain ... obviously the first view is the match and no other views are considered afterwards ... Without multiple policies views are pretty much useless so I believe that I must be doing something wrong here so could anybody help me on this ... Best regards, Bratislav ILIC

6 let, 7 měsíců

3
3
0 0

Knot Resolver 3.0.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 3.0.0 has been released. Incompatible changes -------------------- - cache: fail lua operations if cache isn't open yet (!639) By default cache is opened *after* reading the configuration, and older versions were silently ignoring cache operations. Valid configuration must open cache using `cache.open()` or `cache.size =` before executing cache operations like `cache.clear()`. - libknot >= 2.7.1 is required, which brings also larger API changes - in case you wrote custom Lua modules, please consult https://knot-resolver.readthedocs.io/en/latest/lib.html#incompatible-change… - in case you wrote custom C modules, please see compile against Knot DNS 2.7 and adjust your module according to messages from C compiler - DNS cookie module (RFC 7873) is not available in this release, it will be later reworked to reflect development in IEFT dnsop working group - version module was permanently removed because it was not really used by users; if you want to receive notifications about new releases please subscribe to https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-resolver-announce Bugfixes -------- - fix multi-process race condition in trust anchor maintenance (!643) - ta_sentinel: also consider static trust anchors not managed via RFC 5011 Improvements ------------ - reorder_RR() implementation is brought back - bring in performace improvements provided by libknot 2.7 - cache.clear() has a new, more powerful API - cache documentation was improved - old name "Knot DNS Resolver" is replaced by unambiguous "Knot Resolver" to prevent confusion with "Knot DNS" authoritative server Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v3.0.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-3.0.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-3.0.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v3.0.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

6 let, 8 měsíců

4
3
0 0

policy.lua error attempt to call local 'action' (a table value)

by Yoshihito Horigome

Hello, I set config as below, but an error is output at some timing. Although it is an error message related to policy.lua, reading the document does not know the cause. """ error: /usr/local/lib/kdns_modules/policy.lua:526: attempt to call local 'action' (a table value) error: /usr/local/lib/kdns_modules/policy.lua:526: attempt to call local 'action' (a table value) error: /usr/local/lib/kdns_modules/policy.lua:526: attempt to call local 'action' (a table value) error: /usr/local/lib/kdns_modules/policy.lua:526: attempt to call local 'action' (a table value) """ """ net.listen(net.eth0, 53, false) -- Load Useful modules modules = { 'policy', -- Block queries to local zones/bad sites 'view', -- Views for certain clients 'hints > iterate', -- Hints AFTER iterate 'priming', -- Initializing a DNS Resolver with Priming Queries implemented according. 'detect_time_skew', -- System time skew detector 'detect_time_jump', -- Detect discontinuous jumps in the system time 'daf', predict = { window = 180, -- 180 minutes sampling window period = 24*(60/15) -- track last 24 hours }, 'bogus_log', } modules.list() -- Check module call order -- stub forward policy.add(policy.suffix(policy.PASS({'192.168.1.3@10053', '192.168.1.4@10053'}), {todname('kometch.private')})) policy.add(policy.suffix(policy.PASS({'192.168.1.3@10053', '192.168.1.4@10053'}), {todname('168.192.in-addr.arpa') })) --forward policy policy.add(policy.all(policy.FORWARD({'1.1.1.1', '1.0.0.1'}))) policy.del(0) """ Would you please advise me? Best regards.

6 let, 8 měsíců

2
2
0 0

version module been deleted?

by Yoshihito Horigome

Hello, Since version 2.4.1, have the version module been deleted? I confirmed NEWS, but I could not find a sentence to mention that the "version" module was deleted. https://gitlab.labs.nic.cz/knot/knot-resolver/blob/master/NEWS I have confirmed that it has been deleted from Gitlab. Best regards.

6 let, 8 měsíců

4
4
0 0

Knot Resolver 2.4.1

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 2.4.1 has been released. Security -------- - fix CVE-2018-10920: Improper input validation bug in DNS resolver component (security!7, security!9) Bugfixes -------- - cache: fix TTL overflow in packet due to min_ttl (#388, security!8) - TLS session resumption: avoid bad scheduling of rotation (#385) - HTTP module: fix a regression in 2.4.0 which broke custom certs (!632) - cache: NSEC3 negative cache even without NS record (#384) This fixes lower hit rate in NSEC3 zones (since 2.4.0). - minor TCP and TLS fixes (!623, !624, !626) Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v2.4.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.4.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.4.1.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v2.4.1/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

6 let, 8 měsíců

1
0
0 0

building kresd with redis support

by Bjoern Franke

Hi, I'm trying to build knot-resolver with redis support. I was wondering why the memcache and redis-stuff is commented out within the Makefile, so I uncommented the redis-part, also in modules.mk. Now it fails because it does not find it's own cache.h? modules/redis/redis.c:24:10: fatal error: lib/cache.h: No such file or directory Regards Bjoern

6 let, 8 měsíců

3
3
0 0

Knot resolver module stats - query source ip - knot-resolver-users Digest, Vol 31, Issue 1

by Sýkora Milan

Hello Petr, This a good news, that query source IP would be planned in the future module version. I would like to answer your related notes like: - How many 'most frequent' IP addresses you want to get? - It is better to do the list as variable items, someone needs to list top 10 and someone 1000. - Should the number of addresses be configurable? yes - Do you consider query from the same IP but different port as 'different client' or not? (E.g. clients behind NAT?) In my case, it is not a topic function. - Should IP addresses be somehow tied to most frequent query names or not? yes, it will be better to know frequented queries to domain names. - Do you need a way to flush the table on fly? An option to clear statistic list and count it since a specific time range sound as a good idea. In the case when I´m not so familiar with Lua, where should be added your code part? Best regards, Milan Sýkora -----Original Message----- From: knot-resolver-users [mailto:knot-resolver-users-bounces@lists.nic.cz] On Behalf Of knot-resolver-users-request(a)lists.nic.cz Sent: Tuesday, July 24, 2018 12:00 PM To: knot-resolver-users(a)lists.nic.cz Subject: knot-resolver-users Digest, Vol 31, 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/cgi-bin/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. Knot resolver module stats - query source ip (Sýkora Milan) 2. Re: Knot resolver module stats - query source ip (Petr Špaček) ---------------------------------------------------------------------- Message: 1 Date: Tue, 24 Jul 2018 07:32:52 +0000 From: Sýkora Milan <milan.sykora(a)cetin.cz> To: "knot-resolver-users(a)lists.nic.cz" <knot-resolver-users(a)lists.nic.cz> Subject: [knot-resolver-users] Knot resolver module stats - query source ip Message-ID: <365048c9e5ae48c699c079fee6343a5f(a)cewexch402.ad.cetin> Content-Type: text/plain; charset="iso-8859-2" Hello, I have your cool DNS resolver in version 2.3.0, I know that was released newest version. My question is - is it possible to explore the most frequented IP (queries source) in the module stats? Or exist any other way how to achieve it? Many thanks for your answer in the future, Best regards. Milan Sýkora Obsah této zprávy má výlučně komunikační charakter. Nepředstavuje návrh na uzavření smlouvy či na její změnu ani přijetí případného návrhu. Smlouvy či jejich změny jsou společností Česká telekomunikační infrastruktura a.s. uzavírány v písemné formě nebo v podobě a postupem podle příslušných všeobecných podmínek společnosti Česká telekomunikační infrastruktura a.s., a pokud jsou dohodnuty všechny náležitosti. Smlouvy jsou uzavírány oprávněnou osobou na základě písemného pověření. Smlouvy o smlouvě budoucí jsou uzavírány výhradně v písemné formě, vlastnoručně podepsané nebo s uznávaným elektronickým podpisem. Podmínky, za nichž Česká telekomunikační infrastruktura a.s. přistupuje k jednání o smlouvě a jakými se řídí, jsou dostupné zde<https://www.cetin.cz/cs/jak-cetin-vyjednava-o-smlouve>. The content of this message is intended for communication purposes only. It does neither represent any contract proposal, nor its amendment or acceptance of any potential contract proposal. Česká telekomunikační infrastruktura a.s. concludes contracts or amendments thereto in a written form or in the form and the procedure in accordance with relevant general terms and conditions of Česká telekomunikační infrastruktura a.s., if all requirements are agreed. Contracts are concluded by an authorized person entitled on the basis of a written authorization. Contracts on a future contract are concluded solely in a written form, self-signed or signed by means of an advanced electronic signature. The conditions under which Česká telekomunikační infrastruktura a.s. negotiates contracts and under which it proceeds are available here<https://www.cetin.cz/en/jak-cetin-vyjednava-o-smlouve>. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.nic.cz/pipermail/knot-resolver-users/attachments/20180724/cc47…> ------------------------------ Message: 2 Date: Tue, 24 Jul 2018 11:05:51 +0200 From: Petr Špaček <petr.spacek(a)nic.cz> To: knot-resolver-users(a)lists.nic.cz Subject: Re: [knot-resolver-users] Knot resolver module stats - query source ip Message-ID: <2a769de2-3b70-7d6f-5476-4bc7bd48fa8b(a)nic.cz> Content-Type: text/plain; charset=UTF-8 Hello, at the moment there is no built-in module with this statistics but it can be hacked around (see below). BTW we plan to to rework stats so it would be very valuable to get your requirements! To make sure future version contains what you need, can you specify what kind of data + what configuration you want to get? For example: - How many 'most frequent' IP addresses you want to get? - Should the number of addresses be configurable? - Do you consider query from the same IP but different port as 'different client' or not? (E.g. clients behind NAT?) - Should IP addresses be somehow tied to most frequent query names or not? - Do you need a way to flush the table on fly? For now you can use the following Lua config snippet to log client IP addresses. -- start of config snippet function LOG_IP(state, req) req = kres.request_t(req) if req.qsource == nil or req.qsource.addr == nil then -- internal request, no source return state end print('query from IP ' .. tostring(req.qsource.addr)) return -- continue with other policy rules end policy.add(policy.all(LOG_IP)) -- end of config snipper Output looks like this: "query from IP ::1#56927" This can be further processed by your log processing system to get aggregate numbers over all resolvers or alternativelly it can be extended using LRU library in Lua to get stats for single resolver. I hope it helps. Petr Špaček @ CZ.NIC On 24.7.2018 09:32, Sýkora Milan wrote: > Hello, > > > > I have your cool DNS resolver in version 2.3.0, I know that was > released newest version. > > > > My question is – is it possible to explore the most frequented IP > (queries source) in the module stats? Or exist any other way how to > achieve it? > > > > > > Many thanks for your answer in the future, > > Best regards. > > *Milan Sýkora*** ------------------------------ Subject: Digest Footer -- https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-resolver-users Please change Subject line before before you reply to a digest message! ------------------------------ End of knot-resolver-users Digest, Vol 31, Issue 1 ************************************************** Obsah této zprávy má výlučně komunikační charakter. Nepředstavuje návrh na uzavření smlouvy či na její změnu ani přijetí případného návrhu. Smlouvy či jejich změny jsou společností Česká telekomunikační infrastruktura a.s. uzavírány v písemné formě nebo v podobě a postupem podle příslušných všeobecných podmínek společnosti Česká telekomunikační infrastruktura a.s., a pokud jsou dohodnuty všechny náležitosti. Smlouvy jsou uzavírány oprávněnou osobou na základě písemného pověření. Smlouvy o smlouvě budoucí jsou uzavírány výhradně v písemné formě, vlastnoručně podepsané nebo s uznávaným elektronickým podpisem. Podmínky, za nichž Česká telekomunikační infrastruktura a.s. přistupuje k jednání o smlouvě a jakými se řídí, jsou dostupné zde<https://www.cetin.cz/cs/jak-cetin-vyjednava-o-smlouve>. The content of this message is intended for communication purposes only. It does neither represent any contract proposal, nor its amendment or acceptance of any potential contract proposal. Česká telekomunikační infrastruktura a.s. concludes contracts or amendments thereto in a written form or in the form and the procedure in accordance with relevant general terms and conditions of Česká telekomunikační infrastruktura a.s., if all requirements are agreed. Contracts are concluded by an authorized person entitled on the basis of a written authorization. Contracts on a future contract are concluded solely in a written form, self-signed or signed by means of an advanced electronic signature. The conditions under which Česká telekomunikační infrastruktura a.s. negotiates contracts and under which it proceeds are available here<https://www.cetin.cz/en/jak-cetin-vyjednava-o-smlouve>.

6 let, 9 měsíců

2
1
0 0

Knot resolver module stats - query source ip

by Sýkora Milan

Hello, I have your cool DNS resolver in version 2.3.0, I know that was released newest version. My question is - is it possible to explore the most frequented IP (queries source) in the module stats? Or exist any other way how to achieve it? Many thanks for your answer in the future, Best regards. Milan Sýkora Obsah této zprávy má výlučně komunikační charakter. Nepředstavuje návrh na uzavření smlouvy či na její změnu ani přijetí případného návrhu. Smlouvy či jejich změny jsou společností Česká telekomunikační infrastruktura a.s. uzavírány v písemné formě nebo v podobě a postupem podle příslušných všeobecných podmínek společnosti Česká telekomunikační infrastruktura a.s., a pokud jsou dohodnuty všechny náležitosti. Smlouvy jsou uzavírány oprávněnou osobou na základě písemného pověření. Smlouvy o smlouvě budoucí jsou uzavírány výhradně v písemné formě, vlastnoručně podepsané nebo s uznávaným elektronickým podpisem. Podmínky, za nichž Česká telekomunikační infrastruktura a.s. přistupuje k jednání o smlouvě a jakými se řídí, jsou dostupné zde<https://www.cetin.cz/cs/jak-cetin-vyjednava-o-smlouve>. The content of this message is intended for communication purposes only. It does neither represent any contract proposal, nor its amendment or acceptance of any potential contract proposal. Česká telekomunikační infrastruktura a.s. concludes contracts or amendments thereto in a written form or in the form and the procedure in accordance with relevant general terms and conditions of Česká telekomunikační infrastruktura a.s., if all requirements are agreed. Contracts are concluded by an authorized person entitled on the basis of a written authorization. Contracts on a future contract are concluded solely in a written form, self-signed or signed by means of an advanced electronic signature. The conditions under which Česká telekomunikační infrastruktura a.s. negotiates contracts and under which it proceeds are available here<https://www.cetin.cz/en/jak-cetin-vyjednava-o-smlouve>.

6 let, 9 měsíců

2
1
0 0

can not download a normal root.zone with Cache prefilling

by Yoshi Horigome

Hello, When Cache prefilling added from 2.3.0 is enabled, the following error occurs. https://knot-resolver.readthedocs.io/en/stable/modules.html#cache-prefilling /etc/knot-resolver # kresd -V Knot DNS Resolver, version 2.4.0 [prefill] downloading root zone... [prefill] saving root zone... [ 0][zimport] [zscanner] started; zone file `root.zone` [zscanner] line: 1: parse error; code: -986 ('owner is invalid') Segmentation fault (core dumped) If you check the contents of the downloaded file, it seems that something different file is being downloaded. /etc/knot-resolver # ls -l total 8704 -rw------- 1 root root 12533760 Jul 8 00:24 core.64 -rw-r----- 1 root root 3221225472 Jul 8 00:23 data.mdb -rw-r--r-- 1 1001 1001 2944 Jul 8 00:23 kresd.conf -rw-r----- 1 root root 8192 Jul 8 00:23 lock.mdb -rw-r--r-- 1 root root 832 Jul 7 07:35 root.keys -rw-r--r-- 1 root root 249 Jul 8 00:24 root.zone drwxr-x--- 2 root root 4096 Jun 13 12:56 tty /etc/knot-resolver # cat root.zone <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> The document has moved <a href="https://www.internic.net/domain/root.zone">here</a>. </body></html> Is this supposed behavior? Best regards.

6 let, 9 měsíců

3
5
0 0

Knot Resolver 2.4.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 2.4.0 has been released. Incompatible changes -------------------- - minimal libknot version is now 2.6.7 to pull in latest fixes (#366) Security -------- - fix a rare case of zones incorrectly downgraded to insecure status (!576) New features ------------ - TLS session resumption (RFC 5077), both server and client (!585, #105) (disabled when compiling with gnutls < 3.5) - TLS_FORWARD policy uses system CA certificate store by default (!568) - aggressive caching for NSEC3 zones (!600) - optional protection from DNS Rebinding attack (module rebinding, !608) - module bogus_log to log DNSSEC bogus queries without verbose logging (!613) Bugfixes -------- - prefill: fix ability to read certificate bundle (!578) - avoid turning off qname minimization in some cases, e.g. co.uk. (#339) - fix validation of explicit wildcard queries (#274) - dns64 module: more properties from the RFC implemented (incl. bug #375) Improvements ------------ - systemd: multiple enabled kresd instances can now be started using kresd.target - ta_sentinel: switch to version 14 of the RFC draft (!596) - support for glibc systems with a non-Linux kernel (!588) - support per-request variables for Lua modules (!533) - support custom HTTP endpoints for Lua modules (!527) Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v2.4.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.4.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.4.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v2.4.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

6 let, 9 měsíců

1
0
0 0

documentation of implemented DNS features / RFCs

by nusenu

Hi, is there somewhere a comprehensive list of implemented DNS protocol features / RFCs for knot-resolver? thanks, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

6 let, 10 měsíců

2
2
0 0

TA Sentinel

by Ulrich Wisser

Hi, today I wanted to try the ta sentinel functionality. Unfortunately do I not get the expected results. Maybe somebody could show me some example querries? I tried: dig +dnssec kskroll-sentinel-is-ta-20326.iis.se dig +dnssec kskroll-sentinel-not-ta-20326.iis.se dig +dnssec kskroll-sentinel-is-ta-19036.iis.se dig +dnssec kskroll-sentinel-not-ta-19036.iis.se All with the same result. No answer section. dig +dnssec iis.se iis.se. 60 IN A 91.226.37.214 iis.se. 60 IN RRSIG A 5 2 60 20180615103001 20180605103001 6150 iis.se. XAbt3nM5DmpsDsvZN6gRW94mGwTsCYpAQxurTJYp4FHZXaXt82o+3SMD ZEZjWsDswy3WsYp087Wx7Y4sH6HbuP0VYuwg1yLsBegrj6xNlcd5JarN wi8ZGbTytnDBG5rvpqwUp8fat3ZZ6kko4t7BtsD4cFzdL2xpw4MPbBKz p0s= What am I doing wrong? /Ulrich -- Ulrich Wisser ulrich(a)wisser.se

6 let, 10 měsíců

2
3
0 0

Statistics

by Ulrich Wisser

Hi, over the last weekend I did configure knot resolver on Turris Omnia to write statistics to my influxdb instance. Now that I have statistics, I am not entirely sure what all the data means. Everything under answer is easy to understand. But all data under cache is only 0, although answer.cached is not 0. Please find some stats below. I would be very grateful for some explanation what the data means. My next step would be to try to use RPZ funtionality. is there statistics for RPZ too? /Ulrich > stats.list() [answer.nxdomain] => 360546 [answer.100ms] => 64682 [answer.1500ms] => 2740 [answer.slow] => 12137 [answer.servfail] => 204137 [answer.250ms] => 84208 [answer.cached] => 430091 [answer.nodata] => 1533 [answer.1ms] => 462921 [answer.total] => 922236 [answer.10ms] => 58963 [answer.noerror] => 356015 [answer.50ms] => 195917 [answer.500ms] => 29794 [answer.1000ms] => 7525 [predict.learned] => 54 [predict.epoch] => 19 [predict.queue] => 520 [query.edns] => 152223 [query.dnssec] => 211 > cache.stats() [hit] => 0 [delete] => 0 [miss] => 0 [insert] => 0 -- Ulrich Wisser ulrich(a)wisser.se

6 let, 10 měsíců

2
5
0 0

Running systemd service and binding to privileged ports

by Ondrej Vaško

Hello knot-resolver users, I have a question about design of systemd service for knot-resolver. I installed knot from repository OpenSuse repository <https://software.opensuse.org//download.html?project=home%3ACZ-NIC%3Aknot-r…> on Ubuntu 16 and 18. The systemd service uses user *knot-resolver*. But this user cannot bind to unprivileged ports, so when I have configuration like below where I bind to network interface on privileged port and change user context, it fails with "*[system] bind to '10.20.30.118@853' Permission denied*": ``` net.listen({'10.20.30.118'}, 853, { tls = true }) user('knot-resolver', 'knot-resolver') ``` To fix this I changed User *knot-resolver* to *root* in systemd service. Now service starts to run as root, binds to network interface and then changes context. My question is, is this solution security wise fine? Why is the systemd service designed to run as user knot-resolver, when I guess many people will need to override this in order to use knot-resolver properly? What is the main idea? Or is there a different approach to overcome this (Such as linux capabilities)? Thank you for responses and please correct me in anything if I am wrong. Ondrej Vaško

6 let, 10 měsíců

2
1
0 0

Modifying policy rules of a running resolver instance

by Martin Sehnoutka

Hi, I would like to run Knot Resolver with DNS-over-TLS on my laptop, but I need to configure 'policy.FORWARD' whenever I connect to our corporate network. The information about new connection is provided by the Network Manager, that is not a problem, but then I need to configure the resolver somehow. I was thinking about creating a new configuration file and simply restarting the server, but it fails with "Start request repeated too quickly". Is there a way to add/remove policy rules "on the fly"? The HTTP/2 module seems like a good candidate for doing this. Can this module be used to accomplish this task? Best regards, Martin Sehnoutka PS: If there is anyone using dnssec-trigger, this would be similar, but less complicated. -- Martin Sehnoutka | Associate Software Engineer PGP: 5FD64AF5 UTC+1 (CET) RED HAT | TRIED. TESTED. TRUSTED.

6 let, 10 měsíců

3
7
0 0

How to use forwarding when recursion is failed?

by Ilya Evseev

Hi, Folks! I want to use GoogleDNS 8.8.x.x as fallback forwarder when domain's NS'es are down or inaccessible (for example, when network connectivity between me and NS is broken). Is it possible? policy.add(policy.all(policy.FORWARD({ '8.8.8.8', '8.8.4.4' }))) works well, but disables recursion at all. How to call it only after/when recursion is failed? WBR, Ilya

6 let, 11 měsíců

1
0
0 0

Knot Resolver 2.3.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 2.3.0 has been released. This is a security release that fixes CVE-2018-1110. We're also introducing a new mailing list, knot-resolver-announce. Only notifications about new releases or important announcements will be posted there. https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-resolver-announce Security -------- - fix CVE-2018-1110: denial of service triggered by malformed DNS messages (!550, !558, security!2, security!4) - increase resilience against slow lorris attack (security!5) Bugfixes -------- - validation: fix SERVFAIL in case of CNAME to NXDOMAIN in a single zone (!538) - validation: fix SERVFAIL for DS . query (!544) - lib/resolve: don't send unecessary queries to parent zone (!513) - iterate: fix validation for zones where parent and child share NS (!543) - TLS: improve error handling and documentation (!536, !555, !559) Improvements ------------ - prefill: new module to periodically import root zone into cache (replacement for RFC 7706, !511) - network_listen_fd: always create end point for supervisor supplied file descriptor - use CPPFLAGS build environment variable if set (!547) Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v2.3.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.3.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.3.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v2.3.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

7 let

1
0
0 0

RPM packaging issues

by Martin Sehnoutka

Hi, I have a fresh installation of the Knot Resolver on my Fedora 27: *Package version*: $ rpm -q knot-resolver knot-resolver-2.2.0-1.fc27.x86_64 but it does not work out of the box. The problem is, that the user "knot-resolver" cannot bind to a privileged port. Why is the systemd service file using knot-resolver user? It works just fine, when I remove the "User=" option from service file and add this line into the kres.conf file: user('knot-resolver', 'knot-resolver') The resulting process runs as knot-resolver and it binds successfully. Best regards, -- Martin Sehnoutka | Associate Software Engineer PGP: 5FD64AF5 UTC+1 (CET) RED HAT | TRIED. TESTED. TRUSTED.

7 let

2
3
0 0

Knot Resolver 2.2.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 2.2.0 has been released. New features ------------ - cache server unavailability to prevent flooding unreachable servers (Please note that caching algorithm needs further optimization and will change in further versions but we need to gather operational experience first.) Bugfixes -------- - don't magically -D_FORTIFY_SOURCE=2 in some cases - allow large responses for outbound over TCP - fix crash with RR sets with over 255 records Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v2.2.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.2.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.2.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v2.2.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

7 let

2
1
0 0

How to disable DNSSEC validation for specific domains

by Leonardo Brondani Schenkel

Hello, There is a website I need to use in a daily basis that uses DNSSEC, however their keys have expired which causes validation to fail. I have contacted their support but they failed to resolve the issue so far. Since I can resolve the name when using `dig +cd`, I was hoping I could configure `kresd` to skip validation when resolving that specific domain. It seems that I should be able to do so by using the `policies` module and the `FLAGS` action: https://knot-resolver.readthedocs.io/en/stable/modules.html#actions I am not sure with flag/flags to use. I inspected the source and tried the following: policy.add(policy.suffix(policy.FLAGS('DNSSEC_CD'),{todname('example.org.')})) But this apparently had no effect. I also tried without the trailing dot and played with other flags, but no success. Does anybody know which flag I could set to bypass DNSSEC validation for the specified domain? Or, if the policy module is not the way to achieve that goal, is there any other way? # kresd --version Knot DNS Resolver, version 1.5.1 Any help will be greatly appreciated, // Leonardo.

7 let, 1 měsíc

2
2
0 0

Can't build 2.1 on Ubuntu 16.04.4 LTS

by Paul Hoffman

Greetings. I want to build Knot 2.1 on a Ubuntu 16.04.4 LTS. However, the libknot from the packages is too old: Makefile:87: *** libknot >= 2.6.4 required. Stop. As compared to: libknot-dev/xenial,now 2.1.1-1build1 amd64 [installed] Is it possible to get the libknot package on Ubuntu 16.04.4 LTS updated soon? If not, how do I install the latest libknot by hand? --Paul Hoffman

7 let, 1 měsíc

4
6
0 0

Unsure on the kskroll-sentinel handling

by Paul Hoffman

Greetings. My kresd config file is: net.listen('192.241.207.161', 5364) trust_anchors.file = 'root.keys' modules.load('ta_sentinel') I wanted to test this with a zone I set up at this-is-signed.com. However, I'm getting a positive result back for both the is-ta and the not-ta records (it is properly giving me the SERVFAIL for the bogus record). Have I configured Knot Resolver incorrectly? For Knot 2.2.1, do I need a different form for the names in order to get the kskroll-sentinel effect to kick in? From the DNSOP WG mailing list traffic, I thought I needed the 4f66 tag, but could have misinterpreted that. --Paul Hoffman # dig @192.241.207.161 -p 5364 kskroll-sentinel-is-ta-4f66.this-is-signed.com a ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.241.207.161 -p 5364 kskroll-sentinel-is-ta-4f66.this-is-signed.com a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36153 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;kskroll-sentinel-is-ta-4f66.this-is-signed.com. IN A ;; ANSWER SECTION: kskroll-sentinel-is-ta-4f66.this-is-signed.com. 60 IN CNAME this-is-signed.com. this-is-signed.com. 60 IN A 192.241.207.161 ;; Query time: 283 msec ;; SERVER: 192.241.207.161#5364(192.241.207.161) ;; WHEN: Sun Feb 25 00:09:54 UTC 2018 ;; MSG SIZE rcvd: 105 # dig @192.241.207.161 -p 5364 kskroll-sentinel-not-ta-4f66.this-is-signed.com a ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.241.207.161 -p 5364 kskroll-sentinel-not-ta-4f66.this-is-signed.com a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14466 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;kskroll-sentinel-not-ta-4f66.this-is-signed.com. IN A ;; ANSWER SECTION: kskroll-sentinel-not-ta-4f66.this-is-signed.com. 60 IN CNAME this-is-signed.com. this-is-signed.com. 54 IN A 192.241.207.161 ;; Query time: 5 msec ;; SERVER: 192.241.207.161#5364(192.241.207.161) ;; WHEN: Sun Feb 25 00:10:00 UTC 2018 ;; MSG SIZE rcvd: 106 # dig @192.241.207.161 -p 5364 bogus.this-is-signed.com a ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.241.207.161 -p 5364 bogus.this-is-signed.com a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20810 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;bogus.this-is-signed.com. IN A ;; Query time: 9 msec ;; SERVER: 192.241.207.161#5364(192.241.207.161) ;; WHEN: Sun Feb 25 00:10:08 UTC 2018 ;; MSG SIZE rcvd: 42

7 let, 1 měsíc

2
2
0 0

Knot Resolver 2.1.1 and new package repositories

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 2.1.1 with a couple of bugfixes for caching and TLS forwarding has been released. We'd also like to announce our new upstream repository for latest stable packages for Debian, Ubuntu, CentOS, Fedora and Arch. Knot Resolver 2.1.1 is already available there. You can find instructions on how to use the repository in the updated download section on our website: https://www.knot-resolver.cz/download/ Bugfixes -------- - when iterating, avoid unnecessary queries for NS in insecure parent. This problem worsened in 2.0.0. (#246) - prevent UDP packet leaks when using TLS forwarding - fix the hints module also on some other systems, e.g. Gentoo. Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v2.1.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.1.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.1.1.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v2.1.1/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

7 let, 1 měsíc

1
0
0 0

Knot Resolver 2.1.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 2.1.0 is released. Incompatible changes -------------------- - stats: remove tracking of expiring records (predict uses another way) - systemd: re-use a single kresd.socket and kresd-tls.socket - ta_sentinel: implement protocol draft-ietf-dnsop-kskroll-sentinel-01 (our draft-ietf-dnsop-kskroll-sentinel-00 implementation had inverted logic) - libknot: require version 2.6.4 or newer to get bugfixes for DNS-over-TLS Bugfixes -------- - detect_time_jump module: don't clear cache on suspend-resume (#284) - stats module: fix stats.list() returning nothing, regressed in 2.0.0 - policy.TLS_FORWARD: refusal when configuring with multiple IPs (#306) - cache: fix broken refresh of insecure records that were about to expire - fix the hints module on some systems, e.g. Fedora (came back on 2.0.0) - build with older gnutls (conditionally disable features) - fix the predict module to work with insecure records & cleanup code Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v2.1.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.1.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.1.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v2.1.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

7 let, 2 měsíce

1
0
0 0

Knot Resolver: module view is not able to deal with cache

by Sakirnth Nagarasa

Hi, I am running knot-resolver version 2.0.0 and I would like to redirect (STUB) queries from a subnet to a specific nameserver. For that I created a view configuration for that subnet (see below). A query without being in that subnet caches the answer but unfortunately the cache overrides the answer when doing the same query inside the view. My configuration file looks like that: --- modules = { 'hints > iterate', 'policy > hints', 'view < cache' } view:addr('${SUBNET}', policy.suffix(policy.STUB('${IP}'), {todname('${DOMAIN_SUFFIX}')})) --- Testing procedure: 1) Try to resolve A record being in the special subnet. $kdig @${KNOT-RESOLVER} A www.${DOMAIN_SUFFIX} -> STUB works and answer is correct 2) Try to resolve A record without being in the special subnet. $kdig @${KNOT-RESOLVER} ${KNOT-RESOLVER} -> view is not triggerd and answer is correct 3) Try to resolve A record again within the special subnet. $kdig @${KNOT-RESOLVER} A www.${DOMAIN_SUFFIX} -> The answer is satisfied from cache, which is not the right answer. Is it even possible to do that? Best wishes, Sakirnth

7 let, 2 měsíce

2
1
0 0

Conditional forward with todname configuration

by Petr Špaček

Hello, I'm going to reply here instead of knot-dns-users. On 7.2.2018 03:24, Yoshi Horigome wrote: > Hello Jay, > > Is it ok to understand that it forwards to "192.168.168.1" which is the > local DNS when asking for localnet.mydomain.com > <http://localnet.mydomain.com>? > > If it is, perhaps, I think that setting should be done as follows. > > --If the request is from eng subnet > > if (view:addr('192.168.168.0/24' <http://192.168.168.0/24'>)) then > if (todname('localnet.mydomain.com > <http://localnet.mydomain.com>')) then > - policy.add(policy.suffix(policy.FORWARD('192.168.168.1'), > {todname('localnet.mydomain.com <http://localnet.mydomain.com>')})) > + policy.add(policy.suffix(policy.STUB('192.168.168.1'), > {{'\8localnet\8mydomain\3com'}})) > else > view:addr('192.168.168.0/24 <http://192.168.168.0/24>', > policy.FORWARD('68.111.106.68')) > > end > end First of all the use of `if` conditions above is incorrect. Examples of view configuration can be found here: http://knot-resolver.readthedocs.io/en/latest/modules.html#example-configur… Second part of view definition is basically a rule from policy module, which has examples here: http://knot-resolver.readthedocs.io/en/latest/modules.html#policy-examples I'm not sure I understood your request correctly, so I will provide snippets and let you to combine them together. -- forward all queries for subdomain localnet.mydomain.com to 192.168.168.1 policy.add(policy.suffix(policy.FORWARD('192.168.168.1'), {todname('localnet.mydomain.com')}) -- forward all queries from 192.168.168.0/24 to 68.111.106.68 view:addr('192.168.168.0/24', policy.all(policy.FORWARD('68.111.106.68'))) This needs to be tested as result will depend on order of modules. I can see that you have policy before view, so it might just work. Give it a try. Petr Špaček @ CZ.NIC > I understand that it is policy.STUB if it is version1, and policy.PASS > if it is version2. > > I am sorry if I made a mistake. > > > Best regards. > > Postscript: > It seems that knot resolver's mailing list has been created, so this may > be better. > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-resolver-users > > > 2018-02-07 4:46 GMT+09:00 Jay Remotti <jremotti(a)ontraport.com > <mailto:jremotti@ontraport.com>>: > > I'm getting started with knot resolver and am a bit unclear as to > how this config should be structured. > The result I'm looking for is to forward queries to resolver A if > the source is subnet A; unless the query is for the local domain if > so then query the local DNS. > > I've been working with the config below to accomplish this. However > I'm finding that this config will if the request does not match the > local todname and will use root hints if not but will not use the > FORWARD server. > > Ultimately, this server will resolve DNS for several subnets and > will forward queries to different servers based on the source subnet. > > Would someone mind pointing me in the right direction on this, please? > > for name, addr_list in pairs(net.interfaces()) do > net.listen(addr_list) > end > -- drop root > user('knot', 'knot') > -- Auto-maintain root TA > modules = { > 'policy', -- Block queries to local zones/bad sites > 'view', --view filters > 'hints', -- Load /etc/hosts and allow custom root hints > 'stats', > } > > > -- 4GB local cache for record storage > cache.size = 4 * GB > > --If the request is from eng subnet > > if (view:addr('192.168.168.0/24' <http://192.168.168.0/24'>)) then > if (todname('localnet.mydomain.com > <http://localnet.mydomain.com>')) then > policy.add(policy.suffix(policy.FORWARD('192.168.168.1'), > {todname('localnet.mydomain.com <http://localnet.mydomain.com>')})) > else > view:addr('192.168.168.0/24 <http://192.168.168.0/24>', > policy.FORWARD('68.111.106.68')) > > end > end > > > 855.ONTRAPORT > ontraport.com <https://ontraport.com> > ------------------------------------------------------------------------ > > Get a Demo <https://ontraport.com/demo>| Blog > <https://ontraport.com/blog>| Free Tools <https://ontraport.com/tools> > > > > -- > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users > <https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users>

7 let, 2 měsíce

1
0
0 0