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

by martin.skalicky＠outlook.cz

Hi! I'm pretty new to Knot Resolver, previously i used Bind9 but wanted to try something else. However, i can't really figure out one problem, error: [system] error while loading config: /usr/lib/knot-resolver/kres_modules/policy.lua:43: bad argument #1 to 'kr_straddr_split' (cannot convert 'table' to 'const char *') (workdir '/var/lib/knot-resolver') I don't absolutely know, what am I doing wrong. Can you help me, please? Also, possible communication in Czech if better for someone? Here is my kresd.conf (my actual domains are replaced by domain1.tld, domain2.tld respectively): -- SPDX-License-Identifier: CC0-1.0 -- vim:syntax=lua:set ts=4 sw=4: -- Refer to manual: https://knot-resolver.readthedocs.org/en/stable/ -- Network interface configuration net.listen('127.0.0.1', 53, { kind = 'dns' }) net.listen('127.0.0.1', 853, { kind = 'tls' }) net.listen('::1', 53, { kind = 'dns', freebind = true }) net.listen('::1', 853, { kind = 'tls', freebind = true }) -- Load useful modules modules = { 'hints > iterate', -- Allow loading /etc/hosts or custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } -- Cache size cache.size = 100 * MB -- DNS Rebinding Configuration policy.add(policy.todnames({'domain2.tld', 'domain1.tld'}), policy.PASS) policy.add(policy.todnames({'domain2.tld', 'domain1.tld'}), policy.FORWARD({{'192.168.0.126'}}))

2 roky, 2 měsíce

3
3
0 0

Problems with DNSSEC .CZ

by Martin Doubrava

Hi colleagues, we are using knot-resolver as anycast resolvers for our region wide network. Everything works fine, but from saturday we are experiencing problems with zone .cz on one of our resolvers: lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [plan ][00000.00] plan 'www.seznam.cz.' type 'AAAA' uid [20220.00] lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [iterat][20220.00] 'www.seznam.cz.' type 'AAAA' new uid was assigned .01, parent uid .00 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => skipping exact RR: rank 060 (min. 030), new TTL -16225 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => trying zone: seznam.cz., NSEC3, hash db928b48 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 depth 1: hash 0sil3tll31qpi1iq50o2h3kjrmon169q lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 encloser error for www.seznam.cz.: range search found stale or insecure entry lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 depth 0: hash lg5rgspgqdoqqjko0u7fkpkakk8hgc1s lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 encloser error for seznam.cz.: range search found stale or insecure entry lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => trying zone: seznam.cz., NSEC3, hash f8ba757c lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 depth 1: hash s92e2vuk6k14pvqp4ubga1im9kpgff8a lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 encloser error for www.seznam.cz.: range search found stale or insecure entry lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 depth 0: hash 07u4nbhjigung96jklsqvtf6crqjojp8 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.01] => NSEC3 encloser error for seznam.cz.: range search found stale or insecure entry lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [zoncut][20220.01] found cut: cz. (rank 002 return codes: DS 0, DNSKEY -116) lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [plan ][20220.01] plan 'cz.' type 'DNSKEY' uid [20220.02] lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [iterat][20220.02] 'cz.' type 'DNSKEY' new uid was assigned .03, parent uid .01 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.03] => skipping exact RR: rank 060 (min. 030), new TTL -14979 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.03] => trying zone: cz., NSEC3, hash 20b5ab23 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.03] => NSEC3 depth 0: hash gurgi3ems8m3ts3pvppubu3hhqkivt3l lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.03] => NSEC3 encloser error for cz.: range search found stale or insecure entry lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [cache ][20220.03] => skipping zone: cz., NSEC, hash 0;new TTL -123456789, ret -2 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [select][20220.03] => id: '03706' choosing from addresses: 0 v4 + 0 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is OK lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [select][20220.03] => id: '03706' no suitable transport, zone cut: 'cz.' lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [iterat][20220.03] 'cz.' type 'DNSKEY' new uid was assigned .04, parent uid .01 lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [select][20220.04] => id: '28359' choosing from addresses: 0 v4 + 0 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is OK lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [select][20220.04] => id: '28359' no suitable transport, zone cut: 'cz.' lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [resolv][20220.04] AD: request NOT classified as SECURE lis 27 12:44:19 doubrava-dns-lito-02 kresd[9742]: [resolv][20220.01] finished in state: 8, queries: 1, mempool: 16400 B Version of knot-resolver: 5.7.0-cznic.1 When i turn off DNSSEC with trust_anchors.remove('.') and then turn it on everything works, but only for day or so. Other machines are working seamlessly. What we are doing here wrong? Thank you! -- Best regards Bc. Martin Doubrava CEO _______________________________ DOUBRAVA.NET s.r.o. Náklo 178, 783 32 Náklo Mobil: +420 771 280 361 Technická podpora: +420 776 778 173 Office: +420 588 884 000 E-mail: martin(a)doubrava.net WWW: http://www.doubrava.net Najdete nás i na facebooku: http://www.facebook.com/doubravanet

