Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2018-10-31T15:49:37+01:00https://gitlab.nic.cz/knot/knot-resolver/-/issues/258update documentation around cache.clear() and other cache functions2018-10-31T15:49:37+01:00Petr Špačekupdate documentation around cache.clear() and other cache functionsCache rework for #108 will probably affect interface for cache. Hopefully we will get rid of separate interface for negative answers, which is kind of confusing.
Also, I have suspiction that `cache.clear('example.com.')` flushes everyth...Cache rework for #108 will probably affect interface for cache. Hopefully we will get rid of separate interface for negative answers, which is kind of confusing.
Also, I have suspiction that `cache.clear('example.com.')` flushes everything in `example.com.` sub-tree even though documentation suggests that this requires `*.example.com.`.2017 Q3https://gitlab.nic.cz/knot/knot-resolver/-/issues/247migrate code to monotonic timers (as appropriate)2017-12-17T01:10:18+01:00Petr Špačekmigrate code to monotonic timers (as appropriate)Some parts of code use `gettimeofday()` to get real time and compute differences between consecutive calls.
This approach is causing problems when real time changes e.g. as a result of adminisrator's action.
Code which works with t...Some parts of code use `gettimeofday()` to get real time and compute differences between consecutive calls.
This approach is causing problems when real time changes e.g. as a result of adminisrator's action.
Code which works with time differences should use monotonic timers, please see man `gettimeofday`, `clock_gettime`, and docs in libuv - [libuv has its own monotonic timer](http://docs.libuv.org/en/v1.x/loop.html#c.uv_now).
There is some code which needs real time (DNSSEC signature verification, potentially logging etc.) so this needs to stay.
Beware, there are potential gotchas with monotonic clock when the value is transferred between processes or system reboots. Please make sure the monotonic values which get stored somewhere (e.g. in case) will make sense across processes and reboots (or find a way to make them sensical).2017 Q3https://gitlab.nic.cz/knot/knot-resolver/-/issues/228loading root hints from a zonefile2017-12-17T01:10:18+01:00Vladimír Čunátvladimir.cunat@nic.czloading root hints from a zonefileCurrently we only allow loading them from a lua table: http://knot-resolver.readthedocs.io/en/latest/modules.html#c.hints.root but some systems (like Debian) prefer to package the root hints in zonefile format.
We even have lua bindings...Currently we only allow loading them from a lua table: http://knot-resolver.readthedocs.io/en/latest/modules.html#c.hints.root but some systems (like Debian) prefer to package the root hints in zonefile format.
We even have lua bindings `require('zonefile')`, so this should be easy to implement.
After that, we might consider to kill `lib/root-hints.inc` and instead load defaults from a file at start.2017 Q3https://gitlab.nic.cz/knot/knot-resolver/-/issues/108RFC 8198: Aggressive Use of DNSSEC-Validated Cache2021-01-26T10:03:00+01:00Ondřej SurýRFC 8198: Aggressive Use of DNSSEC-Validated CacheImplementing this would probably require some changes in the cache, but I think it will be worthwhile as it creates less work for resolver and less work for authoritative.
Closed by: !422Implementing this would probably require some changes in the cache, but I think it will be worthwhile as it creates less work for resolver and less work for authoritative.
Closed by: !4222017 Q3Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.cz2017-10-31https://gitlab.nic.cz/knot/knot-resolver/-/issues/104RFC 7858: kresd should be able to use TLS on outbound queries when configured...2018-01-08T20:53:51+01:00Daniel Kahn GillmorRFC 7858: kresd should be able to use TLS on outbound queries when configured in forwarding mode.we currently allow policies like:`policy:add(policy.all(policy.FORWARD('192.168.1.1')))`
It would be great if we could do forwarding (stub-to-recursive) over TLS.
I propose something like `policy:add(policy.all(policy.FORWARD('TLS:192....we currently allow policies like:`policy:add(policy.all(policy.FORWARD('192.168.1.1')))`
It would be great if we could do forwarding (stub-to-recursive) over TLS.
I propose something like `policy:add(policy.all(policy.FORWARD('TLS:192.168.1.1')))`, though i'm open to other suggestions for how this would be implemented.2017 Q3Grigorii DemidovGrigorii Demidovhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/277kresd 1.5.0 assertion failure2018-01-08T12:41:41+01:00Marek Vavrusakresd 1.5.0 assertion failureI'm running the server in a test environment in which it's getting a constant stream of random queries.
This is the configuration (sans network interfaces):
```lua
-- Modules
modules = {
'policy', -- Enforce query/response pol...I'm running the server in a test environment in which it's getting a constant stream of random queries.
This is the configuration (sans network interfaces):
```lua
-- Modules
modules = {
'policy', -- Enforce query/response policies
'view', -- Views for certain clients
'hints > iterate', -- Load /etc/hosts and allow custom root hints
'stats', -- Track internal statistics
'predict', -- Prefetch soon-to-expire records
}
-- Cache configuration
cache.open(4096 * MB, env.CACHE_STORAGE)
cache.max_ttl(1 * 3600) -- 1 hour
cache.min_ttl(5) -- 5 seconds
-- DNSSEC configuration
trust_anchors.file = 'root.keys' -- Enable RFC5011
```
The log:
```
2017-11-22T04:33:19.000 host1 error: /usr/local/lib/kdns_modules/predict.lua:34: 'struct rr_type' has no member named 'TYPE65535'
2017-11-22T23:38:20.000 host1 kresd: daemon/io.c:51: session_clear: Assertion `s->outgoing || s->tasks.len == 0' failed.
```2017 Q4https://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 Q4https://gitlab.nic.cz/knot/knot-resolver/-/issues/271tight loop in kresd 1.3.3 after SIGPIPE2017-12-14T18:21:19+01:00Daniel Kahn Gillmortight loop in kresd 1.3.3 after SIGPIPEI'm running kresd 1.3.3, I found it was stuck in a tight loop. here's the output of strace:
```
write(20, "\27\3\3\1\356\0\0\0\0\0\0\0\2H\364\352e\235\t\274\237YF\244\260\250K\223q\211EW"..., 499) = -1 EPIPE (Broken pipe)
--- SIGPIPE ...I'm running kresd 1.3.3, I found it was stuck in a tight loop. here's the output of strace:
```
write(20, "\27\3\3\1\356\0\0\0\0\0\0\0\2H\364\352e\235\t\274\237YF\244\260\250K\223q\211EW"..., 499) = -1 EPIPE (Broken pipe)
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=24582, si_uid=110} ---
write(20, "\27\3\3\1\356\0\0\0\0\0\0\0\2H\364\352e\235\t\274\237YF\244\260\250K\223q\211EW"..., 499) = -1 EPIPE (Broken pipe)
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=24582, si_uid=110} ---
```
looking at the open file descriptors with `lsof`, i see:
```
kresd 24582 knot-resolver 18ur REG 0,35 8192 12524 /var/cache/knot-resolver/lock.mdb
kresd 24582 knot-resolver 19u REG 0,35 104857600 12525 /var/cache/knot-resolver/data.mdb
kresd 24582 knot-resolver 20u sock 0,8 0t0 4310946 protocol: TCPv6
```
If i kill and restart the daemon, it will likely work fine again.2017 Q4Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/250RFC 8145: Signaling Trust Anchor Knowledge in DNS Security Extensions (Using ...2017-12-17T01:10:18+01:00Petr ŠpačekRFC 8145: Signaling Trust Anchor Knowledge in DNS Security Extensions (Using the Key Tag Query)We should implement https://tools.ietf.org/html/rfc8145#section-5 . The EDNS thing is not supported by others so it does not make much sense for us to do that.We should implement https://tools.ietf.org/html/rfc8145#section-5 . The EDNS thing is not supported by others so it does not make much sense for us to do that.2017 Q4https://gitlab.nic.cz/knot/knot-resolver/-/issues/230think about signed root-servers.net.2017-12-17T01:10:17+01:00Petr Špačekthink about signed root-servers.net.This is note from a hallway discussion so we do not forget:
Here is a theory that signing `root-servets.net.` domain might raise bar for attackers who want to track clients. Unsigned zone allow attackers to poison cache with IP addresse...This is note from a hallway discussion so we do not forget:
Here is a theory that signing `root-servets.net.` domain might raise bar for attackers who want to track clients. Unsigned zone allow attackers to poison cache with IP addresses of man-in-the-middle root servers servers. These attacker's servers cannot modify answers but they can observe the traffic for potentially long time and potentially track the poisoned recursor as it moves between networks.
So ... What happens when `root-servets.net.` is signed? How do we handle RFC 8109 priming in that case?
For validation we need to get `. DNSKEY`. To get `. DNSKEY` we need to contact root servers. To contact root servers, we need get their IP addresses which are signed by `. DNSKEY` ... and we are back at the beginning.
It might be an option to use hints from disk for first refresh and replace these hints only if the answer was validated, which would probably defend against the attack described above.
Related to: #2202017 Q4https://gitlab.nic.cz/knot/knot-resolver/-/issues/222detect time skew during start2017-12-17T01:10:18+01:00Petr Špačekdetect time skew during startOne of things which is notoricously hard to debug are problems with time.
Based on [user feedback](https://gitter.im/CZ-NIC/knot-resolver?at=596864f2c101bc4e3a834993) I propose to use RRSIG inception and expiration timestmps from primin...One of things which is notoricously hard to debug are problems with time.
Based on [user feedback](https://gitter.im/CZ-NIC/knot-resolver?at=596864f2c101bc4e3a834993) I propose to use RRSIG inception and expiration timestmps from priming query to detect clock skew and log error a message system clock is outside of RRSIG validity interval.
Assumption: Probability that DNS root zone RRSIGs are correct is higher than probability that local system clock is off.2017 Q4https://gitlab.nic.cz/knot/knot-resolver/-/issues/220RFC 8109: Priming queries are not implemented2017-12-17T01:10:17+01:00Petr ŠpačekRFC 8109: Priming queries are not implementedKnot Resolver 1.3.2 is not doing priming queries as specified by Best Current Practice https://tools.ietf.org/html/rfc8109 . We should implement that before Knot resolvers gets massive deployment because it will be hard to update it late...Knot Resolver 1.3.2 is not doing priming queries as specified by Best Current Practice https://tools.ietf.org/html/rfc8109 . We should implement that before Knot resolvers gets massive deployment because it will be hard to update it later on.
Please see #230 before implementing this.
Additional notes:
- maybe it makes sense not to limit default TTL for data from root
- what happens if cache size == 0 or max TTL == 0? We should not create problems like the one described in this [talk DNS Priming Queries 2017](https://indico.dns-oarc.net/event/27/session/5/contribution/21) from DNS-OARC 272017 Q4https://gitlab.nic.cz/knot/knot-resolver/-/issues/106Defensive cache usage in case of upstream outages2018-04-04T16:32:13+02:00Ondřej SurýDefensive cache usage in case of upstream outagesThis is post-Dyn thing. Implement something like this: https://datatracker.ietf.org/doc/draft-wkumari-dnsop-ttl-stretching/
But it might be even easier:
- just don't remove the expired records from cache (for some defined/configurabl...This is post-Dyn thing. Implement something like this: https://datatracker.ietf.org/doc/draft-wkumari-dnsop-ttl-stretching/
But it might be even easier:
- just don't remove the expired records from cache (for some defined/configurable period of time)
- return the record from the cache with TTL 0
- check if the DNSSEC signature is still valid
- schedule refresh in the background
There's an patent from Akamai, that needs to be checked, but the described mechanism is not covered as Akamai checks first and returns the record from cache after upstream timeout.2017 Q4Grigorii DemidovGrigorii Demidov2018-01-31https://gitlab.nic.cz/knot/knot-resolver/-/issues/105kresd should support TLS session resumption (clients should be able to resume...2018-09-20T10:33:46+02:00Daniel Kahn Gillmorkresd should support TLS session resumption (clients should be able to resume sessions if they ask for them)kresd currently does not support TLS session resumption. Whether clients ask for session tickets or session IDs, kresd doesn't offer them.
Whether we want to support session tickets or session IDs (or both), if we want multiple concurr...kresd currently does not support TLS session resumption. Whether clients ask for session tickets or session IDs, kresd doesn't offer them.
Whether we want to support session tickets or session IDs (or both), if we want multiple concurrent daemons listening on the same port to support resuming each others' sessions, we'd need to have a communications channel between the kresd.
The simplest approach is to ignore the possibility of multiple concurrent daemons being able to resume each others' sessions. In this case, some sessions will not be resumed, and they will fall back to a normal handshake, so it shouldn't be any worse than the status quo.
Sharing state between servers runs the risk of leaking session resumption keys to disk, so i think we should defer sharing session resumption state between servers to a separate issue.
Session tickets are much easier to implement -- see `gnutls_session_ticket_key_generate` and `gnutls_session_ticket_enable_server`. The only decision we'd need to make is how frequently to rotate the session ticket key. A first-pass implementation could simply schedule a key rotation every two hours.
future/fancier work could create a configuration option to adjust the frequency of key rotation, or a lua directive to rotate session ticket key.2017 Q4Grigorii DemidovGrigorii Demidovhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/293forwarding: knot doesn't repeat query when receives SERVFAIL or REFUSE answer.2018-02-02T18:19:18+01:00Grigorii Demidovforwarding: knot doesn't repeat query when receives SERVFAIL or REFUSE answer.2018 Q1https://gitlab.nic.cz/knot/knot-resolver/-/issues/285Knot resolver 1.5.1 hangs doing dns over tls on port 853 in a tight loop on S...2018-01-08T12:41:15+01:00JohnKnot resolver 1.5.1 hangs doing dns over tls on port 853 in a tight loop on SIGPIPEKnot resolver 1.5.1 crashed doing dns over tls on port 853
```
Program received signal SIGPIPE, Broken pipe.
0x00007f91958144a0 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:84
84 ../sysdeps/unix/syscall-template.S: No suc...Knot resolver 1.5.1 crashed doing dns over tls on port 853
```
Program received signal SIGPIPE, Broken pipe.
0x00007f91958144a0 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:84
84 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0 0x00007f91958144a0 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007f9195a33a93 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#2 0x00007f9195a35514 in uv_write2 () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#3 0x00007f9195a355f5 in uv_try_write () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#4 0x00005646d9e8fc67 in kres_gnutls_push (h=<optimized out>, buf=<optimized out>, len=<optimized out>) at daemon/tls.c:75
#5 0x00007f91952640f5 in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30
#6 0x00007f9195264782 in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30
#7 0x00007f919525f675 in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30
#8 0x00007f91952618b1 in gnutls_record_send () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30
#9 0x00007f9195261988 in gnutls_record_uncork () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30
#10 0x00005646d9e8fdab in tls_push (task=<optimized out>, handle=<optimized out>, pkt=pkt@entry=0x5646db0d4908)
at daemon/tls.c:220
#11 0x00005646d9e8a0a0 in qr_task_send (task=task@entry=0x5646db0d30b0, handle=0x5646db0defb0, addr=addr@entry=0x5646db0d3250,
pkt=0x5646db0d4908) at daemon/worker.c:487
#12 0x00005646d9e8a31f in qr_task_finalize (task=0x5646db0d30b0, state=4) at daemon/worker.c:733
#13 0x00005646d9e8aa0e in qr_task_step (task=0x5646db0d30b0, packet_source=packet_source@entry=0x7ffc48c3b580,
packet=0x5646dad92510) at daemon/worker.c:761
#14 0x00005646d9e8b240 in worker_submit (worker=worker@entry=0x7f9196478010, handle=handle@entry=0x5646db0d71b0,
msg=<optimized out>, addr=addr@entry=0x7ffc48c3b580) at daemon/worker.c:885
#15 0x00005646d9e8587b in udp_recv (handle=0x5646db0d71b0, nread=<optimized out>, buf=<optimized out>, addr=0x7ffc48c3b580,
flags=<optimized out>) at daemon/io.c:152
#16 0x00007f9195a37999 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#17 0x00007f9195a396d8 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#18 0x00007f9195a2b0ac in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#19 0x00005646d9e85477 in run_worker (control_fd=-1, leader=true, ipc_set=0x7ffc48c3e8b0, engine=0x7ffc48c3e8f0,
loop=0x7f9195c43760) at daemon/main.c:407
#20 main (argc=<optimized out>, argv=<optimized out>) at daemon/main.c:759
```2018 Q1https://gitlab.nic.cz/knot/knot-resolver/-/issues/281asynchronous shared cache support2018-05-14T10:10:12+02:00Marek Vavrusaasynchronous shared cache supportI'm going to roughly do this:
* At the end of each request, gather records from `req.answ_selected` and `req.auth_selected` that have been written to cache
* Put these records into a DNS message, set record CLASS to rank, and send to a ...I'm going to roughly do this:
* At the end of each request, gather records from `req.answ_selected` and `req.auth_selected` that have been written to cache
* Put these records into a DNS message, set record CLASS to rank, and send to a multicast address
* Create a background worker in the module using `event.socket()` for non-blocking waits like the `http` module
* The worker would pick up the messages from the multicast address and call `kr_cache_insert` to update local caches2018 Q1Marek VavrusaMarek Vavrusahttps://gitlab.nic.cz/knot/knot-resolver/-/issues/274failure to validate No Data response for explicit wildcard2018-08-04T11:53:46+02:00Jan Včelákfailure to validate No Data response for explicit wildcardkresd 1.5.0 fails to validate No Data response for explicit wildcard.
Query for an existent type:
```
$ kdig @::1 -p 53530 +tcp +adflag \*.wc.dnssec.test +dnssec TXT
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 41557
;; Flags: q...kresd 1.5.0 fails to validate No Data response for explicit wildcard.
Query for an existent type:
```
$ kdig @::1 -p 53530 +tcp +adflag \*.wc.dnssec.test +dnssec TXT
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 41557
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 4096 B; ext-rcode: NOERROR
;; QUESTION SECTION:
;; *.wc.dnssec.test. IN TXT
;; ANSWER SECTION:
*.wc.dnssec.test. 1200 IN TXT "wc"
*.wc.dnssec.test. 1200 IN RRSIG TXT 13 3 1200 20171124132134 20171110132134 59809 dnssec.test. X45WDd9WkTnhlB60DImXo7pdNirsaQc/wTnR5ccJJglAypL121DkvkuMJmbYCWvt1O+U+ycVAKQznmF7D/DyTg==
;; Received 163 B
;; Time 2017-11-13 16:02:29 CET
;; From ::1@53530(TCP) in 41.5 ms
```
Query for a non-existent type:
```
$ kdig @::1 -p 53530 +tcp +adflag \*.wc.dnssec.test +dnssec AAAA
;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 43702
;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
;; QUESTION SECTION:
;; *.wc.dnssec.test. IN AAAA
;; Received 32 B
;; Time 2017-11-13 16:02:37 CET
;; From ::1@53530(TCP) in 45.2 ms
```
kresd trace:
```
[21405][iter] <= answer received:
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 21405
;; Flags: qr aa QUERY: 1; ANSWER: 0; AUTHORITY: 4; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 4096 B; ext-rcode: Unused
;; QUESTION SECTION
*.wc.dnssec.test. AAAA
;; AUTHORITY SECTION
dnssec.test. 1200 SOA a.ns.fcelda.cz. hostmaster.fcelda.cz. 344 3600 1800 2678400 1200
*.wc.dnssec.test. 1200 NSEC no.wc.dnssec.test. TXT RRSIG NSEC
dnssec.test. 1400 RRSIG SOA 13 2 1400 20171124142134 20171110142134 59809 dnssec.test. 0n0ZDgLbhEJTmcbxR6V50T1Xk+39xo8vEzjnEcIdI+m/2fWWw45/MrRU/H5oT8y+LrtFu/wiFI0crvj+lH6NbQ==
*.wc.dnssec.test. 1200 RRSIG NSEC 13 3 1200 20171124132134 20171110132134 59809 dnssec.test. wwOzuf0QBcv1w7WBHlIMvxwZi0cPXDGfYRjxnXUaHx87ekMdislJwk+6Dc1kY8wjA24TAkvY9ViYHUHAikl1aQ==
[21405][iter] <= rcode: NOERROR
[21405][vldr] <= bad NODATA proof
```2018 Q1https://gitlab.nic.cz/knot/knot-resolver/-/issues/255CI: test with burst traffic2018-10-18T14:23:02+02:00Petr ŠpačekCI: test with burst trafficWe should have a short sanity check which replays burst traffic to kresd for limited amount of time (e.g. couple minutes) to make sure it does not crash under heavy load.
Proposal:
- add [Drool](https://github.com/DNS-OARC/drool) into C...We should have a short sanity check which replays burst traffic to kresd for limited amount of time (e.g. couple minutes) to make sure it does not crash under heavy load.
Proposal:
- add [Drool](https://github.com/DNS-OARC/drool) into CI Docker image
- prepare PCAP file with limited amount of traffic taken from CZ.NIC's public resolver
- replay traffic using Drool's strategy `timing ignore` so it is replayed as fast as possible
- test whether kresd crashed or not2018 Q1Tomas KrizekTomas Krizekhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/148Cache pre-filling mechanism2018-05-03T14:34:03+02:00Vladimír Čunátvladimir.cunat@nic.czCache pre-filling mechanismThis is going to be done after agressive NSEC/NSEC3 caching.This is going to be done after agressive NSEC/NSEC3 caching.2018 Q12018-04-30