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

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

4 roky

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

4 roky

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

4 roky

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

4 roky, 1 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

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

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

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

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

4 roky, 3 měsíce

2
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

knot-resolver-users