2 roky, 2 měsíce

2
3
0 0

Accessing DoH headers in Lua

by Blažej Krajňák

Hi there, please, can anyone move me forward? I want to implement new stats counter for DoH requests with “Chrome” in "user-agent" header. I don’t know how to iterate “query.request.qsource.headers”. I have tried: function count_chrome_doh() return function (state, query) if query.request.qsource.flags.http then for k, v in ipairs(query.request.qsource.headers) do if v.name == 'user-agent' and v.value == 'Chrome' then if stats.get('request.agent.chrome') then stats['request.agent.chrome'] = stats.get('request.agent.chrome') + 1 else stats['request.agent.chrome'] = 1 end return nil end end end return nil end end policy.add(count_chrome_doh()) but it falls with error "'struct 322' has no '__ipairs’ metamethod” Thanks! Blažej

2 roky, 5 měsíců

2
3
0 0

Best way to implement kresd to filter by listening interface

by oui.mages_0w＠icloud.com

Hello, What would be the best way to implement the following with kresd? The device used has a 2 core cpu. It has 3 (listening) ip addresses, for example: 10.2.3.4, 2001:0DB8:123::1 and 2001:0DB8:123::64 I want to have kresd to listen to: – 10.2.3.4 and 2001:0DB8:123::1 and do a dns resolution using UDP (53), TLS and HTTPS (the question is not about these settings). – 2001:0DB8:123::64 and use the same settings as above, but adding the dns64 module and resolution (only for requests made to 2001:0DB8:123::64). Having 2 cores, I have 2 identical instances; should I differentiate them and have one for dns64 and one without? or could I have 2 identical instances with a shared configuration file allowing to use dns64 or not depending on the listening ip? Or 4 instances (2 identical for dns64, 2 identical without, to have a spare of each config)? The options with view: are good to filter or do actions depending on the source ip, the queried domain or even the resolved ip (destination), but nothing about the ip used to reach the resolver (the listening address). Thank you.

2 roky, 5 měsíců

1
0
0 0

Accessing DoH headers in Lua

by Blažej Krajňák

Hi there, please, can anyone move me forward? I want to implement new stats counter for DoH requests with “Chrome” in "user-agent" header. I don’t know how to iterate “query.request.qsource.headers”. I have tried: function count_chrome_doh() return function (state, query) if query.request.qsource.flags.http then for k, v in ipairs(query.request.qsource.headers) do if v.name == 'user-agent' and v.value == 'Chrome' then if stats.get('request.agent.chrome') then stats['request.agent.chrome'] = stats.get('request.agent.chrome') + 1 else stats['request.agent.chrome'] = 1 end return nil end end end return nil end end policy.add(count_chrome_doh()) but it falls with error "'struct 322' has no '__ipairs’ metamethod” Thanks! Blažej

