Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2020-11-30T17:52:59+01:00https://gitlab.nic.cz/knot/knot-resolver/-/issues/537module API redesign2020-11-30T17:52:59+01:00Petr Špačekmodule API redesignProblem statement
-----------------
- Current module API is not well defined and does not provide sufficient abstraction
- As a result, modules are not isolated and must know about internals of other modules (e.g. modules resetting reque...Problem statement
-----------------
- Current module API is not well defined and does not provide sufficient abstraction
- As a result, modules are not isolated and must know about internals of other modules (e.g. modules resetting request state must also reset `req.*_selected` arrays)
- Mixing wire-format-generating modules with modules relying on `req.*_selected` arrays leads to weird bugs (one example: !842, !851, !859)
- Lua modules seem to be slow (because of the way how C code calls Lua?)
Related tickets
---------------
- #363 Modules need generic way to persist own state
- #432 Modules need ability to not respond at all (for response rate limiting)
- #483 Modules currently cannot generate answer if no NS is responding
- #447 New server selection system should expose and use API instead of being hard-wired
- #396 SERVFAIL answer can still contain bogus RRsets
- #471 low-level protocol stuff is hard-coded (incorrectly)
- #36 make sure new API does not get in the way when implementing parallel queries
- #527 modules need a way to cooperate with fine-grained logging
- #418 engine object access - I don't know if this requirement will be still valid after redesign, but let's think about it
- #264 error reporing from modules sucks
- #234 a way to cooperate between modules??? e.g. for DNAME support???
- attempt to move `reorder_RR()` into module, ideally in a form of policy action so it can be triggered on per-client basis - what API would be necessary?
Objective
---------
Design a new API for modules in a way which prevents bugs stemming from bad API usage from ever repeating again.
Implementation is expected to be a long-term project, but we need proper design first. Hopefully #447, #535 and other tasks planned for 2020 will provide us sufficient experience for better API design.2020 Q4https://gitlab.nic.cz/knot/knot-resolver/-/issues/536declarative config - experiments with sysrepo2020-10-09T19:18:24+02:00Petr Špačekdeclarative config - experiments with sysrepoProblem statement
-----------------
Current configuration is practically a Lua program, which is a nightmare for multiple reasons:
- non-programmers have hard time understanding what is going on
- Lua language makes it hard to detect mis...Problem statement
-----------------
Current configuration is practically a Lua program, which is a nightmare for multiple reasons:
- non-programmers have hard time understanding what is going on
- Lua language makes it hard to detect mistakes in config
- run-time reconfiguration requires doing each change N times for N processes
- gathering statistics from multiple processes is total pain
- currently it exposes low-level stuff and it prone to crashes on invalid use (#182)
Experiment
----------
Do some preliminary experiments with sysrepo and see if it improves situation sufficiently to make it worth investing into it more.
Objectives
----------
- experimental mode - sysrepo **must not** become a hard dependency of Knot Resolver
- put as much code as possible into separate (and optional) module
- minimize code duplication
- current Lua config must work the same way as it did before, sysrepo only complements the Lua config
Once we have sufficient experience with implementation of sysrepo into kresd we will revisit pros and cons and decide what to do next.
Requirements for next stages
----------------------------
- sysrepo+libyang must be widely available in distros we care about
- sysrepo+libyang must be sufficiently stable
- sysrepo must allow us to build a new user interface with a reasonable complexity
Ideas to try
------------
- [x] build module to translate sysrepo callbacks to Lua config calls
- [x] build command line client which can display and edit declarative config in a text format (probably YAML to make it similar to Knot DNS)2020 Q3https://gitlab.nic.cz/knot/knot-resolver/-/issues/535declarative policy module and other user-supplied DNS data2024-02-28T12:15:39+01:00Petr Špačekdeclarative policy module and other user-supplied DNS dataCurrent problem
---------------
Our current imperative policy module is using chain of Lua functions: This is quite slow and hard to use for non-programmers.
Proposal
--------
Design a new method to configure "policies", preferably in a...Current problem
---------------
Our current imperative policy module is using chain of Lua functions: This is quite slow and hard to use for non-programmers.
Proposal
--------
Design a new method to configure "policies", preferably in a declarative way. By "policies" I mean a generic way to influence resolving and inject user-supplied data into DNS tree or block other stuff.
A declarative way should be more intuitive to use than writing Lua functions, and also faster if we design it right.
Here is incomplete list of stuff we might want to express.
- [x] ability to also block sub-queries, e.g. when following CNAMEs (#217)
- [ ] ability to block RR data - e.g. rebinding protection, blacklist of NS names etc. (#523)
- [x] ACLs (including negative ACLs, #370)
- [x] merge views with other policies (see also #445)?
- [x] redirecting specific zones to user-configured servers (#428, !651)
- [ ] beware that we need also port number, not just IP address
- [x] theoretical "helper" NS+glue records from kresd config should not be retrievable from outside
- FORWARDing
- TLS forwarding has many knobs and might need even more: #481
- do we still need STUB policy? If so see #218
- FORWARDing might need exceptions for some subtrees (see e.g. https://lists.nlnetlabs.nl/pipermail/unbound-users/2019-December/006560.html)
- generally special EDNS tricks: #314, #303; also improve #657
- special cache semantics (do not cache this sub-tree, limit TTL in this sub-tree)
- maybe DNS64 module should be merged with policies and ACLs: #368
- [x] maybe hints module should be merged in as well (see also #205, #349)
- [x] maybe also a way to provide other user-supplied data - #540
* (well, more ways can always be added)
- maybe prefill module should be merged as well (see also #417)
- think of interaction with daf module (beware of #183)
* `@vcunat` would prefer to deprecate DAF,
but theoretically we could think of translating DAF rules into the new policy rules
- design should be able to support full strength of RPZ (example of a problem: #194)
* the most common features are in 6.0.x – CNAME redirection in particular, and interacting well with other rules (multiple rules of different kinds can trigger when jumping through CNAME chains)
- design needs to support efficient mechanism which mimicks RPZ with zone transfer including IXFR(!) (#195)
- build mechanism for better visibility into policies (#364)
- it needs to work with huge lists (apparently users want to have long block lists, see https://lists.nlnetlabs.nl/pipermail/unbound-users/2019-December/006559.html)
* improved in 6.0.x: shared inside LMDB across all processes, but efficiency of restarts/reloads/updates could be significantly improved (as of 6.0.6)
- [x] open question: at which stage should the module kick in? Can it be e.g. used to implement `ignore-cd-flag` policy as seen in Unbound?
* the `view:` part can be used to set such options, though there's no ignore-cd in particular so far
- per-domain setting for rate-limits e.g. like `ratelimit-below-domain`, `ratelimit-for-domain` etc. like in Unbound
* [ ] first per-user changes in rate-limits in `views:` (when we have any rate-limiting)
- [x] special handling for reserved and local-only names: see #205 and think it through2020 Q2https://gitlab.nic.cz/knot/knot-resolver/-/issues/534CI: test server selection algorithm2019-12-18T19:41:28+01:00Petr ŠpačekCI: test server selection algorithmImplement https://gitlab.labs.nic.cz/knot/maze/ into Knot Resolver's CI.
Ideas:
- Gitlab shell executor in a VM with sudo access (yuck!)
- shell executor to a VM with a systemd build which contains https://github.com/systemd/systemd/pul...Implement https://gitlab.labs.nic.cz/knot/maze/ into Knot Resolver's CI.
Ideas:
- Gitlab shell executor in a VM with sudo access (yuck!)
- shell executor to a VM with a systemd build which contains https://github.com/systemd/systemd/pull/138232020 Q1Štěpán BalážikŠtěpán Balážikhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/533AF_XDP optimization2020-11-16T09:37:50+01:00Petr ŠpačekAF_XDP optimizationExplore and implement prototype of AF_XDP network stack optimization.Explore and implement prototype of AF_XDP network stack optimization.2020 Q2Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/447rewrite server selection system2020-12-31T17:01:44+01:00Petr Špačekrewrite server selection systemCurrent server selection mechanism is not well defined, and sometimes exhibits hard-to-debug quirks. This is ticket for collecting ideas what we need from a proper server selection system.
Caveats
-------
- **look for an existing litera...Current server selection mechanism is not well defined, and sometimes exhibits hard-to-debug quirks. This is ticket for collecting ideas what we need from a proper server selection system.
Caveats
-------
- **look for an existing literature about server selection!**
- **forwarding and iteration probably need different algorithms!**
- **what should be the overall criteria?** lowest RTT? reliability? lowest RTT when taking reliability into account? :-)
- can we map this to multi-armed bandit (or some other) model in statistics?
- verify that it is okay to operate with *server == IP address* mapping
- multiple NS names can map to a single IP address
- NS names are probably not significant, properties could be associated with IP addresses
- think about unresolved NS names/incomplete glue
- consider lazy NS name -> IP address resolving if we have enough working servers
- what about anycast nodes with different properties? is it worth considering, or just unsupported configuration? read related RFCs about anycast DNS operation
- server selection probably needs to include *transport protocol* selection for each IP address - UDP, TCP, TLS, DTLS, QUIC, DoH, ...
- some errors (REFUSED, SERVFAIL, ...) are not property of an IP address but in fact are property of (IP address, zone) pair
- e.g. one lame delegation to a name server of big web hosting company should not penalize NS IP address as whole
- transport protocols are likely to have different properties/statistics - RTT, reliability, etc.
- think about TLS-to-auth auto discovery
- how can we incorporate https://tools.ietf.org/html/draft-ietf-dnsop-extended-error draft?
- properties can change over time so our stats need to expire
Ideas for attributes
====================
IP address
----------
- supported EDNS version version (to avoid FORMERR loops, but maybe we need only per-query state ...)
- supported transport protocols (TLS configuration etc.)
- DNS cookies
(IP address, protocol)
----------------------
- RTT
- transport layer "reliability" (maybe timeouts should not be mixed with RTT ...)
- transport protocol information (cached TLS certificate, session resumption, 0-RTT data support, ...)
(IP address, zone)
------------------
- usefulness - ok, SERVFAIL, REFUSED, BOGUS (lame delegations, expired zone data etc.)
Obviously storing (server, zone) attributes might lead to state explosion. We need to think twice about this. Maybe there is a way to optimize, e.g. store only "broken" (server, zone) pairs so we can penalize these during server selection but do not bother with vast majority of "working" pairs.
Assorted ideas
--------------
Serve stale
- timestamp of last attempt
- SERVFAIL a ok per server?
- counters for DoS mitigation (query per zone per server or ...)2020 Q2Štěpán BalážikŠtěpán Balážikhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/384NSEC3 caching doesn't seem to work2018-07-27T19:48:16+02:00Marek VavrusaNSEC3 caching doesn't seem to workI was trying the aggressive NSEC3 caching in the v2.4.0 tag (4141975d2f8d5c2e45cc319de20af356eb2a8b3e).
```
$ cat config # Empty configuration
$ rm *.mdb
$ kresd -a 127.0.0.1#5354 -k root.keys -v
[tls] session ticket: epoch 374032, sch...I was trying the aggressive NSEC3 caching in the v2.4.0 tag (4141975d2f8d5c2e45cc319de20af356eb2a8b3e).
```
$ cat config # Empty configuration
$ rm *.mdb
$ kresd -a 127.0.0.1#5354 -k root.keys -v
[tls] session ticket: epoch 374032, scheduling rotation check in 3276245 ms
[ ta ] new state of trust anchors for a domain: . 172800 DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
[ ta ] new state of trust anchors for a domain: . 172800 DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
. 172800 DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
[system] interactive mode
>
```
When I query for a name that exists, caching seems to work:
```
$ kdig @127.0.0.1 -p 5354 nic.cz | grep From
;; From 127.0.0.1@5354(UDP) in 870.8 ms
$ kdig @127.0.0.1 -p 5354 nic.cz | grep From
;; From 127.0.0.1@5354(UDP) in 0.2 ms
```
When I query for a name that doesn't exist, caching doesn't seem to work:
```
$ kdig @127.0.0.1 -p 5354 bla2.nic.cz | grep From
;; From 127.0.0.1@5354(UDP) in 1208.7 ms
$ kdig @127.0.0.1 -p 5354 bla2.nic.cz | grep From
;; From 127.0.0.1@5354(UDP) in 412.8 ms
```
Here's the server log:
```
[ 0][plan] plan 'bla2.nic.cz.' type 'A'
[63031][iter] 'bla2.nic.cz.' type 'A' id was assigned, parent id 0
[63031][cach] => no NSEC* cached for zone: cz.
[63031][zcut] found cut: cz. (rank 002 return codes: DS 0, DNSKEY 0)
[29651][iter] 'bla2.nic.cz.' type 'A' id was assigned, parent id 0
[29651][resl] => querying: '194.0.13.1' score: 95 zone cut: 'cz.' qname: 'NiC.cZ.' qtype: 'NS' proto: 'udp'
[29651][resl] => querying: '2001:678:10::1' score: 95 zone cut: 'cz.' qname: 'NiC.cZ.' qtype: 'NS' proto: 'udp'
[29651][iter] <= rcode: NOERROR
[29651][iter] <= continuing with qname minimization
[29651][resl] <= server: '194.0.13.1' rtt: 175 ms
[28702][iter] 'bla2.nic.cz.' type 'A' id was assigned, parent id 0
[28702][plan] plan 'nic.cz.' type 'DS'
[40723][iter] 'nic.cz.' type 'DS' id was assigned, parent id 28702
[40723][cach] => satisfied by exact RRset: rank 060, new TTL 3513
[40723][iter] <= rcode: NOERROR
[40723][vldr] <= DS: OK
[40723][vldr] <= parent: updating DS
[40723][vldr] <= answer valid, OK
[60915][iter] 'bla2.nic.cz.' type 'A' id was assigned, parent id 0
[60915][plan] plan 'nic.cz.' type 'DNSKEY'
[ 5674][iter] 'nic.cz.' type 'DNSKEY' id was assigned, parent id 60915
[ 5674][cach] => satisfied by exact RRset: rank 060, new TTL 1713
[ 5674][iter] <= rcode: NOERROR
[ 5674][vldr] <= parent: updating DNSKEY
[ 5674][vldr] <= answer valid, OK
[29278][iter] 'bla2.nic.cz.' type 'A' id was assigned, parent id 0
[29278][resl] => query[29278][resl] => querying: '2001:678:f::1' score: 11 zone cut: 'nic.cz.' qname: 'BLa2.Nic.Cz.' qtype: 'A' proto: 'udp'
[29278][iter] <= rcode: NXDOMAIN
[29278][vldr] <= answer valid, OK
[29278][cach] => stashed 61irsbhhtmb5arro3jt924s607pojbnu.nic.cz. NSEC3, rank 060, 149 B total, incl. 1 RRSIGs
[29278][cach] => stashed 7cnkran8antk3fkqoiivftbr83c4fk16.nic.cz. NSEC3, rank 060, 141 B total, incl. 1 RRSIGs
[29278][cach] => stashed 038c9fesqq3ofr3cefq91hji5h3mq5mc.nic.cz. NSEC3, rank 060, 150 B total, incl. 1 RRSIGs
[29278][cach] => stashed nic.cz. SOA, rank 060, 159 B total, incl. 1 RRSIGs
[29278][cach] => nsec_p stash skipped (extra TTL: 88)
[29278][resl] <= server: '194.0.12.1' rtt: 169 ms
[ 0][resl] AD: request classified as SECURE
[29278][resl] finished: 4, queries: 3, mempool: 82000 B
[ 0][plan] plan 'bla2.nic.cz.' type 'A'
[24186][iter] 'bla2.nic.cz.' type 'A' id was assigned, parent id 0
[24186][cach] => no NSEC* cached for zone: cz.
[24186][zcut] found cut: cz. (rank 002 return codes: DS 0, DNSKEY 0)
[ 390][iter] 'bla2.nic.cz.' type 'A' id was assigned, parent id 0
[ 390][resl] => querying: '194.0.12.1' score: 90 zone cut: 'cz.' qname: 'NIc.cZ.' qtype: 'NS' proto: 'udp'
[ 390][resl] => querying: '2001:678:f::1' score: 90 zone cut: 'cz.' qname: 'NIc.cZ.' qtype: 'NS' proto: 'udp'
[ 390][iter] <= rcode: NOERROR
[ 390][iter] <= continuing with qname minimization
[ 390][resl] <= server: '194.0.12.1' rtt: 180 ms
[21470][iter] 'bla2.nic.cz.' type 'A' id was assigned, parent id 0
[21470][plan] plan 'nic.cz.' type 'DS'
[60687][iter] 'nic.cz.' type 'DS' id was assigned, parent id 21470
[60687][cach] => satisfied by exact RRset: rank 060, new TTL 3512
[60687][iter] <= rcode: NOERROR
[60687][vldr] <= DS: OK
[60687][vldr] <= parent: updating DS
[60687][vldr] <= answer valid, OK
[31813][iter] 'bla2.nic.cz.' type 'A' id was assigned, parent id 0
[31813][plan] plan 'nic.cz.' type 'DNSKEY'
[52521][iter] 'nic.cz.' type 'DNSKEY' id was assigned, parent id 31813
[52521][cach] => satisfied by exact RRset: rank 060, new TTL 1712
[52521][iter] <= rcode: NOERROR
[52521][vldr] <= parent: updating DNSKEY
[52521][vldr] <= answer valid, OK
[47111][iter] 'bla2.nic.cz.' type 'A' id was assigned, parent id 0
[47111][resl] => query[47111][resl] => querying: '194.0.14.1' score: 116 zone cut: 'nic.cz.' qname: 'bla2.Nic.cZ.' qtype: 'A' proto: 'udp'
[47111][iter] <= rcode: NXDOMAIN
[47111][vldr] <= answer valid, OK
[47111][cach] => stashed 61irsbhhtmb5arro3jt924s607pojbnu.nic.cz. NSEC3, rank 060, 149 B total, incl. 1 RRSIGs
[47111][cach] => stashed 7cnkran8antk3fkqoiivftbr83c4fk16.nic.cz. NSEC3, rank 060, 141 B total, incl. 1 RRSIGs
[47111][cach] => stashed 038c9fesqq3ofr3cefq91hji5h3mq5mc.nic.cz. NSEC3, rank 060, 150 B total, incl. 1 RRSIGs
[47111][cach] => stashed nic.cz. SOA, rank 060, 159 B total, incl. 1 RRSIGs
[47111][cach] => nsec_p stash skipped (extra TTL: 89)
[47111][resl] <= server: '2001:678:11::1' rtt: 157 ms
[ 0][resl] AD: request classified as SECURE
[47111][resl] finished: 4, queries: 3, mempool: 82000 B
```
When I clear cache and restart the daemon, the caching sometimes works, but most of the time it doesn't. That's strange.
I was trying to test aggressive NSEC3 caching originally with bla3, bla4, bla5, ... bla10.nic.cz, but it doesn't seem to work even when I ask the same name repetitively, so I'm not sure what am I doing wrong.
cc @anb @pspacek @vcunat2018 Q3Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/367daemon refactoring 20182018-12-17T13:28:37+01:00Petr Špačekdaemon refactoring 2018Current kresd daemon is hard to maintain and extend as we have seen when introducting TLS client during end of 2017 and beginning of 2018.
We need to refactor the daemon to:
- [x] get rid of copy&pasted code
- [x] split connection handl...Current kresd daemon is hard to maintain and extend as we have seen when introducting TLS client during end of 2017 and beginning of 2018.
We need to refactor the daemon to:
- [x] get rid of copy&pasted code
- [x] split connection handling to smaller functions with proper documentation of conditions
- [x] possibly share connection management between TCP and TLS
- [x] do something about `qr_task_step()` in particular https://gitlab.labs.nic.cz/knot/knot-resolver/issues/245
- prepare structure which can accomodate new features.
**This is a thought experiment to force us to think about generics, we are not going to implement this list** as it is:
- [x] transport like DTLS
- [x] actual structure of daemon allows to implement this without larger changes
- [ ] transports like [DNS-over-HTTP](https://tools.ietf.org/html/draft-ietf-doh-dns-over-https)
- [ ] transports like DNS-over-QUIC
- [ ] Highly depends on structure of available QUIC implementations. https://github.com/quicwg/base-drafts/wiki/Implementations Additional research required.
- [ ] [DNS Transport over TCP - Implementation Requirements](https://tools.ietf.org/html/rfc7766)
- [x] `libuv` [doesn't support client-side TCP fast-open](https://github.com/libuv/libuv/pull/1136). Other requirements have either already been implemented or can be implemented without significant structural changes.
- [x] [The edns-tcp-keepalive EDNS0 Option](https://tools.ietf.org/html/rfc7828)
- [x] no significant changes required
- [ ] ability to keep TCP/TLS connections open until we approach limit for number of open connections
- [x] Requies minor refactoring to minimize access time to certain internal structures (qtrie should be used instead of array_t). It must be done anyway. Expected complexity - low. However, profiling is highly recommended.
- [ ] passive DNS - ability to send out information about cache misses to some external database
- [ ] Complexity depends on the sending strategy; some clarificatoins needed.
- [x] [ATR: Additional Truncation Response for Large DNS Response](http://tools.ietf.org/html/draft-song-atr-large-resp)
- [x] Daemon doesn't require changes in existing structures, but it is necessary to add some additional structures. Expected level of complexity - minor up to meduim.
- [ ] distributed cache (? multicast); older discussions: https://gitlab.labs.nic.cz/knot/knot-resolver/issues/276 and linked
- [ ] it would be better if we made this outside of the daemon
- [x] proper NOTIMP answers for unsupported opcodes and message structures (e.g. when a [DNS Stateful Operation](https://tools.ietf.org/html/draft-ietf-dnsop-session-signal) is received). #225
- [x] no significant changes required
- [ ] parallel queries #36
- [x] requires a lot of work
- [ ] support for rate-limiting, in some form
- [ ] it doesn't belongs to the daemon
It is important to keep in mind that some of these features (e.g. ATR) could be solved outside of kresd itself and it might be okay to say "no, this does not fit into the resolver".2018 Q4https://gitlab.nic.cz/knot/knot-resolver/-/issues/358update sentinel implementation to draft-ietf-dnsop-kskroll-sentinel-142018-06-25T18:38:22+02:00Petr Špačekupdate sentinel implementation to draft-ietf-dnsop-kskroll-sentinel-14Implement https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-14 + testsImplement https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-14 + tests2018-06-30https://gitlab.nic.cz/knot/knot-resolver/-/issues/351migrate to libknot 2.72018-08-14T14:02:06+02:00Petr Špačekmigrate to libknot 2.7It is not necessary to support libknot 2.6 at the same time, just migrate to the new code.
Expected outcome:
- better resource utilization and performanceIt is not necessary to support libknot 2.6 at the same time, just migrate to the new code.
Expected outcome:
- better resource utilization and performance2018 Q3Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/350migrate to a standard build system2019-03-12T12:12:25+01:00Petr Špačekmigrate to a standard build systemThe current build system is a mess and confuses users. Something standard (autotools? meson? something else?) would be more familiar and could solve some of these issues "for free":
- #338
- #212 (maybe we should remove support for stat...The current build system is a mess and confuses users. Something standard (autotools? meson? something else?) would be more familiar and could solve some of these issues "for free":
- #338
- #212 (maybe we should remove support for static build)
- #290
- #267
Also something which can gather some parts of C headers for further use in Lua FFI would be useful.4.0.0Tomas KrizekTomas Krizek2019-06-30https://gitlab.nic.cz/knot/knot-resolver/-/issues/336crash while processing malformed query with 0 question with OPT2018-05-31T10:23:09+02:00vendemiatcrash while processing malformed query with 0 question with OPT```
(gdb) bt
#0 knot_wire_is_pointer (pos=0x557aac60607c "\300\f") at ./libknot/packet/wire.h:901
#1 knot_wire_get_pointer (pos=0x557aac60607c "\300\f") at libknot/packet/wire.c:122
#2 0x00007f6bee68c105 in knot_wire_seek_label (wire=...```
(gdb) bt
#0 knot_wire_is_pointer (pos=0x557aac60607c "\300\f") at ./libknot/packet/wire.h:901
#1 knot_wire_get_pointer (pos=0x557aac60607c "\300\f") at libknot/packet/wire.c:122
#2 0x00007f6bee68c105 in knot_wire_seek_label (wire=0x557aac605ff0 "", lp=<optimized out>) at ./libknot/packet/wire.h:910
#3 knot_wire_next_label (wire=0x557aac605ff0 "", lp=<optimized out>) at ./libknot/packet/wire.h:920
#4 knot_dname_labels (name=<optimized out>, pkt=0x557aac605ff0 "") at libknot/dname.c:781
#5 0x00007f6bee68e7e8 in knot_pkt_put (pkt=0x557aac5c9760, compr_hint=<optimized out>, rr=0x557aac5c9868, flags=<optimized out>)
at libknot/packet/pkt.c:563
#6 0x00007f6bee9254e9 in kr_resolve_finish () from /usr/local/lib/libkres.so.6
#7 0x0000557aa81ecb26 in ?? ()
#8 0x0000000000000106 in ?? ()
#9 0x0000557aac5c7eb0 in ?? ()
#10 0x0000000000000106 in ?? ()
#11 0x0000000000000008 in ?? ()
#12 0x00007f6beedad010 in ?? ()
#13 0x0000557aa81edae9 in ?? ()
#14 0x0000000000000000 in ?? ()
(gdb) f 5
#5 0x00007f6bee68e7e8 in knot_pkt_put (pkt=0x557aac5c9760,
compr_hint=<optimized out>, rr=0x557aac5c9868, flags=<optimized out>)
at libknot/packet/pkt.c:563
563 libknot/packet/pkt.c: No such file or directory.
(gdb) print pkt
$4 = (knot_pkt_t *) 0x557aac5c9760
(gdb) print *pkt
$5 = {wire = 0x557aac605ff0 "", size = 12, max_size = 65535, parsed = 0,
reserved = 0, qname_size = 0, rrset_count = 0, flags = 2,
opt_rr = 0x557aac5c9868, tsig_rr = 0x0, tsig_wire = {pos = 0x0, len = 0},
current = KNOT_ADDITIONAL, sections = {{pkt = 0x557aac5c9760, pos = 0,
count = 0}, {pkt = 0x557aac5c9760, pos = 0, count = 0}, {
pkt = 0x557aac5c9760, pos = 0, count = 0}}, rrset_allocd = 16,
rr_info = 0x557aac5c9898, rr = 0x557aac5c9ad8, mm = {ctx = 0x557aac5c7e40,
alloc = 0x557aa81faee0 <mp_alloc>, free = 0x0}, compr = {
wire = 0x557aac605ff0 "", rrinfo = 0x557aac5c9898, suffix = {pos = 12,
labels = 0 '\000'}}}
(gdb) print rr
$6 = (const knot_rrset_t *) 0x557aac5c9868
(gdb) print *rr
$7 = {owner = 0x557aac5c9860 "", type = 41, rclass = 1536, rrs = {
rr_count = 1, data = 0x557aac5c9890 ""}, additional = 0x0}
```
it shouldnt read qname if it's not there
https://github.com/CZ-NIC/knot/blob/master/src/libknot/packet/pkt.c#L522
cc @vavrusam @anbGrigorii DemidovGrigorii Demidovhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/335knot-resolver 2.2.0 segfault when malformed response, which has label "\000".2018-05-31T10:16:51+02:00Toshifumi Sakaguchiknot-resolver 2.2.0 segfault when malformed response, which has label "\000".## Overview
Knot-resolver crashes when malformed response is received from a malicious
authoritative server in my test(fuzzing) environment.
response from authoritative server.
```
;; QUESTION SECTION:
;www.example.com. IN A
;; AUT...## Overview
Knot-resolver crashes when malformed response is received from a malicious
authoritative server in my test(fuzzing) environment.
response from authoritative server.
```
;; QUESTION SECTION:
;www.example.com. IN A
;; AUTHORITY SECTION:
www.example.com. 600 IN NS \000.example.com.
;; ADDITIONAL SECTION:
\000.example.com. 600 IN A 192.168.33.101
```
message at crach.
```
# /usr/local/sbin/kresd -c /usr/local/etc/knot-resolver/kresd.conf
[system] interactive mode
> Segmentation fault
```
debugger output.
```
# gdb /usr/local/sbin/kresd
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7_4.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/sbin/kresd...(no debugging symbols found)...done.
(gdb) run -c /usr/local/etc/knot-resolver/kresd.conf
Starting program: /usr/local/sbin/kresd -c /usr/local/etc/knot-resolver/kresd.conf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[system] interactive mode
>
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7947488 in knot_dname_lf () from /lib64/libknot.so.7
Missing separate debuginfos, use: debuginfo-install glibc-2.17-196.el7_4.2.x86_64 gmp-6.0.0-15.el7.x86_64 gnutls-3.3.26-9.el7.x86_64 knot-libs-2.6.5-1.el7.x86_64 libcap-ng-0.7.5-4.el7.x86_64 libffi-3.0.13-18.el7.x86_64 libgcc-4.8.5-16.el7_4.2.x86_64 libstdc++-4.8.5-16.el7_4.2.x86_64 libtasn1-4.10-1.el7.x86_64 libuv-1.10.2-1.el7.x86_64 lmdb-libs-0.9.18-1.el7.x86_64 luajit-2.0.4-3.el7.x86_64 nettle-2.7.1-8.el7.x86_64 p11-kit-0.23.5-3.el7.x86_64 zlib-1.2.7-17.el7.x86_64
(gdb) list
No symbol table is loaded. Use the "file" command.
(gdb) bt
#0 0x00007ffff7947488 in knot_dname_lf () from /lib64/libknot.so.7
#1 0x00007ffff7b7736f in peek_exact_real.isra.9 ()
from /usr/local/lib/libkres.so.7
#2 0x00007ffff7b8ea23 in kr_zonecut_find_cached ()
from /usr/local/lib/libkres.so.7
#3 0x00007ffff7b88aae in zone_cut_check () from /usr/local/lib/libkres.so.7
#4 0x00007ffff7b8a657 in kr_resolve_produce ()
from /usr/local/lib/libkres.so.7
#5 0x0000555555561c83 in qr_task_step ()
#6 0x000055555555c19a in udp_recv ()
#7 0x00007ffff72c2696 in uv__udp_io () from /lib64/libuv.so.1
#8 0x00007ffff72c42e8 in uv__io_poll () from /lib64/libuv.so.1
#9 0x00007ffff72b5db8 in uv_run () from /lib64/libuv.so.1
#10 0x000055555555bd19 in main ()
```
## Environment
### IP Addresses of each servers.
* root DNS server: 192.168.33.100/24
* malicious authoritative server: 192.168.33.101/24
* victim full service resolver: 192.168.33.102/24
### OS, Software of each servers.
#### root DNS server
* OS: CentOS 7.4 x86_64 on VirtualBox VM
* DNS: bind
#### Malicious authoritative server
* OS: CentOS 7.4 x86_64 on VirtualBox VM
#### victim full service resolver
* OS: CentOS 7.4 x86_64 on VirtualBox VM
* DNS: knot-resolver 2.2.0
## Setup steps of Environment
### root servers
Install CentOS 7.4 from install ISO image.
Set IP address VM to 192.168.33.100/24.
Set firewalld.
```
# firewall-cmd --zone=public --add-service=dns --permanent
# firewall-cmd --reload
```
Install Bind.
```
# yum install bind bind-utils
```
Upload and extract test-files.tar.gz
```
# cd /tmp
# tar xzf /path/to/test-files.tar.gz
```
Copy named.conf and root zone file.
```
# cp /tmp/test-files/root.named.conf /etc/named.conf
# cp /tmp/test-files/root.zone /var/named/root.zone
# chmod 644 /var/named/root.zone
```
Start named.
```
# systemctl start named
# systemctl enable named
```
#### Malicious authoritative server
Install CentOS 7.4 from install ISO image.
Set IP address to 192.168.33.101/24.
Set firewalld
```
# firewall-cmd --zone=public --add-service=dns --permanent
# firewall-cmd --reload
```
Install Build tools.
```
# yum install epel-release
# yum install gcc-c++ boost-devel wget perl yaml-cpp-devel bind-utils
# wget https://cmake.org/files/v3.10/cmake-3.10.0-Linux-x86_64.sh
# sh cmake-3.10.0-Linux-x86_64.sh --skip-license --prefix=/usr/local
```
Install openssl 1.0.1 from source file.
```
# wget https://www.openssl.org/source/openssl-1.1.0g.tar.gz
# tar xzf openssl-1.1.0g.tar.gz
# cd openssl-1.1.0g
# ./config
# maket
# make install
```
Upload and extract test-tools.tar.gz.
```
# cd /tmp
# tar xzf /path/to/test-tools.tar.gz
# cd test-tools
# OPENSSL_ROOT_DIR=/usr/local/ssl cmake .
# make
```
Start DNS service foreground.
```
# ./bin/knot-dname_lf
```
Login to authoritative server from other terminal, and check response of knot-dname_lf on other terminal.
```
# dig \@127.0.0.1 www.example.com a +norec
; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.2 <<>> @127.0.0.1 www.example.com a +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44651
;; flags: qr aa ad cd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;www.example.com. IN A
;; AUTHORITY SECTION:
www.example.com. 600 IN NS \000.example.com.
;; ADDITIONAL SECTION:
\000.example.com. 600 IN A 192.168.33.101
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Apr 04 01:10:59 JST 2018
;; MSG SIZE rcvd: 104
```
### victim full service resolver
Install CentOS 7.4 from install ISO image.
Set IP address to 192.168.33.102/24.
Install Build tools.
```
# yum install epel-release
# yum install gcc-c++ openssl-devel wget knot-devel bind-utils luajit-devel libuv-devel
```
Install knot-resolver
```
# wget https://secure.nic.cz/files/knot-resolver/knot-resolver-2.2.0.tar.xz
# tar xJf knot-resolver-2.2.0.tar.xz
# cd knot-resolver-2.2.0
# make CFLAGS=-DNDEBUG
# make install
# echo /usr/local/lib > /etc/ld.so.conf.d/knot.conf
# ldconfig
```
Upload and extract test-files.tar.gz.
```
# cd /tmp
# tar xzf /path/to/test-files.tar.gz
```
Copy kresd.conf and hints file.
```
# cp /tmp/test-files/kresd.conf /usr/local/etc/knot-resolver
# cp /tmp/test-files/root.hints /usr/local/etc/knot-resolver
```
Start knot-resolver
```
# mkdir -p /tmp/db
# cd /tmp/db
# rm -f * ; /usr/local/sbin/kresd -c /usr/local/etc/knot-resolver/kresd.conf
```
Login to victim full service resolver from other terminal, and send queries to knot-resolver.
```
# sh -x /tmp/test-files/crash.sh
```
Check knot-resolver process.
```
# /usr/local/sbin/kresd -c /usr/local/etc/knot-resolver/kresd.conf
[system] interactive mode
> Segmentation fault
```
[test-files.tar.gz](/uploads/afe8c7be07dd8efdc28b28f28516509c/test-files.tar.gz)
[test-tools.tar.gz](/uploads/79014a2e4e99983e5662412c8d88a0d6/test-tools.tar.gz)https://gitlab.nic.cz/knot/knot-resolver/-/issues/334knot-resolver 2.2.0 crashes when malformed response, which include SIG record...2018-05-31T10:22:34+02:00Toshifumi Sakaguchiknot-resolver 2.2.0 crashes when malformed response, which include SIG record in authority section, is received.## Overview
Knot-resolver crashes when malformed response is received from a malicious
authoritative server in my test environment.
response from authoritative server.
```
;; QUESTION SECTION:
;www.example.com. IN ...## Overview
Knot-resolver crashes when malformed response is received from a malicious
authoritative server in my test environment.
response from authoritative server.
```
;; QUESTION SECTION:
;www.example.com. IN A
;; AUTHORITY SECTION:
www.example.com. 600 CH SIG A 1 3 3600 19700102034640 19700101135320 174 www.example.com. AQE.... snip ....
```
message at crach.
```
# /usr/local/sbin/kresd -c /usr/local/etc/knot-resolver/kresd.conf
[system] interactive mode
> kresd: lib/cache/api.c:254: key_exact_type_maypkt: Assertion `!knot_rrtype_is_metatype(type)' failed.
Aborted
```
Please read README.md whichi includes reproduce steps.
[README.md](/uploads/1f87bb00d6ce354120772fc2d1f4dd60/README.md)
[test-files.tar.gz](/uploads/9633ee2f097827b3149758f4b886a0d7/test-files.tar.gz)
[test-tools.tar.gz](/uploads/22cb32ed448550be29e8f55a2d6994dc/test-tools.tar.gz)2018 Q2Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/320Feature request - DNS rebinding protection2018-06-26T14:58:41+02:00Jan PavlinecFeature request - DNS rebinding protectionIt would be nice to have DNS rebinding protection.
Maybe It would be enought to add special filter for that (just blind idea) where you can filter all local subnet which aren't part of active hints. http://knot-resolver.readthedocs.io...It would be nice to have DNS rebinding protection.
Maybe It would be enought to add special filter for that (just blind idea) where you can filter all local subnet which aren't part of active hints. http://knot-resolver.readthedocs.io/en/stable/modules.html#query-policies2018 Q2https://gitlab.nic.cz/knot/knot-resolver/-/issues/315policy.TLS_FORWARD emits UDP packets (cleartext DNS) on port 853 after some ...2018-02-21T19:59:40+01:00Daniel Kahn Gillmorpolicy.TLS_FORWARD emits UDP packets (cleartext DNS) on port 853 after some timeI set up a local `kresd` instance, version 2.1.0 on debian testing/unstable, with the following policy:
policy.add(policy.all(policy.TLS_FORWARD({{'9.9.9.9', hostname='dns.quad9.net', ca_file='/etc/ssl/certs/ca-certificates.crt'}}))...I set up a local `kresd` instance, version 2.1.0 on debian testing/unstable, with the following policy:
policy.add(policy.all(policy.TLS_FORWARD({{'9.9.9.9', hostname='dns.quad9.net', ca_file='/etc/ssl/certs/ca-certificates.crt'}})))
I did a few queries on it while using wireshark to gather all traffic to/from `9.9.9.9`.
As expected, most traffic was TCP port 853, consisting of TLS traffic.
However, i did see occasional bursts of UDP traffic, also on port 853.
that traffic appears to actually be cleartext UDP traffic, described by wireshark (when i decode it as DNS) as:
W.X.Y.Z 9.9.9.9 DNS 70 Standard query 0x1c30 DNSKEY <Root> OPT
perhaps this is intended to be a priming query?
note that 9.9.9.9 sends ICMP "Host administratively prohibited" responses to UDP traffic on port 853. They only support TLS (over TCP).
In another case, i saw a query going out for an actual A record:
W.X.Y.Z 9.9.9.9 DNS 83 Standard query 0x08ee A WWW.IetF.org OPT
So in addition to a bug, this appears to be a leak of the private dns request! I have not tried to debug it further.Grigorii DemidovGrigorii Demidovhttps://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/270CI: optimize package installation2017-11-27T17:27:21+01:00Petr ŠpačekCI: optimize package installationIt seems that new Docker image introduced in !375 is not fully used because e.g.
https://gitlab.labs.nic.cz/knot/knot-resolver/blob/master/.gitlab-ci.yml#L47
is still doing some package installation etc. which slows whole CI down.
Most ...It seems that new Docker image introduced in !375 is not fully used because e.g.
https://gitlab.labs.nic.cz/knot/knot-resolver/blob/master/.gitlab-ci.yml#L47
is still doing some package installation etc. which slows whole CI down.
Most of the package preparations should be done in Dockerfile so the CI just runs the image and we do not spend time on waiting while running CI jobs.https://gitlab.nic.cz/knot/knot-resolver/-/issues/257improve cache flushing/eviction mechanism2019-07-03T15:43:16+02:00Petr Špačekimprove cache flushing/eviction mechanismRight now cache flushing is kind of dumb because it flushes whole cache as soon as it is full. This does not behave very well under high load because it leads to bursts of queries.
We need to find a way to implement proper cache evictio...Right now cache flushing is kind of dumb because it flushes whole cache as soon as it is full. This does not behave very well under high load because it leads to bursts of queries.
We need to find a way to implement proper cache eviction so items can be removed incrementally instead of dropping whole cache.
See https://gitlab.labs.nic.cz/knot/knot-resolver/wikis/Knot-Resolver-Cache-Garbage-CollectorLibor PeltanLibor Peltanhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/256CI: sanity check loadability of all modules2019-12-18T14:33:56+01:00Petr ŠpačekCI: sanity check loadability of all modulesWe need a sanity check that all modules can be loaded and that (at very least) the kresd still resolves something when everything is loaded.
I envision going though [modules](http://knot-resolver.readthedocs.io/en/latest/modules.html) s...We need a sanity check that all modules can be loaded and that (at very least) the kresd still resolves something when everything is loaded.
I envision going though [modules](http://knot-resolver.readthedocs.io/en/latest/modules.html) section of documentation and copy-pasting all examples into single config + some test to see if we can get valid DNS reply.2019 Q4