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

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

5 let, 4 měsíce

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

5 let, 4 měsíce

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

5 let, 4 měsíce

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

5 let, 4 měsíce

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

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

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

5 let, 6 měsíců

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

5 let, 8 měsíců

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

5 let, 8 měsíců

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

5 let, 8 měsíců

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

knot-resolver-users