Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2022-05-09T11:46:29+02:00https://gitlab.nic.cz/knot/knot-resolver/-/issues/406validate: fails to accept some correct proofs in deeper NSEC zones2022-05-09T11:46:29+02:00Vladimír Čunátvladimir.cunat@nic.czvalidate: fails to accept some correct proofs in deeper NSEC zonesReal-life example: `_domainkey.bronz.cz` - it's an empty non-terminal covered by
```
*.bronz.cz. 3589 IN NSEC arcz._domainkey.bronz.cz. CNAME RRSIG NSEC
```
Note: aggressive cache does generate the proof correctly...Real-life example: `_domainkey.bronz.cz` - it's an empty non-terminal covered by
```
*.bronz.cz. 3589 IN NSEC arcz._domainkey.bronz.cz. CNAME RRSIG NSEC
```
Note: aggressive cache does generate the proof correctly, if the record is in cache; it's just validator not accepting it. In real life this issue will probably be rarely causing problems, moreover NODATA isn't often recognizable from SERVFAIL.https://gitlab.nic.cz/knot/knot-resolver/-/issues/404incorrect handling of EDNS version 1+2019-07-09T17:12:25+02:00Petr Špačekincorrect handling of EDNS version 1+Apparently we do not return BADVERS as we should:
```
$ dig +nocookie +rec +noad +edns=1 +noednsneg +ednsopt=100 soa isc.org. @1.1.1.1
; <<>> DiG 9.13.0-dev <<>> +nocookie +rec +noad +edns=1 +noednsneg +ednsopt=100 soa isc.org. @1.1.1....Apparently we do not return BADVERS as we should:
```
$ dig +nocookie +rec +noad +edns=1 +noednsneg +ednsopt=100 soa isc.org. @1.1.1.1
; <<>> DiG 9.13.0-dev <<>> +nocookie +rec +noad +edns=1 +noednsneg +ednsopt=100 soa isc.org. @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20124
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;isc.org. IN SOA
;; ANSWER SECTION:
isc.org. 6914 IN SOA ns-int.isc.org. hostmaster.isc.org. 2018092500 7200 3600 24796800 3600
;; Query time: 16 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Oct 01 13:40:13 CEST 2018
;; MSG SIZE rcvd: 90
```
Test suite:
https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing
run `genreport -R` with input like:
`nic.cz. resolver.test. 1.1.1.1`
Output at the moment:
```
nic.cz. @1.1.1.1 (resolver.test.): dns=ok edns=ok edns1=noerror,badversion,soa edns@512=ok ednsopt=ok edns1opt=noerror,badversion,soa do=ok ednsflags=ok optlist=ok signed=ok,yes ednstcp=ok
```https://gitlab.nic.cz/knot/knot-resolver/-/issues/396SERVFAIL answer still contains bogus RRsets2020-04-15T10:25:21+02:00Petr ŠpačekSERVFAIL answer still contains bogus RRsetsAttached test [val_ad_qtype_ds.rpl](/uploads/a35e1072c53b8e68374b158d36d04d3a/val_ad_qtype_ds.rpl) contains incorrect SOA serial, i.e. RRSIG for `. SOA` does not match the SOA RR.
Kresd 3.0.0 correctly detects bogus answer, clears AD bi...Attached test [val_ad_qtype_ds.rpl](/uploads/a35e1072c53b8e68374b158d36d04d3a/val_ad_qtype_ds.rpl) contains incorrect SOA serial, i.e. RRSIG for `. SOA` does not match the SOA RR.
Kresd 3.0.0 correctly detects bogus answer, clears AD bit and sets RCODE=SERVFAIL but the bogus RR is still present in response sent to client:
```
E id 43842
E opcode QUERY
E rcode SERVFAIL
E flags QR RD RA
E edns 0
E eflags DO
E payload 4096
E ;QUESTION
E test. IN DS
E ;ANSWER
E ;AUTHORITY
E . 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017030902 1800 900 604800 86400
E test. 86400 IN NSEC . NS RRSIG NSEC
E . 86400 IN RRSIG SOA 8 0 86400 20180922145219 20180823145219 61125 . oUmzRZlxlk8WMI6EVAVqveSrD7gY7dxo g/KF0xIsUgb4wuw7ysD4C1E7GCKA8UqF XKsJn+RpKJHiHAASLctCL8Ewnger2ebe RtTNENEuqyvWlJwWHIY9Bk9YvMr5RzNd TfyLS+EGFGQzk2G793DOoi0DuNFaFK1A kN/jDDzDuGxwK/9oZ4X9Sk2mKeZfjKWI oXaPhMonfnWtX+6rKeMvgSjMZYEXz0+E XYHeHwvtUIPYzMfO2iCrEfCABH04OG61 NP5N9W+IiOKP1KAmT8id3JyFJACHjSP6 BeEIv6Ydzz3M9vq4B4pj0Cr9ePH0GnNC 0Sg8uOfHzjC5bHldoaJs4g==
E test. 86400 IN RRSIG NSEC 8 1 86400 20180922145219 20180823145219 61125 . Fgq94cQgkH4LhB0NFRSzqZT09eLTr4Jd P+xV+s5HEPiipfmaRSy3Y1ZoihtofwjO +LObPVLmyPz7WUWmJBCu3bPRS0GU4Ltq YmpBpUxjuaVqbiw07/GO3IS6nLD1IVYp uXzktncdJDkwalkPb/qMtrMTSEzH5V6a 9CJErKJRIEn36Ypg6+hvKXJT5uJyqcTs eqFXnHDXBzIQjlc6rm7gPCdUCzxx9UrP SxVeNfLSYUV96RA2G1NgksCejP7TPpIi heRXDIItvl/XtQy5pdaPsdE+bJHQaxC2 uTabzvGPoLHRahfCjtH2XxuFsWCSm7ad 0bRQH4v1o05CB8Cv9JkDEQ==
E ;ADDITIONAL
```
RR `. SOA` should not be there, it is bogus.Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/390unsigned same-server delegation does not work (SERVFAIL when iterating)2020-08-10T12:38:58+02:00Petr Špačekunsigned same-server delegation does not work (SERVFAIL when iterating)Attached [test](/uploads/faf14f8a4d04b5331a3d3ec150027dfc/qlist) asks for `unsigned2.box. SOA` and the request ends with SERVFAIL.
I believe that it should work because the domain is an unsigned delegation from parent, with child hosted...Attached [test](/uploads/faf14f8a4d04b5331a3d3ec150027dfc/qlist) asks for `unsigned2.box. SOA` and the request ends with SERVFAIL.
I believe that it should work because the domain is an unsigned delegation from parent, with child hosted on the same server.
The delegation is inside opt-out range so resolver should verify unsigned status of zone and continue.
(I hope there is no mistake in the test, I did my best. If there is a mistake in test itself I apologize.)https://gitlab.nic.cz/knot/knot-resolver/-/issues/385log flood from TLS session key rotation2018-08-16T00:17:26+02:00Petr Špačeklog flood from TLS session key rotationFor some reason kresd log is full of these:
```
[tls] session ticket: epoch 374131, scheduling rotation check in 0 ms
[tls] session ticket: epoch 374131, scheduling rotation check in 0 ms
[tls] session ticket: epoch 374131, scheduling ro...For some reason kresd log is full of these:
```
[tls] session ticket: epoch 374131, scheduling rotation check in 0 ms
[tls] session ticket: epoch 374131, scheduling rotation check in 0 ms
[tls] session ticket: epoch 374131, scheduling rotation check in 0 ms
[tls] session ticket: epoch 374131, scheduling rotation check in 0 ms
[tls] session ticket: epoch 374131, scheduling rotation check in 0 ms
[tls] session ticket: epoch 374131, scheduling rotation check in 0 ms
[tls] session ticket: epoch 374131, scheduling rotation check in 0 ms
[tls] session ticket: epoch 374131, scheduling rotation check in 0 ms
[tls] session ticket: epoch 374131, scheduling rotation check in 0 ms
[tls] session ticket: epoch 374131, scheduling rotation check in 0 ms
[tls] session ticket: epoch 374131, scheduling rotation check in 0 ms
[tls] session ticket: epoch 374131, scheduling rotation check in 0 ms
[tls] session ticket: epoch 374131, scheduling rotation check in 0 ms
[tls] session ticket: epoch 374131, scheduling rotation check in 0 ms
[tls] session ticket: epoch 374132, scheduling rotation check in 4096000 ms
```
This is post-2.4.0 code c222c545d8bd3feec94a59f1a624ffda253586e3 running in single process.https://gitlab.nic.cz/knot/knot-resolver/-/issues/377kresd fails to bind IPv6 TLS socket sometimes (but IPv4 works)2019-06-06T12:46:11+02:00Petr Špačekkresd fails to bind IPv6 TLS socket sometimes (but IPv4 works)I have no idea why, this issues is here to remind us to inspect code for stream socket binding:
kresd should be listening on port 53028 for IPv4 and IPv6 at the same time but it is not. [config](/uploads/864f0d5638e9ec828d0d8085869938d3...I have no idea why, this issues is here to remind us to inspect code for stream socket binding:
kresd should be listening on port 53028 for IPv4 and IPv6 at the same time but it is not. [config](/uploads/864f0d5638e9ec828d0d8085869938d3/config)
```
$ netstat -lptn | grep kresd
tcp 0 0 127.0.0.1:53021 0.0.0.0:* LISTEN 79892/kresd
tcp 0 0 127.0.0.1:53022 0.0.0.0:* LISTEN 79894/kresd
tcp 0 0 127.0.0.1:53028 0.0.0.0:* LISTEN 79892/kresd
tcp6 0 0 ::1:53021 :::* LISTEN 79892/kresd
tcp6 0 0 ::1:53022 :::* LISTEN 79894/kresd
```https://gitlab.nic.cz/knot/knot-resolver/-/issues/375DNS64 should not perform synthesis for queries with CD and DO flags2018-07-02T15:41:42+02:00Ondřej CaletkaDNS64 should not perform synthesis for queries with CD and DO flagsAccording to [RFC 6147, section 5.5, paragraph 3](https://tools.ietf.org/html/rfc6147#section-5.5), DNS64 synthesis MUST NOT be performed for queries with CD and DO flags (not to fool validating stub resolvers). Knot Resolver is not comp...According to [RFC 6147, section 5.5, paragraph 3](https://tools.ietf.org/html/rfc6147#section-5.5), DNS64 synthesis MUST NOT be performed for queries with CD and DO flags (not to fool validating stub resolvers). Knot Resolver is not compliant with this requirement.
# dig ipv4only.arpa aaaa +cdflag +dnssec +short
64:ff9b::c000:aa
64:ff9b::c000:ab
Both BIND and Unbound DNS64 modules perform well:
# dig ipv4only.arpa aaaa +cdflag +dnssec +short
<empty>2018 Q2Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/347knot-resolver fails to build from source on hurd due to missing MAXPATHLEN2018-05-03T12:48:02+02:00Daniel Kahn Gillmorknot-resolver fails to build from source on hurd due to missing MAXPATHLENthe [debian hurd build daemon](https://buildd.debian.org/status/fetch.php?pkg=knot-resolver&arch=hurd-i386&ver=2.3.0-2&stamp=1524785893&raw=0) shows:
```
daemon/engine.c: In function 'engine_set_moduledir':
daemon/engine.c:231:15: error...the [debian hurd build daemon](https://buildd.debian.org/status/fetch.php?pkg=knot-resolver&arch=hurd-i386&ver=2.3.0-2&stamp=1524785893&raw=0) shows:
```
daemon/engine.c: In function 'engine_set_moduledir':
daemon/engine.c:231:15: error: 'MAXPATHLEN' undeclared (first use in this function); did you mean 'MAXNAMLEN'?
char l_paths[MAXPATHLEN] = { 0 };
^~~~~~~~~~
MAXNAMLEN
```
See [Justus Winter's thoughts on MAXPATHLEN](https://lists.debian.org/debian-hurd/2012/01/msg00166.html) about why this might not be something worth relying on.https://gitlab.nic.cz/knot/knot-resolver/-/issues/321resolving broken DNSSEC domain with CD flag sometimes returns SERVFAIL2018-02-27T15:32:36+01:00Tomas Krizekresolving broken DNSSEC domain with CD flag sometimes returns SERVFAILWhen DNSSEC validation is turned on and I attempt to resolve a broken DNSSEC domain with the CD flag on, kresd should return NOERROR. Instead, it occasionally returns SERVFAIL.
```
dig rhybar.cz +cd
```
[log.txt](/uploads/64e219320eef0...When DNSSEC validation is turned on and I attempt to resolve a broken DNSSEC domain with the CD flag on, kresd should return NOERROR. Instead, it occasionally returns SERVFAIL.
```
dig rhybar.cz +cd
```
[log.txt](/uploads/64e219320eef0f1eb4c8faae5478a19d/log.txt): when kresd return SERVFAILhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/318map_set is used incorrectly on some places2018-05-03T17:06:32+02:00Vladimír Čunátvladimir.cunat@nic.czmap_set is used incorrectly on some placesProbably due to misleading API docs; when it returns 1, it's replaced the value, but sometimes we free the value afterwards assuming ENOMEM. Some `set_add` call sites might also be affected.Probably due to misleading API docs; when it returns 1, it's replaced the value, but sometimes we free the value afterwards assuming ENOMEM. Some `set_add` call sites might also be affected.https://gitlab.nic.cz/knot/knot-resolver/-/issues/308debian stretch PPA: systemd service doesn't have privileges to bind to well-k...2018-02-28T10:19:28+01:00Ghost Userdebian stretch PPA: systemd service doesn't have privileges to bind to well-known portsIf I install the current knot-resolver package (1.5.0-1+0~20171112102149.11+stretch~1.gbp1554e1) from the projects debian repositories to a up to date debian stretch I can't get it running because it can't bind to the configured interfac...If I install the current knot-resolver package (1.5.0-1+0~20171112102149.11+stretch~1.gbp1554e1) from the projects debian repositories to a up to date debian stretch I can't get it running because it can't bind to the configured interface addresses.
The problem is that the daemon is started as user knot-resolver over systemd. This users hasn't the permission to bind to the necessary interface addresses and port configured in the config. Also the dropping of permissions over the config doesn't work because there are no permission to drop. This looks like a wrong default value for the user in the systemd config file. If this is on purpose there should be a hint in the documentation an default config file.Tomas KrizekTomas Krizekhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/307debian stretch PPA: missing icann-ca.pem2018-02-28T10:18:47+01:00Ghost Userdebian stretch PPA: missing icann-ca.pemIf I install the current knot-resolver package (1.5.0-1+0~20171112102149.11+stretch~1.gbp1554e1) from the projects debian repositories I can't get it running with the following error:
```
/usr/lib/knot-resolver/trust_anchors.lua:380: [ ...If I install the current knot-resolver package (1.5.0-1+0~20171112102149.11+stretch~1.gbp1554e1) from the projects debian repositories I can't get it running with the following error:
```
/usr/lib/knot-resolver/trust_anchors.lua:380: [ ta ] fetch of "https://data.iana.org/root-anchors/root-anchors.xml" failed: error loading CA locations (No such file or directory)
[ ta ] Failed to bootstrap root trust anchors; see:
https://knot-resolver.readthedocs.io/en/latest/daemon.html#enabling-dnssec
```
Looking further with strace there is call to open `/etc/knot-resolver/icann-ca.pem`
```
open("/etc/knot-resolver/icann-ca.pem", O_RDONLY) = -1 ENOENT (No such file or directory)
```
But querying the package files with `dpkg-query -L knot-resolver` shows that the requested file is also missing in the package.
```
/etc
/etc/default
/etc/default/kresd
/etc/init.d
/etc/init.d/kresd
/etc/knot-resolver
/etc/knot-resolver/kresd.conf
```
This are the only files in the `/etc` directory. So the missing file should be added to the package if the code depends on it. Adding the missing file fixed the problem in my local installation.Tomas KrizekTomas Krizekhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/306TLS forwarding: configure multiple IPv4 targets2018-02-15T10:40:53+01:00Tomas KrizekTLS forwarding: configure multiple IPv4 targetsTLS forwarding can't be configured with multiple IPv4 targets. Attempting to do so results in `TLS_FORWARD configuration cannot declare two configs for IP address A.B.C.D` error. It doesn't affect IPv6.
Reproducer: extend [modules/polic...TLS forwarding can't be configured with multiple IPv4 targets. Attempting to do so results in `TLS_FORWARD configuration cannot declare two configs for IP address A.B.C.D` error. It doesn't affect IPv6.
Reproducer: extend [modules/policy/policy.test.lua](https://gitlab.labs.nic.cz/knot/knot-resolver/blob/master/modules/policy/policy.test.lua) with the following test cases.
```
ok(policy.TLS_FORWARD({{'100:dead::', insecure=true},
{'100:beef::', insecure=true}
}), 'TLS_FORWARD with different IPv6 addresses is allowed')
ok(policy.TLS_FORWARD({{'127.0.0.1', insecure=true},
{'127.0.0.2', insecure=true}
}), 'TLS_FORWARD with different IPv4 addresses is allowed')
```
For some reason, `ffi.string(sockaddr_c, ffi.C.kr_inaddr_len(sockaddr_c))` ([policy.lua#L212](https://gitlab.labs.nic.cz/knot/knot-resolver/blob/master/modules/policy/policy.lua#L212)) returns the same value for different IPv4 addresses.Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/301Kresd segfault on resolving domain name from hints2018-02-13T16:49:44+01:00Maria MatejkaKresd segfault on resolving domain name from hintsUsing this config file:
```
net = { '127.0.0.1', '::1', '192.168.7.200' }
user('knot-resolver','knot-resolver')
modules = { 'hints < iterate' }
hints.set("dns.msftncsi.com. 192.168.7.200")
```
and resolving (`dig dns.msftncsi.com @localh...Using this config file:
```
net = { '127.0.0.1', '::1', '192.168.7.200' }
user('knot-resolver','knot-resolver')
modules = { 'hints < iterate' }
hints.set("dns.msftncsi.com. 192.168.7.200")
```
and resolving (`dig dns.msftncsi.com @localhost`) causes kresd to segfault. Stack trace is like this:
```
#0 0x00007ffff7948183 in knot_dname_is_equal () from /usr/lib/x86_64-linux-gnu/libknot.so.7
#1 0x00007ffff3870a80 in ?? () from /usr/local/lib/kdns_modules/hints.so
#2 0x00007ffff3871454 in ?? () from /usr/local/lib/kdns_modules/hints.so
#3 0x00007ffff7b87a98 in kr_resolve_produce () from /usr/local/lib/libkres.so.4
#4 0x00005555555603b5 in ?? ()
#5 0x000055555555b65b in ?? ()
#6 0x00007ffff72c318b in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#7 0x00007ffff72c4ef8 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#8 0x00007ffff72b6934 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#9 0x000055555555b465 in ?? ()
#10 0x00007ffff5e122b1 in __libc_start_main (main=0x55555555a240, argc=5, argv=0x7fffffffe4a8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe498) at ../csu/libc-start.c:291
#11 0x000055555555b4ba in _start ()
```https://gitlab.nic.cz/knot/knot-resolver/-/issues/297docker start fails on libstdc++.so.6 @ ahocorasick.so2018-01-25T15:39:58+01:00Ghost Userdocker start fails on libstdc++.so.6 @ ahocorasick.soHi,
`docker run cznic/knot-resolver`
results in
`error: error loading module 'ahocorasick' from file '/usr/local/lib/kdns_modules/ahocorasick.so':
Error loading shared library libstdc++.so.6: No such file or directory (needed by /usr...Hi,
`docker run cznic/knot-resolver`
results in
`error: error loading module 'ahocorasick' from file '/usr/local/lib/kdns_modules/ahocorasick.so':
Error loading shared library libstdc++.so.6: No such file or directory (needed by /usr/local/lib/kdns_modules/ahocorasick.so)
[system] error error: No such file or directory`
I tried a Dockerfile from https://hub.docker.com/r/cznic/knot-resolver/~/dockerfile/
It compiles, but it does not run.
I unsuccessfully tried it on multiple Ubuntu hosts, no good. I also tried to install *libstdc++.6*, or change LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/ (or another), but the outcome was always the same.https://gitlab.nic.cz/knot/knot-resolver/-/issues/296regression: failure to follow a referral (sometimes?)2018-02-02T18:20:10+01:00Vladimír Čunátvladimir.cunat@nic.czregression: failure to follow a referral (sometimes?)Test case: `www.automobile.fr. AAAA`, bisected to commit e7c5c102d0eb. (In particular, it works OK on 1.5.1.)
Interesting part from log:
```
[52590][iter] 'www.automobile.fr.' type 'AAAA' id was assigned, parent id 0
[52590][resl] ...Test case: `www.automobile.fr. AAAA`, bisected to commit e7c5c102d0eb. (In particular, it works OK on 1.5.1.)
Interesting part from log:
```
[52590][iter] 'www.automobile.fr.' type 'AAAA' id was assigned, parent id 0
[52590][resl] => querying: '2a04:cb41:a516:3::3' score: 10 zone cut: 'automobile.fr.' m12n: 'WWW.automOBilE.fr.' type: 'AAAA' proto: 'udp'
[52590][iter] <= answer received:
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 52590
;; Flags: qr QUERY: 1; ANSWER: 0; AUTHORITY: 4; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1280 B; ext-rcode: Unused
;; QUESTION SECTION
www.automobile.fr. AAAA
;; AUTHORITY SECTION
www.automobile.fr. 600 NS ns1.p13.dynect.net.
www.automobile.fr. 600 NS ns2.p13.dynect.net.
www.automobile.fr. 600 NS ns3.p13.dynect.net.
www.automobile.fr. 600 NS ns4.p13.dynect.net.
[52590][iter] <= referral response, follow
[52590][ rc ] => stashing rank: 010, NS www.automobile.fr.
[40645][iter] 'www.automobile.fr.' type 'AAAA' id was assigned, parent id 0
[40645][plan] plan 'dns47-2.mobile.de.' type 'A'
[27333][iter] 'dns47-2.mobile.de.' type 'A' id was assigned, parent id 40645
[27333][ rc ] => rank: 001, lowest 000, A dns47-2.mobile.de.
[27333][ rc ] => satisfied from cache
[27333][iter] <= answer received:
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 27333
;; Flags: qr aa QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
;; QUESTION SECTION
dns47-2.mobile.de. A
;; ANSWER SECTION
dns47-2.mobile.de. 86400 A 91.211.75.18
[27333][iter] <= rcode: NOERROR
[40645][iter] <= using glue for 'dns47-2.mobile.de.': '91.211.75.18'
[28159][iter] 'www.automobile.fr.' type 'AAAA' id was assigned, parent id 0
[28159][resl] => querying: '91.211.75.18' score: 10 zone cut: 'www.automobile.fr.' m12n: 'www.AutOMoBILe.fr.' type: 'AAAA' proto: 'udp'
```
On the last line kresd queries `@dns47-2.mobile.de.` (again), despite getting referral for the `www` zone to `ns*.p13.dynect.net.` in the previous iteration step.
Another example: `settings.services.mozilla.com. SOA`. This one also gets broken on that commit though the log _looks_ different: `mirror.nsc.liu.se. CNAME`.https://gitlab.nic.cz/knot/knot-resolver/-/issues/292tls forwarding: there are high likelyhood of msg-id duplication for active qu...2018-02-16T11:04:58+01:00Grigorii Demidovtls forwarding: there are high likelyhood of msg-id duplication for active query under heavy loadhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/287crash on startup if cache directory is not writeable2018-09-12T11:08:36+02:00Petr Špačekcrash on startup if cache directory is not writeable```
$ chmod u-w .
$ kresd
[cache] LMDB error: Permission denied
kresd: lib/cdb_lmdb.c:67: lmdb_error: Assertion `false' failed.
Aborted (core dumped)
``````
$ chmod u-w .
$ kresd
[cache] LMDB error: Permission denied
kresd: lib/cdb_lmdb.c:67: lmdb_error: Assertion `false' failed.
Aborted (core dumped)
```https://gitlab.nic.cz/knot/knot-resolver/-/issues/278confusing error message when root hints cannot be loaded2017-12-17T01:10:17+01:00Horigome Yoshihitoconfusing error message when root hints cannot be loadedI compile 1.5.0 from the source file and try to find the root.hints file even though I set the following parameters in the setting file.
```
modules = {
'view', -- Views for certain clients
predict = {
...I compile 1.5.0 from the source file and try to find the root.hints file even though I set the following parameters in the setting file.
```
modules = {
'view', -- Views for certain clients
predict = {
window = 60, -- 60 minutes sampling window
period = 24*(60/15) -- track last 24 hours
},
'daf',
'hints', -- Load /etc/hosts and allow custom root hints
'stats', -- Track internal statistics
}
modules.list() -- Check module call order
hints.root_file = ('named.root')
```
```
$ sudo kresd --version
Knot DNS Resolver, version 1.5.0
```
```
$ sudo /usr/local/sbin/kresd -c /etc/knot-resolver/kresd.conf -v -f 1 -k /etc/knot-resolver/root.keys /var/knot-resolver
[system] bind to 'fe80::25fb:404d:7dd0:3f8b@9953' Invalid argument
[ 0][plan] plan '.' type 'DNSKEY'
[46588][iter] '.' type 'DNSKEY' id was assigned, parent id 0
[46588][resl] => using root hints
[50083][iter] '.' type 'DNSKEY' id was assigned, parent id 0
[50083][resl] => no valid NS left
[ 0][resl] finished: 8, queries: 1, mempool: 81952 B
[ ta ] new state of trust anchors for a domain:
. 172800 DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
[ ta ] new state of trust anchors for a domain:
. 172800 DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
. 172800 DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
error when opening '/etc/knot-resolver//root.hints': failed to open root hints file
```https://gitlab.nic.cz/knot/knot-resolver/-/issues/272tests broken in 1.5.02017-11-14T13:47:55+01:00Ondřej Surýtests broken in 1.5.0```
config-test: hints
/bin/sh: 1: /usr/sbin/kresd: not found
tests/config/test_config.mk:12: recipe for target 'check-config' failed
make[2]: *** [check-config] Error 1
``````
config-test: hints
/bin/sh: 1: /usr/sbin/kresd: not found
tests/config/test_config.mk:12: recipe for target 'check-config' failed
make[2]: *** [check-config] Error 1
```2017 Q4