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

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, 11 měsíců

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

5 let

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

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, 1 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, 3 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

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

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

5 let, 4 měsíce

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

5 let, 4 měsíce

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

knot-resolver-users