Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2022-04-08T16:13:59+02:00https://gitlab.nic.cz/knot/knot-resolver/-/issues/703Optimize network configuration for lower verbosity2022-04-08T16:13:59+02:00Vaclav SraierOptimize network configuration for lower verbosityWhen we look at a more complicated configuration, for example our ODVR, the network section is unnecessarily verbose. We should make it more concise...
Note: issue changed topic due to a developing discussion. The previous topic was rec...When we look at a more complicated configuration, for example our ODVR, the network section is unnecessarily verbose. We should make it more concise...
Note: issue changed topic due to a developing discussion. The previous topic was recreated under knot-resolver-manager#46Aleš MrázekAleš Mrázekhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/31tests: test binary using socket_wrapper (cwrap)2022-04-08T16:13:58+02:00Grigorii Demidovtests: test binary using socket_wrapper (cwrap)Write guide to using integration tests with arbitrary dns-servers.Write guide to using integration tests with arbitrary dns-servers.Grigorii DemidovGrigorii Demidovhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/17daemon: improve tty interface2022-04-08T16:13:58+02:00Ghost Userdaemon: improve tty interface### Problem
The CLI interface is based on reading stdin lines, not a TTY, so it doesn't support text cursor, tab completion or multiline commands.
### Expected outcome
Basically it should behave like a Lua interpreter, but inte...### Problem
The CLI interface is based on reading stdin lines, not a TTY, so it doesn't support text cursor, tab completion or multiline commands.
### Expected outcome
Basically it should behave like a Lua interpreter, but integrated in libuv loop.
There is already TTY code in libuv, and Lua interpreters around so we might want to reuse something.
* [ ] Real TTY, support for arrows
* [ ] Basic introspection
* [ ] Tab completion2015 Q3https://gitlab.nic.cz/knot/knot-resolver/-/issues/735XDP broken in kresd, since libknot 3.12022-04-04T10:40:29+02:00makeXDP broken in kresd, since libknot 3.1There are some problem for us to get reply from knot resolver after we use xdp.
The details are shown below:
```
OS: Ubuntu 21.14
kernel: 5.13.0-35-generic
network card: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (driver i...There are some problem for us to get reply from knot resolver after we use xdp.
The details are shown below:
```
OS: Ubuntu 21.14
kernel: 5.13.0-35-generic
network card: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (driver i40e)
knot-resolver:5.5.0-cznic.1
knot:3.1.1-cznic.1
```
`kresd.conf`
```
-- 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('10.0.0.2', 53, { kind = 'xdp' })
--net.listen('10.0.0.2', 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
}
-- Cache size
cache.size = 1024 * MB
```
`kresd@service`
```
# SPDX-License-Identifier: CC0-1.0
[Unit]
Description=Knot Resolver daemon
Documentation=man:kresd.systemd(7)
Documentation=man:kresd(8)
Wants=kres-cache-gc.service
Before=kres-cache-gc.service
Wants=network-online.target
After=network-online.target
Before=nss-lookup.target
Wants=nss-lookup.target
[Service]
Type=notify
Environment="SYSTEMD_INSTANCE=%i"
WorkingDirectory=/var/lib/knot-resolver
ExecStart=/usr/sbin/kresd -c /usr/lib/knot-resolver/distro-preconfig.lua -c /etc/knot-resolver/kresd.conf -n
ExecStopPost=/usr/bin/env rm -f "/run/knot-resolver/control/%i"
User=knot-resolver
Group=knot-resolver
CapabilityBoundingSet=CAP_NET_RAW CAP_NET_ADMIN CAP_SYS_ADMIN CAP_SYS_RESOURCE
AmbientCapabilities=CAP_NET_RAW CAP_NET_ADMIN CAP_SYS_ADMIN CAP_SYS_RESOURCE
TimeoutStopSec=10s
WatchdogSec=10s
Restart=on-abnormal
LimitNOFILE=524288
Slice=system-kresd.slice
[Install]
WantedBy=kresd.target
```
And after we start knot resolver through `systemctl start kresd@1.service`, and run `dig @10.0.0.2 www.baidu.com`, we
cannot get reply from knot resolver
```
root@master-ubuntu1:~# systemctl status kresd@1.service
● kresd@1.service - Knot Resolver daemon
Loaded: loaded (/lib/systemd/system/kresd@.service; disabled; vendor preset: enabled)
Active: active (running) since Tue 2022-03-22 14:32:34 CST; 4s ago
Docs: man:kresd.systemd(7)
man:kresd(8)
Main PID: 17028 (kresd)
Tasks: 1 (limit: 629145)
Memory: 21.2M
CPU: 106ms
CGroup: /system.slice/system-kresd.slice/kresd@1.service
└─17028 /usr/sbin/kresd -c /usr/lib/knot-resolver/distro-preconfig.lua -c /etc/knot-resolver/kresd.conf -n
3月 22 14:32:34 master-ubuntu1 systemd[1]: Starting Knot Resolver daemon...
3月 22 14:32:34 master-ubuntu1 kresd[17028]: libbpf: Kernel error message: XDP program already attached
3月 22 14:32:34 master-ubuntu1 systemd[1]: Started Knot Resolver daemon.
```
```
root@master-ubuntu1:~# dig @10.0.0.2 www.baidu.com
; <<>> DiG 9.16.15-Ubuntu <<>> @10.0.0.2 www.baidu.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
```https://gitlab.nic.cz/knot/knot-resolver/-/issues/729preventing manager from running multiple times with the same service prefix2022-03-31T16:46:13+02:00Vaclav Sraierpreventing manager from running multiple times with the same service prefix- We are guaranteed to have exclusive access to the working directory with changes in !1263
- However, in different configuration files, there could be still same systemd unit prefix, which would lead to weird failure.
Suggested fix - ...- We are guaranteed to have exclusive access to the working directory with changes in !1263
- However, in different configuration files, there could be still same systemd unit prefix, which would lead to weird failure.
Suggested fix - use some form of `hash($cwd)` as a tag instead of configurable prefix. I don't have any other idea as of now.https://gitlab.nic.cz/knot/knot-resolver/-/issues/710modelling: more readable error messages2022-03-31T16:37:05+02:00Vaclav Sraiermodelling: more readable error messagessee https://relaxng.org/jclark/derivative.html#Error_handling for inspiration
an implementation of that is this https://relaxng.org/jclark/jing.html
cc @llhotkasee https://relaxng.org/jclark/derivative.html#Error_handling for inspiration
an implementation of that is this https://relaxng.org/jclark/jing.html
cc @llhotkaVaclav SraierVaclav Sraierhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/618doh2: respond to invalid requests with proper status code2022-03-25T12:53:33+01:00Tomas Krizekdoh2: respond to invalid requests with proper status codeAs of version 5.2.0, DoH(2) only sends 200 OK HTTP status code, or closes the stream inside a connection without any status code. It would be cleaner to reply to at least some invalid requests, see test coverage `tests/config/doh2.test.l...As of version 5.2.0, DoH(2) only sends 200 OK HTTP status code, or closes the stream inside a connection without any status code. It would be cleaner to reply to at least some invalid requests, see test coverage `tests/config/doh2.test.lua` for commented out test cases.
Ignored queries (FORMERR) could also be handled, but it's outside the scope of this ticket, see #471https://gitlab.nic.cz/knot/knot-resolver/-/issues/619doh2: multiplexing DATA frames from multiple streams2022-03-21T16:18:59+01:00Tomas Krizekdoh2: multiplexing DATA frames from multiple streamsHTTP/2 can multiplex streams inside a single connection. If all the following conditions are met, one query won't be answered, even though it is a valid situation from HTTP/2 perspective.
- we have a large enough query to be split betwe...HTTP/2 can multiplex streams inside a single connection. If all the following conditions are met, one query won't be answered, even though it is a valid situation from HTTP/2 perspective.
- we have a large enough query to be split between multiple DATA frames (unlikely)
- we use POST
- the client sends two queries at the same time, interleaving their streams (probably quite unlikely)
Then, the frames on the connection could look as following:
```
HEADERS1 DATA1_1 HEADERS2 DATA2 DATA1_2
```
This is explicitly not supported, as it would require multiple session buffers for a single connection. All queries sent over POST must be serialized, e.g.:
```
HEADERS1 DATA1_1 DATA1_2 HEADERS2 DATA2
```
This does not affect GET, since all data is sent inside a HEADERS frame.https://gitlab.nic.cz/knot/knot-resolver/-/issues/727DNS64: PTR synthesis yields SERVFAIL for some cache contents2022-03-21T11:03:34+01:00Ondřej CaletkaDNS64: PTR synthesis yields SERVFAIL for some cache contentsSummary
-------
When cache is cold, PTR synthesis of DNS64 module works well. When cache gets populated by quering without DNS64 synthesis on, PTR synthesis stops working and SERVFAIL is returned instead.
Steps to reproduce
-----------...Summary
-------
When cache is cold, PTR synthesis of DNS64 module works well. When cache gets populated by quering without DNS64 synthesis on, PTR synthesis stops working and SERVFAIL is returned instead.
Steps to reproduce
------------------
```
# cat /etc/knot-resolver/kresd.conf
-- 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('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
'dns64',
'view',
}
-- Disable DNS64 for IPv4
view:addr('0.0.0.0/0', policy.all(policy.FLAGS('DNS64_DISABLE')))
-- Cache size
cache.size = 100 * MB
```
First query over IPv6 works as expected:
```
# kdig @::1 -x 64:ff9b::101:101 +noall +answer
1.0.1.0.1.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.9.f.f.4.6.0.0.ip6.arpa. 60 IN CNAME 1.1.1.1.in-addr.arpa.
1.1.1.1.in-addr.arpa. 1265 IN PTR one.one.one.one.
```
Query over IPv4, where DNS64 is disabled, also works properly with `NXDOMAIN`:
```
# kdig @127.0.0.1 -x 64:ff9b::101:101
;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 41713
;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 0
;; QUESTION SECTION:
;; 1.0.1.0.1.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.9.f.f.4.6.0.0.ip6.arpa. IN PTR
;; AUTHORITY SECTION:
ip6.arpa. 3600 IN SOA b.ip6-servers.arpa. nstld.iana.org. 2021111921 1800 900 604800 3600
```
After this query, PTR synthesis does not work anymore and yields `SERVFAIL`:
```
# kdig @::1 -x 64:ff9b::101:101
;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 25807
;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
;; QUESTION SECTION:
;; 1.0.1.0.1.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.9.f.f.4.6.0.0.ip6.arpa. IN PTR
```
Clearing the cache restores correct behavior for a while.https://gitlab.nic.cz/knot/knot-resolver/-/issues/670"map() error while connecting to control socket" regression [5.2.0, 5.2.1, 5....2022-03-16T16:42:56+01:00Jonathan Coetzee"map() error while connecting to control socket" regression [5.2.0, 5.2.1, 5.3.0]I've noticed this regression when using 5.2.0+ my ARMv7 (32-bit) on Docker on Raspberry Pi OS. My logs will fill up with hundreds of the following entries
map() error while connecting to control socket /srv/knot-resolver/data/contro...I've noticed this regression when using 5.2.0+ my ARMv7 (32-bit) on Docker on Raspberry Pi OS. My logs will fill up with hundreds of the following entries
map() error while connecting to control socket /srv/knot-resolver/data/control/9: socket:connect: Connection refused (ignoring this socket)
map() error while connecting to control socket /srv/knot-resolver/data/control/6: socket:connect: Connection refused (ignoring this socket)
map() error while connecting to control socket /srv/knot-resolver/data/control/9: socket:connect: Connection refused (ignoring this socket)
map() error while connecting to control socket /srv/knot-resolver/data/control/6: socket:connect: Connection refused (ignoring this socket)
map() error while connecting to control socket /srv/knot-resolver/data/control/9: socket:connect: Connection refused (ignoring this socket)
map() error while connecting to control socket /srv/knot-resolver/data/control/6: socket:connect: Connection refused (ignoring this socket)
These logs aren't present on 5.1.3. Please let me know what other information you need.https://gitlab.nic.cz/knot/knot-resolver/-/issues/722server selection: practical issues with some Microsoft domains2022-03-14T11:17:15+01:00Vladimír Čunátvladimir.cunat@nic.czserver selection: practical issues with some Microsoft domains With some Microsoft domains (outlook.com, office.com, office365.com) a small part of the nameservers is non-responsive, but kresd (sometimes) does not gracefully fall back to the other servers.
The same issue can surely happen with som... With some Microsoft domains (outlook.com, office.com, office365.com) a small part of the nameservers is non-responsive, but kresd (sometimes) does not gracefully fall back to the other servers.
The same issue can surely happen with someone else's names as well, but this set seems far the most commonly encountered in practice. It might be related to the NS server names being served by the same partially broken set.https://gitlab.nic.cz/knot/knot-resolver/-/issues/726manager: make sure we do not get stuck waiting for systemd2022-03-13T16:39:56+01:00Vaclav Sraiermanager: make sure we do not get stuck waiting for systemdIn some weird cases, manager can get stuck on waiting for systemd. Make sure this does not happen. If not possible, add timeout to detect these states and react accordingly.
The problem is due to races happening here (some of them are a...In some weird cases, manager can get stuck on waiting for systemd. Make sure this does not happen. If not possible, add timeout to detect these states and react accordingly.
The problem is due to races happening here (some of them are already solved by !1262):
https://gitlab.nic.cz/knot/knot-resolver/-/blob/manager/manager/knot_resolver_manager/kresd_controller/systemd/dbus_api.py#L61-108https://gitlab.nic.cz/knot/knot-resolver/-/issues/723manager: race condition with watchdog while starting workers2022-03-04T12:17:09+01:00Vaclav Sraiermanager: race condition with watchdog while starting workersHow to reproduce:
1. disable worker count limit
2. set worker count to 1000
3. run the manager
4. watch the world burn (like really, these steps will trash your system)
5. manager crashes (on my machine after starting 183 instances of k...How to reproduce:
1. disable worker count limit
2. set worker count to 1000
3. run the manager
4. watch the world burn (like really, these steps will trash your system)
5. manager crashes (on my machine after starting 183 instances of kresd)
I am guessing, that the same behavior could be reproduced by hammering manager with worker count change requests. But I haven't tested that.Vaclav SraierVaclav Sraierhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/432module API: add ability not to respond2022-02-28T11:58:55+01:00Petr Špačekmodule API: add ability not to respondIt would be useful for rate-limiting but we need to investigate how hard it would be, and if the difference is big enough when compared to an empty answer.It would be useful for rate-limiting but we need to investigate how hard it would be, and if the difference is big enough when compared to an empty answer.https://gitlab.nic.cz/knot/knot-resolver/-/issues/724Failing to bind to IPv6 link local addresses2022-02-23T03:16:56+01:00Jon PolomFailing to bind to IPv6 link local addressesKnot Resolver 5.4.4 appears to fail to bind to IPv6 link local addresses. This was experienced on an up-to-date Fedora 35 system. The following `net.listen()` invocations produce errors:
```
net.listen(net.diag, 53, { kind = 'dns', free...Knot Resolver 5.4.4 appears to fail to bind to IPv6 link local addresses. This was experienced on an up-to-date Fedora 35 system. The following `net.listen()` invocations produce errors:
```
net.listen(net.diag, 53, { kind = 'dns', freebind = true })
```
or, directly referencing the link local address for the diag interface:
```
net.listen('fe80::ae1f:6bff:fe6f:e818', 53, { kind = 'dns', freebind = true })
```
When asking kresd to listen on the link local address, the service fails to start and the following is observed in the log:
```
Feb 21 18:35:44 fedora kresd[21349]: [net ] bind to 'fe80::ae1f:6bff:fe6f:e818@53' (UDP): Invalid argument
Feb 21 18:35:44 fedora kresd[21349]: [system] error while loading config: error occurred here
stack traceback:
[C]: in function 'listen'
/etc/knot-resolver/kresd.conf:7: in main chunk
ERROR: net.listen() failed to bind (workdir '/var/lib/knot-resolver')
Feb 21 18:35:44 fedora systemd[1]: kresd@1.service: Main process exited, code=exited, status=1/FAILURE
Feb 21 18:35:44 fedora systemd[1]: kresd@1.service: Failed with result 'exit-code'.
Feb 21 18:35:44 fedora systemd[1]: Failed to start kresd@1.service - Knot Resolver daemon.
```
Interestingly, an IPv6 wildcard address does not result in the same error (kresd starts up just fine):
```
net.listen('::', 53, { kind = 'dns', freebind = true })
```
I was originally intending to configure kresd to listen on several named _interfaces_ (not v4 or v6 subnets) to improve resiliency in the event networks are re-assigned by using `net.listen(net.interface_name, ...)` in the config. Unfortunately this does not seem to work as it attempts to listen on the link local, producing an error and preventing the resolver process from starting.
I was initially unsure if IPv6 link local addresses were supported but noticed that #101 was opened several years ago about IPv6 LL addresses. I noticed that there was an MR referenced so I assume this is still supported? The documentation is not clear but it does not mention a limitation here either.https://gitlab.nic.cz/knot/knot-resolver/-/issues/450resurrect Coverity scan2022-02-22T11:47:26+01:00Petr Špačekresurrect Coverity scan... eventually. There is no rush, Clang's `scan-build` is doing a good job.... eventually. There is no rush, Clang's `scan-build` is doing a good job.Oto ŠťávaOto Šťávahttps://gitlab.nic.cz/knot/knot-resolver/-/issues/101Missing support for link-local addresses2022-02-22T00:48:32+01:00Ondřej CaletkaMissing support for link-local addresses1. Binding to [IPv6 link-local addresses](https://en.wikipedia.org/wiki/IPv6_address#Local_addresses) isn't possible in kresd (it isn't counted on).
2. Consequence: whenever I run `kresd` on Turris Omnia with forwarding turned on, it ...1. Binding to [IPv6 link-local addresses](https://en.wikipedia.org/wiki/IPv6_address#Local_addresses) isn't possible in kresd (it isn't counted on).
2. Consequence: whenever I run `kresd` on Turris Omnia with forwarding turned on, it crashes with following error:
`/usr/lib/kdns_modules/policy.lua:60: FORWARD target 'fe80::92f6:52ff:fef6:1ce4%eth1" is not a valid IP address`
Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/712DoH can't be configured2022-02-21T11:27:23+01:00Vladimír Čunátvladimir.cunat@nic.czDoH can't be configured`kind: doh` in config generates `kind = 'doh'` for lua, but that won't work (at least for now), and might be better to generate `'doh2'` even in case the alias will work in future.`kind: doh` in config generates `kind = 'doh'` for lua, but that won't work (at least for now), and might be better to generate `'doh2'` even in case the alias will work in future.https://gitlab.nic.cz/knot/knot-resolver/-/issues/699prometheus & graphite: aggregation and relaying of metrics in manager2022-02-19T10:42:49+01:00Vaclav Sraierprometheus & graphite: aggregation and relaying of metrics in managerfollowing [this discussion on Slack](https://cznic.slack.com/archives/C01EC5ADMB6/p1637675341005100)following [this discussion on Slack](https://cznic.slack.com/archives/C01EC5ADMB6/p1637675341005100)https://gitlab.nic.cz/knot/knot-resolver/-/issues/694docs: generating documentation from configuration datamodel2022-02-19T10:40:59+01:00Aleš Mrázekdocs: generating documentation from configuration datamodelLightweight documentation of every declarative configuration option should be generated automatically from our configuration schema. If something is changed in the configuration model, it will be automatically reflected in the documentat...Lightweight documentation of every declarative configuration option should be generated automatically from our configuration schema. If something is changed in the configuration model, it will be automatically reflected in the documentation.
It includes:
- structure defined by `SchemaNode` subclasses
- configuration options/fields names, types and default values
- docstrings of `SchemaNode` subclassesVaclav SraierVaclav Sraier