Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2017-12-17T01:10:18+01:00https://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/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/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/233random generator: consider using gnutls instead of ISAAC2018-12-21T13:33:20+01:00Vladimír Čunátvladimir.cunat@nic.czrandom generator: consider using gnutls instead of ISAAC[GnuTLS _NONCE level](http://www.gnutls.org/manual/gnutls.html#Random-number-generation) might be suitable. TODO: profile.
- Advantages: smaller state (~2kB -> 140B), dropping extra code that we don't (want to) maintain in exchange for...[GnuTLS _NONCE level](http://www.gnutls.org/manual/gnutls.html#Random-number-generation) might be suitable. TODO: profile.
- Advantages: smaller state (~2kB -> 140B), dropping extra code that we don't (want to) maintain in exchange for the lib that we depend on anyway, maybe better quality of randomness.
- Disadvantages: probably more CPU-intensive, but most likely not noticeable for our use cases.2018 Q3https://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/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/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/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/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/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/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/368DNS64 for subnets2021-08-25T13:32:55+02:00Petr ŠpačekDNS64 for subnetsRIPE NCC and Ondřej Caletka expressed demand for ability to limit which subnets are covered by DNS64.
We need to think whether this should be generalized to some form of ACL like in BIND, or if another one-off for DNS64 is okay.
RIPE N...RIPE NCC and Ondřej Caletka expressed demand for ability to limit which subnets are covered by DNS64.
We need to think whether this should be generalized to some form of ACL like in BIND, or if another one-off for DNS64 is okay.
RIPE NCC wanted the equivalent of the Bind ACL options:
```
acl nat64-users {
2001:67c:64:49::/64;
};
options {
dns64 64:ff9b::/96 {
clients { nat64-users; };
};
};
```
Their own hack used this config:
```
-- RIPE NCC DNS64 config
ripencc.dns64_proxy('64:ff9b::')
ripencc.dns64_subnet('2001:67c:64:49::/64')
```Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/359CNAME breaks DS queries if CNAME is at apex (non-compliant auth side)2020-04-27T16:47:06+02:00Petr ŠpačekCNAME breaks DS queries if CNAME is at apex (non-compliant auth side)kresd replies incorrectly for `name.example. DS` queries if `name.example.` has CNAME at apex `name.example.`.
This seems to affect only non-compliant servers which allow CNAME at apex. **Such zones are illegal according to https://tool...kresd replies incorrectly for `name.example. DS` queries if `name.example.` has CNAME at apex `name.example.`.
This seems to affect only non-compliant servers which allow CNAME at apex. **Such zones are illegal according to https://tools.ietf.org/html/rfc1034#section-3.6.2.**
This bug is present in 2.3.0 and breaks validating forwarders which point to kresd. Related: #153
Affected domain: ucarecdn.com
DNSViz: http://dnsviz.net/d/ucarecdn.com/WvYPzQ/dnssec/
DNSViz mirror [dnsviz-ucarecdn.pdf](/uploads/78e3058f79b4f774bd852dc1221bdff2/dnsviz-ucarecdn.pdf)
Second affected domain (with wildcard): coder.show
DNSViz: http://dnsviz.net/d/coder.show/WwVyFQ/dnssec/
DNSViz mirror [dnsviz-coder-show.pdf](/uploads/a2fb42ca1098b9ed26ec9b762e57ded2/dnsviz-coder-show.pdf)
Steps to reproduce:
1. dig +dnssec coder.show A
2. dig +dnssec coder.show DS
https://gitlab.nic.cz/knot/knot-resolver/-/issues/331Resolver allows cache snooping by default2019-09-18T11:26:57+02:00Marek VavrusaResolver allows cache snooping by defaultBy default all requests without the RD bit are satisfied from cache or SERVFAIL.
This can be a privacy issue in smaller networks as it allows checking whether a certain name has been asked or not.
Unbound for example doesn't enable `allo...By default all requests without the RD bit are satisfied from cache or SERVFAIL.
This can be a privacy issue in smaller networks as it allows checking whether a certain name has been asked or not.
Unbound for example doesn't enable `allow_snoop` by default, so it'd be nice to do that (or at least have an option to turn it off) https://www.unbound.net/documentation/unbound.conf.htmlhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/319validator: add TTL checks2022-05-08T12:09:35+02:00Vladimír Čunátvladimir.cunat@nic.czvalidator: add TTL checksProbably to be within `kr_rrset_validate_with_key()` or inside a sub-call.
- [x] check TTL going over RRSIG expiration;
- [x] check TTL going over the signed TTL.
Possible actions:
1. clamp the TTL
2. refuse such signature -> BOGUSProbably to be within `kr_rrset_validate_with_key()` or inside a sub-call.
- [x] check TTL going over RRSIG expiration;
- [x] check TTL going over the signed TTL.
Possible actions:
1. clamp the TTL
2. refuse such signature -> BOGUS4.2.1Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/317seccomp support2022-05-08T11:48:30+02:00Jan Pavlinecseccomp supportIt would be nice, if we could build knot-resolver with seccomp support which should reduce attack surface by filtering syscalls.
Note: similar approach for hardening was made to dnsmasq by google zero team (but it's not merged into ups...It would be nice, if we could build knot-resolver with seccomp support which should reduce attack surface by filtering syscalls.
Note: similar approach for hardening was made to dnsmasq by google zero team (but it's not merged into upstream yet)
https://security.googleblog.com/2017/10/behind-masq-yet-more-dns-and-dhcp.html
https://github.com/google/security-research-pocs/blob/master/vulnerabilities/dnsmasq/sandbox/dnsmasq-sandbox.patchhttps://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/275enable supervision by the systemd watchdog, if building against libsystemd2019-06-24T16:12:46+02:00Daniel Kahn Gillmorenable supervision by the systemd watchdog, if building against libsystemdThe tight loop that `kresd` hit in #271 didn't need to cause a permanent system hang -- if kresd had commited to checking in with a supervising watchdog regularly, then the tight loop would have caused it to miss a watchdog checkin, and ...The tight loop that `kresd` hit in #271 didn't need to cause a permanent system hang -- if kresd had commited to checking in with a supervising watchdog regularly, then the tight loop would have caused it to miss a watchdog checkin, and the supervisor could have killed it and restarted it automatically.
systemd makes this process relatively painless. At startup, kresd would use `sd_watchdog_enabled(3)` to verify whether it was expected to use the watchdog, and if so, how frequently it needs to check in. if enabled, then kresd would add a timer to its event loop that invokes `sd_notify(0, "WATCHDOG=1")`. To enable the use of the watchdog, we'd set `WatchdogSec=` in `kresd.service`.
`sd_watchdog_enabled(3)` and `sd_notify(3)` and `systemd.service(5)` for more details.
Ideally, of course, there would be no hangs. But if the goal is a robust service with minimum downtime, this kind of supervision can be a way to work around any future bugs that pop up.Tomas KrizekTomas Krizekhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/260remove the --forks=1 constraint for socket-activated kresd2018-02-13T17:02:49+01:00Daniel Kahn Gillmorremove the --forks=1 constraint for socket-activated kresdWhen implementing socket activation, we put in a constraing that `--forks` had to be set to 1.
As `kresd(8)` says:
When socket-activated and supervised by systemd or the equiva‐
lent, kresd defaults to --forks=1, and mu...When implementing socket activation, we put in a constraing that `--forks` had to be set to 1.
As `kresd(8)` says:
When socket-activated and supervised by systemd or the equiva‐
lent, kresd defaults to --forks=1, and must not be set to any
other value. If you want multiple concurrent processes super‐
vised in this way, they should be supervised independently.
It's no longer clear to me that this constraint should be required. We should look into what can be done to allow a socket-activated service to have `--forks=N` where `N > 1`.
Main questions, as i see it:
* who does the passed-in control socket talk to? presumably the "leader", but does that mean that the children need to close their copy of the control socket?
* should the child processes expose any direct control sockets of their own? if so, should those also be socket-activated?