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

by Champion Xie

*kresc> cache.stats()* [hit] => 0 [delete] => 0 [miss] => 0 *[insert] => 280* *kresc> stats.list()* [answer.nxdomain] => 0 [answer.100ms] => 0 [answer.1500ms] => 0 [answer.slow] => 0 [answer.servfail] => 0 [answer.250ms] => 0 *[answer.cached] => 2430* [answer.nodata] => 0 [query.edns] => 2710 [query.dnssec] => 1 [answer.total] => 2710 [answer.10ms] => 272 [answer.noerror] => 2710 [answer.50ms] => 8 [answer.500ms] => 0 [answer.1000ms] => 0 [answer.1ms] => 2430 *kresc> cache.count()* *372* -- Best Regards!! champion_xie

7 let, 5 měsíců

2
1
0 0

forward policy stub kind of round robin

by Thomas Belián

Hello, I have at the moment a network with 3 DNS servers. They do recursive/caching as well as authorative zones (Bind 9). I want to build a structure with 2 authorative Servers using Knot-DNS and 3 resolvers using Knot-Resolver. As our authorative servers are in our network and as I want to get any changes in their zones as fast as possible to our users I use from the documentation: Replacing part of the DNS tree Interesting is this line: policy.add(policy.suffix(policy.STUB({'$our ip'}), extraTrees)) Can I put more than one IP at this line to forward the queries? We have 2 authorative servers, so I want ask both of them round robin like. In my config I have comma separated two servers, kresd is running with it, but it seems it uses only the first. Is there a way to get my desired behavior? Regards Thomas P.S.: Versions are Knot-Resolver 3.2.1 and OS is Ubuntu 18.04.02 -- Thomas Belián Fachhochschule Erfurt Fak. GTI / FR AI & Hochschulrechenzentrum Postfach 45 01 55, 99051 Erfurt Telefon: +49361 6700 - 647 E-Mail: thomas.belian(a)fh-erfurt.de

7 let, 5 měsíců

2
2
0 0

Knot Resolver 3.2.1

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 3.2.1 has been released. Bugfixes -------- - trust_anchors: respect validity time range during TA bootstrap (!748) - fix TLS rehandshake handling (!739) - make TLS_FORWARD compatible with GnuTLS 3.3 (!741) - special thanks to Grigorii Demidov for his long-term work on Knot Resolver! Improvements ------------ - improve handling of timeouted outgoing TCP connections (!734) - trust_anchors: check syntax of public keys in DNSKEY RRs (!748) - validator: clarify message about bogus non-authoritative data (!735) - dnssec validation failures contain more verbose reasoning (!735) - new function trust_anchors.summary() describes state of DNSSEC TAs (!737), and logs new state of trust anchors after start up and automatic changes - trust anchors: refuse revoked DNSKEY even if specified explicitly, and downgrade missing the SEP bit to a warning Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v3.2.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-3.2.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-3.2.1.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v3.2.1/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

7 let, 6 měsíců

1
0
0 0

knot-resolver 2.4.1 centos 7 aborts

by Harry Hoffman

