Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2022-05-08T12:09:35+02:00https://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/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/165RFC 8094: DNS over Datagram Transport Layer Security (DTLS)2020-11-24T16:40:39+01:00Ondřej SurýRFC 8094: DNS over Datagram Transport Layer Security (DTLS)A topic for next Hackathon for @ondrej and @dkg ? :)A topic for next Hackathon for @ondrej and @dkg ? :)https://gitlab.nic.cz/knot/knot-resolver/-/issues/232provide option for explicit port randomization2020-11-24T16:40:30+01:00Vladimír Čunátvladimir.cunat@nic.czprovide option for explicit port randomizationLinux defaults are reasonable for our use of ephemeral ports, but FreeBSD reportedly assigns them in a sequential-like fashion which is bad for spoofability of data not covered by DNSSEC. [Reported on gitter](https://gitter.im/CZ-NIC/kn...Linux defaults are reasonable for our use of ephemeral ports, but FreeBSD reportedly assigns them in a sequential-like fashion which is bad for spoofability of data not covered by DNSSEC. [Reported on gitter](https://gitter.im/CZ-NIC/knot-resolver?at=59870755bc464729745a6141).https://gitlab.nic.cz/knot/knot-resolver/-/issues/251warn if static (unmanaged) key is used2020-10-15T13:19:01+02:00Petr Špačekwarn if static (unmanaged) key is usedStatic key configuration (i.e. without enabling RFC 5011) causes problems with roll-overs. Wild idea: Maybe we should warn if an unmanaged key is configured?Static key configuration (i.e. without enabling RFC 5011) causes problems with roll-overs. Wild idea: Maybe we should warn if an unmanaged key is configured?https://gitlab.nic.cz/knot/knot-resolver/-/issues/134Resolver should ask for `DS` right after delegation `NS` is received and `DS`...2020-07-20T13:23:40+02:00Ondřej SurýResolver should ask for `DS` right after delegation `NS` is received and `DS` is not in the `AUTHORITY` section.In case the parent and child zone is hosted at the same server, the delegation NS query returns only `NS` in the `ANSWER` section (instead of `AUTHORITY`). See example from `nic.cz` vs `sury.cz`:
```
;; ->>HEADER<<- opcode: QUERY; status...In case the parent and child zone is hosted at the same server, the delegation NS query returns only `NS` in the `ANSWER` section (instead of `AUTHORITY`). See example from `nic.cz` vs `sury.cz`:
```
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 4713
;; Flags: qr aa rd; QUERY: 1; ANSWER: 4; AUTHORITY: 0; ADDITIONAL: 13
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: Unused
;; QUESTION SECTION:
;; nic.cz. IN NS
;; ANSWER SECTION:
nic.cz. 1800 IN NS a.ns.nic.cz.
nic.cz. 1800 IN NS b.ns.nic.cz.
nic.cz. 1800 IN NS d.ns.nic.cz.
nic.cz. 1800 IN RRSIG NS 13 2 1800 20170202003914 20170119215003 53569 nic.cz. +eiUp1ZxK1WH9+So5TmDtxIegeRmVcaxLPEauxAWVHbs4H8qSu6LILPZONj+B8iN3mMa3nJrsiMVb88+jSUj6g==
;; ADDITIONAL SECTION:
a.ns.nic.cz. 1800 IN A 194.0.12.1
a.ns.nic.cz. 1800 IN RRSIG A 13 4 1800 20170202145140 20170119215003 53569 nic.cz. 6aCe1zhyPIDgrHpM3kImovkRZ53FwSeD4ByiTsGopTs6fkyiAvIUJagHjjwBr89krTX3LXVd1nNUM4XJRBSe5Q==
b.ns.nic.cz. 1800 IN A 194.0.13.1
b.ns.nic.cz. 1800 IN RRSIG A 13 4 1800 20170202045948 20170119215003 53569 nic.cz. ftVQuQpJSumxw7UgNJV9WMPq07fKeyUyo0DvXtEQux5jgJkB2nmtlefMFBS7/ZAH8TEWltzcOX6cw2/mgjnKPg==
d.ns.nic.cz. 1800 IN A 193.29.206.1
d.ns.nic.cz. 1800 IN RRSIG A 13 4 1800 20170202161830 20170119215003 53569 nic.cz. YKcDKUPSJWQuuKRIPt+WKHi6/BItA8bRQYrUyFRUK+we4111UBYKt2aO8LWIL5RlHKLnPr4Zmu71Ol1LKIYXaw==
a.ns.nic.cz. 1800 IN AAAA 2001:678:f::1
a.ns.nic.cz. 1800 IN RRSIG AAAA 13 4 1800 20170202151241 20170119215003 53569 nic.cz. ujW2zr1GOcqp6RDATgn30PuxIfiicFFaGG/+7/XoiycCi2OR1XIwMHlLznv8qPYYnNyrOZPEVTnCDog1uSvBiw==
b.ns.nic.cz. 1800 IN AAAA 2001:678:10::1
b.ns.nic.cz. 1800 IN RRSIG AAAA 13 4 1800 20170202011018 20170119215003 53569 nic.cz. Ho+Mdn0jP04LkjwwE41eArn9ePCV2HaWRkjT89d2rSRGXcx31rUYQo8FT+lKg5hJX/k18ZbSGZwDly3ktaPNWw==
d.ns.nic.cz. 1800 IN AAAA 2001:678:1::1
d.ns.nic.cz. 1800 IN RRSIG AAAA 13 4 1800 20170202002553 20170119215003 53569 nic.cz. a4akrH95iu3YSU6Y2Eis8Bx4Ko6BzIw0S/A9n0tI72C1T8iQjVgUxwikKtf55ZN6ylqb+dsPscfUxZOL6LWiKg==
;; Received 932 B
;; Time 2017-01-23 13:21:09 CET
;; From 2001:678:f::1@53(UDP) in 0.8 ms
```
```
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 14000
;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 4; ADDITIONAL: 4
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: Unused
;; QUESTION SECTION:
;; sury.cz. IN NS
;; AUTHORITY SECTION:
sury.cz. 18000 IN NS trubka.network.cz.
sury.cz. 18000 IN NS master.dns.rocks.
sury.cz. 18000 IN DS 44950 8 2 7D1FEF31405513CD00CD41A2A7107C3B7A949F0A05158264F06665C5E33393F4
sury.cz. 18000 IN RRSIG DS 10 2 18000 20170204123925 20170123103958 58211 cz. qllrV+THBIRutS0VfRJgp1tKictj73PHSPn3YOjlk/Mk6PbPsEIfcoTVFDp1cmOIG4gD+JNdMCDSDV4v5gjKlrwksDbH47ri3otZja0Uhd1RS5D+y9neXVtwJiSq22a/yGEp7xVWaoZNnxOp4J+Lva8LHW3q5/YF3RBmC7Uc7Vk=
;; ADDITIONAL SECTION:
trubka.network.cz. 18000 IN A 81.91.84.116
trubka.network.cz. 18000 IN AAAA 2001:1568:b::145
trubka.network.cz. 18000 IN AAAA 2001:1568:b:145::1
;; Received 377 B
;; Time 2017-01-23 13:21:27 CET
;; From 2001:678:f::1@53(UDP) in 0.7 ms
```
In such case and when the parent zone is secure (e.g. signed and valid), the logic should re-query for `DS` records first (instead of turning off QNAME minimization):
```
[14667][iter] 'www.nic.cz.' type 'A' id was assigned, parent id 0
[14667][resl] => querying: '2001:678:1::1' score: 11 zone cut: 'cz.' m12n: 'nIC.Cz.' type: 'NS' proto: 'udp'
[14667][iter] <= rcode: NOERROR
[14667][iter] <= found cut, retrying with non-minimized name
[14667][resl] <= server: '2001:678:1::1' rtt: 0 ms
```
This is an optimalization and not a critical bugfix, so assigning it to 1.3.0 release.https://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/288introduce proper metatype for knot_dname_t2020-04-06T14:51:49+02:00Petr Špačekintroduce proper metatype for knot_dname_tFollow-up from "WIP: Add useful lua functions to handle knot types"
The following discussion from !425 should be addressed:
- [ ] Eventually `knot_dname_t` should be a proper metatype, but this will require multitude of changes that I ...Follow-up from "WIP: Add useful lua functions to handle knot types"
The following discussion from !425 should be addressed:
- [ ] Eventually `knot_dname_t` should be a proper metatype, but this will require multitude of changes that I didn't want to bundle in this PR. [discussion](https://gitlab.labs.nic.cz/knot/knot-resolver/merge_requests/425#note_65039): (+5 comments)https://gitlab.nic.cz/knot/knot-resolver/-/issues/528control socket logging is too noisy2019-12-11T10:48:23+01:00Petr Špačekcontrol socket logging is too noisyOn busy systems the control socket is too noisy.
Originally I thought it is a "security"/"audit" feature that all the traffic will get into kresd logs, but it turns out that some users use the API heavily and this leads to voluminous an...On busy systems the control socket is too noisy.
Originally I thought it is a "security"/"audit" feature that all the traffic will get into kresd logs, but it turns out that some users use the API heavily and this leads to voluminous and at the same time useless log.
Proposal:
Log socket communication only if verbose mode is enabled.
Better solution would be fine-grained logging configuration (#527) but that's out out of scope of this ticket.5.0.0Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://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/109iterate: more queries than required, in some cases2019-08-12T16:51:47+02:00Vladimír Čunátvladimir.cunat@nic.cziterate: more queries than required, in some casesExample, without dnssec for simplicity:
```
[plan] plan 'git.nic.cz.' type 'A'
[resl] => using root hints
[resl] => querying: '2001:dc3::35' score: 10 zone cut: '.' m12n: 'Cz.' type: 'NS' proto: 'udp'
[iter] <= using glue for 'c.ns...Example, without dnssec for simplicity:
```
[plan] plan 'git.nic.cz.' type 'A'
[resl] => using root hints
[resl] => querying: '2001:dc3::35' score: 10 zone cut: '.' m12n: 'Cz.' type: 'NS' proto: 'udp'
[iter] <= using glue for 'c.ns.nic.cz.'
[iter] <= using glue for 'b.ns.nic.cz.'
[iter] <= using glue for 'd.ns.nic.cz.'
[iter] <= using glue for 'a.ns.nic.cz.'
[iter] <= referral response, follow
[resl] <= server: '2001:dc3::35' rtt: 31 ms
[resl] => querying: '2001:678:1::1' score: 10 zone cut: 'cz.' m12n: 'niC.cz.' type: 'NS' proto: 'udp'
[iter] <= rcode: NOERROR
[iter] <= found cut, retrying with non-minimized name
[resl] <= server: '2001:678:1::1' rtt: 4 ms
[resl] => querying: '2001:678:11::1' score: 10 zone cut: 'cz.' m12n: 'gIt.niC.cz.' type: 'A' proto: 'udp'
[iter] <= using glue for 'a.ns.nic.cz.'
[iter] <= using glue for 'b.ns.nic.cz.'
[iter] <= using glue for 'd.ns.nic.cz.'
[iter] <= referral response, follow
[resl] <= server: '2001:678:11::1' rtt: 14 ms
[resl] => querying: '2001:678:10::1' score: 10 zone cut: 'nic.cz.' m12n: 'gIt.nic.cZ.' type: 'A' proto: 'udp'
[iter] <= using glue for 'a.ns.nic.cz.'
[iter] <= using glue for 'b.ns.nic.cz.'
[iter] <= using glue for 'd.ns.nic.cz.'
[iter] <= rcode: NOERROR
[resl] <= server: '2001:678:10::1' rtt: 35 ms
[resl] finished: 4, queries: 1, mempool: 16400 B
```
It seems an infrequent edge case. AFAIK doing the same (sub-)query twice brings no benefit. (It happens the same with dnssec enabled, only there's lots of additional "noise".)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/253systemd socket activation documentation improvements2019-06-06T13:55:27+02:00Ghost Usersystemd socket activation documentation improvementsDocumentation for systemd socket activation should contain following:
- systemd-resolved should be `disabled`
- kresd.socket should be `enabled` and not the kresd.service (which is being activated, but this might be unclear to casual sys...Documentation for systemd socket activation should contain following:
- systemd-resolved should be `disabled`
- kresd.socket should be `enabled` and not the kresd.service (which is being activated, but this might be unclear to casual systemd users)
- for listening on public interfaces w/ socket activation is necessary to add FreeBind=true directive into [Socket] section
- maybe socket file can contain FreeBind=true by default as it is no harm on local interfaces
Hopefully this will make it easier for people who struggle to use systemd socket activated kresd.
Regards.https://gitlab.nic.cz/knot/knot-resolver/-/issues/126cache.get(): show contents of RRs2019-03-22T13:54:44+01:00Vladimír Čunátvladimir.cunat@nic.czcache.get(): show contents of RRs... to simplify debugging.
Probably `knot_rrset_txt_dump*` from `cache_dump_key`.... to simplify debugging.
Probably `knot_rrset_txt_dump*` from `cache_dump_key`.https://gitlab.nic.cz/knot/knot-resolver/-/issues/290Remove support for Go modules?2019-03-12T12:12:24+01:00Marek VavrusaRemove support for Go modules?There is still optional build support for Go modules, which has never been (and probably never will be) more than experimental due to challenges with differences between Go and C runtime. Do you have any plan for keeping it supported or ...There is still optional build support for Go modules, which has never been (and probably never will be) more than experimental due to challenges with differences between Go and C runtime. Do you have any plan for keeping it supported or removing it?Tomas KrizekTomas Krizekhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/338doc/kresd.8 is generated during the install phase2019-03-12T12:12:23+01:00Daniel Kahn Gillmordoc/kresd.8 is generated during the install phasein `daemon/daemon.mk` we see that `doc/kresd.8` is produced from `doc/kresd.8.in` as part of the `daemon-install` target.
This means that if the `make` invocation sets `KEYFILE_DEFAULT` or `MODULEDIR` or `VERSION`, but the same value is...in `daemon/daemon.mk` we see that `doc/kresd.8` is produced from `doc/kresd.8.in` as part of the `daemon-install` target.
This means that if the `make` invocation sets `KEYFILE_DEFAULT` or `MODULEDIR` or `VERSION`, but the same value is not also set during `make install` the sed replacements won't have the correct value.
`doc/kresd.8` should have an explicit build target that should be a part of the standard `make` invocation so that it gets the right substitutions.
`daemon-install` can then take responsibility for installing the generated manpage.Tomas KrizekTomas Krizekhttps://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/411test build on MacOS X2018-11-14T14:51:52+01:00Petr Špačektest build on MacOS XIt turns out that bunch of technical people want to use Mac OS to play with Resolver.
We should have at least sanity check that Resolver builds and installs on Mac OS to allow
people to play with it easily.
**There is no intent to make...It turns out that bunch of technical people want to use Mac OS to play with Resolver.
We should have at least sanity check that Resolver builds and installs on Mac OS to allow
people to play with it easily.
**There is no intent to make performance optimizations for Mac OS.**
**Mac OS build is intended for playground usage and nothing else.**Tomas KrizekTomas Krizekhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/410test Dockerfile in Gitlab CI2018-11-14T14:24:50+01:00Petr Špačektest Dockerfile in Gitlab CIRight now Docker file `scripts/Dockerfile` is tested asynchronously by Docker Hub which pulls it from Github repo mirror.
This is of course suboptimal because we find problems only when the change is already merged in master.
Once we ha...Right now Docker file `scripts/Dockerfile` is tested asynchronously by Docker Hub which pulls it from Github repo mirror.
This is of course suboptimal because we find problems only when the change is already merged in master.
Once we have time we should integrate Dockerfile testing into Gitlab CI to get rid of annoying problems
with asynchronous tests.Tomas KrizekTomas Krizek