2 roky, 5 měsíců

1
0
0 0

Knot Resolver 5.7.0

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.7.0 has been released! Security - avoid excessive TCP reconnections in a few more cases Like before, the remote server had to behave nonsensically in order to inflict this upon itself, but it might be abusable for DoS. We thank Ivan Jedek from OryxLabs for reporting this. Improvements - forwarding mode: tweak dealing with failures from forwarders, in particular prefer sending CD=0 upstream (!1392) Bugfixes - fix unusual timestamp format in debug dumps of records (!1386) - adjust linker options; it should help less common platforms (!1384) - hints module: fix names inside home.arpa. (!1406) - EDNS padding (RFC 8467) compatibility with knot-dns 3.3 libs (!1422) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.7.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.7.0/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

2 roky, 5 měsíců

1
0
0 0

PID file path

by snowmailer＠gmail.com

Is there any way to write PID file to /var/run or so with knot-resolver? I can't find any info in documentation about it.

2 roky, 7 měsíců

2
1
0 0

Knot Resolver - redirect wildcard domain

by Milan Jeskynka Kazatel

Hello, could you please help me with knot resolver configuration in the case when I need to redirect each variation for the domain to some address. e.g. www.example.com, m.example.com, domain.example.com ... like wildcard record *.example.com 10.0.0.50 In my configuration is it handeled by file with static records -- load static records hints.add_hosts('/etc/knot-resolver/static_records.txt') which contains address to be redirected and the domain. 10.0.0.50 1xbet.com 10.0.0.50 thelotter.com 10.0.0.50 webmoneycasino.com 10.0.0.50 betworld.com 10.0.0.50 bosscasino.eu 10.0.0.50 sportingbull.com But I´m not able to handle the correct syntax for a wildcard domain redirection. Best regards, -- Smil Milan Jeskyňka Kazatel

2 roky, 7 měsíců

3
7
0 0

Setting up to use the OpenNIC root zone

by Ed V.

Hoping someone can help... Built Knot Resolver v5.6.0 from source. It works and resolves correctly for "regular" TLDs. However, I would like to point it to OpenNIC for resolution /forwarding so that I can resolve the expanded /alternative TLDs. Default configuration with: policy.add(policy.all( policy.FORWARD( {'2001:19f0:b001:379:5400:3ff:fe68:1cc6', '138.197.140.189', '2600:3c04::f03c:93ff:febd:be27', '45.61.49.203'}))) and it fails to find "grep.geek" using the standard root zone /hints: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22871 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;grep.geek. IN A ;; AUTHORITY SECTION: . 86077 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2023050902 1800 900 604800 86400 So I checked the Documentation site and found "hints.root" which theoretically will override any other root hints. Using the OpenNIC root zone file (downloads as "db.root") I set: hints.root ({ ['ns13.opennic.glue.'] = { '2a01:4f8:192:43a5::2', '144.76.103.143' } }) in kresd.conf. Still no joy - "grep.geek" is NXDOMAIN from a.root-servers.net again. Any thoughts? Things I might have missed along the way?

2 roky, 9 měsíců

3
5
0 0

DoH connection closed after 10 seconds

by Blažej Krajňák

Hello, it's me again :) I just want to make sure if behaviour of Knot Resolver is correct. I implemented DDR mechanism to discover DoH / DoT DNS servers. My Macbook with Ventura successfully discovered DoH server and started to use it. But: Knot Resolver sends 10 seconds after establishing FIN,ACK packet and connection is correctly closed. From this moment, Macbook starts to use DNS over UDP again and will retry DoH connection after 10-30s later. Then it uses DoH server again for 10 seconds .... Is this behaviour correct? Should Macbook sends some keepalive messages to prevent connection closing? Or should Macbook reopen DoH connection more quickly? Thanks, Blažej

2 roky, 11 měsíců

2
3
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

knot-resolver-users