Hi Folks, Pretty new to knot-resolver and I've been searching around but haven't found anyone with the same error. I'm running CentOS 7 with knot-resolver 2.4.1 from the EPEL repository. I believe that my config is only slightly modified from an example config. [root@usher knot-resolver]# cat kresd.conf -- Config file example useable for personal resolver. -- The goal is to have a validating resolver with tiny memory footprint, -- while actively tracking and refreshing frequent records to lower user latency. -- Refer to manual: https://knot-resolver.readthedocs.io/en/latest/daemon.html#configuration -- Listen on localhost (default) -- net = { '127.0.0.1', '::1' } -- Drop root privileges -- user('knot-resolver', 'knot-resolver') -- Auto-maintain root TA trust_anchors.file = 'root.keys' -- Load Useful modules modules = { 'policy', -- Block queries to local zones/bad sites 'hints', -- Load /etc/hosts and allow custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } -- Smaller cache size cache.size = 10 * MB verbose(true) policy.add(policy.all(policy.TLS_FORWARD({ {'9.9.9.9', hostname='dns.quad9.net'}, {'1.1.1.1', hostname='cloudflare-dns.com'}, {'149.112.112.112', hostname='dns.quad9.net'}, {'1.0.0.1', hostname='cloudflare-dns.com'}, }))) When running (either via systemd or at a command line) kresd aborts. Below are the verbose logs: [root@usher knot-resolver]# /usr/sbin/kresd --config=/etc/knot-resolver/kresd.conf --forks=1 [gnutls] (2) Initializing PKCS #11 modules [gnutls] (2) p11: Initializing module: p11-kit-trust [gnutls] (3) ASSERT: pkcs11.c:665 [gnutls] (2) p11: No login requested. [gnutls] (2) p11: No login requested. [gnutls] (3) ASSERT: pkcs11.c:2664 [gnutls] (3) ASSERT: pkcs11.c:2993 [tls_client] imported 151 certs from system store [gnutls] (2) p11: No login requested. [gnutls] (2) p11: No login requested. [gnutls] (3) ASSERT: pkcs11.c:2664 [gnutls] (3) ASSERT: pkcs11.c:2993 [tls_client] imported 151 certs from system store [gnutls] (2) p11: No login requested. [gnutls] (2) p11: No login requested. [gnutls] (3) ASSERT: pkcs11.c:2664 [gnutls] (3) ASSERT: pkcs11.c:2993 [tls_client] imported 151 certs from system store [gnutls] (2) p11: No login requested. [gnutls] (2) p11: No login requested. [gnutls] (3) ASSERT: pkcs11.c:2664 [gnutls] (3) ASSERT: pkcs11.c:2993 [tls_client] imported 151 certs from system store [gnutls] (2) p11: No login requested. [gnutls] (2) p11: No login requested. [gnutls] (3) ASSERT: pkcs11.c:2664 [gnutls] (3) ASSERT: pkcs11.c:2993 [tls_client] imported 151 certs from system store [gnutls] (2) p11: No login requested. [gnutls] (2) p11: No login requested. [gnutls] (3) ASSERT: pkcs11.c:2664 [gnutls] (3) ASSERT: pkcs11.c:2993 [tls_client] imported 151 certs from system store [gnutls] (2) p11: No login requested. [gnutls] (2) p11: No login requested. [gnutls] (3) ASSERT: pkcs11.c:2664 [gnutls] (3) ASSERT: pkcs11.c:2993 [tls_client] imported 151 certs from system store [gnutls] (2) p11: No login requested. [gnutls] (2) p11: No login requested. [gnutls] (3) ASSERT: pkcs11.c:2664 [gnutls] (3) ASSERT: pkcs11.c:2993 [tls_client] imported 151 certs from system store [tls_client] error: hostname 'dns.quad9.net' for address '9.9.9.9#00853' already was set, ignoring [tls_client] error: system ca for address '9.9.9.9#00853' already was set, ignoring [tls_client] error: hostname 'cloudflare-dns.com' for address '1.0.0.1#00853' already was set, ignoring [tls_client] error: system ca for address '1.0.0.1#00853' already was set, ignoring [tls_client] error: hostname 'dns.quad9.net' for address '149.112.112.112#00853' already was set, ignoring [tls_client] error: system ca for address '149.112.112.112#00853' already was set, ignoring [tls_client] error: hostname 'cloudflare-dns.com' for address '1.1.1.1#00853' already was set, ignoring [tls_client] error: system ca for address '1.1.1.1#00853' already was set, ignoring [ 0][plan] plan '.' type 'NS' [50114][iter] '.' type 'NS' id was assigned, parent id 0 [50114][plan] plan '.' type 'DNSKEY' [26197][iter] '.' type 'DNSKEY' id was assigned, parent id 50114 [ ][nsre] score 1 for 9.9.9.9; cached RTT: -1 [ ][nsre] score 1 for 1.1.1.1; cached RTT: -1 [ ][nsre] score 1 for 149.112.112.112; cached RTT: -1 [ ][nsre] score 1 for 1.0.0.1; cached RTT: -1 [gnutls] (5) REC[0x55801d4242b0]: Allocating epoch #0 [26197][wrkr] => connecting to: '9.9.9.9' [ 0][plan] plan '.' type 'NS' [38655][iter] '.' type 'NS' id was assigned, parent id 0 [ ][nsre] score 1 for 9.9.9.9; cached RTT: -1 [ ][nsre] score 1 for 1.1.1.1; cached RTT: -1 [ ][nsre] score 1 for 149.112.112.112; cached RTT: -1 [ ][nsre] score 1 for 1.0.0.1; cached RTT: -1 [26197][wrkr] => connected to '9.9.9.9' [gnutls] (3) ASSERT: gnutls_constate.c:586 [gnutls] (5) REC[0x55801d4242b0]: Allocating epoch #1 [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_GCM_SHA256 (C0.2B) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_GCM_SHA384 (C0.2C) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_ECDSA_CAMELLIA_128_GCM_SHA256 (C0.86) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_ECDSA_CAMELLIA_256_GCM_SHA384 (C0.87) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA1 (C0.09) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA256 (C0.23) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA1 (C0.0A) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_ECDSA_CAMELLIA_128_CBC_SHA256 (C0.72) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_ECDSA_3DES_EDE_CBC_SHA1 (C0.08) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256 (C0.2F) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384 (C0.30) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_128_GCM_SHA256 (C0.8A) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_256_GCM_SHA384 (C0.8B) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 (C0.13) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256 (C0.27) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 (C0.14) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_128_CBC_SHA256 (C0.76) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1 (C0.12) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_AES_128_GCM_SHA256 (00.9C) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_AES_256_GCM_SHA384 (00.9D) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_CAMELLIA_128_GCM_SHA256 (C0.7A) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_CAMELLIA_256_GCM_SHA384 (C0.7B) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 (00.2F) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256 (00.3C) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 (00.35) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256 (00.3D) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 (00.41) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA256 (00.BA) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 (00.84) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA256 (00.C0) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 (00.0A) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_AES_128_GCM_SHA256 (00.9E) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_AES_256_GCM_SHA384 (00.9F) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_GCM_SHA256 (C0.7C) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_GCM_SHA384 (C0.7D) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 (00.33) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256 (00.67) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 (00.39) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256 (00.6B) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 (00.45) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA256 (00.BE) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 (00.88) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA256 (00.C4) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 (00.16) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_AES_128_GCM_SHA256 (00.A2) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_AES_256_GCM_SHA384 (00.A3) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_GCM_SHA256 (C0.80) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_GCM_SHA384 (C0.81) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1 (00.32) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA256 (00.40) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1 (00.38) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA256 (00.6A) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 (00.44) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA256 (00.BD) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 (00.87) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA256 (00.C3) [gnutls] (4) HSK[0x55801d4242b0]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 (00.13) [gnutls] (4) EXT[0x55801d4242b0]: Sending extension STATUS REQUEST (5 bytes) [gnutls] (4) EXT[0x55801d4242b0]: Sending extension SAFE RENEGOTIATION (1 bytes) [gnutls] (4) EXT[0x55801d4242b0]: Sending extension SESSION TICKET (0 bytes) [gnutls] (4) EXT[0x55801d4242b0]: Sending extension SUPPORTED ECC (8 bytes) [gnutls] (4) EXT[0x55801d4242b0]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes) [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (4.1) RSA-SHA256 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (4.2) DSA-SHA256 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (4.3) ECDSA-SHA256 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (5.1) RSA-SHA384 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (5.3) ECDSA-SHA384 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (6.1) RSA-SHA512 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (6.3) ECDSA-SHA512 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (3.1) RSA-SHA224 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (3.2) DSA-SHA224 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (3.3) ECDSA-SHA224 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (2.1) RSA-SHA1 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (2.2) DSA-SHA1 [gnutls] (4) EXT[0x55801d4242b0]: sent signature algo (2.3) ECDSA-SHA1 [gnutls] (4) EXT[0x55801d4242b0]: Sending extension SIGNATURE ALGORITHMS (28 bytes) [gnutls] (4) HSK[0x55801d4242b0]: CLIENT HELLO was queued [227 bytes] [gnutls] (5) REC[0x55801d4242b0]: Preparing Packet Handshake(22) with length: 227 and min pad: 0 [gnutls] (5) REC[0x55801d4242b0]: Sent Packet[1] Handshake(22) in epoch 0 and length: 232 [ 0][wrkr] [tls_client] push 232 <0x55801d3f4400> [gnutls] (3) ASSERT: gnutls_buffers.c:1139 [gnutls] (2) The pull function has been replaced but not the pull timeout.[gnutls] (3) ASSERT: gnutls_buffers.c:731 [gnutls] (3) ASSERT: gnutls_buffers.c:332 [gnutls] (3) ASSERT: gnutls_buffers.c:572 [gnutls] (3) ASSERT: gnutls_record.c:1063 [gnutls] (3) ASSERT: gnutls_record.c:1184 [gnutls] (3) ASSERT: gnutls_buffers.c:1393 [gnutls] (3) ASSERT: gnutls_handshake.c:1440 [gnutls] (3) ASSERT: gnutls_handshake.c:2739 [tls_client] handshake failed (Error in the pull function.) [ 0][resl] AD: request NOT classified as SECURE [26197][resl] finished: 0, queries: 0, mempool: 81952 B [priming] cannot resolve '.' NS, next priming query in 10 seconds [ 0][resl] AD: request NOT classified as SECURE [38655][resl] finished: 0, queries: 0, mempool: 81952 B [detect_time_skew] cannot resolve '.' NS [gnutls] (5) REC[0x55801d4242b0]: Start of epoch cleanup [gnutls] (5) REC[0x55801d4242b0]: End of epoch cleanup [gnutls] (5) REC[0x55801d4242b0]: Epoch #0 freed [gnutls] (5) REC[0x55801d4242b0]: Epoch #1 freed [ 0][plan] plan '.' type 'DNSKEY' [35791][iter] '.' type 'DNSKEY' id was assigned, parent id 0 [ ][nsre] score 1 for 9.9.9.9; cached RTT: -1 [ ][nsre] score 1 for 1.1.1.1; cached RTT: -1 [ ][nsre] score 1 for 149.112.112.112; cached RTT: -1 [ ][nsre] score 1 for 1.0.0.1; cached RTT: -1 kresd: daemon/worker.c:1691: qr_task_step: Assertion `session->outgoing' failed. Aborted

7 let, 7 měsíců

2
6
0 0

