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

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

2 roky, 10 měsíců

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

2 roky, 10 měsíců

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

2 roky, 10 měsíců

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

2 roky, 10 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...

2 roky, 11 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

2 roky, 11 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

2 roky, 11 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

2 roky, 11 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

2 roky, 11 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

3
4
0 0

2024

2023

2022

2021

2020

2019

2018

knot-resolver-users