Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2020-11-16T12:31:57+01:00https://gitlab.nic.cz/knot/knot-resolver/-/issues/491how can i run the lua cache test?2020-11-16T12:31:57+01:00beckhamaaahow can i run the lua cache test?**i want to insert RR to cache by lua script, but i don't know how can i invoke? there is the source in the directory: /tests/config/cache.test.lua**
`-- test access to cache through context
local function test_context_cache()
local c ...**i want to insert RR to cache by lua script, but i don't know how can i invoke? there is the source in the directory: /tests/config/cache.test.lua**
`-- test access to cache through context
local function test_context_cache()
local c = kres.context().cache
is(type(c), 'cdata', 'context has a cache object')
local s = c.stats
isnt(s.read and s.read_miss and s.write, 'context cache stats works')
-- insert a record into cache
local rdata = '\1\2\3\4'
local rr = kres.rrset('\3com\0', kres.type.A, kres.class.IN, 66)
rr:add_rdata(rdata, #rdata)
local s_write = s.write
ok(c:insert(rr, nil, 0, 0), 'cache insertion works')
ok(c:commit(), 'cache commit works')
isnt(s.write, s_write, 'cache insertion increments counters')
end`
**i invoke it when the kresd start,suffer the error:**
`modules = { 'insert' }
0
1
error: ERROR: Function not implemented
stack traceback:
[C]: in function 'get'
.../local/kr/lib/x86_64-linux-gnu/knot-resolver/sandbox.lua:251: in function '__index'
...b/x86_64-linux-gnu/knot-resolver/kres_modules/insert.lua:99: in function 'test_context_cache'
...b/x86_64-linux-gnu/knot-resolver/kres_modules/insert.lua:108: in main chunk
[C]: at 0x7f28bc6addf0
[C]: in function 'load'
.../local/kr/lib/x86_64-linux-gnu/knot-resolver/sandbox.lua:147: in function '__newindex'
.../local/kr/lib/x86_64-linux-gnu/knot-resolver/sandbox.lua:300: in function '__newindex'
[string "modules = { 'insert' }"]:1: in main chunk
ERROR: No such file or directory
stack traceback:
[C]: in function 'load'
.../local/kr/lib/x86_64-linux-gnu/knot-resolver/sandbox.lua:147: in function '__newindex'
.../local/kr/lib/x86_64-linux-gnu/knot-resolver/sandbox.lua:300: in function '__newindex'
[string "modules = { 'insert' }"]:1: in main chunk
`https://gitlab.nic.cz/knot/knot-resolver/-/issues/487dnssec and PTR zones in knot dns resolver2019-07-16T13:39:29+02:00signupforacommentdnssec and PTR zones in knot dns resolverHi,
maybe first the setup. Running a Debian Jessie / Stretch and using NSD as nameserver. NSD serves a number of purely internal zones, e.g. "mydomain.dmz" and "mydomain.pub" and so on.
Then installing knot dns resolver from the reposito...Hi,
maybe first the setup. Running a Debian Jessie / Stretch and using NSD as nameserver. NSD serves a number of purely internal zones, e.g. "mydomain.dmz" and "mydomain.pub" and so on.
Then installing knot dns resolver from the repository you provide and get it running, e.g. by a config like:
```
--
-- Bind works well
--
net = { '127.0.0.1', '::1' }
net.listen ( net.eth0 )
user ( 'bind', 'bind' )
cache.size = 25*MB
modules = {
'hints',
'policy',
'view'
}
cache.open (25 * MB, 'lmdb:///var/run/knot-resolver')
cache.size = 25 * MB
trust_anchors.add_file ('/usr/share/dns/root.key', 'readonly=true')
modules = {
'hints',
'policy',
'view'
}
LocalDomains = policy.todnames ({
'example.dmz',
'example.pub',
'10.168.192.in-addr.arpa',
'11.168.192.in-addr.arpa',
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.3.a.2.e.4.1.8.8.0.4.d.f.ip6.arpa',
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0.3.a.2.e.4.1.8.8.0.4.d.f.ip6.arpa'
})
trust_anchors.set_insecure ({
'10.168.192.in-addr.arpa',
'11.168.192.in-addr.arpa',
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.3.a.2.e.4.1.8.8.0.4.d.f.ip6.arpa',
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0.3.a.2.e.4.1.8.8.0.4.d.f.ip6.arpa' })
trust_anchors.add_file ('/etc/nsd/ksk/Kexample.dmz.key', readonly)
trust_anchors.add_file ('/etc/nsd/ksk/Kexample.pub.key', readonly)
policy.add (
policy.suffix (
policy.FORWARD ({ '192.168.10.1@5353', '192.168.10.2@5353' }), LocalDomains
)
)
policy.add (
policy.all (
policy.FORWARD ({ '8.8.8.8', '8.8.4.4' })
)
)
```
So far so good. The keys are created with "ldns-keygen -a RSASHA256 -b 2048 -k example.com".
Doing a "dig" on some host, everything works as expected and I get a signed response. Doing a PTR dig, everything works well and I get a non-signed response. Doing a PTR dig on the IPv6, I get a "SERVFAIL" by knot dns resolver.
Doing the PTR IPv6 dig directly on NSD, I get a response.
E.g.
```
dig something.example.com
; <<>> DiG 9.14.3 <<>> something.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22849
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;something.example.com. IN A
;; ANSWER SECTION:
something.example.com. 251185 IN A 192.168.11.5
;; Query time: 1 msec
;; SERVER: 192.168.10.1#53(192.168.10.1)
;; WHEN: lun. juil. 15 19:56:35 CEST 2019
;; MSG SIZE rcvd: 63
dig -t PTR 5.11.168.192.in-addr.arpa
; <<>> DiG 9.14.3 <<>> -t PTR 5.11.168.192.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34131
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;5.11.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
5.11.168.192.in-addr.arpa. 251159 IN PTR something.example.com.
;; Query time: 1 msec
;; SERVER: 192.168.10.1#53(192.168.10.1)
;; WHEN: lun. juil. 15 19:56:58 CEST 2019
;; MSG SIZE rcvd: 86
dig -t PTR 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0.3.a.2.e.4.1.8.8.0.4.d.f.ip6.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45840
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0.3.a.2.e.4.1.8.8.0.4.d.f.ip6.arpa. IN PTR
;; Query time: 2 msec
;; SERVER: 192.168.10.1#53(192.168.10.1)
;; WHEN: lun. juil. 15 19:59:41 CEST 2019
;; MSG SIZE rcvd: 101
dig -t PTR 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0.3.a.2.e.4.1.8.8.0.4.d.f.ip6.arpa @192.168.10.1 -p5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40316
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0.3.a.2.e.4.1.8.8.0.4.d.f.ip6.arpa. IN PTR
;; ANSWER SECTION:
5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0.3.a.2.e.4.1.8.8.0.4.d.f.ip6.arpa. 259200 IN PTR radius.arrishq.dmz.
;; AUTHORITY SECTION:
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0.3.a.2.e.4.1.8.8.0.4.d.f.ip6.arpa. 259200 IN NS ns1.example.dmz.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0.3.a.2.e.4.1.8.8.0.4.d.f.ip6.arpa. 259200 IN NS ns2.example.dmz.
;; Query time: 1 msec
;; SERVER: 192.168.10.1#5353(192.168.10.1)
;; WHEN: lun. juil. 15 20:03:24 CEST 2019
;; MSG SIZE rcvd: 169
```
Disabling dnssec in the knot dns resolver configuration and changing nothing else, thing start working as expected.
The used version is "4.1.0", with the only change that I manually overwrite the systemd dependency because I'm using a different init system.
Loading kresd directly via CLI:
```
[system] bind to 'fe80::abcd:edfg:hijk:lmno@53' (UDP): Invalid argument
[ ta ] warning: overriding previously set trust anchors for .
[system] interactive mode
> [ta_update] refreshing TA for example.dmz.
[ta_update] refreshing TA for example.pub.
[ta_update] key: 49312 state: Valid
[ta_update] next refresh for example.dmz. in 1 hours
[ta_update] key: 14881 state: Valid
[ta_update] next refresh for example.pub. in 1 hours
```
Maybe it's just a layer 8 problem, maybe.https://gitlab.nic.cz/knot/knot-resolver/-/issues/486DoH cycling2019-12-18T15:33:21+01:00Vladimír Čunátvladimir.cunat@nic.czDoH cyclingWith kresd 4.0.0 we've seen it occasionally slip into a loop consuming 100% CPU, becoming unresponsive. So far we've been unable to intentionally reproduce that, and apparently it would never happen with Firefox DoH as the client in com...With kresd 4.0.0 we've seen it occasionally slip into a loop consuming 100% CPU, becoming unresponsive. So far we've been unable to intentionally reproduce that, and apparently it would never happen with Firefox DoH as the client in combination with recent lua library versions on kresd side. So far it's very unclear what's the underlying problem.
Technical details [note to self]: the cqueues event loop got 100% busy with processing immediate actions, so even the concept of "time now" got never updated and other future events wouldn't be processed.https://gitlab.nic.cz/knot/knot-resolver/-/issues/485drop systemd socket activation support2020-01-27T12:13:19+01:00Tomas Krizekdrop systemd socket activation supportReplace systemd socket activation with old-style network interface configuration in config file.
`CAP_NET_BIND_SERVICE` should be added during service startup and dropped once sockets are bound via `net.listen()`
For more details, see ...Replace systemd socket activation with old-style network interface configuration in config file.
`CAP_NET_BIND_SERVICE` should be added during service startup and dropped once sockets are bound via `net.listen()`
For more details, see discussion on mailing list: https://lists.nic.cz/pipermail/knot-resolver-users/2019/000182.html
Related: #484 #342 #445
#### Related changes
(preliminary plans)
- [x] failing `net.listen()` should throw a lua error and therefore fail kresd if specified in configuration (by default)
- [x] allow specifying `FREEBIND` in `net.listen()`
- [x] unify TTY sockets, e.g. `net.listen('path', nil, { kind = 'control' })`
- [x] add distro-specific preconfig (control socket location, cache size)
- [x] use upgrade script to suggest updates to config and test in various envs5.0.0Tomas KrizekTomas Krizekhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/484Can't keep systemd sockets open on Ubuntu 18.04.22019-12-18T15:23:07+01:00Michael AdamsCan't keep systemd sockets open on Ubuntu 18.04.2Came across this systemd "bug" tonight, while trying to setup Knot Resolver 2.1.1 on Ubuntu 18.04.2. The Github page in question explicitly calls out a documentation conflict between **systemd** and **kresd** for socket clearing behavior...Came across this systemd "bug" tonight, while trying to setup Knot Resolver 2.1.1 on Ubuntu 18.04.2. The Github page in question explicitly calls out a documentation conflict between **systemd** and **kresd** for socket clearing behavior.
[using Sockets= in a drop-in for instantiated service doesn't clear the list of previously defined sockets](https://github.com/systemd/systemd/issues/12415)https://gitlab.nic.cz/knot/knot-resolver/-/issues/480"attempt to call a string value" in lua-http2019-11-01T14:50:43+01:00Héctor Molinero Fernández"attempt to call a string value" in lua-httpHi,
I'm having the following exception with lua-http:
```
[worker.background] error: /usr/local/share/lua/5.1/http/hpack.lua:0: attempt to call a string value stack traceback:
/usr/local/share/lua/5.1/http/hpack.lua: in function 'decod...Hi,
I'm having the following exception with lua-http:
```
[worker.background] error: /usr/local/share/lua/5.1/http/hpack.lua:0: attempt to call a string value stack traceback:
/usr/local/share/lua/5.1/http/hpack.lua: in function 'decode_header_helper'
/usr/local/share/lua/5.1/http/hpack.lua:836: in function 'decode_headers'
/usr/local/share/lua/5.1/http/h2_stream.lua:467: in function 'handler'
/usr/local/share/lua/5.1/http/h2_connection.lua:219: in function 'handle_frame'
/usr/local/share/lua/5.1/http/h2_connection.lua:260: in function 'step'
/usr/local/share/lua/5.1/http/h2_connection.lua:342: in function 'get_next_incoming_stream'
/usr/local/share/lua/5.1/http/server.lua:155: in function </usr/local/share/lua/5.1/http/server.lua:132>
```
I have tried to build Knot Resolver `4.0.0` with lua-http `0.3` and `scm-0` and in both the same problem occurs to me. The curious thing is that it only happens in an `arm64v8` server, it works properly in `x86_64`.
The problem can be reproduced with this Docker image: https://github.com/hectorm/hblock-resolverhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/478Handling of PTR records in DNS64 module2021-08-25T13:32:54+02:00Ondřej CaletkaHandling of PTR records in DNS64 moduleI know this omision is [documented](https://knot-resolver.readthedocs.io/en/stable/modules.html?highlight=PTR+synthesis#dns64), but still [RFC 6147](https://tools.ietf.org/html/rfc6147#section-5.3.1) requires proper handling of PTR recor...I know this omision is [documented](https://knot-resolver.readthedocs.io/en/stable/modules.html?highlight=PTR+synthesis#dns64), but still [RFC 6147](https://tools.ietf.org/html/rfc6147#section-5.3.1) requires proper handling of PTR records for the DNS64 translation prefix.
Since DNS64-enabled instances of Knot resolver are being deployed both by [Cloudflare](https://developers.cloudflare.com/1.1.1.1/support-nat64/) and [RIPE NCC](https://ripe78.ripe.net/on-site/tech-info/ipv6-only-network/), it would help a lot, especially during tracerouting, to have the PTR handling implemented properly.Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/477knot-resolver 4 won't build on macos because of ld: -pagezero_size option2019-05-16T10:33:23+02:00Jayson Reisknot-resolver 4 won't build on macos because of ld: -pagezero_size optionHi there, I am trying to compile the new version on macos but it seems to be failing because of [this issue](https://github.com/Homebrew/homebrew-core/issues/37169), even though the workaround is on meson.build it seems to be having the ...Hi there, I am trying to compile the new version on macos but it seems to be failing because of [this issue](https://github.com/Homebrew/homebrew-core/issues/37169), even though the workaround is on meson.build it seems to be having the same effect.
Steps to reproduce:
```
git clone https://github.com/CZ-NIC/knot-resolver.git
...
The Meson build system
Version: 0.50.1
Source dir: /Users/jayson/src/knot-resolver
Build dir: /Users/jayson/src/knot-resolver/build
Build type: native build
Project name: knot-resolver
Project version: 4.0.0
Native C compiler: cc (clang 10.0.1 "Apple LLVM version 10.0.1 (clang-1001.0.46.4)")
Native C++ compiler: c++ (clang 10.0.1 "Apple LLVM version 10.0.1 (clang-1001.0.46.4)")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Message: --- required dependencies ---
Found pkg-config: /usr/local/bin/pkg-config (0.29.2)
Dependency libknot found: YES 2.8.1
Dependency libdnssec found: YES 2.8.1
Dependency libzscanner found: YES 2.8.1
Dependency libuv found: YES 1.28.0
Found CMake: /usr/local/bin/cmake (3.14.3)
Dependency lmdb found: NO (tried pkgconfig, cmake and framework)
Library lmdb found: YES
Dependency gnutls found: YES 3.6.7
Dependency luajit found: YES 2.0.5
Message: ------------------------------
Message: --- systemd socket activation ---
Dependency libsystemd found: NO (tried pkgconfig, cmake and framework)
Message: ---------------------------
Configuring kresconfig.h using configuration
Message: --- client dependencies ---
Dependency libedit found: NO (tried pkgconfig, cmake and framework)
Library edit found: YES
Message: ---------------------------
Configuring trust_anchors.lua using configuration
Configuring sandbox.lua using configuration
Program ./kres-gen.sh found: YES (/Users/jayson/src/knot-resolver/daemon/lua/./kres-gen.sh)
Message: --- dnstap module dependencies ---
Dependency libprotobuf-c found: YES 1.3.1
Dependency libfstrm found: YES 0.5.0
Program protoc-c found: YES (/usr/local/bin/protoc-c)
Message: ----------------------------------
Configuring http.lua using configuration
Message: --- unit_tests dependencies ---
Dependency cmocka found: YES 1.1.5
Message: -------------------------------
Configuring kresd.8 using configuration
Program ../scripts/make-doc.sh found: YES (/Users/jayson/src/knot-resolver/doc/../scripts/make-doc.sh)
Configuring config.cluster using configuration
Configuring config.docker using configuration
Configuring config.isp using configuration
Configuring config.personal using configuration
Configuring config.splitview using configuration
Configuring kresd.conf using configuration
Message: --- lint dependencies ---
Program clang-tidy found: NO
Program luacheck found: NO
Program flake8 found: NO
Program scripts/run-pylint.sh found: YES (/Users/jayson/src/knot-resolver/scripts/run-pylint.sh)
Message: -------------------------
Message:
======================= SUMMARY =======================
paths
prefix: /usr/local
lib_dir: /usr/local/lib/knot-resolver
sbin_dir: /usr/local/sbin
etc_dir: /usr/local/etc/knot-resolver
root.hints: /usr/local/etc/knot-resolver/root.hints
trust_anchors
keyfile_default: /usr/local/etc/knot-resolver/root.keys
managed_ta: enabled
systemd:
socket activation: disabled
files: disabled
work_dir:
optional components
client: enabled
dnstap: enabled
unit_tests: enabled
config_tests: disabled
extra_tests: disabled
additional
user: knot-resolver
group: knot-resolver
install_kresd_conf: enabled
=======================================================
Build targets in project: 27
Found ninja-1.9.0 at /usr/local/bin/ninja
ninja -C build
ninja: Entering directory `build'
[46/100] Compiling C object 'daemon/f77b12a@@kresd@exe/bindings_net.c.o'.
../daemon/bindings/net.c:918:17: warning: unused variable 'engine' [-Wunused-variable]
struct engine *engine = engine_luaget(L);
^
../daemon/bindings/net.c:951:17: warning: unused variable 'engine' [-Wunused-variable]
struct engine *engine = engine_luaget(L);
^
2 warnings generated.
[52/100] Linking target lib/libkres.9.dylib.
FAILED: lib/libkres.9.dylib
cc -o lib/libkres.9.dylib 'lib/76b5a35@@kres@sha/cache_api.c.o' 'lib/76b5a35@@kres@sha/cache_cdb_lmdb.c.o' 'lib/76b5a35@@kres@sha/cache_entry_list.c.o' 'lib/76b5a35@@kres@sha/cache_entry_pkt.c.o' 'lib/76b5a35@@kres@sha/cache_entry_rr.c.o' 'lib/76b5a35@@kres@sha/cache_knot_pkt.c.o' 'lib/76b5a35@@kres@sha/cache_nsec1.c.o' 'lib/76b5a35@@kres@sha/cache_nsec3.c.o' 'lib/76b5a35@@kres@sha/cache_peek.c.o' 'lib/76b5a35@@kres@sha/dnssec.c.o' 'lib/76b5a35@@kres@sha/dnssec_nsec.c.o' 'lib/76b5a35@@kres@sha/dnssec_nsec3.c.o' 'lib/76b5a35@@kres@sha/dnssec_signature.c.o' 'lib/76b5a35@@kres@sha/dnssec_ta.c.o' 'lib/76b5a35@@kres@sha/generic_lru.c.o' 'lib/76b5a35@@kres@sha/generic_map.c.o' 'lib/76b5a35@@kres@sha/generic_queue.c.o' 'lib/76b5a35@@kres@sha/generic_trie.c.o' 'lib/76b5a35@@kres@sha/layer_cache.c.o' 'lib/76b5a35@@kres@sha/layer_iterate.c.o' 'lib/76b5a35@@kres@sha/layer_validate.c.o' 'lib/76b5a35@@kres@sha/module.c.o' 'lib/76b5a35@@kres@sha/nsrep.c.o' 'lib/76b5a35@@kres@sha/resolve.c.o' 'lib/76b5a35@@kres@sha/rplan.c.o' 'lib/76b5a35@@kres@sha/utils.c.o' 'lib/76b5a35@@kres@sha/zonecut.c.o' -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names -shared -install_name @rpath/libkres.9.dylib -compatibility_version 9 -current_version 9 contrib/libcontrib.a /usr/local/Cellar/libuv/1.28.0/lib/libuv.dylib -lpthread -ldl -llmdb /usr/local/Cellar/knot/2.8.1/lib/libknot.dylib /usr/local/Cellar/knot/2.8.1/lib/libdnssec.dylib /usr/local/Cellar/gnutls/3.6.7.1/lib/libgnutls.dylib -pagezero_size 10000 -image_base 100000000 /usr/local/Cellar/luajit/2.0.5/lib/libluajit-5.1.dylib -Wl,-headerpad_max_install_names -Wl,-rpath,@loader_path/../contrib -Wl,-rpath,/usr/local/Cellar/knot/2.8.1/lib -Wl,-rpath,/usr/local/Cellar/gnutls/3.6.7.1/lib
ld: -pagezero_size option can only be used when linking a main executable
clang: error: linker command failed with exit code 1 (use -v to see invocation)
[65/100] Compiling C++ object 'modules/policy/6a19ea2@@ahocorasick@sha/lua-aho-corasick_ac_fast.cxx.o'.
ninja: build stopped: subcommand failed.
```
THank you in advancehttps://gitlab.nic.cz/knot/knot-resolver/-/issues/476ulimit -n2020-01-07T14:45:12+01:00Vladimír Čunátvladimir.cunat@nic.czulimit -n##### Problem
Very often the number of file-descriptors is limited quite low by default. Consequently, kresd's _uncached_ QPS may be unnecessarily limited by that (lots of SERVFAILs), at least by default.
##### Details
The limits I oft...##### Problem
Very often the number of file-descriptors is limited quite low by default. Consequently, kresd's _uncached_ QPS may be unnecessarily limited by that (lots of SERVFAILs), at least by default.
##### Details
The limits I often see on Linux: 1024 soft + 4096 hard, which seems ridiculous for typical resources of nowadays machines. We open a new FD for every UDP packet upstream in order to maximize entropy from port randomization.
I expect the problem is partially mitigated by the fact that these limits apply per-process, but even so – it seems easy to improve the defaults at least a bit.
##### What we can do:
- [x] `LimitNOFILE=foo` in `kresd@.service`
- [x] document it somewhere
- [x] (maybe) use `ulimit()` or similar to let kresd increase it – just moving from 1024 to 4096 seems quite a substantial improvement, and 4096 even seems OK-ish for some cases I tested
- [ ] (possibly, in future) in case of plaintext forwarding, automatically prefer TCP when QPS gets high and/or getting problems like `EMFILE` errors. Users behind some NATs are also severely limited in terms of "concurrent connection count".
Thoughts?5.0.0Tomas KrizekTomas Krizekhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/472running without any trust anchors leads to insufficient caching2020-04-27T16:33:18+02:00Vladimír Čunátvladimir.cunat@nic.czrunning without any trust anchors leads to insufficient cachingRR ranks are confused: _some_ records get cached with `KR_RANK_TRY`, but that's insufficient for using in answers &ndash; at least `KR_RANK_INSECURE` and that would be the correct rank in this case IMO.
_It's a low-priority configuratio...RR ranks are confused: _some_ records get cached with `KR_RANK_TRY`, but that's insufficient for using in answers – at least `KR_RANK_INSECURE` and that would be the correct rank in this case IMO.
_It's a low-priority configuration for us._https://gitlab.nic.cz/knot/knot-resolver/-/issues/466move docker image to registry.labs.nic.cz2021-11-25T16:26:11+01:00Tomas Krizekmove docker image to registry.labs.nic.czDocker image for knot-resolver should be moved to our own upstream registry. The effect for end users would be to switch the image name from `cznic/knot-resolver` to something like `registry.labs.nic.cz/knot/knot-resolver`
The issues wi...Docker image for knot-resolver should be moved to our own upstream registry. The effect for end users would be to switch the image name from `cznic/knot-resolver` to something like `registry.labs.nic.cz/knot/knot-resolver`
The issues with current setup in docker hub:
- after their recent "update", automated build require **administrative** access to source code repository
> This service account should have access to any repositories to be built, and must have administrative access to the source code repositories so it can manage deploy keys. (source: https://docs.docker.com/docker-hub/builds/#service-users-for-team-autobuilds )
I have no idea what is "managing deploy keys" and why an administrative access to make a build from publicly pushed branch / tag would even be required in the first place.
- providing docker hub with unneeded privileges goes against good security practices and ends up as one would expect (https://news.ycombinator.com/item?id=19763413)
---
Since we already have our own registry and CI/CD infrastructure, I think we should take advantage of it and use it for docker image builds for both latest master branch and tagged versions.
This would fix the currently broken automation of image builds and also simplify the entire process (using docker hub requires github, so we need to mirror there first, then build an image from there...)
@dsalzman Do you think this would make sense for Knot DNS image as well?https://gitlab.nic.cz/knot/knot-resolver/-/issues/465DoH: error: attempt to call a userdata value stack traceback2020-08-27T14:07:31+02:00Foundation for Applied PrivacyDoH: error: attempt to call a userdata value stack tracebackThanks for adding DoH support in your latest release.
We started the process to migrate our current public DoH server to knot-resolver.
Our knot-resolver test setup works so far but we see the following entries in our logs when pointing ...Thanks for adding DoH support in your latest release.
We started the process to migrate our current public DoH server to knot-resolver.
Our knot-resolver test setup works so far but we see the following entries in our logs when pointing (a single) firefox (in GET mode) to the endpoint (which is behind nginx):
```
[worker.background] error: attempt to call a userdata value stack traceback:
#011[C]: in function 'wait'
#011/usr/share/lua/5.1/cqueues/condition.lua:13: in function 'wait'
#011/usr/lib/knot-resolver/kres_modules/http_doh.lua:102: in function 'data'
#011/usr/lib/knot-resolver/kres_modules/http.lua:177: in function </usr/lib/knot-resolver/kres_modules/http.lua:160>
#011[C]: in function 'yieldable_pcall'
#011/usr/lib/knot-resolver/kres_modules/http.lua:232: in function </usr/lib/knot-resolver/kres_modules/http.lua:207>
#011[C]: in function 'yieldable_pcall'
#011/usr/share/lua/5.1/http/server.lua:159: in function </usr/share/lua/5.1/http/server.lua:158>
```
The frequency of these log events varies but we see multiple occurrences with a single browser.
firefox (network.trr.useGET = true) -> nginx -> knot-resolver
knot-resolver 4.0.0https://gitlab.nic.cz/knot/knot-resolver/-/issues/464stats module sigsegv2019-05-03T09:34:49+02:00tcelystats module sigsegvhttps://github.com/alpinelinux/aports/blob/2426121faa85d777cceb332b88b943ab672767d0/testing/knot-resolver4/stats-module-memset-upstreams.patch
I discovered that the stats module in `3.2.1` and `4.0.0` was crashing with `SIGSEGV` in `sta...https://github.com/alpinelinux/aports/blob/2426121faa85d777cceb332b88b943ab672767d0/testing/knot-resolver4/stats-module-memset-upstreams.patch
I discovered that the stats module in `3.2.1` and `4.0.0` was crashing with `SIGSEGV` in `stats_init` on Alpine Linux. The patch used to solve that problem is linked above.https://gitlab.nic.cz/knot/knot-resolver/-/issues/463stats module malloc2019-04-26T01:41:18+02:00tcelystats module malloc[modules/stats/stats.c#L486](modules/stats/stats.c#L486)
> `struct stat_data *data = malloc(sizeof(*data));`
This `malloc` call would appear to be incorrect. The argument to `sizeof` should be `stat_data` unless I have missed something.[modules/stats/stats.c#L486](modules/stats/stats.c#L486)
> `struct stat_data *data = malloc(sizeof(*data));`
This `malloc` call would appear to be incorrect. The argument to `sizeof` should be `stat_data` unless I have missed something.https://gitlab.nic.cz/knot/knot-resolver/-/issues/461dnstap meson ordering problem2019-04-25T13:24:49+02:00tcelydnstap meson ordering problem```
ninja: Entering directory `build'
[1/101] Compiling C object 'modules/dnstap/8572298@@dnstap@sha/dnstap.c.o'.
FAILED: modules/dnstap/8572298@@dnstap@sha/dnstap.c.o
gcc -Imodules/dnstap/8572298@@dnstap@sha -Imodules/dnstap -I../modul...```
ninja: Entering directory `build'
[1/101] Compiling C object 'modules/dnstap/8572298@@dnstap@sha/dnstap.c.o'.
FAILED: modules/dnstap/8572298@@dnstap@sha/dnstap.c.o
gcc -Imodules/dnstap/8572298@@dnstap@sha -Imodules/dnstap -I../modules/dnstap -I. -I../ -Icontrib/ -I../contrib/ -fdiagnostics-color=always -DNDEBUG -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu11 -O3 -D_GNU_SOURCE -Wformat -Wformat-security -Wtype-limits -Wshadow -fvisibility=hidden -Os -fomit-frame-pointer -Os -fomit-frame-pointer -fPIC -MD -MQ 'modules/dnstap/8572298@@dnstap@sha/dnstap.c.o' -MF 'modules/dnstap/8572298@@dnstap@sha/dnstap.c.o.d' -o 'modules/dnstap/8572298@@dnstap@sha/dnstap.c.o' -c ../modules/dnstap/dnstap.c
../modules/dnstap/dnstap.c:23:10: fatal error: modules/dnstap/dnstap.pb-c.h: No such file or directory
#include "modules/dnstap/dnstap.pb-c.h"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
```
I think the fix is:
https://github.com/alpinelinux/aports/blob/89ed9f344b63ac0dac9bdd4b50fd121d51accdcc/testing/knot-resolver4/meson-dnstap-generated-sources.patchTomas KrizekTomas Krizekhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/458dnstap module compilation error on Turris Omnia2019-04-17T18:26:25+02:00Jan Pavlinecdnstap module compilation error on Turris OmniaHi,
I'm trying to build dnstap module for Turris Omnia, but it fails to generate dnstap.pb-c.h
> ../modules/dnstap/dnstap.c:23:40: fatal error: modules/dnstap/dnstap.pb-c.h: No such file or directory
which is probably caused by this...Hi,
I'm trying to build dnstap module for Turris Omnia, but it fails to generate dnstap.pb-c.h
> ../modules/dnstap/dnstap.c:23:40: fatal error: modules/dnstap/dnstap.pb-c.h: No such file or directory
which is probably caused by this
```
FAILED: modules/dnstap/dnstap.pb-c.h modules/dnstap/dnstap.pb-c.c
/home/cznic/data/src/openwrt_devhonza_lastlast/openwrt/staging_dir/host/bin/protoc-c --c_out=modules/dnstap --proto_path /home/cznic/data/src/openwrt_devhonza_lastlast/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl-1.1.15_eabi/knot-resolver/modules/dnstap dnstap.proto
dnstap.proto: No such file or directory
```
I tried to fixed that with this patch and now it looks that dnstap modules is build.
```
Index: knot-resolver/modules/dnstap/meson.build
===================================================================
--- knot-resolver.orig/modules/dnstap/meson.build
+++ knot-resolver/modules/dnstap/meson.build
@@ -27,9 +27,8 @@ if build_dnstap
'dnstap_pb',
command: [
protoc_c,
- '--c_out=@OUTDIR@',
- '--proto_path', meson.current_source_dir(),
- 'dnstap.proto',
+ '--c_out=' + meson.current_build_dir(),
+ '--proto_path', meson.current_source_dir(), join_paths([meson.current_source_dir(), 'dnstap.proto']),
],
output: [
'dnstap.pb-c.h',
```
Tomas KrizekTomas Krizekhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/457Error compiling pytests in Ubuntu 18.042019-04-05T18:45:04+02:00Héctor Molinero FernándezError compiling pytests in Ubuntu 18.04I'm getting the following error when compiling pytests in Ubuntu 18.04:
```
../tests/pytests/proxy/tls-proxy.c: In function 'tls_process_from_client':
../tests/pytests/proxy/tls-proxy.c:849:9: warning: implicit declaration of function 't...I'm getting the following error when compiling pytests in Ubuntu 18.04:
```
../tests/pytests/proxy/tls-proxy.c: In function 'tls_process_from_client':
../tests/pytests/proxy/tls-proxy.c:849:9: warning: implicit declaration of function 'tls_process_reauth'; did you mean 'tls_process_handshake'? [-Wimplicit-function-declaration]
ret = tls_process_reauth(client);
^~~~~~~~~~~~~~~~~~
tls_process_handshake
```
It seems that [`tls_process_reauth` is only declared](https://gitlab.labs.nic.cz/knot/knot-resolver/blob/b2ebd4442d6b897c132ca07af59afac61e3679c3/tests/pytests/proxy/tls-proxy.c#L802-803) when `GNUTLS_VERSION_NUMBER` is greater than or equal to `0x030604` while in Ubuntu 18.04 the included version of GnuTLS has as value `0x030512`.https://gitlab.nic.cz/knot/knot-resolver/-/issues/454[ubuntu] http module can't bind to address2020-05-26T09:14:54+02:00Tomas Krizek[ubuntu] http module can't bind to addressUpstream package `knot-resolver-module-http` for Ubuntu 18.04, 18.10 is unusable, because it fails to bind to the specified address.
```
error: failed to listen on 127.0.0.1@8053: Address family not supported by protocol
```
It also fa...Upstream package `knot-resolver-module-http` for Ubuntu 18.04, 18.10 is unusable, because it fails to bind to the specified address.
```
error: failed to listen on 127.0.0.1@8053: Address family not supported by protocol
```
It also fails with `::1`, `0.0.0.0` or any other interface.https://gitlab.nic.cz/knot/knot-resolver/-/issues/453policy.RPZ parser: significant issues2019-03-06T12:21:59+01:00Vladimír Čunátvladimir.cunat@nic.czpolicy.RPZ parser: significant issuesA [real-life RPZ](https://urlhaus.abuse.ch/downloads/rpz/) starts with:
```
$TTL 30
@ SOA rpz.urlhaus.abuse.ch. hostmaster.urlhaus.abuse.ch. 1903050701 3600 1800 604800 30
NS localhost.
```
**with CRLFs as EOLs** in that part. That sil...A [real-life RPZ](https://urlhaus.abuse.ch/downloads/rpz/) starts with:
```
$TTL 30
@ SOA rpz.urlhaus.abuse.ch. hostmaster.urlhaus.abuse.ch. 1903050701 3600 1800 604800 30
NS localhost.
```
**with CRLFs as EOLs** in that part. That silently breaks with kresd 3.2.1, resulting into ignoring the whole file contents.
_[Reported via chat](https://gitter.im/CZ-NIC/knot-resolver?at=5c7d8893212d0c1e1ad1af83)._https://gitlab.nic.cz/knot/knot-resolver/-/issues/452[meson] skipped tests not detected (in some cases)2019-03-12T12:12:23+01:00Vladimír Čunátvladimir.cunat@nic.cz[meson] skipped tests not detected (in some cases)```
ok 1 - skipping worker test because it doesnt support background worker
25/41 knot-resolver:postinstall+config / config.keyfile.nonexist1 UNEXPECTEDPASS 0.04 s
26/41 knot-resolver:postinstall+config / config.keyfile.nonexist2 UNEXP...```
ok 1 - skipping worker test because it doesnt support background worker
25/41 knot-resolver:postinstall+config / config.keyfile.nonexist1 UNEXPECTEDPASS 0.04 s
26/41 knot-resolver:postinstall+config / config.keyfile.nonexist2 UNEXPECTEDPASS 0.04 s
```
I don't know ATM – is there some other return code we should use?Tomas KrizekTomas Krizek