Knot Resolver 3.2.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 3.2.0 has been released. New features ------------ - module edns_keepalive to implement server side of RFC 7828 (#408) - module nsid to implement server side of RFC 5001 (#289) - module bogus_log provides .frequent() table (!629, credit Ulrich Wisser) - module stats collects flags from answer messages (!629, credit Ulrich Wisser) - module view supports multiple rules with identical address/TSIG specification and keeps trying rules until a "non-chain" action is executed (!678) - module experimental_dot_auth implements an DNS-over-TLS to auth protocol (!711, credit Manu Bretelle) - net.bpf bindings allow advanced users to use eBPF socket filters Bugfixes -------- - http module: only run prometheus in parent process if using --forks=N, as the submodule collects metrics from all sub-processes as well. - TLS fixes for corner cases (!700, !714, !716, !721, !728) - fix build with -DNOVERBOSELOG (#424) - policy.{FORWARD,TLS_FORWARD,STUB}: respect net.ipv{4,6} setting (!710) - avoid SERVFAILs due to certain kind of NS dependency cycles, again (#374) this time seen as 'circular dependency' in verbose logs - policy and view modules do not overwrite result finished requests (!678) Improvements ------------ - Dockerfile: rework, basing on Debian instead of Alpine - policy.{FORWARD,TLS_FORWARD,STUB}: give advantage to IPv6 when choosing whom to ask, just as for iteration - use pseudo-randomness from gnutls instead of internal ISAAC (#233) - tune the way we deal with non-responsive servers (!716, !723) - documentation clarifies interaction between policy and view modules (!678, !730) Module API changes ------------------ - new layer is added: answer_finalize - kr_request keeps ::qsource.packet beyond the begin layer - kr_request::qsource.tcp renamed to ::qsource.flags.tcp - kr_request::has_tls renamed to ::qsource.flags.tls - kr_zonecut_add(), kr_zonecut_del() and kr_nsrep_sort() changed parameters slightly Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v3.2.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-3.2.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-3.2.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v3.2.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

7 let, 7 měsíců

1
0
0 0

knot-resolver 3.1.0 nevrací A záznam pro www.cezdistribuce.cz

by Zdeněk Janiš

Dobrý den, používám knot-resolver ver. 3.1.0 a zjistil, že nevrací A záznamy pro: www.cezdistribuce.cz když vymažu cache: cache.clear('cezdistribuce.cz') tak se knot-resolver na nedefinovanou dobu umoudří a A záznamy normálně vrací. Přitom google DNS 8.8.8.8 záznamy vrací v pořádku. Jinou anomálii jsem nezjistil. V čem může být problém? Konfigurace? Nefunkční výpis: $ dig @192.168.100.100 -t A www.cezdistribuce.cz ; <<>> DiG 9.11.4-P2-3~bpo9+1-Debian <<>> @192.168.100.100 -t A www.cezdistribuce.cz ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26696 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.cezdistribuce.cz. IN A ;; AUTHORITY SECTION: cezdistribuce.cz. 41952 IN SOA ns10.cez.cz. netmaster.cezdata.cz. 2018112701 28800 7200 864000 86400 ;; Query time: 1 msec ;; SERVER: 192.168.100.100#53(192.168.100.100) ;; WHEN: Po pro 10 07:58:55 CET 2018 ;; MSG SIZE rcvd: 112 Funkční, po vymazaní z cache: $ dig @192.168.100.100 -t A www.cezdistribuce.cz ; <<>> DiG 9.11.4-P2-3~bpo9+1-Debian <<>> @192.168.100.100 -t A www.cezdistribuce.cz ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 89 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.cezdistribuce.cz. IN A ;; ANSWER SECTION: www.cezdistribuce.cz. 24 IN A 89.111.76.140 ;; Query time: 0 msec ;; SERVER: 192.168.100.100#53(192.168.100.100) ;; WHEN: Po pro 10 08:09:59 CET 2018 ;; MSG SIZE rcvd: 65 Děkuji za pomoc. -- Zdeněk Janiš

7 let, 7 měsíců

3
2
0 0

not able to configure kresd

by Ján Boroš

hi My idea is to use knot resolver as dns forwarder / cache instead using dnsmasq. I am using old PC with archlinux as router. I did change dnsmasq config so it listen on port 5353. following steps here https://wiki.archlinux.org/index.php/Knot_Resolver I did change systemd unit so my kresd is listening on both local interfaces. I am checking that with ss command and it is ok. here is my config of kresd cat /etc/knot-resolver/kresd.conf -- vim:syntax=lua: -- Refer to manual: http://knot-resolver.readthedocs.org/en/latest/daemon.html#configuration -- Load useful modules modules = { 'policy', -- Block queries to local zones/bad sites 'hints > iterate', -- Load /etc/hosts and allow custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } -- See kresd.systemd(7) about configuring network interfaces when using systemd -- Listen on localhost (default) -- net = { '127.0.0.1', '::1'} -- Enable DNSSEC validation -- trust_anchors.file = '/etc/knot-resolver/root.keys' hints.root_file = '/etc/knot-resolver/root.hints' -- Cache size cache.size = 100 * MB After start I can see following errors in journal Nov 08 22:49:43 skriatok systemd[1]: Starting Knot Resolver daemon... Nov 08 22:49:43 skriatok systemd[1]: Started Knot Resolver daemon. Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'b.root- servers.net.', type: 1 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'b.root- servers.net.', type: 28 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'h.root- servers.net.', type: 28 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'j.root- servers.net.', type: 1 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'm.root- servers.net.', type: 1 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'l.root- servers.net.', type: 1 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'j.root- servers.net.', type: 28 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'i.root- servers.net.', type: 28 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'g.root- servers.net.', type: 28 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'f.root- servers.net.', type: 28 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'e.root- servers.net.', type: 28 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'd.root- servers.net.', type: 28 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'a.root- servers.net.', type: 28 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'h.root- servers.net.', type: 1 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'c.root- servers.net.', type: 1 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'k.root- servers.net.', type: 1 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'e.root- servers.net.', type: 1 Nov 08 22:49:53 skriatok kresd[9012]: [priming] cannot resolve address 'f.root- servers.net.', type: 1 ... thank you for help

7 let, 8 měsíců

3
6
0 0

Status of DNS over HTTPS in knot resolver

by Arsen STASIC

Hi, What is the current status for DoH (DNS over HTTPS) in knot resolver? There is an open issue #280 https://gitlab.labs.nic.cz/knot/knot-resolver/issues/280 Marek Vavrusa from Cloudflare offers a patch for this, but I haven't found it so far and dnsprivacy.org also mentions (probably) this patch. https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status Is this patch available? cheers -arsen

7 let, 8 měsíců

2
1
0 0

forward for given zones

by Ivo Panáček

Hi, I am not able to force knot-resolver to forward some queries. I have real DNS zone and in internal network I have few 3rd level subzones. For them I would like to make my kresd forward queries to our internal DNS server (bind9). My computer is not inside company nework - connected via openvpn. System is ubuntu 18.04.1 (up-to-date) and knot-resolver 3.0.0. Relevant part of kresd.conf is: policy.add(policy.suffix( policy.FORWARD('10.0.0.1'),{ todname('sub1.company.cz'), todname('sub2.company.cz') } )) dig machine.sub1.company.cz @127.0.0.53 does NOT work, dig machine.sub1.company.cz @10.0.0.1 DOES work I have set verbose(true) but with no help. kresd queries 10.0.0.1 for 'company.cz' only, but that's all. I am just working on it on my ubuntu workstation, but real target will be turris omnia with its kresd, which connects via openvpn to company network. -- Sincerely Ivo Panacek

7 let, 9 měsíců

3
8
0 0

Knot Resolver 3.1.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 3.1.0 has been released. Incompatible changes -------------------- - hints.use_nodata(true) by default; that's what most users want - libknot >= 2.7.2 is required Improvements ------------ - cache: handle out-of-space SIGBUS slightly better (#197) - daemon: improve TCP timeout handling (!686) Bugfixes -------- - cache.clear('name'): fix some edge cases in API (#401) - fix error handling from TLS writes (!669) - avoid SERVFAILs due to certain kind of NS dependency cycles (#374) Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v3.1.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-3.1.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-3.1.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v3.1.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

7 let, 9 měsíců

1
0
0 0

views with more than one policy

by Bratislav ILIC

Dear Knot Resolver users, Is it possible to create a view with more than one policie? If I do for example something like this: view:addr('192.168.1.0/24', policy.suffix( policy.PASS, policy.todnames({'good.com','better.com','best.com'}) ) ) view:addr('192.168.1.0/24', policy.suffix( policy.REFUSE,{todname('bad.com')} ) ) Knot resolver will obey only the first view and users will be able to resolve the bad.com domain ... obviously the first view is the match and no other views are considered afterwards ... Without multiple policies views are pretty much useless so I believe that I must be doing something wrong here so could anybody help me on this ... Best regards, Bratislav ILIC

7 let, 10 měsíců

3
3
0 0

Knot Resolver 3.0.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 3.0.0 has been released. Incompatible changes -------------------- - cache: fail lua operations if cache isn't open yet (!639) By default cache is opened *after* reading the configuration, and older versions were silently ignoring cache operations. Valid configuration must open cache using `cache.open()` or `cache.size =` before executing cache operations like `cache.clear()`. - libknot >= 2.7.1 is required, which brings also larger API changes - in case you wrote custom Lua modules, please consult https://knot-resolver.readthedocs.io/en/latest/lib.html#incompatible-change… - in case you wrote custom C modules, please see compile against Knot DNS 2.7 and adjust your module according to messages from C compiler - DNS cookie module (RFC 7873) is not available in this release, it will be later reworked to reflect development in IEFT dnsop working group - version module was permanently removed because it was not really used by users; if you want to receive notifications about new releases please subscribe to https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-resolver-announce Bugfixes -------- - fix multi-process race condition in trust anchor maintenance (!643) - ta_sentinel: also consider static trust anchors not managed via RFC 5011 Improvements ------------ - reorder_RR() implementation is brought back - bring in performace improvements provided by libknot 2.7 - cache.clear() has a new, more powerful API - cache documentation was improved - old name "Knot DNS Resolver" is replaced by unambiguous "Knot Resolver" to prevent confusion with "Knot DNS" authoritative server Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v3.0.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-3.0.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-3.0.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v3.0.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

7 let, 11 měsíců

4
3
0 0

policy.lua error attempt to call local 'action' (a table value)

by Yoshihito Horigome

Hello, I set config as below, but an error is output at some timing. Although it is an error message related to policy.lua, reading the document does not know the cause. """ error: /usr/local/lib/kdns_modules/policy.lua:526: attempt to call local 'action' (a table value) error: /usr/local/lib/kdns_modules/policy.lua:526: attempt to call local 'action' (a table value) error: /usr/local/lib/kdns_modules/policy.lua:526: attempt to call local 'action' (a table value) error: /usr/local/lib/kdns_modules/policy.lua:526: attempt to call local 'action' (a table value) """ """ net.listen(net.eth0, 53, false) -- Load Useful modules modules = { 'policy', -- Block queries to local zones/bad sites 'view', -- Views for certain clients 'hints > iterate', -- Hints AFTER iterate 'priming', -- Initializing a DNS Resolver with Priming Queries implemented according. 'detect_time_skew', -- System time skew detector 'detect_time_jump', -- Detect discontinuous jumps in the system time 'daf', predict = { window = 180, -- 180 minutes sampling window period = 24*(60/15) -- track last 24 hours }, 'bogus_log', } modules.list() -- Check module call order -- stub forward policy.add(policy.suffix(policy.PASS({'192.168.1.3@10053', '192.168.1.4@10053'}), {todname('kometch.private')})) policy.add(policy.suffix(policy.PASS({'192.168.1.3@10053', '192.168.1.4@10053'}), {todname('168.192.in-addr.arpa') })) --forward policy policy.add(policy.all(policy.FORWARD({'1.1.1.1', '1.0.0.1'}))) policy.del(0) """ Would you please advise me? Best regards.

8 let

2
2
0 0

version module been deleted?

by Yoshihito Horigome

Hello, Since version 2.4.1, have the version module been deleted? I confirmed NEWS, but I could not find a sentence to mention that the "version" module was deleted. https://gitlab.labs.nic.cz/knot/knot-resolver/blob/master/NEWS I have confirmed that it has been deleted from Gitlab. Best regards.

8 let

4
4
0 0

Knot Resolver 2.4.1

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 2.4.1 has been released. Security -------- - fix CVE-2018-10920: Improper input validation bug in DNS resolver component (security!7, security!9) Bugfixes -------- - cache: fix TTL overflow in packet due to min_ttl (#388, security!8) - TLS session resumption: avoid bad scheduling of rotation (#385) - HTTP module: fix a regression in 2.4.0 which broke custom certs (!632) - cache: NSEC3 negative cache even without NS record (#384) This fixes lower hit rate in NSEC3 zones (since 2.4.0). - minor TCP and TLS fixes (!623, !624, !626) Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v2.4.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.4.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.4.1.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v2.4.1/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

8 let

1
0
0 0

building kresd with redis support

by Bjoern Franke

Hi, I'm trying to build knot-resolver with redis support. I was wondering why the memcache and redis-stuff is commented out within the Makefile, so I uncommented the redis-part, also in modules.mk. Now it fails because it does not find it's own cache.h? modules/redis/redis.c:24:10: fatal error: lib/cache.h: No such file or directory Regards Bjoern

8 let

3
3
0 0

Knot resolver module stats - query source ip - knot-resolver-users Digest, Vol 31, Issue 1

by Sýkora Milan

Hello Petr, This a good news, that query source IP would be planned in the future module version. I would like to answer your related notes like: - How many 'most frequent' IP addresses you want to get? - It is better to do the list as variable items, someone needs to list top 10 and someone 1000. - Should the number of addresses be configurable? yes - Do you consider query from the same IP but different port as 'different client' or not? (E.g. clients behind NAT?) In my case, it is not a topic function. - Should IP addresses be somehow tied to most frequent query names or not? yes, it will be better to know frequented queries to domain names. - Do you need a way to flush the table on fly? An option to clear statistic list and count it since a specific time range sound as a good idea. In the case when I´m not so familiar with Lua, where should be added your code part? Best regards, Milan Sýkora -----Original Message----- From: knot-resolver-users [mailto:knot-resolver-users-bounces@lists.nic.cz] On Behalf Of knot-resolver-users-request(a)lists.nic.cz Sent: Tuesday, July 24, 2018 12:00 PM To: knot-resolver-users(a)lists.nic.cz Subject: knot-resolver-users Digest, Vol 31, Issue 1 Send knot-resolver-users mailing list submissions to knot-resolver-users(a)lists.nic.cz To subscribe or unsubscribe via the World Wide Web, visit https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-resolver-users or, via email, send a message with subject or body 'help' to knot-resolver-users-request(a)lists.nic.cz You can reach the person managing the list at knot-resolver-users-owner(a)lists.nic.cz When replying, please edit your Subject line so it is more specific than "Re: Contents of knot-resolver-users digest..." Today's Topics: 1. Knot resolver module stats - query source ip (Sýkora Milan) 2. Re: Knot resolver module stats - query source ip (Petr Špaček) ---------------------------------------------------------------------- Message: 1 Date: Tue, 24 Jul 2018 07:32:52 +0000 From: Sýkora Milan <milan.sykora(a)cetin.cz> To: "knot-resolver-users(a)lists.nic.cz" <knot-resolver-users(a)lists.nic.cz> Subject: [knot-resolver-users] Knot resolver module stats - query source ip Message-ID: <365048c9e5ae48c699c079fee6343a5f(a)cewexch402.ad.cetin> Content-Type: text/plain; charset="iso-8859-2" Hello, I have your cool DNS resolver in version 2.3.0, I know that was released newest version. My question is - is it possible to explore the most frequented IP (queries source) in the module stats? Or exist any other way how to achieve it? Many thanks for your answer in the future, Best regards. Milan Sýkora Obsah této zprávy má výlučně komunikační charakter. Nepředstavuje návrh na uzavření smlouvy či na její změnu ani přijetí případného návrhu. Smlouvy či jejich změny jsou společností Česká telekomunikační infrastruktura a.s. uzavírány v písemné formě nebo v podobě a postupem podle příslušných všeobecných podmínek společnosti Česká telekomunikační infrastruktura a.s., a pokud jsou dohodnuty všechny náležitosti. Smlouvy jsou uzavírány oprávněnou osobou na základě písemného pověření. Smlouvy o smlouvě budoucí jsou uzavírány výhradně v písemné formě, vlastnoručně podepsané nebo s uznávaným elektronickým podpisem. Podmínky, za nichž Česká telekomunikační infrastruktura a.s. přistupuje k jednání o smlouvě a jakými se řídí, jsou dostupné zde<https://www.cetin.cz/cs/jak-cetin-vyjednava-o-smlouve>. The content of this message is intended for communication purposes only. It does neither represent any contract proposal, nor its amendment or acceptance of any potential contract proposal. Česká telekomunikační infrastruktura a.s. concludes contracts or amendments thereto in a written form or in the form and the procedure in accordance with relevant general terms and conditions of Česká telekomunikační infrastruktura a.s., if all requirements are agreed. Contracts are concluded by an authorized person entitled on the basis of a written authorization. Contracts on a future contract are concluded solely in a written form, self-signed or signed by means of an advanced electronic signature. The conditions under which Česká telekomunikační infrastruktura a.s. negotiates contracts and under which it proceeds are available here<https://www.cetin.cz/en/jak-cetin-vyjednava-o-smlouve>. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.nic.cz/pipermail/knot-resolver-users/attachments/20180724/cc47…> ------------------------------ Message: 2 Date: Tue, 24 Jul 2018 11:05:51 +0200 From: Petr Špaček <petr.spacek(a)nic.cz> To: knot-resolver-users(a)lists.nic.cz Subject: Re: [knot-resolver-users] Knot resolver module stats - query source ip Message-ID: <2a769de2-3b70-7d6f-5476-4bc7bd48fa8b(a)nic.cz> Content-Type: text/plain; charset=UTF-8 Hello, at the moment there is no built-in module with this statistics but it can be hacked around (see below). BTW we plan to to rework stats so it would be very valuable to get your requirements! To make sure future version contains what you need, can you specify what kind of data + what configuration you want to get? For example: - How many 'most frequent' IP addresses you want to get? - Should the number of addresses be configurable? - Do you consider query from the same IP but different port as 'different client' or not? (E.g. clients behind NAT?) - Should IP addresses be somehow tied to most frequent query names or not? - Do you need a way to flush the table on fly? For now you can use the following Lua config snippet to log client IP addresses. -- start of config snippet function LOG_IP(state, req) req = kres.request_t(req) if req.qsource == nil or req.qsource.addr == nil then -- internal request, no source return state end print('query from IP ' .. tostring(req.qsource.addr)) return -- continue with other policy rules end policy.add(policy.all(LOG_IP)) -- end of config snipper Output looks like this: "query from IP ::1#56927" This can be further processed by your log processing system to get aggregate numbers over all resolvers or alternativelly it can be extended using LRU library in Lua to get stats for single resolver. I hope it helps. Petr Špaček @ CZ.NIC On 24.7.2018 09:32, Sýkora Milan wrote: > Hello, > > > > I have your cool DNS resolver in version 2.3.0, I know that was > released newest version. > > > > My question is – is it possible to explore the most frequented IP > (queries source) in the module stats? Or exist any other way how to > achieve it? > > > > > > Many thanks for your answer in the future, > > Best regards. > > *Milan Sýkora*** ------------------------------ Subject: Digest Footer -- https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-resolver-users Please change Subject line before before you reply to a digest message! ------------------------------ End of knot-resolver-users Digest, Vol 31, Issue 1 ************************************************** Obsah této zprávy má výlučně komunikační charakter. Nepředstavuje návrh na uzavření smlouvy či na její změnu ani přijetí případného návrhu. Smlouvy či jejich změny jsou společností Česká telekomunikační infrastruktura a.s. uzavírány v písemné formě nebo v podobě a postupem podle příslušných všeobecných podmínek společnosti Česká telekomunikační infrastruktura a.s., a pokud jsou dohodnuty všechny náležitosti. Smlouvy jsou uzavírány oprávněnou osobou na základě písemného pověření. Smlouvy o smlouvě budoucí jsou uzavírány výhradně v písemné formě, vlastnoručně podepsané nebo s uznávaným elektronickým podpisem. Podmínky, za nichž Česká telekomunikační infrastruktura a.s. přistupuje k jednání o smlouvě a jakými se řídí, jsou dostupné zde<https://www.cetin.cz/cs/jak-cetin-vyjednava-o-smlouve>. The content of this message is intended for communication purposes only. It does neither represent any contract proposal, nor its amendment or acceptance of any potential contract proposal. Česká telekomunikační infrastruktura a.s. concludes contracts or amendments thereto in a written form or in the form and the procedure in accordance with relevant general terms and conditions of Česká telekomunikační infrastruktura a.s., if all requirements are agreed. Contracts are concluded by an authorized person entitled on the basis of a written authorization. Contracts on a future contract are concluded solely in a written form, self-signed or signed by means of an advanced electronic signature. The conditions under which Česká telekomunikační infrastruktura a.s. negotiates contracts and under which it proceeds are available here<https://www.cetin.cz/en/jak-cetin-vyjednava-o-smlouve>.

8 let

2
1
0 0

Knot resolver module stats - query source ip

by Sýkora Milan

Hello, I have your cool DNS resolver in version 2.3.0, I know that was released newest version. My question is - is it possible to explore the most frequented IP (queries source) in the module stats? Or exist any other way how to achieve it? Many thanks for your answer in the future, Best regards. Milan Sýkora Obsah této zprávy má výlučně komunikační charakter. Nepředstavuje návrh na uzavření smlouvy či na její změnu ani přijetí případného návrhu. Smlouvy či jejich změny jsou společností Česká telekomunikační infrastruktura a.s. uzavírány v písemné formě nebo v podobě a postupem podle příslušných všeobecných podmínek společnosti Česká telekomunikační infrastruktura a.s., a pokud jsou dohodnuty všechny náležitosti. Smlouvy jsou uzavírány oprávněnou osobou na základě písemného pověření. Smlouvy o smlouvě budoucí jsou uzavírány výhradně v písemné formě, vlastnoručně podepsané nebo s uznávaným elektronickým podpisem. Podmínky, za nichž Česká telekomunikační infrastruktura a.s. přistupuje k jednání o smlouvě a jakými se řídí, jsou dostupné zde<https://www.cetin.cz/cs/jak-cetin-vyjednava-o-smlouve>. The content of this message is intended for communication purposes only. It does neither represent any contract proposal, nor its amendment or acceptance of any potential contract proposal. Česká telekomunikační infrastruktura a.s. concludes contracts or amendments thereto in a written form or in the form and the procedure in accordance with relevant general terms and conditions of Česká telekomunikační infrastruktura a.s., if all requirements are agreed. Contracts are concluded by an authorized person entitled on the basis of a written authorization. Contracts on a future contract are concluded solely in a written form, self-signed or signed by means of an advanced electronic signature. The conditions under which Česká telekomunikační infrastruktura a.s. negotiates contracts and under which it proceeds are available here<https://www.cetin.cz/en/jak-cetin-vyjednava-o-smlouve>.

8 let

2
1
0 0

can not download a normal root.zone with Cache prefilling

by Yoshi Horigome

Hello, When Cache prefilling added from 2.3.0 is enabled, the following error occurs. https://knot-resolver.readthedocs.io/en/stable/modules.html#cache-prefilling /etc/knot-resolver # kresd -V Knot DNS Resolver, version 2.4.0 [prefill] downloading root zone... [prefill] saving root zone... [ 0][zimport] [zscanner] started; zone file `root.zone` [zscanner] line: 1: parse error; code: -986 ('owner is invalid') Segmentation fault (core dumped) If you check the contents of the downloaded file, it seems that something different file is being downloaded. /etc/knot-resolver # ls -l total 8704 -rw------- 1 root root 12533760 Jul 8 00:24 core.64 -rw-r----- 1 root root 3221225472 Jul 8 00:23 data.mdb -rw-r--r-- 1 1001 1001 2944 Jul 8 00:23 kresd.conf -rw-r----- 1 root root 8192 Jul 8 00:23 lock.mdb -rw-r--r-- 1 root root 832 Jul 7 07:35 root.keys -rw-r--r-- 1 root root 249 Jul 8 00:24 root.zone drwxr-x--- 2 root root 4096 Jun 13 12:56 tty /etc/knot-resolver # cat root.zone <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="https://www.internic.net/domain/root.zone">here</a>.</p> </body></html> Is this supposed behavior? Best regards.

8 let

3
5
0 0

Knot Resolver 2.4.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 2.4.0 has been released. Incompatible changes -------------------- - minimal libknot version is now 2.6.7 to pull in latest fixes (#366) Security -------- - fix a rare case of zones incorrectly downgraded to insecure status (!576) New features ------------ - TLS session resumption (RFC 5077), both server and client (!585, #105) (disabled when compiling with gnutls < 3.5) - TLS_FORWARD policy uses system CA certificate store by default (!568) - aggressive caching for NSEC3 zones (!600) - optional protection from DNS Rebinding attack (module rebinding, !608) - module bogus_log to log DNSSEC bogus queries without verbose logging (!613) Bugfixes -------- - prefill: fix ability to read certificate bundle (!578) - avoid turning off qname minimization in some cases, e.g. co.uk. (#339) - fix validation of explicit wildcard queries (#274) - dns64 module: more properties from the RFC implemented (incl. bug #375) Improvements ------------ - systemd: multiple enabled kresd instances can now be started using kresd.target - ta_sentinel: switch to version 14 of the RFC draft (!596) - support for glibc systems with a non-Linux kernel (!588) - support per-request variables for Lua modules (!533) - support custom HTTP endpoints for Lua modules (!527) Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v2.4.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.4.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.4.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v2.4.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

8 let, 1 měsíc

1
0
0 0

documentation of implemented DNS features / RFCs

by nusenu

Hi, is there somewhere a comprehensive list of implemented DNS protocol features / RFCs for knot-resolver? thanks, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

8 let, 1 měsíc

2
2
0 0

TA Sentinel

by Ulrich Wisser

Hi, today I wanted to try the ta sentinel functionality. Unfortunately do I not get the expected results. Maybe somebody could show me some example querries? I tried: dig +dnssec kskroll-sentinel-is-ta-20326.iis.se dig +dnssec kskroll-sentinel-not-ta-20326.iis.se dig +dnssec kskroll-sentinel-is-ta-19036.iis.se dig +dnssec kskroll-sentinel-not-ta-19036.iis.se All with the same result. No answer section. dig +dnssec iis.se iis.se. 60 IN A 91.226.37.214 iis.se. 60 IN RRSIG A 5 2 60 20180615103001 20180605103001 6150 iis.se. XAbt3nM5DmpsDsvZN6gRW94mGwTsCYpAQxurTJYp4FHZXaXt82o+3SMD ZEZjWsDswy3WsYp087Wx7Y4sH6HbuP0VYuwg1yLsBegrj6xNlcd5JarN wi8ZGbTytnDBG5rvpqwUp8fat3ZZ6kko4t7BtsD4cFzdL2xpw4MPbBKz p0s= What am I doing wrong? /Ulrich -- Ulrich Wisser ulrich(a)wisser.se

8 let, 2 měsíce

2
3
0 0

Statistics

by Ulrich Wisser

Hi, over the last weekend I did configure knot resolver on Turris Omnia to write statistics to my influxdb instance. Now that I have statistics, I am not entirely sure what all the data means. Everything under answer is easy to understand. But all data under cache is only 0, although answer.cached is not 0. Please find some stats below. I would be very grateful for some explanation what the data means. My next step would be to try to use RPZ funtionality. is there statistics for RPZ too? /Ulrich > stats.list() [answer.nxdomain] => 360546 [answer.100ms] => 64682 [answer.1500ms] => 2740 [answer.slow] => 12137 [answer.servfail] => 204137 [answer.250ms] => 84208 [answer.cached] => 430091 [answer.nodata] => 1533 [answer.1ms] => 462921 [answer.total] => 922236 [answer.10ms] => 58963 [answer.noerror] => 356015 [answer.50ms] => 195917 [answer.500ms] => 29794 [answer.1000ms] => 7525 [predict.learned] => 54 [predict.epoch] => 19 [predict.queue] => 520 [query.edns] => 152223 [query.dnssec] => 211 > cache.stats() [hit] => 0 [delete] => 0 [miss] => 0 [insert] => 0 -- Ulrich Wisser ulrich(a)wisser.se

8 let, 2 měsíce

2
5
0 0

Running systemd service and binding to privileged ports

by Ondrej Vaško

Hello knot-resolver users, I have a question about design of systemd service for knot-resolver. I installed knot from repository OpenSuse repository <https://software.opensuse.org//download.html?project=home%3ACZ-NIC%3Aknot-r…> on Ubuntu 16 and 18. The systemd service uses user *knot-resolver*. But this user cannot bind to unprivileged ports, so when I have configuration like below where I bind to network interface on privileged port and change user context, it fails with "*[system] bind to '10.20.30.118@853' Permission denied*": ``` net.listen({'10.20.30.118'}, 853, { tls = true }) user('knot-resolver', 'knot-resolver') ``` To fix this I changed User *knot-resolver* to *root* in systemd service. Now service starts to run as root, binds to network interface and then changes context. My question is, is this solution security wise fine? Why is the systemd service designed to run as user knot-resolver, when I guess many people will need to override this in order to use knot-resolver properly? What is the main idea? Or is there a different approach to overcome this (Such as linux capabilities)? Thank you for responses and please correct me in anything if I am wrong. Ondrej Vaško

8 let, 2 měsíce

2
1
0 0

Modifying policy rules of a running resolver instance

by Martin Sehnoutka

Hi, I would like to run Knot Resolver with DNS-over-TLS on my laptop, but I need to configure 'policy.FORWARD' whenever I connect to our corporate network. The information about new connection is provided by the Network Manager, that is not a problem, but then I need to configure the resolver somehow. I was thinking about creating a new configuration file and simply restarting the server, but it fails with "Start request repeated too quickly". Is there a way to add/remove policy rules "on the fly"? The HTTP/2 module seems like a good candidate for doing this. Can this module be used to accomplish this task? Best regards, Martin Sehnoutka PS: If there is anyone using dnssec-trigger, this would be similar, but less complicated. -- Martin Sehnoutka | Associate Software Engineer PGP: 5FD64AF5 UTC+1 (CET) RED HAT | TRIED. TESTED. TRUSTED.

8 let, 2 měsíce

3
7
0 0

How to use forwarding when recursion is failed?

by Ilya Evseev

Hi, Folks! I want to use GoogleDNS 8.8.x.x as fallback forwarder when domain's NS'es are down or inaccessible (for example, when network connectivity between me and NS is broken). Is it possible? policy.add(policy.all(policy.FORWARD({ '8.8.8.8', '8.8.4.4' }))) works well, but disables recursion at all. How to call it only after/when recursion is failed? WBR, Ilya

8 let, 2 měsíce

1
0
0 0

Knot Resolver 2.3.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 2.3.0 has been released. This is a security release that fixes CVE-2018-1110. We're also introducing a new mailing list, knot-resolver-announce. Only notifications about new releases or important announcements will be posted there. https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-resolver-announce Security -------- - fix CVE-2018-1110: denial of service triggered by malformed DNS messages (!550, !558, security!2, security!4) - increase resilience against slow lorris attack (security!5) Bugfixes -------- - validation: fix SERVFAIL in case of CNAME to NXDOMAIN in a single zone (!538) - validation: fix SERVFAIL for DS . query (!544) - lib/resolve: don't send unecessary queries to parent zone (!513) - iterate: fix validation for zones where parent and child share NS (!543) - TLS: improve error handling and documentation (!536, !555, !559) Improvements ------------ - prefill: new module to periodically import root zone into cache (replacement for RFC 7706, !511) - network_listen_fd: always create end point for supervisor supplied file descriptor - use CPPFLAGS build environment variable if set (!547) Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v2.3.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.3.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.3.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v2.3.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

8 let, 3 měsíce

1
0
0 0

RPM packaging issues

by Martin Sehnoutka

Hi, I have a fresh installation of the Knot Resolver on my Fedora 27: *Package version*: $ rpm -q knot-resolver knot-resolver-2.2.0-1.fc27.x86_64 but it does not work out of the box. The problem is, that the user "knot-resolver" cannot bind to a privileged port. Why is the systemd service file using knot-resolver user? It works just fine, when I remove the "User=" option from service file and add this line into the kres.conf file: user('knot-resolver', 'knot-resolver') The resulting process runs as knot-resolver and it binds successfully. Best regards, -- Martin Sehnoutka | Associate Software Engineer PGP: 5FD64AF5 UTC+1 (CET) RED HAT | TRIED. TESTED. TRUSTED.

8 let, 3 měsíce

2
3
0 0

Knot Resolver 2.2.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 2.2.0 has been released. New features ------------ - cache server unavailability to prevent flooding unreachable servers (Please note that caching algorithm needs further optimization and will change in further versions but we need to gather operational experience first.) Bugfixes -------- - don't magically -D_FORTIFY_SOURCE=2 in some cases - allow large responses for outbound over TCP - fix crash with RR sets with over 255 records Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v2.2.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.2.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.2.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v2.2.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

8 let, 4 měsíce

2
1
0 0

How to disable DNSSEC validation for specific domains

by Leonardo Brondani Schenkel

Hello, There is a website I need to use in a daily basis that uses DNSSEC, however their keys have expired which causes validation to fail. I have contacted their support but they failed to resolve the issue so far. Since I can resolve the name when using `dig +cd`, I was hoping I could configure `kresd` to skip validation when resolving that specific domain. It seems that I should be able to do so by using the `policies` module and the `FLAGS` action: https://knot-resolver.readthedocs.io/en/stable/modules.html#actions I am not sure with flag/flags to use. I inspected the source and tried the following: policy.add(policy.suffix(policy.FLAGS('DNSSEC_CD'),{todname('example.org.')})) But this apparently had no effect. I also tried without the trailing dot and played with other flags, but no success. Does anybody know which flag I could set to bypass DNSSEC validation for the specified domain? Or, if the policy module is not the way to achieve that goal, is there any other way? # kresd --version Knot DNS Resolver, version 1.5.1 Any help will be greatly appreciated, // Leonardo.

8 let, 5 měsíců

2
2
0 0

Can't build 2.1 on Ubuntu 16.04.4 LTS

by Paul Hoffman

Greetings. I want to build Knot 2.1 on a Ubuntu 16.04.4 LTS. However, the libknot from the packages is too old: Makefile:87: *** libknot >= 2.6.4 required. Stop. As compared to: libknot-dev/xenial,now 2.1.1-1build1 amd64 [installed] Is it possible to get the libknot package on Ubuntu 16.04.4 LTS updated soon? If not, how do I install the latest libknot by hand? --Paul Hoffman

8 let, 5 měsíců

4
6
0 0

Unsure on the kskroll-sentinel handling

by Paul Hoffman

Greetings. My kresd config file is: net.listen('192.241.207.161', 5364) trust_anchors.file = 'root.keys' modules.load('ta_sentinel') I wanted to test this with a zone I set up at this-is-signed.com. However, I'm getting a positive result back for both the is-ta and the not-ta records (it is properly giving me the SERVFAIL for the bogus record). Have I configured Knot Resolver incorrectly? For Knot 2.2.1, do I need a different form for the names in order to get the kskroll-sentinel effect to kick in? From the DNSOP WG mailing list traffic, I thought I needed the 4f66 tag, but could have misinterpreted that. --Paul Hoffman # dig @192.241.207.161 -p 5364 kskroll-sentinel-is-ta-4f66.this-is-signed.com a ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.241.207.161 -p 5364 kskroll-sentinel-is-ta-4f66.this-is-signed.com a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36153 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;kskroll-sentinel-is-ta-4f66.this-is-signed.com. IN A ;; ANSWER SECTION: kskroll-sentinel-is-ta-4f66.this-is-signed.com. 60 IN CNAME this-is-signed.com. this-is-signed.com. 60 IN A 192.241.207.161 ;; Query time: 283 msec ;; SERVER: 192.241.207.161#5364(192.241.207.161) ;; WHEN: Sun Feb 25 00:09:54 UTC 2018 ;; MSG SIZE rcvd: 105 # dig @192.241.207.161 -p 5364 kskroll-sentinel-not-ta-4f66.this-is-signed.com a ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.241.207.161 -p 5364 kskroll-sentinel-not-ta-4f66.this-is-signed.com a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14466 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;kskroll-sentinel-not-ta-4f66.this-is-signed.com. IN A ;; ANSWER SECTION: kskroll-sentinel-not-ta-4f66.this-is-signed.com. 60 IN CNAME this-is-signed.com. this-is-signed.com. 54 IN A 192.241.207.161 ;; Query time: 5 msec ;; SERVER: 192.241.207.161#5364(192.241.207.161) ;; WHEN: Sun Feb 25 00:10:00 UTC 2018 ;; MSG SIZE rcvd: 106 # dig @192.241.207.161 -p 5364 bogus.this-is-signed.com a ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.241.207.161 -p 5364 bogus.this-is-signed.com a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20810 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;bogus.this-is-signed.com. IN A ;; Query time: 9 msec ;; SERVER: 192.241.207.161#5364(192.241.207.161) ;; WHEN: Sun Feb 25 00:10:08 UTC 2018 ;; MSG SIZE rcvd: 42

8 let, 5 měsíců

2
2
0 0

Knot Resolver 2.1.1 and new package repositories

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 2.1.1 with a couple of bugfixes for caching and TLS forwarding has been released. We'd also like to announce our new upstream repository for latest stable packages for Debian, Ubuntu, CentOS, Fedora and Arch. Knot Resolver 2.1.1 is already available there. You can find instructions on how to use the repository in the updated download section on our website: https://www.knot-resolver.cz/download/ Bugfixes -------- - when iterating, avoid unnecessary queries for NS in insecure parent. This problem worsened in 2.0.0. (#246) - prevent UDP packet leaks when using TLS forwarding - fix the hints module also on some other systems, e.g. Gentoo. Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v2.1.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.1.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.1.1.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v2.1.1/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

8 let, 5 měsíců

1
0
0 0

Knot Resolver 2.1.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 2.1.0 is released. Incompatible changes -------------------- - stats: remove tracking of expiring records (predict uses another way) - systemd: re-use a single kresd.socket and kresd-tls.socket - ta_sentinel: implement protocol draft-ietf-dnsop-kskroll-sentinel-01 (our draft-ietf-dnsop-kskroll-sentinel-00 implementation had inverted logic) - libknot: require version 2.6.4 or newer to get bugfixes for DNS-over-TLS Bugfixes -------- - detect_time_jump module: don't clear cache on suspend-resume (#284) - stats module: fix stats.list() returning nothing, regressed in 2.0.0 - policy.TLS_FORWARD: refusal when configuring with multiple IPs (#306) - cache: fix broken refresh of insecure records that were about to expire - fix the hints module on some systems, e.g. Fedora (came back on 2.0.0) - build with older gnutls (conditionally disable features) - fix the predict module to work with insecure records & cleanup code Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v2.1.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.1.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.1.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v2.1.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

8 let, 5 měsíců

1
0
0 0

Knot Resolver: module view is not able to deal with cache

by Sakirnth Nagarasa

Hi, I am running knot-resolver version 2.0.0 and I would like to redirect (STUB) queries from a subnet to a specific nameserver. For that I created a view configuration for that subnet (see below). A query without being in that subnet caches the answer but unfortunately the cache overrides the answer when doing the same query inside the view. My configuration file looks like that: --- modules = { 'hints > iterate', 'policy > hints', 'view < cache' } view:addr('${SUBNET}', policy.suffix(policy.STUB('${IP}'), {todname('${DOMAIN_SUFFIX}')})) --- Testing procedure: 1) Try to resolve A record being in the special subnet. $kdig @${KNOT-RESOLVER} A www.${DOMAIN_SUFFIX} -> STUB works and answer is correct 2) Try to resolve A record without being in the special subnet. $kdig @${KNOT-RESOLVER} ${KNOT-RESOLVER} -> view is not triggerd and answer is correct 3) Try to resolve A record again within the special subnet. $kdig @${KNOT-RESOLVER} A www.${DOMAIN_SUFFIX} -> The answer is satisfied from cache, which is not the right answer. Is it even possible to do that? Best wishes, Sakirnth

