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

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

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

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

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

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

3 roky, 11 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...

4 roky

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

4 roky

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

knot-resolver-users