Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2020-01-07T17:16:08+01:00https://gitlab.nic.cz/knot/knot-resolver/-/issues/88TA bootstrap doesn't work without external resolver2020-01-07T17:16:08+01:00Ondřej SurýTA bootstrap doesn't work without external resolverIf `/etc/resolv.conf` contains `nameserver 127.0.0.1` and the nameserver running on `127.0.0.1` is the Knot Resolver instance bootstrapping the root TA, then the bootstrapping fails with name resolution error as it doesn't start resolvin...If `/etc/resolv.conf` contains `nameserver 127.0.0.1` and the nameserver running on `127.0.0.1` is the Knot Resolver instance bootstrapping the root TA, then the bootstrapping fails with name resolution error as it doesn't start resolving until the root TA is bootstrapped.
Knot Resolver should be able to resolve at least `data.iana.org` when doing the bootstrap and it should probably fail to start if it can't bootstrap root TA.https://gitlab.nic.cz/knot/knot-resolver/-/issues/185test graphite module2019-12-18T18:39:02+01:00Petr Špačektest graphite moduleThis might be lower priority than other tests.This might be lower priority than other tests.https://gitlab.nic.cz/knot/knot-resolver/-/issues/187test etcd module2017-10-09T17:00:34+02:00Petr Špačektest etcd moduleAn open question is how to mock etcd.An open question is how to mock etcd.https://gitlab.nic.cz/knot/knot-resolver/-/issues/207workarounds: log using generic workarounds2020-02-03T16:20:36+01:00Vladimír Čunátvladimir.cunat@nic.czworkarounds: log using generic workaroundsWhen using generic workarounds, it would be nice to have a possibility to log them, so the protocol violations might be collected and reported e.g. at https://github.com/dns-violations/, at the server operator, etc. ([Suggested by Anand...When using generic workarounds, it would be nice to have a possibility to log them, so the protocol violations might be collected and reported e.g. at https://github.com/dns-violations/, at the server operator, etc. ([Suggested by Anand.](https://ripe74.ripe.net/archives/video/159/))
It's probably of no use for the specific cases in the workarounds module, as those are known.https://gitlab.nic.cz/knot/knot-resolver/-/issues/218dns64 is broken with policy.STUB2024-02-28T12:09:18+01:00Vladimír Čunátvladimir.cunat@nic.czdns64 is broken with policy.STUBSee e.g. 0b748e0e49. Related: https://gitlab.nic.cz/knot/knot-resolver/issues/217See e.g. 0b748e0e49. Related: https://gitlab.nic.cz/knot/knot-resolver/issues/217https://gitlab.nic.cz/knot/knot-resolver/-/issues/224validate: support mixing NSEC and NSEC3 in a single packet2017-10-10T10:08:11+02:00Vladimír Čunátvladimir.cunat@nic.czvalidate: support mixing NSEC and NSEC3 in a single packethttps://gitlab.nic.cz/knot/knot-resolver/-/issues/225opcode IQUERY returns SERVFAIL instead of NOTIMP2019-07-09T17:14:22+02:00Štěpán Kotekopcode IQUERY returns SERVFAIL instead of NOTIMPUnsupported opcode must lead to `RCODE=NOTIMP`. This will get back and bite us when the session signalling draft comes by.
Clarification: Response to unknown OPCODE must contain only the DNS message header and nothing else, not even EDN...Unsupported opcode must lead to `RCODE=NOTIMP`. This will get back and bite us when the session signalling draft comes by.
Clarification: Response to unknown OPCODE must contain only the DNS message header and nothing else, not even EDNS. The reason is that different OPCODEs might potentially use very different message format so it is risky to return anything beyond the DNS header.
test failing: `sets/resolver/iter_opcode_notimp.rpl ` in deckard, branch `unknown-opcode`
blocks deckard#112019 Q1https://gitlab.nic.cz/knot/knot-resolver/-/issues/262simplify DNS64 code2017-10-22T14:25:03+02:00Petr Špačeksimplify DNS64 codeNew code introduced in #203 seems ugly because it introduced FFI spaghetti into DNS64 module. When you have some time, we should refactor that so it is readable again.New code introduced in #203 seems ugly because it introduced FFI spaghetti into DNS64 module. When you have some time, we should refactor that so it is readable again.https://gitlab.nic.cz/knot/knot-resolver/-/issues/264errors from Lua module interface are not developer friendly2019-12-18T19:56:41+01:00Petr Špačekerrors from Lua module interface are not developer friendlyI'm creating a "Hello world" Lua plugin and the process is not straightforward as I would wish.
Interestingly if a Lua module does not return a table (which is easy to forget when you start), it spits out quite confusing error message:
...I'm creating a "Hello world" Lua plugin and the process is not straightforward as I would wish.
Interestingly if a Lua module does not return a table (which is easy to forget when you start), it spits out quite confusing error message:
```
> modules.load('test')
attempt to index a boolean value
```
I was looking into the C code which loads the Lua modules and it does not have any super-easy fix because of Lua-C integration. This lead me to idea that we might rewrite Lua-module loading into Lua, so it is not such a long spagetti. (Or not, if it does not simplify the code. I'm just thinking aloud.)https://gitlab.nic.cz/knot/knot-resolver/-/issues/295validator might better ignore out-of-bailiwick crap2018-01-22T15:27:22+01:00Vladimír Čunátvladimir.cunat@nic.czvalidator might better ignore out-of-bailiwick crapReal-life example: `www.vikhockey.se. AAAA` fails in validator, due to server returning:
```
kdig @195.74.39.30 www.vikhockey.se. AAAA +dnssec
;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 50218
;; Flags: qr aa rd; QUERY: 1; ANSWE...Real-life example: `www.vikhockey.se. AAAA` fails in validator, due to server returning:
```
kdig @195.74.39.30 www.vikhockey.se. AAAA +dnssec
;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 50218
;; Flags: qr aa rd; QUERY: 1; ANSWER: 2; AUTHORITY: 8; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 1680 B; ext-rcode: NOERROR
;; QUESTION SECTION:
;; www.vikhockey.se. IN AAAA
;; ANSWER SECTION:
www.vikhockey.se. 600 IN CNAME vvik1-vvik.ramses.nu.
www.vikhockey.se. 600 IN RRSIG CNAME 8 3 600 20180201000000 20180111000000 34296 vikhockey.se. mnn7gL0v3BupFGZi4N/CV6vINkNOFy2y4H0Vx0ukrYDScxCubeLA0YCYCIE3thu13DCkOFuijUbWtaA9KSMivfJUb1q5yX0jdT0b5nvwK1/YSk2YnXMEbrjWqTu4rig+KsrZ0XSb76E0d/9wN5VtFxNkhfZypu5HSj85Isy46Bw=
;; AUTHORITY SECTION:
ramses.nu. 3600 IN SOA ns3.binero.se. registry.binero.se. 1516233600 86400 5400 604800 3600
ramses.nu. 3600 IN RRSIG SOA 8 2 3600 20180201000000 20180111000000 34296 ramses.nu. g4KxoD6HuieeEBgG6Z6oUTlhwdGelcUWRUq3Jd9osVaFzvn8XscQDdmcGh4maK0yofoz8t/ShRVjC4XQGnj5//eejMXY1jgra39VMbJ9P+7JOvGUuETw0WJL8oT7YehfFkCv1CRL5IoM6d9SYdYkmcDt/aoDMeoG+WgEZ6QHW5Y=
v8ssphenr3p30k9a4dpae5pr9ib7m3l1.ramses.nu. 3600 IN NSEC3 1 1 1 AB 18AJT6FFNC06017DT70ELSCVH3763P1C NS SOA MX RRSIG DNSKEY NSEC3PARAM
v8ssphenr3p30k9a4dpae5pr9ib7m3l1.ramses.nu. 3600 IN RRSIG NSEC3 8 3 3600 20180201000000 20180111000000 34296 ramses.nu. wSFv8izGquRzjaZJSnXn+7hgpaqfKGEr3l5OwtEI0KlBRPFmXGv8RD1d9dhJqp1QeaDK67rZqzFHioA/p13RP7kYDUCiOHX8VoA9hbQr3nFHeerkt+zSiYNaAH43sWT7oHpnrN9ODUIIB0s4Tbm1+U2G7tJ90JyjCjmMEXu+UQQ=
3dnbf1prkcm9234cr9atsv8a2gfs2oua.ramses.nu. 3600 IN NSEC3 1 1 1 AB 71O8H4PM96IP6HK4FDMQ2G34KD9KKGV4 A RRSIG
3dnbf1prkcm9234cr9atsv8a2gfs2oua.ramses.nu. 3600 IN RRSIG NSEC3 8 3 3600 20180201000000 20180111000000 34296 ramses.nu. dFKDMKzdwDmNEFfItTlEIIhAqqbk13WEO/etgywJLzEt3PRW1s70jfFCWqTeOjAUdeF6JEfLWklPYkhpBe0UwmYEVqlQcYJ37AKX7gUyN/iBKTtMfQWTXfdHMyjj1fyfEoeFh2SMk1Vl5bys1HKajB0SkOnKmzDKnZjBftDuimE=
j8qedtq6ned9n5sl7e99incs8s1m29sb.ramses.nu. 3600 IN NSEC3 1 1 1 AB MUE5EI8JM7A860A6HCDO7LQ42OSF6V55 A RRSIG
j8qedtq6ned9n5sl7e99incs8s1m29sb.ramses.nu. 3600 IN RRSIG NSEC3 8 3 3600 20180201000000 20180111000000 34296 ramses.nu. HTN4XXRy53RX8p2wksZ5HwW8gYisHHCWwbD/yjiUc4CC+q2tc9jiX9NTriGuKd32BCKqceHlPrAeU62Bn1fujCCKvmctVavr0oUXw4XSl0sJblyH5FitapCBwSW2rmiFY53Jup8oUQLpuNeNP8euADbai//gUiBl9UwHR0qR65c=
;; Received 1224 B
;; Time 2018-01-19 13:42:17 CET
;; From 195.74.39.30@53(UDP) in 130.5 ms
```
The part about CNAME is OK, but the NXDOMAIN on the target is BOGUS. (Seems like outdated `ramses.nu.` zone remaining on the server.)https://gitlab.nic.cz/knot/knot-resolver/-/issues/326Use connected UDP sockets for outgoing queries2019-04-02T17:26:25+02:00Marek VavrusaUse connected UDP sockets for outgoing queriesIt'd be nice to use connected UDP sockets for outgoing queries as it makes it a little bit harder to spoof, and a bit more efficient as kernel can discard dgrams from different source addresses than the connected one.
Currently libuv do...It'd be nice to use connected UDP sockets for outgoing queries as it makes it a little bit harder to spoof, and a bit more efficient as kernel can discard dgrams from different source addresses than the connected one.
Currently libuv doesn't have a facility for connected UDP sockets, so I'm creating the issue to track this when it gets it: https://github.com/libuv/leps/pull/10https://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/517OCSP stapling for server side2019-12-18T15:28:32+01:00Vladimír Čunátvladimir.cunat@nic.czOCSP stapling for server sideOCSP stapling seems to make much sense for server side as well, at least at a quick look.OCSP stapling seems to make much sense for server side as well, at least at a quick look.https://gitlab.nic.cz/knot/knot-resolver/-/issues/568Some cases of DNS resolution from lua fail if OS provides only IPv6 resolvers2020-04-24T10:04:07+02:00Vladimír Čunátvladimir.cunat@nic.czSome cases of DNS resolution from lua fail if OS provides only IPv6 resolversConditions:
- `resolv.conf` only containing IPv6 nameservers. Mix works OK. I believe that very few people have IPv6-only there, luckily.
- Use DNS resolution based on `lua-cqueues`, e.g. `prefill` module or root trust anchors bootst...Conditions:
- `resolv.conf` only containing IPv6 nameservers. Mix works OK. I believe that very few people have IPv6-only there, luckily.
- Use DNS resolution based on `lua-cqueues`, e.g. `prefill` module or root trust anchors bootstrapping – both only after !894 (kresd >= 5.0.0).
Result example:
```
[prefill] fetch of `https://www.internic.net/domain/root.zone` failed: HTTP client library error: A non-recoverable error occurred when attempting to resolve the name (-1684960053)), will retry root zone download in 09 minutes 59 seconds
```
This is a problem in lua libraries that we've chosen to use: https://github.com/wahern/dns/issues/23https://gitlab.nic.cz/knot/knot-resolver/-/issues/801multiple manager instances not runnable in parallel2023-09-28T04:48:33+02:00Vladimír Čunátvladimir.cunat@nic.czmultiple manager instances not runnable in parallelMultiple manager instances are not runnable in parallel, even if no socket or path from configuration clashes, e.g. when testing without containers.
It's prevented by the `sd_notify` plugin hardcoding the name of abstract unix socket to...Multiple manager instances are not runnable in parallel, even if no socket or path from configuration clashes, e.g. when testing without containers.
It's prevented by the `sd_notify` plugin hardcoding the name of abstract unix socket to `knot-resolver-control-socket`.https://gitlab.nic.cz/knot/knot-resolver/-/issues/906local-data: allow even with +nord2024-03-04T10:24:29+01:00Vladimír Čunátvladimir.cunat@nic.czlocal-data: allow even with +nordWhile it makes sense to disallow *cached* records in +nord mode by default (for privacy reasons), those arguments do not hold for other kinds of local data, and there might be some use cases, e.g. [resolver.arpa. RESINFO](https://www.iet...While it makes sense to disallow *cached* records in +nord mode by default (for privacy reasons), those arguments do not hold for other kinds of local data, and there might be some use cases, e.g. [resolver.arpa. RESINFO](https://www.ietf.org/archive/id/draft-ietf-add-resolver-info-11.html#section-3)