8 let, 5 měsíců

2
1
0 0

Conditional forward with todname configuration

by Petr Špaček

Hello, I'm going to reply here instead of knot-dns-users. On 7.2.2018 03:24, Yoshi Horigome wrote: > Hello Jay, > > Is it ok to understand that it forwards to "192.168.168.1" which is the > local DNS when asking for localnet.mydomain.com > <http://localnet.mydomain.com>? > > If it is, perhaps, I think that setting should be done as follows. > > --If the request is from eng subnet > > if (view:addr('192.168.168.0/24' <http://192.168.168.0/24'>)) then > if (todname('localnet.mydomain.com > <http://localnet.mydomain.com>')) then > - policy.add(policy.suffix(policy.FORWARD('192.168.168.1'), > {todname('localnet.mydomain.com <http://localnet.mydomain.com>')})) > + policy.add(policy.suffix(policy.STUB('192.168.168.1'), > {{'\8localnet\8mydomain\3com'}})) > else > view:addr('192.168.168.0/24 <http://192.168.168.0/24>', > policy.FORWARD('68.111.106.68')) > > end > end First of all the use of `if` conditions above is incorrect. Examples of view configuration can be found here: http://knot-resolver.readthedocs.io/en/latest/modules.html#example-configur… Second part of view definition is basically a rule from policy module, which has examples here: http://knot-resolver.readthedocs.io/en/latest/modules.html#policy-examples I'm not sure I understood your request correctly, so I will provide snippets and let you to combine them together. -- forward all queries for subdomain localnet.mydomain.com to 192.168.168.1 policy.add(policy.suffix(policy.FORWARD('192.168.168.1'), {todname('localnet.mydomain.com')}) -- forward all queries from 192.168.168.0/24 to 68.111.106.68 view:addr('192.168.168.0/24', policy.all(policy.FORWARD('68.111.106.68'))) This needs to be tested as result will depend on order of modules. I can see that you have policy before view, so it might just work. Give it a try. Petr Špaček @ CZ.NIC > I understand that it is policy.STUB if it is version1, and policy.PASS > if it is version2. > > I am sorry if I made a mistake. > > > Best regards. > > Postscript: > It seems that knot resolver's mailing list has been created, so this may > be better. > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-resolver-users > > > 2018-02-07 4:46 GMT+09:00 Jay Remotti <jremotti(a)ontraport.com > <mailto:jremotti@ontraport.com>>: > > I'm getting started with knot resolver and am a bit unclear as to > how this config should be structured. > The result I'm looking for is to forward queries to resolver A if > the source is subnet A; unless the query is for the local domain if > so then query the local DNS. > > I've been working with the config below to accomplish this. However > I'm finding that this config will if the request does not match the > local todname and will use root hints if not but will not use the > FORWARD server. > > Ultimately, this server will resolve DNS for several subnets and > will forward queries to different servers based on the source subnet. > > Would someone mind pointing me in the right direction on this, please? > > for name, addr_list in pairs(net.interfaces()) do > net.listen(addr_list) > end > -- drop root > user('knot', 'knot') > -- Auto-maintain root TA > modules = { > 'policy', -- Block queries to local zones/bad sites > 'view', --view filters > 'hints', -- Load /etc/hosts and allow custom root hints > 'stats', > } > > > -- 4GB local cache for record storage > cache.size = 4 * GB > > --If the request is from eng subnet > > if (view:addr('192.168.168.0/24' <http://192.168.168.0/24'>)) then > if (todname('localnet.mydomain.com > <http://localnet.mydomain.com>')) then > policy.add(policy.suffix(policy.FORWARD('192.168.168.1'), > {todname('localnet.mydomain.com <http://localnet.mydomain.com>')})) > else > view:addr('192.168.168.0/24 <http://192.168.168.0/24>', > policy.FORWARD('68.111.106.68')) > > end > end > > > 855.ONTRAPORT > ontraport.com <https://ontraport.com> > ------------------------------------------------------------------------ > > Get a Demo <https://ontraport.com/demo>| Blog > <https://ontraport.com/blog>| Free Tools <https://ontraport.com/tools> > > > > -- > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users > <https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users>

