Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2023-09-28T04:48:14+02:00https://gitlab.nic.cz/knot/knot-resolver/-/issues/803additional2023-09-28T04:48:14+02:00Nikolay PavlovadditionalHello, how to activate additional section: ?Hello, how to activate additional section: ?https://gitlab.nic.cz/knot/knot-resolver/-/issues/801multiple manager instances not runnable in parallel2023-09-28T04:48:33+02:00Vladimír Čunátvladimir.cunat@nic.czmultiple manager instances not runnable in parallelMultiple manager instances are not runnable in parallel, even if no socket or path from configuration clashes, e.g. when testing without containers.
It's prevented by the `sd_notify` plugin hardcoding the name of abstract unix socket to...Multiple manager instances are not runnable in parallel, even if no socket or path from configuration clashes, e.g. when testing without containers.
It's prevented by the `sd_notify` plugin hardcoding the name of abstract unix socket to `knot-resolver-control-socket`.https://gitlab.nic.cz/knot/knot-resolver/-/issues/800DNS64 with IPv6-only (NAT64) resolver2023-09-28T04:48:58+02:00Karl GrubeDNS64 with IPv6-only (NAT64) resolverMaybe it is possible to configure Knot Resolver to support this, but I haven't seen it in the documentation. An example explanation of what I mean: https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver/
Basically it wou...Maybe it is possible to configure Knot Resolver to support this, but I haven't seen it in the documentation. An example explanation of what I mean: https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver/
Basically it would be useful to set up the resolver in a way that uses NAT64 for its own queries. That way one can avoid giving the resolvers IPv4 addresses directly. I think it would be a cool and useful feature.https://gitlab.nic.cz/knot/knot-resolver/-/issues/798OBS build for debian 122023-06-21T14:19:11+02:00Sergio CallegariOBS build for debian 12Hi, I am finding some confusion with the download documentation for debian:
- Main download page (https://www.knot-resolver.cz/download/) says to directly grab `knot-resolver-release.deb` from https://secure.nic.cz/files/knot-resolver/ ...Hi, I am finding some confusion with the download documentation for debian:
- Main download page (https://www.knot-resolver.cz/download/) says to directly grab `knot-resolver-release.deb` from https://secure.nic.cz/files/knot-resolver/ yet it is not clarified whether this will then automatically update in case of security issues, nor whether it is fine for platforms different from amd64;
- There also seems to be an OBS build factory (https://software.opensuse.org/download.html?project=home%3ACZ-NIC%3Aknot-resolver-latest&package=knot-resolver) however going there, there seems to be still no debian 12. Would using `debian_next` be fine for the time being?
Can the download/install info for debian be clarified a little? In case there is an official debian repo, it is important to know where, particularly for cases where debian needs to be updated from one version to another one (e.g. bullseye to bookworm).
Thanks.https://gitlab.nic.cz/knot/knot-resolver/-/issues/797DNS64 synthesis fails for tudelft.account.worldcat.org2024-03-11T22:27:53+01:00Ondřej CaletkaDNS64 synthesis fails for tudelft.account.worldcat.orgIn kresd version 5.6.0 with DNS64 module enabled, when resolving `tudelft.account.worldcat.org`, DNS64 does not kick in:
```
$ dig tudelft.account.worldcat.org a
; <<>> DiG 9.16.37 <<>> tudelft.account.worldcat.org a
;; global optio...In kresd version 5.6.0 with DNS64 module enabled, when resolving `tudelft.account.worldcat.org`, DNS64 does not kick in:
```
$ dig tudelft.account.worldcat.org a
; <<>> DiG 9.16.37 <<>> tudelft.account.worldcat.org a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52064
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;tudelft.account.worldcat.org. IN A
;; ANSWER SECTION:
tudelft.account.worldcat.org. 2459 IN CNAME emea.account.worldcat.org.
emea.account.worldcat.org. 28 IN A 193.240.184.98
$ dig tudelft.account.worldcat.org aaaa
; <<>> DiG 9.16.37 <<>> tudelft.account.worldcat.org aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63626
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 4 (Forged Answer): (BHD4: DNS64 synthesis)
;; QUESTION SECTION:
;tudelft.account.worldcat.org. IN AAAA
;; AUTHORITY SECTION:
worldcat.org. 653 IN SOA michelle.ns.cloudflare.com. dns.cloudflare.com. 2312413286 10000 2400 604800 1800
```
The zone in question is hosted by Cloudflare and has DNSSEC enabled so my wild guess is that it has something to do with the way Cloudflare signs negative answers.https://gitlab.nic.cz/knot/knot-resolver/-/issues/796docs: documentation for version 62024-03-19T12:23:57+01:00Aleš Mrázekdocs: documentation for version 6The goal is to have almost finished documentation for version 6.
Current documentation can be seen with [gitlab pages](https://www.knot-resolver.cz/documentation/latest). (generated on-demand from branches chosen by us)
# Step 1: Writi...The goal is to have almost finished documentation for version 6.
Current documentation can be seen with [gitlab pages](https://www.knot-resolver.cz/documentation/latest). (generated on-demand from branches chosen by us)
# Step 1: Writing the documentation
The structure of documentation is based on #776.
Some related comments can be found in !1377.
- [x] **Getting Started** section: installation, startup, initial configuration (examples)
- [ ] **Configuration** section: rewrite [pages about Lua configuration](https://knot.pages.nic.cz/knot-resolver/config-lua.html) with declarative configuration
- [ ] syntax and conventions (this might be already rewritten somewhere)
- [ ] modules
- [ ] networking
- [ ] performance and resiliency
- [ ] policy, access control and data manipulation
- [ ] logging, monitoring, diagnostics
- [ ] DNSSEC, data verification
- [ ] experimental features
- [ ] **Management** section
- [ ] HTTP API
- [x] kresctl utility
- [ ] **For operators** section
- [ ] upgrading to version 6
- [ ] **For developers** section
- [ ] internal architecture
- [x] **Deployment** guides
- [x] manual
- [x] systemd
- [x] docker
- [x] multiple instances
- [ ] extending the resolver
- [ ] create gitlab issues for all documentation sections that won't be fully completed with this MR
# Step 2: Collect and implement feedback
1. [ ] run spell checker
2. [ ] collect feedback from @vcunat
3. [ ] implement feedback
4. [ ] collect feedback from @llhotka
5. [ ] implement feedback
6. [ ] collect feedback from someone unrelated to the dev team (ODVR admins, someone random, ...)
7. [ ] implement feedback
Related !1377
Closes #7766.1.0Aleš MrázekAleš Mrázekhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/784manager: disallow relative paths in config2023-03-08T13:47:12+01:00Vaclav Sraiermanager: disallow relative paths in config- `rundir` should be only absolute
- all other paths should be relative to `rundir`
- kresctl can then accept `--config` and infers socket path from it- `rundir` should be only absolute
- all other paths should be relative to `rundir`
- kresctl can then accept `--config` and infers socket path from itVaclav SraierVaclav Sraierhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/778Tab completion for kresctl utility2023-01-10T19:25:43+01:00Aleš MrázekTab completion for kresctl utility- [ ] top-level options/args completion
- [ ] cmds name completion
- [ ] cmds options/args completion
- [ ] config path completion
- [ ] completion for different shells
- [ ] bash
- [ ] fish- [ ] top-level options/args completion
- [ ] cmds name completion
- [ ] cmds options/args completion
- [ ] config path completion
- [ ] completion for different shells
- [ ] bash
- [ ] fishhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/776docs: new sphinx documentation and its structure2023-06-06T16:23:45+02:00Aleš Mrázekdocs: new sphinx documentation and its structureThis issue is intended as a space for discussion about structure and content of the new sphinx documentation.
## New top level sections
Sections do not differ much from the original ones, rather the name is slightly modified for consis...This issue is intended as a space for discussion about structure and content of the new sphinx documentation.
## New top level sections
Sections do not differ much from the original ones, rather the name is slightly modified for consistency or better naming of the content inside.
- GETTING STARTED
- The resolver introduction (manager introduction and its (dis)advantages)
- Installation from packages
- The resolver systemd startup with manager and legacy daemon. First DNS query(kdig).
- Configuration: YAML config file, management API, kresctl utility, legacy Lua
- COMMON USE CASES
- The resolver common use cases with configuration and related info.
- Perhaps some guides HTTP API, kresctl, no-systemd, ansible, etc... (It would require better name for the section.)
- CONFIGURATION
- Structure will be very similar to the current except for added YAML configuration using `sphinx-tabs`. Mayme it will be slightly modified in favor of the new declarative configuration schema.
- FOR OPERATORS
- Information for users who already operate the resolver.
- upgrading guides, 5.x -> 6.0, release notes, ...
- FOR DEVELOPERS
- Information for developers and advanced users (lib, lua modules, Lua stuff)
- Building from source (apkg, meson, doc)
## Related comments:
- [In current docs, -rosetta would seem to fit well into the "Upgrading" section.](https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1351#note_268322)https://gitlab.nic.cz/knot/knot-resolver/-/issues/775Knot Resolver mishandles some cases when bad dns response packet is received2022-12-02T14:34:53+01:00mingkwindKnot Resolver mishandles some cases when bad dns response packet is receivedHi,
When Knot Resolver iteratively queries the malicious domain name server, it returns some malformed dns packets, and dnsmasq returns the packet to the client without proper verification, which will give the user a distrust or malicio...Hi,
When Knot Resolver iteratively queries the malicious domain name server, it returns some malformed dns packets, and dnsmasq returns the packet to the client without proper verification, which will give the user a distrust or malicious data. Other authoritative dns resolver have done correct verification.
There are two bugs below, you can start a fake domain name server locally and return specific data.
In order to easily reproduce these bugs, I turn off case randomlization by adding `policy.add(policy.all(policy.FLAGS({'NO_0X20'})))` to the `knot.conf`.
# First Bug
## Description
When the return answer type in the answer section dose not match the query class type, (for example, the query class type is *0x0001* and the return answer type is *0xdf01*), the answer packet is forwarded to the client and the RCODE of the Knot Resolver return packet is **0**.
## Expected/Actual behavior
Bind and Pdns return the response packet with a RCODE of **2**.
## Steps to reproduce
### 1、Turn on a fake name server and return a specific payload.
https://643684107.oss-cn-beijing.aliyuncs.com/knot-test/dns_server.py
https://643684107.oss-cn-beijing.aliyuncs.com/knot-test/response1
The details of the response packet(response1) from the fake server are as follows:
```
+ HEADER
+ transaction, flags, questions, answers, authority, additional:
+ 38 CB 81 80 00 01 00 01 00 02 00 01
+
+ QUESTION
+ 06 63 65 72 74 30 31 07 65 78 61 6D 70 6C 65 00 00 25 00 01
+
+ ANSWER
+ C0 0C 00 25 DF 01 00 00 00 00 00 55
+ FF FE FF FF FE 33 11 5C 6F 2F 64 FF 2B DE 74 C7
+ D0 80 AC E1 1F 97 AB D0 CB BF BC 82 F3 E3 92 24
+ B2 47 1E 14 68 22 58 29 FF 1B 11 E1 6A 2E 95 02
+ E1 C0 A0 D5 33 E1 8A 14 D6 D5 5F 48 24 AA 41 89
+ FA FF FD 75 53 A3 65 77 CD 23 11 E0 BC 69 3A CE
+ F8 A2 A6 09 A6
+
+ AUTHORITY
+ C0 13 00 02 00 01 00 00 00 00 00 06
+ 03 6E 73 34 C0 13
+ C0 13 00 02 00 01 00 00 00 00 00 06
+ 03 6E 73 32 C0 13
+
+ ADDITIONAL
+ 00 00 29 10 00 00 00 00 00 00 00
```
Download them and run this script like so:
```
python3 dns_server.py response1
```
### 2、Start Knot Resolver.
The configuration options are as follows:
```
-- 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', 5555, { kind = 'dns' })
--net.listen('127.0.0.1', 853, { kind = 'tls' })
--net.listen('127.0.0.1', 443, { kind = 'doh2' })
--net.listen('::1', 53, { kind = 'dns', freebind = true })
--net.listen('::1', 853, { kind = 'tls', freebind = true })
--net.listen('::1', 443, { kind = 'doh2' })
-- Load useful modules
modules = {
'policy',
'view',
}
modules.unload('priming')
trust_anchors.remove('.')
log_level('debug')
-- Cache size
-- cache.size = 100 * MB
-- view:addr('127.0.0.1/8', function (req, qry) return policy.PASS end)
policy.add(policy.all(policy.FLAGS({'NO_0X20'})))
policy.add(policy.all(policy.FLAGS({'NO_CACHE'})))
policy.add(policy.all(policy.STUB({'127.0.0.1'})))
```
Then run like this:
```
./kresd -c knot.conf -n
```
### 3、Send the corresponding dns request.
https://643684107.oss-cn-beijing.aliyuncs.com/knot-test/dns_request.py
https://643684107.oss-cn-beijing.aliyuncs.com/knot-test/request1
The details of the request packet(request1) from client are as follows:
```
+ HEADER
+ transaction, flags, questions, answers, authority, additional:
+ 31 32 01 00 00 01 00 00 00 00 00 00
+
+ QUESTION
+ 06 63 65 72 74 30 31 07 65 78 61 6D 70 6C 65 00 00 25 00 01
+
+ ANSWER
+
+ AUTHORITY
+
+ ADDITIONAL
```
Download them and run this script like so:
```
python3 dns_request.py request1 5555
```
# Second bug
## Description
When Knot Resolver iteratively queries the malicious domain name server as a DNS forwarder, the domain name server returns some malformed dns packets, (for exameple, the Addtional RRS is _0x0001_ but the number of records in the Addtional Records section is _2_ ), and Knot Resolver returns a correctly formatted packet with a RCODE of **0** to the client.
## Expected/Actual behavior
Bind and Pdns returns the response packet with a RCODE of **2**.
According to **RFC5625-6.3**(https://datatracker.ietf.org/doc/html/rfc5625#section-6.3), when dns resolver receives malformed packet, it SHOULD synthesise a suitable DNS error(i.e., SERVFAIL) response to the client.
## Steps to reproduce
### 1、Turn on a fake name server and return a specific payload.
https://643684107.oss-cn-beijing.aliyuncs.com/knot-test/dns_server.py
https://643684107.oss-cn-beijing.aliyuncs.com/knot-test/response3
The details of the response packet(response3) from the fake server are as follows:
```
+ 0000 31 32 81 80 00 01 00 00 00 02 00 01 06 63 65 72 .............cer
+ 0010 74 30 31 07 65 78 61 6D 70 6C 65 00 00 25 00 01 t01.example..%..
+ 0020 C0 0C 00 25 00 01 00 00 00 00 00 55 FF FE FF FF ...%.......U....
+ 0030 FE 33 11 5C 6F 2F 64 FF 2B DE 74 C7 D0 80 AC E1 .3.\o/d.+.t.....
+ 0040 1F 97 AB D0 CB BF BC 82 F3 E3 92 24 B2 47 1E 14 ...........$.G..
+ 0050 68 22 58 29 FF 1B 11 E1 6A 2E 95 02 E1 C0 A0 D5 h"X)....j.......
+ 0060 33 E1 8A 14 D6 D5 5F 48 24 AA 41 89 FA FF FD 75 3....._H$.A....u
+ 0070 53 A3 65 77 CD 23 11 E0 BC 69 3A CE F8 A2 A6 09 S.ew.#...i:.....
+ 0080 A6 C0 13 00 02 00 01 00 00 00 00 00 06 03 6E 73 ..............ns
+ 0090 34 C0 13 C0 13 00 02 00 01 00 00 00 00 00 06 03 4...............
+ 00A0 6E 73 32 C0 13 00 00 29 10 00 00 00 00 00 00 00 ns2....)........
```
Download them and run this script like so:
```bash
python3 dns_server.py response3
```
### 2、Start Knot Resolver.
The configuration options are as follows:
```
-- 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', 5555, { kind = 'dns' })
--net.listen('127.0.0.1', 853, { kind = 'tls' })
--net.listen('127.0.0.1', 443, { kind = 'doh2' })
--net.listen('::1', 53, { kind = 'dns', freebind = true })
--net.listen('::1', 853, { kind = 'tls', freebind = true })
--net.listen('::1', 443, { kind = 'doh2' })
-- Load useful modules
modules = {
'policy',
'view',
}
modules.unload('priming')
trust_anchors.remove('.')
log_level('debug')
-- Cache size
-- cache.size = 100 * MB
-- view:addr('127.0.0.1/8', function (req, qry) return policy.PASS end)
policy.add(policy.all(policy.FLAGS({'NO_0X20'})))
policy.add(policy.all(policy.FLAGS({'NO_CACHE'})))
policy.add(policy.all(policy.STUB({'127.0.0.1'})))
```
Then run like this:
```
./kresd -c knot.conf -n
```
### 3、Send the corresponding dns request.
https://643684107.oss-cn-beijing.aliyuncs.com/knot-test/dns_request.py
https://643684107.oss-cn-beijing.aliyuncs.com/knot-test/request3
The details of the request packet(request1) from client are as follows:
```
+ HEADER
+ transaction, flags, questions, answers, authority, additional:
+ 31 32 81 80 00 01 00 00 00 02 00 00
+
+ QUESTION
+ 06 63 65 72 74 30 31 07 65 78 61 6D 70 6C 65 00 00 25 00 01
+
+ ANSWER
+
+ AUTHORITY
+ C0 0C 00 25 00 01 00 00 00 00 00 55
+ FF FE FF FF FE 33 11 5C 6F 2F 64 FF 2B DE 74 C7
+ D0 80 AC E1 1F 97 AB D0 CB BF BC 82 F3 E3 92 24
+ B2 47 1E 14 68 22 58 29 FF 1B 11 E1 6A 2E 95 02
+ E1 C0 A0 D5 33 E1 8A 14 D6 D5 5F 48 24 AA 41 89
+ FA FF FD 75 53 A3 65 77 CD 23 11 E0 BC 69 3A CE
+ F8 A2 A6 09 A6
+ C0 13 00 02 00 01 00 00 00 00 00 06
+ 03 6E 73 34 C0 13
+
+ ADDITIONAL
```
Download them and run this script like so:
```bash
python3 dns_request.py request3 5555
```
Thankshttps://gitlab.nic.cz/knot/knot-resolver/-/issues/771Failed to allocate some buffers on AF_XDP ZC enabled Rx ring 0 (pf_q 0)2023-09-28T04:49:34+02:00CybertronicFailed to allocate some buffers on AF_XDP ZC enabled Rx ring 0 (pf_q 0)When enabling XDP on an interface, I am getting this error.
i40e 0000:03:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 0
i40e 0000:03:00.0: Failed to allocate some buffers on AF_XDP ZC enabled Rx ring 0 (pf_q 0)
Is the...When enabling XDP on an interface, I am getting this error.
i40e 0000:03:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 0
i40e 0000:03:00.0: Failed to allocate some buffers on AF_XDP ZC enabled Rx ring 0 (pf_q 0)
Is there a tunable I need to set somewhere?
please advise. thankshttps://gitlab.nic.cz/knot/knot-resolver/-/issues/770Ubuntu 22.04 - [system] error while loading config: /usr/lib/knot-resolver/kr...2022-10-17T10:24:16+02:00Pål SollieUbuntu 22.04 - [system] error while loading config: /usr/lib/knot-resolver/kres_modules/policy.lua:579: [poli] lua-cqueues required to watch and reload RPZ file (workdir '/var/lib/knot-resolver')After upgrading a box to Ubuntu 22.04 kresd started complaining about cqueues when I try to start it.
It errors out with the following message.
`[system] error while loading config: /usr/lib/knot-resolver/kres_modules/policy.lua:579: [p...After upgrading a box to Ubuntu 22.04 kresd started complaining about cqueues when I try to start it.
It errors out with the following message.
`[system] error while loading config: /usr/lib/knot-resolver/kres_modules/policy.lua:579: [poli] lua-cqueues required to watch and reload RPZ file (workdir '/var/lib/knot-resolver')`
I'm running 5.5.3
```
❯ kresd -V
Knot Resolver, version 5.5.3
```
I have the same config running on the same version of kresd on an Ubuntu 20.04 server, so I was expecting a straight upgrade to just work.
knot-resolver and all related packages were purged and reinstalled with `apt install knot-resolver`, which resulted in the following packages being installed.
```dns-root-data
knot-resolver
libdnssec8
libknot12
libluajit-5.1-2
libluajit-5.1-common
lua-basexx
lua-binaryheap
lua-bit32
lua-compat53
lua-cqueues
lua-fifo
lua-http
lua-lpeg
lua-lpeg-patterns
lua-luaossl
lua-psl
```
The packages are installed from following the instructions on `https://www.knot-resolver.cz/download/`
Source repo was updated after OS upgrade.
Looking at an strace, it seems to be able to read the cqueues.notify source file `strace -e trace=open,openat,close,read,write,connect,accept /usr/sbin/kresd -c /usr/lib/knot-resolver/distro-preconfig.lua -c /etc/knot-resolver/kresd.conf -n`
```openat(AT_FDCWD, "/etc/knot-resolver/kresd.conf.d/150-blacklist.conf", O_RDONLY) = 19
read(19, "-- Add blacklist zone\n\npolicy.ad"..., 8192) = 133
read(19, "", 4096) = 0
close(19) = 0
openat(AT_FDCWD, "/var/lib/knot-resolver/hblock.rpz", O_RDONLY) = 19
close(19) = 0
openat(AT_FDCWD, "/usr/lib/knot-resolver/cqueues/notify.lua", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/knot-resolver/cqueues/notify/init.lua", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "./cqueues/notify.lua", O_RDONLY) = -1 EACCES (Permission denied)
openat(AT_FDCWD, "/usr/share/luajit-2.1.0-beta3/cqueues/notify.lua", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/local/share/lua/5.1/cqueues/notify.lua", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/local/share/lua/5.1/cqueues/notify/init.lua", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/lua/5.1/cqueues/notify.lua", O_RDONLY) = 19
close(19) = 0
openat(AT_FDCWD, "/usr/share/lua/5.1/cqueues/notify.lua", O_RDONLY) = 19
read(19, "local loader = function(loader, "..., 8192) = 1364
read(19, "", 4096) = 0
```
Any suggestions for further debugging?https://gitlab.nic.cz/knot/knot-resolver/-/issues/768Cipher order and other minor security issues2022-10-09T11:48:48+02:00Zdeněk ŠvarcCipher order and other minor security issuesI suggest to work on compliance with security testing [testssl.sh](https://testssl.sh/). Especially cipher order, although this is a common testing flaw.
DoT test results follow:
```
Testing protocols via sockets except NPN+ALPN
SSL...I suggest to work on compliance with security testing [testssl.sh](https://testssl.sh/). Especially cipher order, although this is a common testing flaw.
DoT test results follow:
```
Testing protocols via sockets except NPN+ALPN
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 not offered
TLS 1.1 not offered
TLS 1.2 offered (OK)
TLS 1.3 offered (OK): final
NPN/SPDY not offered
ALPN/HTTP2 not offered
Testing cipher categories
NULL ciphers (no encryption) not offered (OK)
Anonymous NULL Ciphers (no authentication) not offered (OK)
Export ciphers (w/o ADH+NULL) not offered (OK)
LOW: 64 Bit + DES, RC[2,4] (w/o export) not offered (OK)
Triple DES Ciphers / IDEA not offered
Obsolete CBC ciphers (AES, ARIA etc.) offered
Strong encryption (AEAD ciphers) offered (OK)
Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4
PFS is offered (OK) TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES256-CCM TLS_AES_128_GCM_SHA256 TLS_AES_128_CCM_SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES128-CCM
Elliptic curves offered: prime256v1 secp384r1 secp521r1 X25519 X448
Finite field group: ffdhe2048 ffdhe3072 ffdhe4096 ffdhe6144 ffdhe8192
Testing server preferences
Has server cipher order? no (NOT ok)
Negotiated protocol TLSv1.3
Negotiated cipher TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) (limited sense as client will pick)
Negotiated cipher per proto (limited sense as client will pick)
ECDHE-ECDSA-AES256-GCM-SHA384: TLSv1.2
TLS_AES_256_GCM_SHA384: TLSv1.3
No further cipher order check has been done as order is determined by the client
Testing server defaults (Server Hello)
TLS extensions (standard) "EC point formats/#11" "session ticket/#35" "renegotiation info/#65281" "key share/#51" "supported versions/#43"
Session Ticket RFC 5077 hint 21600 seconds, session tickets keys seems to be rotated < daily
SSL Session ID support yes
Session Resumption Tickets: yes, ID: yes
TLS clock skew Random values, no fingerprinting possible
Signature Algorithm SHA256 with RSA
Server key size EC 384 bits
Server key usage Digital Signature
Server extended key usage TLS Web Server Authentication, TLS Web Client Authentication
Serial 047E...0D1D (OK: length 18)
Fingerprints SHA1 1A5...BAA
SHA256 53EB...DAB
Common Name (CN) --
subjectAltName (SAN) --
Issuer R3 (Let's Encrypt from US)
Trust (hostname) Ok via SAN (same w/o SNI)
Chain of trust Ok
EV cert (experimental) no
ETS/"eTLS", visibility info not present
Certificate Validity (UTC) 89 >= 30 days (2022-10-08 14:40 --> 2023-01-06 14:40)
# of certificates provided 3
Certificate Revocation List --
OCSP URI http://r3.o.lencr.org
OCSP stapling not offered
OCSP must staple extension --
DNS CAA RR (experimental) not offered
Certificate Transparency yes (certificate extension)
Testing vulnerabilities
Heartbleed (CVE-2014-0160) not vulnerable (OK), no heartbeat extension
CCS (CVE-2014-0224) not vulnerable (OK)
Ticketbleed (CVE-2016-9244), experiment. -- (applicable only for HTTPS)
ROBOT Server does not support any cipher suites that use RSA key transport
Secure Renegotiation (RFC 5746) supported (OK)
Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), potential DoS threat
CRIME, TLS (CVE-2012-4929) not vulnerable (OK) (not using HTTP anyway)
POODLE, SSL (CVE-2014-3566) not vulnerable (OK), no SSLv3 support
TLS_FALLBACK_SCSV (RFC 7507) No fallback possible (OK), no protocol below TLS 1.2 offered
SWEET32 (CVE-2016-2183, CVE-2016-6329) not vulnerable (OK)
FREAK (CVE-2015-0204) not vulnerable (OK)
DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host and port (OK)
no RSA certificate, thus certificate can't be used with SSLv2 elsewhere
LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2
BEAST (CVE-2011-3389) not vulnerable (OK), no SSL3 or TLS1
LUCKY13 (CVE-2013-0169), experimental potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS. Check patches
RC4 (CVE-2013-2566, CVE-2015-2808) no RC4 ciphers detected (OK)
Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength
Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384
x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20 256 TLS_CHACHA20_POLY1305_SHA256
xc02c ECDHE-ECDSA-AES256-GCM-SHA384 ECDH 253 AESGCM 256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
xc00a ECDHE-ECDSA-AES256-SHA ECDH 253 AES 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
xcca9 ECDHE-ECDSA-CHACHA20-POLY1305 ECDH 253 ChaCha20 256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
xc0ad ECDHE-ECDSA-AES256-CCM ECDH 253 AESCCM 256 TLS_ECDHE_ECDSA_WITH_AES_256_CCM
x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128 TLS_AES_128_GCM_SHA256
x1304 TLS_AES_128_CCM_SHA256 ECDH 253 AESCCM 128 TLS_AES_128_CCM_SHA256
xc02b ECDHE-ECDSA-AES128-GCM-SHA256 ECDH 253 AESGCM 128 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
xc009 ECDHE-ECDSA-AES128-SHA ECDH 253 AES 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
xc0ac ECDHE-ECDSA-AES128-CCM ECDH 253 AESCCM 128 TLS_ECDHE_ECDSA_WITH_AES_128_CCM
Could not determine the protocol, only simulating generic clients.
Running client simulations via sockets
Android 8.1 (native) TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
Android 9.0 (native) No connection
Android 10.0 (native) No connection
Android 11 (native) No connection
Android 12 (native) No connection
Java 7u25 No connection
Java 8u161 TLSv1.2 ECDHE-ECDSA-AES256-SHA, 256 bit ECDH (P-256)
Java 11.0.2 (OpenJDK) TLSv1.3 TLS_AES_128_GCM_SHA256, 256 bit ECDH (P-256)
Java 17.0.3 (OpenJDK) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
go 1.17.8 No connection
LibreSSL 2.8.3 (Apple) TLSv1.2 ECDHE-ECDSA-CHACHA20-POLY1305, 253 bit ECDH (X25519)
OpenSSL 1.0.2e TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
OpenSSL 1.1.0l (Debian) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 253 bit ECDH (X25519)
OpenSSL 1.1.1d (Debian) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
OpenSSL 3.0.3 (git) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
```https://gitlab.nic.cz/knot/knot-resolver/-/issues/763I cannot start kresd with the data.mdb that I generate through lua2022-09-01T11:17:12+02:00makeI cannot start kresd with the data.mdb that I generate through luaI generate a data.mdb and set the cache maximum size 1GB, it works well. But After I increase it to 50GB and generate a new data.mdb, there are some problems for me to start it.
![image](/uploads/446655285edea1962b270cb9d7fa1fc3/image.p...I generate a data.mdb and set the cache maximum size 1GB, it works well. But After I increase it to 50GB and generate a new data.mdb, there are some problems for me to start it.
![image](/uploads/446655285edea1962b270cb9d7fa1fc3/image.png)
And before I run kresd,
![捕获](/uploads/c2db07acd5f60eef81fc7f54ff0d1b22/捕获.PNG)
But after I run kresd,
![image](/uploads/1de5d306ac89983f96776d544f948884/image.png)https://gitlab.nic.cz/knot/knot-resolver/-/issues/761logging: consider adding startup and shutdown messages2022-10-10T11:45:32+02:00Matt Taggartlogging: consider adding startup and shutdown messagesI thought I was having a problem with my kresd.log as it wasn't getting updated. Then I realized mostly only errors get logged there and nothing is printed there on service start or stop. If I did a known bad query I could cause an updat...I thought I was having a problem with my kresd.log as it wasn't getting updated. Then I realized mostly only errors get logged there and nothing is printed there on service start or stop. If I did a known bad query I could cause an update there.
Please consider log entries on start/stop. I note that kres-cache-gc already does this on startup:
```kres-cache-gc[18916]: Knot Resolver Cache Garbage Collector, version 5.5.2```
so maybe something similar for kresd, and shutting down messages for both.
Thankshttps://gitlab.nic.cz/knot/knot-resolver/-/issues/754manager: datamodel: location for default values and constants2022-07-04T17:51:07+02:00Aleš Mrázekmanager: datamodel: location for default values and constantsWe should agree on location and definition of default values and constants. Some are currently defined in the configuration schema and some outside if it.
Issue follows the [comment](https://gitlab.nic.cz/knot/knot-resolver/-/merge_requ...We should agree on location and definition of default values and constants. Some are currently defined in the configuration schema and some outside if it.
Issue follows the [comment](https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1280#note_256358) in !1280.https://gitlab.nic.cz/knot/knot-resolver/-/issues/752Protocol layers2022-07-18T10:01:11+02:00Oto ŠťávaProtocol layersSee snippet $1448See snippet $1448https://gitlab.nic.cz/knot/knot-resolver/-/issues/744tests/packaging: failing tests2022-06-01T14:06:50+02:00Oto Šťávatests/packaging: failing testsI'm opening this issue so that we are tracking these test fails somewhere, but I'm not sure what we can do about them.
* `centos_7`
* outdated `luarocks` (is `2.x` required `3.x`) - cannot install `process`. I've tried to resolve th...I'm opening this issue so that we are tracking these test fails somewhere, but I'm not sure what we can do about them.
* `centos_7`
* outdated `luarocks` (is `2.x` required `3.x`) - cannot install `process`. I've tried to resolve this by explicitly installing older `process`, that does not require the new `luarocks`, but it attempts to install the new version anyway
* `centos_8`
* appstream fails to prepare internal mirrorlist
* no such command `config-manager`
* `fedora_31`
* outdated `knot` - is `3.0.1`, required `3.0.2`
* `leap_15.2`
* package conflicts
Related MR: !1304 (adds better logging for failing commands)https://gitlab.nic.cz/knot/knot-resolver/-/issues/737knot-resolver crashes regularly on macOS 12.3.1 (intel and arm version), sinc...2022-06-20T11:53:32+02:00owahknot-resolver crashes regularly on macOS 12.3.1 (intel and arm version), since updating to 5.5.0Hello team,
with the latest update to knot-resolver on macOS, I've been experiencing many crashes and I don't know how to debug them, as the log stays empty.
I would be working/browsing and suddenly pages do not load anymore, if I chec...Hello team,
with the latest update to knot-resolver on macOS, I've been experiencing many crashes and I don't know how to debug them, as the log stays empty.
I would be working/browsing and suddenly pages do not load anymore, if I check on the service as you can see below, it would be in an error state. Running `brew services restart knot-resolver` fixes the issue up until the next crash.
```
$ sudo brew services 14:10:29
Password:
Name Status User File
dbus none
emacs none
knot none
knot-resolver started root /Library/LaunchDaemons/homebrew.mxcl.knot-resolver.plist
stubby none
tor none
unbound none
$ sudo brew services 14:24:54
Password:
Name Status User File
dbus none
emacs none
knot none
knot-resolver error 6 root /Library/LaunchDaemons/homebrew.mxcl.knot-resolver.plist
stubby none
tor none
unbound none
```
This is the config file I am using. DNSSEC is disabled because nextdns already validates it for me, and it used to create random SERVFAILs.
```
-- Network interface configuration
net.listen('127.0.0.1', 53, { kind = 'dns' })
--net.listen('127.0.0.1', 853, { kind = 'tls' })
--net.listen('127.0.0.1', 443, { kind = 'doh2' })
--net.listen('::1', 53, { kind = 'dns', freebind = true })
--net.listen('::1', 853, { kind = 'tls', freebind = true })
--net.listen('::1', 443, { kind = 'doh2' })
-- Load useful modules
modules = {
'hints > iterate', -- Allow loading /etc/hosts or custom root hints
'stats', -- Track internal statistics
'predict', -- Prefetch expiring/frequent records
}
log_level('err')
policy.add(policy.all(policy.TLS_FORWARD({
{'45.90.28.0', hostname='<removed>.dns1.nextdns.io'},
{'2a07:a8c0::', hostname='<removed>.dns1.nextdns.io'},
{'45.90.30.0', hostname='<removed>.dns2.nextdns.io'},
{'2a07:a8c1::', hostname='<removed>.dns2.nextdns.io'}
})))
trust_anchors.remove('.')
-- Cache size
cache.size = 100 * MB
```
My log file only shows:
```
...
[system] Knot Resolver is tested on Linux, other platforms might exhibit bugs.
Please report issues to https://gitlab.nic.cz/knot/knot-resolver/issues/
Thank you for your time and interest!
[system] Knot Resolver is tested on Linux, other platforms might exhibit bugs.
Please report issues to https://gitlab.nic.cz/knot/knot-resolver/issues/
Thank you for your time and interest!
[system] Knot Resolver is tested on Linux, other platforms might exhibit bugs.
Please report issues to https://gitlab.nic.cz/knot/knot-resolver/issues/
Thank you for your time and interest!
```
I had changed the log-level to debug already once too, but it seems that it crashes so hard, it doesn't have a chance to write anything to the log .
Any advice on how to get some better reporting going for this issue? It also surprises me that no one else reported this issue after upgrading to 5.5.0. At first I assumed that my machine is at fault, but only a few days ago I setup a brand new machine (macbook with ARM processor) and the crashing behaviour is the same.https://gitlab.nic.cz/knot/knot-resolver/-/issues/731knot resolver in docker in production2022-03-24T11:18:22+01:00elandorrknot resolver in docker in productionHello all,
I'm looking to run the resolver in prod docker. The authoritative knot works well in docker - unfortunately I saw you deprecated forking for the resolver.
Your docker image is just for testing purposes as you say and does no...Hello all,
I'm looking to run the resolver in prod docker. The authoritative knot works well in docker - unfortunately I saw you deprecated forking for the resolver.
Your docker image is just for testing purposes as you say and does not include garbage collection or a watchdog replacement.
Would you please let us know the best practices for accomplishing this?
I suppose we need:
- multiple processes for prod(as far as I can tell, in dockerland they're meant to be spawned and handled by the parent, but kresd is separate)
- therefore supervisord (Which is not all that nice, as the auth. knotd is relatively lightweight and handles itself without any additional bloat. I strive to keep things as light as possible, and wouldn't want to start creating frankensteins for the resolver either, if at all avoidable.)
- a way to run kres-cache-gc automatically from inside the container (not externally pushed as that'd be a bit of a 'hackjob')
A standard, 'official' solution would benefit many. We'd appreciate your input!
I tried to research other people's solutions, but it looks as though nobody has published about it yet. Everyone just keeps using unbound, especially in docker. I'd really like to give kresd a try as knotd is great! It even seems to be smaller than unbound.
Have a great evening!