8 let, 5 měsíců

1
0
0 0

Knot Resolver 2.0.0 feature release

by Vladimír Čunát

Dear Knot Resolver users, Knot Resolver 2.0.0 brings lots of changed code, including two bigger new features: aggressive cache and pipelined TLS forwarding. Incompatible changes -------------------- - systemd: change unit files to allow running multiple instances, deployments with single instance now must use `kresd(a)1.service` instead of `kresd.service`; see kresd.systemd(8) for details - systemd: the directory for cache is now /var/cache/knot-resolver - unify default directory and user to `knot-resolver` - directory with trust anchor file specified by -k option must be writeable - policy module is now loaded by default to enforce RFC 6761; see documentation for policy.PASS if you use locally-served DNS zones - drop support for alternative cache backends memcached, redis, and for Lua bindings for some specific cache operations - REORDER_RR option is not implemented (temporarily) New features ------------ - aggressive caching of validated records (RFC 8198) for NSEC zones; thanks to ICANN for sponsoring this work. - forwarding over TLS, authenticated by SPKI pin or certificate. policy.TLS_FORWARD pipelines queries out-of-order over shared TLS connection Beware: Some resolvers do not support out-of-order query processing. TLS forwarding to such resolvers will lead to slower resolution or failures. - trust anchors: you may specify a read-only file via -K or --keyfile-ro - trust anchors: at build-time you may set KEYFILE_DEFAULT (read-only) - ta_sentinel module implements draft ietf-dnsop-kskroll-sentinel-00, enabled by default - serve_stale module is prototype, subject to change - extended API for Lua modules Bugfixes -------- - fix build on osx - regressed in 1.5.3 (different linker option name) Full changelog: https://gitlab.labs.nic.cz/knot/knot-resolver/raw/v2.0.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.0.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-2.0.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v2.0.0/ --Vladimir

8 let, 6 měsíců

1
0
0 0

Re: [knot-resolver-users] [knot-dns-users] Knot Resolver 1.5.2 security release

by Daniel Kahn Gillmor

On Mon 2018-01-22 12:42:47 +0100, Vladimír Čunát wrote: > Knot Resolver 1.5.2 is a security release! > > Security > -------- > - fix CVE-2018-1000002: insufficient DNSSEC validation, allowing > attackers to deny existence of some data by forging packets. > Some combinations pointed out in RFC 6840 sections 4.1 and 4.3 > were not taken into account. Thanks for this report, Vladimír! Out of curiosity, are there any test suites available that exercise this particular attack? I'm trying to sort out a backported fix for the version of knot-resolver in debian stable (1.2.0) and enough of the codebase has changed that it's not as simple as just cherry-picking patches f90d27de49c9d3be0424d5d5457fb18df7d5c3f3 and d296e36eb554148f3d6f1f86e8f86ddec81de962, so i want to be sure that any attempted change actually fixes the problem. --dkg

8 let, 6 měsíců

2
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

knot-resolver-users