Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2021-12-21T11:55:58+01:00https://gitlab.nic.cz/knot/knot-resolver/-/issues/690CNAME chain not being followed while resolving ap-southeast-1.console.aws.ama...2021-12-21T11:55:58+01:00Ondřej BenkovskýCNAME chain not being followed while resolving ap-southeast-1.console.aws.amazon.com.Hello, we are currently running instance of Knot Resolver with these settings [config](/uploads/8fd91f71d1bbcfbd96842c8b771a1e0d/config)
and we were alerted that when we are resolving `ap-southeast-1.console.aws.amazon.com.` domain thr...Hello, we are currently running instance of Knot Resolver with these settings [config](/uploads/8fd91f71d1bbcfbd96842c8b771a1e0d/config)
and we were alerted that when we are resolving `ap-southeast-1.console.aws.amazon.com.` domain through the instance of Knot Resolver (100.64.0.104 is the address of our instance of Knot Resolver), we receive this answer with no answer section
```
dig @100.64.0.104 ap-southeast-1.console.aws.amazon.com.
; <<>> DiG 9.16.20 <<>> @100.64.0.104 ap-southeast-1.console.aws.amazon.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27863
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ap-southeast-1.console.aws.amazon.com. IN A
;; Query time: 220 msec
;; SERVER: 100.64.0.104#53(100.64.0.104)
;; WHEN: Mon Dec 20 09:20:43 UTC 2021
;; MSG SIZE rcvd: 66
```
on the other hand, when we resolve the same domain using GoogleDNS(8.8.8.8), we get this proper answer
```
dig @8.8.8.8 ap-southeast-1.console.aws.amazon.com.
; <<>> DiG 9.16.20 <<>> @8.8.8.8 ap-southeast-1.console.aws.amazon.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1185
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ap-southeast-1.console.aws.amazon.com. IN A
;; ANSWER SECTION:
ap-southeast-1.console.aws.amazon.com. 28 IN CNAME gr.console-geo.ap-southeast-1.amazonaws.com.
gr.console-geo.ap-southeast-1.amazonaws.com. 60 IN CNAME a299197c08ba4f000.awsglobalaccelerator.com.
a299197c08ba4f000.awsglobalaccelerator.com. 9 IN A 3.3.14.1
a299197c08ba4f000.awsglobalaccelerator.com. 9 IN A 3.3.15.1
;; Query time: 16 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Dec 20 11:11:35 UTC 2021
;; MSG SIZE rcvd: 205
```
**the logs from the Knot Resolver for problematic resolution looks like this** [logs.log](/uploads/ab755a2cc002c36ac86374f1dfb529aa/logs.log)
**Do you see where is the problem? Could you assist me?** It seems that we are hitting this issue only for some subdomains of console.aws.amazon.com. For example us-east-1.console.aws.com resolves through the instance of Knot Resolver with no problemshttps://gitlab.nic.cz/knot/knot-resolver/-/issues/702datamodel: zone name as key in forward/stub-zones dictionary2022-06-21T11:56:53+02:00Aleš Mrázekdatamodel: zone name as key in forward/stub-zones dictionaryCurrently, the zone name is a key of stub/forward zone [dict](https://gitlab.nic.cz/knot/knot-resolver-manager/-/blob/datamodel-policy/knot_resolver_manager/datamodel/config_schema.py#L57), so it is not possible to create two configurati...Currently, the zone name is a key of stub/forward zone [dict](https://gitlab.nic.cz/knot/knot-resolver-manager/-/blob/datamodel-policy/knot_resolver_manager/datamodel/config_schema.py#L57), so it is not possible to create two configurations for one zone.
However, this can be a problem, for example, if I want to set up different stub/forward servers for `view` which differs from the global configuration.Aleš MrázekAleš Mrázekhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/689policy RPZ/action logging2021-12-22T11:04:19+01:00Jon Polompolicy RPZ/action loggingIs there a list of available [log groups](https://knot-resolver.readthedocs.io/en/stable/config-logging-monitoring.html?highlight=logging#log_level)?Is there a list of available [log groups](https://knot-resolver.readthedocs.io/en/stable/config-logging-monitoring.html?highlight=logging#log_level)?https://gitlab.nic.cz/knot/knot-resolver/-/issues/701full partial config updates2022-08-30T14:43:29+02:00Vaclav Sraierfull partial config updatesCurrently, we can only change configuration model with whole subtrees. So for example, you can't update a list or a dictionary with one value, you have to replace it whole.Currently, we can only change configuration model with whole subtrees. So for example, you can't update a list or a dictionary with one value, you have to replace it whole.Vaclav SraierVaclav Sraierhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/700kresd process manager: decouple restarts from config change requests2022-11-19T20:51:24+01:00Vaclav Sraierkresd process manager: decouple restarts from config change requests- goals:
- increase throughput for config changes
- limitations:
- we can't make a config change faster as we have to restart everything
- proposed solution:
- keep track of config versions and restart `kresd`s continuously decoupl...- goals:
- increase throughput for config changes
- limitations:
- we can't make a config change faster as we have to restart everything
- proposed solution:
- keep track of config versions and restart `kresd`s continuously decoupled from requests. Mark request as finished when the config version of all `kresd`s is higherhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/699prometheus & graphite: aggregation and relaying of metrics in manager2022-02-19T10:42:49+01:00Vaclav Sraierprometheus & graphite: aggregation and relaying of metrics in managerfollowing [this discussion on Slack](https://cznic.slack.com/archives/C01EC5ADMB6/p1637675341005100)following [this discussion on Slack](https://cznic.slack.com/archives/C01EC5ADMB6/p1637675341005100)https://gitlab.nic.cz/knot/knot-resolver/-/issues/698logging: aggregation of records in the log of individual processes2022-10-12T16:03:55+02:00Aleš Mrázeklogging: aggregation of records in the log of individual processesThe user should have easy access to log records of all knot-resolver processes(kresd instances, cache garbage collector and manager).
With systemd, the solution could look like `systemctl status knot-resolver` or `journalctl -u knot-res...The user should have easy access to log records of all knot-resolver processes(kresd instances, cache garbage collector and manager).
With systemd, the solution could look like `systemctl status knot-resolver` or `journalctl -u knot-resolver`Vaclav SraierVaclav Sraierhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/688DNSSEC validation not occurring2021-12-07T18:00:43+01:00Jon PolomDNSSEC validation not occurringKnot Resolver does not seem to be validating DNSSEC in my test configuration. Perhaps this is actually expected behavior but it is different from what I observe with other validating DNS servers (1.1.1.1, local unbound instances, resolve...Knot Resolver does not seem to be validating DNSSEC in my test configuration. Perhaps this is actually expected behavior but it is different from what I observe with other validating DNS servers (1.1.1.1, local unbound instances, resolved).
I am running Knot Resolver version 5.4.2 on Fedora 35 using the distribution provided packages and distribution provided configuration. At the moment this is a single daemon local resolver for testing, in a virtual machine. The server is being queried over the loopback interface. The default configuration will be posted at the end.
Here are some test cases that suggest something is not right:
### `drill -D sigfail.verteiltesysteme.net @127.0.0.1`
```
[vagrant@fedora knot-resolver]$ drill -D sigfail.verteiltesysteme.net @127.0.0.1
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 17339
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; sigfail.verteiltesysteme.net. IN A
;; ANSWER SECTION:
sigfail.verteiltesysteme.net. 60 IN A 134.91.78.139
sigfail.verteiltesysteme.net. 60 IN RRSIG A 5 3 60 20220301030001 20211130030001 30665 verteiltesysteme.net. //This+RRSIG+is+deliberately+broken///For+more+information+please+go+to/http+//www+verteiltesysteme+net///////////////////////////////////////////////////////////////////8=
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 140 msec
;; EDNS: version 0; flags: do ; udp: 1232
;; SERVER: 127.0.0.1
;; WHEN: Tue Dec 7 01:12:33 2021
;; MSG SIZE rcvd: 253
```
### Trace for sigfail.verteiltesysteme.net
```
[vagrant@fedora knot-resolver]$ drill -DT sigfail.verteiltesysteme.net @127.0.0.1
;; Number of trusted keys: 1
;; Domain: .
[T] . 172800 IN DNSKEY 256 3 8 ;{id = 14748 (zsk), size = 2048b}
. 172800 IN DNSKEY 257 3 8 ;{id = 20326 (ksk), size = 2048b}
Checking if signing key is trusted:
New key: . 172800 IN DNSKEY 256 3 8 AwEAAY+oUaY0b7Z45vRD1ef/GykZqgHJtfdzRcnQNvGVQAqlH22QChtG+n1EMugw7T/6uDBAGlRIkXASdtHXhxStb9lPpyQe5/JIuMIlg+NhxKxEJ5e3J9SSPCavvDhH/BPrBCJwn8b68QAWRjVW6Rgdx63pUm7lfsimiWGMfplHNvcZWgVbKA9OI2o2lU8rT8n7zuwtlZPNpDLSI5GzrJgIiKR2Id16fmAgTJBOw14Xye/t4/BxTdxeMiiVFwA4KUV2VeqspHKSHFOz+lUIIqBRknEmYpSvnxnyi0n1n4tGnGP8z6ZwRACi1Rw0nCu7BGOU9M6LpInRoW/W4KXLODr6xqU= ;{id = 14748 (zsk), size = 2048b}
Trusted key: . 172800 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b}
Trusted key: . 172800 IN DNSKEY 256 3 8 AwEAAY+oUaY0b7Z45vRD1ef/GykZqgHJtfdzRcnQNvGVQAqlH22QChtG+n1EMugw7T/6uDBAGlRIkXASdtHXhxStb9lPpyQe5/JIuMIlg+NhxKxEJ5e3J9SSPCavvDhH/BPrBCJwn8b68QAWRjVW6Rgdx63pUm7lfsimiWGMfplHNvcZWgVbKA9OI2o2lU8rT8n7zuwtlZPNpDLSI5GzrJgIiKR2Id16fmAgTJBOw14Xye/t4/BxTdxeMiiVFwA4KUV2VeqspHKSHFOz+lUIIqBRknEmYpSvnxnyi0n1n4tGnGP8z6ZwRACi1Rw0nCu7BGOU9M6LpInRoW/W4KXLODr6xqU= ;{id = 14748 (zsk), size = 2048b}
Key is now trusted!
Trusted key: . 172800 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b}
[T] net. 86400 IN DS 35886 8 2 7862b27f5f516ebe19680444d4ce5e762981931842c465f00236401d8bd973ee
;; Domain: net.
[T] net. 86400 IN DNSKEY 257 3 8 ;{id = 35886 (ksk), size = 2048b}
net. 86400 IN DNSKEY 256 3 8 ;{id = 40649 (zsk), size = 1280b}
Checking if signing key is trusted:
New key: net. 86400 IN DNSKEY 256 3 8 AQPc+XHppSgsIokAod79sL0jKA4sBuePSLrBBrcQCAJJSpxto7hsQWGUtmk0sFKAoVMrBto4lVpTBvHuDiaE+S98ptvBw7d5llp9dd9bZvX3Z47U+KVEE3zmPT887w+WZ05PDzib7hy+QMg/uug/F+lJTIr+dGXCGvLyuWtvmWqV+hH0BL40DY2Wy4KE04NgfwWU3B5QqjFaVc9TK3R8BHl1 ;{id = 40649 (zsk), size = 1280b}
Trusted key: . 172800 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b}
Trusted key: . 172800 IN DNSKEY 256 3 8 AwEAAY+oUaY0b7Z45vRD1ef/GykZqgHJtfdzRcnQNvGVQAqlH22QChtG+n1EMugw7T/6uDBAGlRIkXASdtHXhxStb9lPpyQe5/JIuMIlg+NhxKxEJ5e3J9SSPCavvDhH/BPrBCJwn8b68QAWRjVW6Rgdx63pUm7lfsimiWGMfplHNvcZWgVbKA9OI2o2lU8rT8n7zuwtlZPNpDLSI5GzrJgIiKR2Id16fmAgTJBOw14Xye/t4/BxTdxeMiiVFwA4KUV2VeqspHKSHFOz+lUIIqBRknEmYpSvnxnyi0n1n4tGnGP8z6ZwRACi1Rw0nCu7BGOU9M6LpInRoW/W4KXLODr6xqU= ;{id = 14748 (zsk), size = 2048b}
Trusted key: . 172800 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b}
Trusted key: net. 86400 IN DNSKEY 257 3 8 AQOYBnzqWXIEj6mlgXg4LWC0HP2n8eK8XqgHlmJ/69iuIHsa1TrHDG6TcOra/pyeGKwH0nKZhTmXSuUFGh9BCNiwVDuyyb6OBGy2Nte9Kr8NwWg4q+zhSoOf4D+gC9dEzg0yFdwT0DKEvmNPt0K4jbQDS4Yimb+uPKuF6yieWWrPYYCrv8C9KC8JMze2uT6NuWBfsl2fDUoV4l65qMww06D7n+p7RbdwWkAZ0fA63mXVXBZF6kpDtsYD7SUB9jhhfLQE/r85bvg3FaSs5Wi2BaqN06SzGWI1DHu7axthIOeHwg00zxlhTpoYCH0ldoQz+S65zWYi/fRJiyLSBb6JZOvn ;{id = 35886 (ksk), size = 2048b}
Trusted key: net. 86400 IN DNSKEY 256 3 8 AQPc+XHppSgsIokAod79sL0jKA4sBuePSLrBBrcQCAJJSpxto7hsQWGUtmk0sFKAoVMrBto4lVpTBvHuDiaE+S98ptvBw7d5llp9dd9bZvX3Z47U+KVEE3zmPT887w+WZ05PDzib7hy+QMg/uug/F+lJTIr+dGXCGvLyuWtvmWqV+hH0BL40DY2Wy4KE04NgfwWU3B5QqjFaVc9TK3R8BHl1 ;{id = 40649 (zsk), size = 1280b}
Key is now trusted!
[T] verteiltesysteme.net. 86400 IN DS 61908 5 1 3497d121f4c91369e95dc73d8032e688e1abb1fe
verteiltesysteme.net. 86400 IN DS 61908 5 2 2f87866a60c3603f447658ac3ea72baec053b7f9f85fa4b531aabe88b06f5aee
;; Domain: verteiltesysteme.net.
[T] verteiltesysteme.net. 3600 IN DNSKEY 257 3 5 ;{id = 61908 (ksk), size = 1024b}
verteiltesysteme.net. 3600 IN DNSKEY 256 3 5 ;{id = 30665 (zsk), size = 1024b}
[T] Existence denied: sigfail.verteiltesysteme.net. DS
;; No ds record for delegation
;; Domain: sigfail.verteiltesysteme.net.
;; No DNSKEY record found for sigfail.verteiltesysteme.net.
[B] sigfail.verteiltesysteme.net. 60 IN A 134.91.78.139
;; Error: Bogus DNSSEC signature
;;[S] self sig OK; [B] bogus; [T] trusted
```
### `drill -D sigfail.verteiltesysteme.net @1.1.1.1`
```
[vagrant@fedora knot-resolver]$ drill -D sigfail.verteiltesysteme.net @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, rcode: SERVFAIL, id: 15928
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; sigfail.verteiltesysteme.net. IN A
;; ANSWER SECTION:
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 347 msec
;; EDNS: version 0; flags: do ; udp: 1232
;; Data: \# 12 000f00020006000f00020016
;; SERVER: 1.1.1.1
;; WHEN: Tue Dec 7 01:16:55 2021
;; MSG SIZE rcvd: 69
```
As you can see the answers section is empty and the response is a SERVFAIL when querying 1.1.1.1 for this domain with deliberately broken DNSSEC records. I obtain the same results from running a local unbound recursive server and from other public validating DNS servers.
It seems like DNSSEC validation isn't occurring and Knot is going on to return unvalidated data in its response. It's clear from the trace that this domain does not have valid DNSSEC data associated with it. My expectation is that unless I were to disable DNSSEC in knot that it would not return a result for such a domain.
Perhaps there are some configuration items that need to be changed here? I've read the Knot Resolver documentation on DNSSEC validation and it suggests that it is enabled by default and shouldn't require any configuration. I have checked and it appears the trust anchor is loaded so I don't believe that is the issue.
### Tested configuration
```
[vagrant@fedora knot-resolver]$ cat /etc/knot-resolver/kresd.conf
-- SPDX-License-Identifier: CC0-1.0
-- vim:syntax=lua:set ts=4 sw=4:
-- Refer to manual: https://knot-resolver.readthedocs.org/en/stable/
-- Network interface configuration
net.listen('127.0.0.1', 53, { kind = 'dns' })
net.listen('127.0.0.1', 853, { kind = 'tls' })
--net.listen('127.0.0.1', 443, { kind = 'doh2' })
net.listen('::1', 53, { kind = 'dns', freebind = true })
net.listen('::1', 853, { kind = 'tls', freebind = true })
--net.listen('::1', 443, { kind = 'doh2' })
-- Load useful modules
modules = {
'hints < iterate', -- Load /etc/hosts and allow custom root hints
'stats', -- Track internal statistics
'predict', -- Prefetch expiring/frequent records
}
net.ipv6 = false
-- Cache size
cache.size = 100 * MB
```
Overall I am super impressed with Knot Resolver from a technical perspective. It seems to be incredibly customizable and configurable using a standard language. It's entirely possible I am not understanding what the proper behavior is here, but I feel like I should open an issue in case this is in fact a real problem.https://gitlab.nic.cz/knot/knot-resolver/-/issues/687serve_stale module doesn't provide stale answers when auths are unresponsive2022-03-09T11:16:31+01:00Tomas Krizekserve_stale module doesn't provide stale answers when auths are unresponsiveAs of version 5.4.2, `serve_stale` module doesn't work when auth servers are unresponsive (which is the typical case with network issues). The server selection algorithm tries very hard to resolve the request by re-trying different auth ...As of version 5.4.2, `serve_stale` module doesn't work when auth servers are unresponsive (which is the typical case with network issues). The server selection algorithm tries very hard to resolve the request by re-trying different auth servers and increasing their allowed timeouts, until the request ultimately times out and returns SERVFAIL instead of a stale answer.
If the auth servers are reachable but REFUSE to respond, the serve_stale module works as expected (that was our former test case with deckard).
Some notes about possible resolution:
- to be useful for clients, the stale answer should be provided quickly enough ([RFC 8767.5](https://datatracker.ietf.org/doc/html/rfc8767#section-5) suggests sending stale answer after 1.8s). The timeout used for serve_stale should ideally be configurable.
- the request resolution should keep going even after the stale answer is sent to the client to refresh data from slower auth severs (possible option: spawn a new duplicate internal request after providing the stale answer?)
- server selection should have a configurable time limit that is respected and allows serve_stale to activate in time
- the server selection time limit shouldn't be used unless serve_stale module is loaded _and_ there is a possible stale answer in the cachehttps://gitlab.nic.cz/knot/knot-resolver/-/issues/686Please document SOA included in authority section for queries within local (a...2021-11-13T10:32:21+01:00Sergio CallegariPlease document SOA included in authority section for queries within local (and how to avoid it)As mentioned in https://forum.turris.cz/t/avahi-local-domain-warning-on-ubuntu/13437, knot resolver answers any queries within local by NXDOMAIN but it adds this SOA in the authority section:
```
$ dig local
;; WARNING: .local is reserv...As mentioned in https://forum.turris.cz/t/avahi-local-domain-warning-on-ubuntu/13437, knot resolver answers any queries within local by NXDOMAIN but it adds this SOA in the authority section:
```
$ dig local
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56352
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;local. IN A
;; AUTHORITY SECTION:
local. 10800 IN SOA local. nobody.invalid. 1 3600 1200 604800 10800
;; ADDITIONAL SECTION:
explanation.invalid. 10800 IN TXT “Blocking is mandated by standards, see references on https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml”
```
Unfortunately, this confuses `systemd-resolved` (maybe just older versions of it) and completely breaks mDNS name resolution on ubuntu focal (and possibly other distros).
What happens is as follows:
1. You do something like `ping foo.local`
2. Ubuntu focal has by default the host field in nsswitch.conf set to:
`hosts: files mdns4_minimal [NOTFOUND=return] dns`
so it tries the `/etc/hosts/` file and then mdns via the nss `mdns4_minimal` client
3. The `mdns4_minimal` client before doing anything else tries unicast DNS looking for a SOA for `local.` This mechanism is
present in the mdns4_minimal client to avoid issues when `local` in under DNS control and is documented at
https://github.com/lathiat/nss-mdns/blob/master/README.md
4. Ubuntu focal uses by default `systemd-resolved` as a caching DNS, so the query from `mdns4_minimal` gets to it
5. `systemd-resolved` passes the query to the DNS it is configured to use. If this is Knot resolver it gets that special SOA
in the authority section and turns it into a regular SOA reply (no NXDOMAIN)
6. `mdns4_minimal` receives a SOA reply for local and gives up
7. At this point DNS is queried. Back to `systemd-resolved` now trying to get the A field for `foo.local`.
8. By default `systemd-resolved` on ubuntu is configured not to do mDNS itself (even if it has this capability). Hence the
query at the previous point fails.
9. Rather than pinging foo.local you get an error.
I believe that:
- This is not a bug in knot resolver, rather a bug in `systemd-resolved` that makes itself confused by a legitimate answer
from knot resolver
- The issue in `systemd-resolved` may have been fixed in versions of systemd more recent than the one shipped in Ubuntu focal
(at least some quick testing on a rolling distro seems not to give the problem)
However, because:
1. Ubuntu Focal is extremely widespread
2. Ubuntu Focal is likely that it will not backport fixes to its `systemd-resolved` (because this is shipped in the `systemd` package that is quite delicate to touch)
3. The returning of the special SOA for things within `local` is something that older versions of knot resolver did not do
I believe that it could be worth adding an explicit note in the knot resolver documentation about the special SOA returned for queries within `local` and on how to avoid it in case it causes issues with mDNS name resolution.
I have observed that something like
```
policy.add(policy.suffix(policy.DROP, policy.todnames({'local.'})))
```
added to `kresd.conf` seems to be enough to workaround the problem, but I am not knowledgeable enough to know if this is the right solution.https://gitlab.nic.cz/knot/knot-resolver/-/issues/684ANSWER section not empty on SERVFAIL2021-11-04T10:58:48+01:00Tomas KrizekANSWER section not empty on SERVFAILIn some cases, the ANSWER section contains (unvalidated) data while the request ends with SERVFAIL.
In my specific conditions, the issue seems reproducible when:
- cache is clear
- IPv6 isn't available, but isn't turned off with net.ipv...In some cases, the ANSWER section contains (unvalidated) data while the request ends with SERVFAIL.
In my specific conditions, the issue seems reproducible when:
- cache is clear
- IPv6 isn't available, but isn't turned off with net.ipv6
- server selection chooses specific servers (and typically chooses the non-functioning IPv6 ones)
```
$ kdig @::1 -p 5553 +timeout=16 +edns signotincepted.bad-dnssec.wb.sidnlabs.nl
;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 6998
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; QUESTION SECTION:
;; signotincepted.bad-dnssec.wb.sidnlabs.nl. IN A
;; ANSWER SECTION:
signotincepted.bad-dnssec.wb.sidnlabs.nl. 3600 IN A 94.198.159.39
;; Received 85 B
;; Time 2021-11-04 10:45:32 CET
;; From ::1@5553(UDP) in 10027.7 ms
```
See attached [log.txt](/uploads/8d1aa54458e26860a5d0f4e36d105cad/log.txt)https://gitlab.nic.cz/knot/knot-resolver/-/issues/683performance problem because of shared cache2021-10-26T11:50:06+02:00Hamza Kılıçperformance problem because of shared cacheI am making benchmarks for a project. And sending 10M queries to resolvers for test.
- Every test starts with cold start.
- Opening 8 process.
- measuring %core, pps, elapsed miliseconds, and download Mbps.
I founded an interesting ...I am making benchmarks for a project. And sending 10M queries to resolvers for test.
- Every test starts with cold start.
- Opening 8 process.
- measuring %core, pps, elapsed miliseconds, and download Mbps.
I founded an interesting result.
Opening 8 process with shared cache at the same folder (/var/cache/knot-resolver) vs 8 process with different cache folders
results look like these values (approximately)
- each core (every 8 cores)
- % 60 - %99
- pps
- 20000- 30000
- elapsed miliseconds
- 500 - 300
- download Mbps
- 100 - 160
conclusion: using shared cache slows down performance dramatically.
Is there a way to fix this problem?https://gitlab.nic.cz/knot/knot-resolver/-/issues/682CNAME forward lookup failing2021-10-25T15:26:50+02:00Ghost UserCNAME forward lookup failingHello there,
I am not sure if this is a bug or not but I am starting to be clueless. I am using a high availibity Pihole-KRESD combination for external lookups to have an ad-free network.
So far it works perfectly without many user int...Hello there,
I am not sure if this is a bug or not but I am starting to be clueless. I am using a high availibity Pihole-KRESD combination for external lookups to have an ad-free network.
So far it works perfectly without many user intervention but today I stumbled into a strange behaviour of Knot Resolver as it seems not to follow all CNAMEs of a domain.
Lookup via Pi-hole + KRESD always give me following lookup:
```
dig go.zextras.com @192.168.20.105
; <<>> DiG 9.16.1-Ubuntu <<>> go.zextras.com @192.168.20.105
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59509
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;go.zextras.com. IN A
;; ANSWER SECTION:
go.zextras.com. 39957 IN CNAME go.pardot.com.
go.pardot.com. 2859 IN CNAME pi.pardot.com.
pi.pardot.com. 523 IN A 127.0.0.1
;; Query time: 10 msec
;; SERVER: 192.168.20.105#53(192.168.20.105)
;; WHEN: Mon Oct 25 12:02:20 CEST 2021
;; MSG SIZE rcvd: 100
```
The correct answer should be:
```
dig go.zextras.com @9.9.9.9
; <<>> DiG 9.16.1-Ubuntu <<>> go.zextras.com @9.9.9.9
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1953
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;go.zextras.com. IN A
;; ANSWER SECTION:
go.zextras.com. 43200 IN CNAME go.pardot.com.
go.pardot.com. 3602 IN CNAME pi.pardot.com.
pi.pardot.com. 300 IN CNAME pi-ue1.pardot.com.
pi-ue1.pardot.com. 900 IN CNAME pi.t.pardot.com.
pi.t.pardot.com. 30 IN CNAME pi-ue1-lba2.pardot.com.
pi-ue1-lba2.pardot.com. 36 IN A 52.21.178.134
;; Query time: 260 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Mon Oct 25 12:03:28 CEST 2021
;; MSG SIZE rcvd: 166
```
To be totally sure I have also queried all of the DNS servers I have set up within kresd.conf. Everyone is giving me the right answer.
As mentioned: I am not sure if this is a Knot Resolver bug or if there is kind of a config parameter (e.g. just follow x CNAME else return 127.0.0.1).
My current configuration of KRESD would be:
```
-- Default empty Knot DNS Resolver configuration in -*- lua -*-
-- Switch to unprivileged user --
user('knot-resolver','knot-resolver')
-- Unprivileged
-- cache.size = 100*MB
net.listen('127.0.0.1', 5555)
net.listen('192.168.20.105', 5555)
modules = {
'policy',
'view',
'hints',
'serve_stale < cache',
'workarounds < iterate',
'stats',
'predict'
}
--Accept all requests from these subnets
view:addr('127.0.0.1/8', function (req, qry) return policy.PASS end)
view:addr('192.168.10.0/24', function (req, qry) return policy.PASS end)
view:addr('192.168.20.0/24', function (req, qry) return policy.PASS end)
view:addr('192.168.101.0/24', function (req, qry) return policy.PASS end)
-- Drop everything that hasn't matched
view:addr('0.0.0.0/0', function (req, qry) return policy.DROP end)
policy.add(policy.all(policy.TLS_FORWARD({
-- {'80.241.218.68', hostname='fdns1.dismail.de'},
-- {'159.69.114.157', hostname='fdns2.dismail.de'},
-- {'89.233.43.71', hostname='unicast.censurfridns.dk'},
-- {'91.239.100.100', hostname='anycast.censurfridns.dk'},
{'46.182.19.48', hostname='dns2.digitalcourage.de'},
{'176.9.93.198', hostname='dnsforge.de'},
})))
predict.config({ window = 20, period = 72 })
```https://gitlab.nic.cz/knot/knot-resolver/-/issues/680Progressively failing DoT to Quad9 servers2021-10-22T11:34:44+02:00savchenkoProgressively failing DoT to Quad9 serversI am seeing progressively increasing number of endpoints failing with:
```
[tls_client] failed to verify peer certificate: The certificate is NOT trusted. The revocation or OCSP data are old and have been superseded.
```
All nodes are ...I am seeing progressively increasing number of endpoints failing with:
```
[tls_client] failed to verify peer certificate: The certificate is NOT trusted. The revocation or OCSP data are old and have been superseded.
```
All nodes are running Debian 11.1 and are fully updated including `ca-certificates` and subsequent `update-ca-certificates --fresh`.
Interestingly, I can't reproduce it universally, only select hosts appear to be affected. I do see gradual increase in a number of failing nodes.
All targets are provisioned with the same Ansible playbook. Switching policy to regular DNS-over-UDP "solves" the issue.
Example of the policy that fails:
```lua
-- DNS-over-TLS
policy.add(policy.all(policy.TLS_FORWARD({
{'9.9.9.9', hostname='dns.quad9.net'},
{'149.112.112.112', hostname='dns.quad9.net'}
})))
```
Example of the working policy:
```lua
-- DNS-over-UDP
policy.add(policy.all(policy.FORWARD({'9.9.9.9', '149.112.112.112'})))
```
I would appreciate any suggestions as to what can be the root cause.https://gitlab.nic.cz/knot/knot-resolver/-/issues/679DNSSEC failure on insecure subzone2021-10-23T10:08:30+02:00Tomas KrizekDNSSEC failure on insecure subzoneReported on [knot-resolver-users](https://lists.nic.cz/pipermail/knot-resolver-users/2021/000396.html) by Matthew Richardson
Attempting to resolve `213-133-203-34.newtel.in-addr.itconsult.net. PTR` ends up with a DNSSEC failure, even to...Reported on [knot-resolver-users](https://lists.nic.cz/pipermail/knot-resolver-users/2021/000396.html) by Matthew Richardson
Attempting to resolve `213-133-203-34.newtel.in-addr.itconsult.net. PTR` ends up with a DNSSEC failure, even tough the record itself is in an insecure subzone.
> The zone cut is between itconsult.net & newtel.in-addr.itconsult.net.
> Also whilst itconsult.net is DNSSEC signed, newtel.in-addr.itconsult.net is
> not. Thus, in-addr.itconsult.net is an empty non-terminal.
>
> If one asks for NS for newtel.in-addr.itconsult.net, thereafter resolution
> of the PTR then succeeds
```
[plan ][00000.00] plan '213-133-203-34.newtel.in-addr.itconsult.net.' type 'PTR' uid [51359.00]
[iterat][51359.00] '213-133-203-34.newtel.in-addr.itconsult.net.' type 'PTR' new uid was assigned .01, parent uid .00
[cache ][51359.01] => skipping exact RR: rank 027 (min. 030), new TTL 43131
[cache ][51359.01] => trying zone: itconsult.net., NSEC3, hash c75d4f37
[cache ][51359.01] => NSEC3 depth 3: hash uabfrhboj2pe1qnmfscd0adr77hqoirb
[cache ][51359.01] => NSEC3 encloser error for 213-133-203-34.newtel.in-addr.itconsult.net.: range search miss (!covers)
[cache ][51359.01] => NSEC3 depth 2: hash 7kdfmdhll7ee02vprj1oivl33lg5r7vu
[cache ][51359.01] => NSEC3 encloser error for newtel.in-addr.itconsult.net.: range search miss (!covers)
[cache ][51359.01] => NSEC3 depth 1: hash 4je672clu0jh2pbkm6mdj2n4ps7e9t2h
[cache ][51359.01] => NSEC3 encloser: only found existence of an ancestor
[cache ][51359.01] => skipping zone: itconsult.net., NSEC, hash 0;new TTL -123456789, ret -2
[zoncut][51359.01] found cut: itconsult.net. (rank 002 return codes: DS 0, DNSKEY 0)
[select][51359.01] => id: '47786' choosing: 'd.itconsult-dns.co.uk.'@'2001:67c:10b8::100#00053' with timeout 400 ms zone cut: 'itconsult.net.'
[resolv][51359.01] => id: '47786' querying: 'd.itconsult-dns.co.uk.'@'2001:67c:10b8::100#00053' zone cut: 'itconsult.net.' qname: 'iN-ADDR.iTConSult.neT.' qtype: 'NS' proto: 'udp'
[select][51359.01] NO6: timeouted, appended, timeouts 5/6
[select][51359.01] => id: '47786' noting selection error: 'd.itconsult-dns.co.uk.'@'2001:67c:10b8::100#00053' zone cut: 'itconsult.net.' error: 1 QUERY_TIMEOUT
[iterat][51359.01] '213-133-203-34.newtel.in-addr.itconsult.net.' type 'PTR' new uid was assigned .02, parent uid .00
[select][51359.02] => id: '56910' choosing: 'd.itconsult-dns.co.uk.'@'176.97.158.100#00053' with timeout 38 ms zone cut: 'itconsult.net.'
[resolv][51359.02] => id: '56910' querying: 'd.itconsult-dns.co.uk.'@'176.97.158.100#00053' zone cut: 'itconsult.net.' qname: 'in-aDdR.itCONsuLt.neT.' qtype: 'NS' proto: 'udp'
[select][51359.02] => id: '56910' updating: 'd.itconsult-dns.co.uk.'@'176.97.158.100#00053' zone cut: 'itconsult.net.' with rtt 18 to srtt: 18 and variance: 4
[iterat][51359.02] <= rcode: NOERROR
[iterat][51359.02] <= retrying with non-minimized name
[iterat][51359.02] '213-133-203-34.newtel.in-addr.itconsult.net.' type 'PTR' new uid was assigned .03, parent uid .00
[select][51359.03] => id: '18773' choosing: 'd.itconsult-dns.co.uk.'@'176.97.158.100#00053' with timeout 38 ms zone cut: 'itconsult.net.'
[resolv][51359.03] => id: '18773' querying: 'd.itconsult-dns.co.uk.'@'176.97.158.100#00053' zone cut: 'itconsult.net.' qname: '213-133-203-34.nEWtEL.IN-AdDr.ITcONsuLt.NEt.' qtype: 'PTR' proto: 'udp'
[select][51359.03] => id: '18773' updating: 'd.itconsult-dns.co.uk.'@'176.97.158.100#00053' zone cut: 'itconsult.net.' with rtt 16 to srtt: 18 and variance: 4
[iterat][51359.03] <= rcode: NOERROR
[valdtr][51359.03] >< cut changed, needs revalidation
[resolv][51359.03] => resuming yielded answer
[valdtr][51359.03] >< no valid RRSIGs found: 213-133-203-34.newtel.in-addr.itconsult.net. PTR (0 matching RRSIGs, 0 expired, 0 not yet valid, 0 invalid signer, 0 invalid label count, 0 invalid key, 0 invalid crypto, 0 invalid NSEC)
[plan ][51359.03] plan 'in-addr.itconsult.net.' type 'DS' uid [51359.04]
[iterat][51359.04] 'in-addr.itconsult.net.' type 'DS' new uid was assigned .05, parent uid .03
[cache ][51359.05] => trying zone: itconsult.net., NSEC3, hash c75d4f37
[cache ][51359.05] => NSEC3 depth 1: hash 4je672clu0jh2pbkm6mdj2n4ps7e9t2h
[cache ][51359.05] => NSEC3 sname: match proved NODATA, new TTL 43131
[iterat][51359.05] <= rcode: NOERROR
[valdtr][51359.05] <= parent: updating DS
[valdtr][51359.05] <= answer valid, OK
[resolv][51359.03] => resuming yielded answer
[valdtr][51359.03] >< no valid RRSIGs found: 213-133-203-34.newtel.in-addr.itconsult.net. PTR (0 matching RRSIGs, 0 expired, 0 not yet valid, 0 invalid signer, 0 invalid label count, 0 invalid key, 0 invalid crypto, 0 invalid NSEC)
[plan ][51359.03] plan 'in-addr.itconsult.net.' type 'DS' uid [51359.06]
[iterat][51359.06] 'in-addr.itconsult.net.' type 'DS' new uid was assigned .07, parent uid .03
[cache ][51359.07] => trying zone: itconsult.net., NSEC3, hash c75d4f37
[cache ][51359.07] => NSEC3 depth 1: hash 4je672clu0jh2pbkm6mdj2n4ps7e9t2h
[cache ][51359.07] => NSEC3 sname: match proved NODATA, new TTL 43131
[iterat][51359.07] <= rcode: NOERROR
[valdtr][51359.07] <= parent: updating DS
[valdtr][51359.07] <= answer valid, OK
[resolv][51359.03] => resuming yielded answer
[valdtr][51359.03] >< no valid RRSIGs found: 213-133-203-34.newtel.in-addr.itconsult.net. PTR (0 matching RRSIGs, 0 expired, 0 not yet valid, 0 invalid signer, 0 invalid label count, 0 invalid key, 0 invalid crypto, 0 invalid NSEC)
[valdtr][51359.03] <= continuous revalidation, fails
[cache ][51359.03] => not overwriting PTR 213-133-203-34.newtel.in-addr.itconsult.net.
[cache ][51359.03] => not overwriting PTR 213-133-203-34.newtel.in-addr.itconsult.net.
[dnssec] validation failure: 213-133-203-34.newtel.in-addr.itconsult.net. PTR
[resolv][51359.00] request failed, answering with empty SERVFAIL
[resolv][51359.03] finished in state: 8, queries: 2, mempool: 32800 B
```https://gitlab.nic.cz/knot/knot-resolver/-/issues/678listening sockets receive and send buffer size2021-10-20T09:19:28+02:00Hamza Kılıçlistening sockets receive and send buffer sizeplease add configuration options for socket receive/send buffer sizeplease add configuration options for socket receive/send buffer sizehttps://gitlab.nic.cz/knot/knot-resolver/-/issues/677Erratic stats figures2021-11-22T18:05:11+01:00Ghost UserErratic stats figuresWhen using the http and stats modules. Restarting the services doesn't fully zero out the counters nor does it keep them at their current values but instead resets them to what seems like a random lower value.
Rebooting the server does ...When using the http and stats modules. Restarting the services doesn't fully zero out the counters nor does it keep them at their current values but instead resets them to what seems like a random lower value.
Rebooting the server does fully reset all counters.
This could be offset if the stats/http modules also listed the uptime of the device or atleast the main thread.https://gitlab.nic.cz/knot/knot-resolver/-/issues/676deb package for latest seems broken2021-10-16T14:01:02+02:00Richard Vencudeb package for latest seems brokenthe terminal freezes at this command in Ubuntu 20.04
wget https://secure.nic.cz/files/knot-resolver/knot-resolver-release.deb
--2021-10-15 15:46:40-- https://secure.nic.cz/files/knot-resolver/knot-resolver-release.deb
Resolving secure....the terminal freezes at this command in Ubuntu 20.04
wget https://secure.nic.cz/files/knot-resolver/knot-resolver-release.deb
--2021-10-15 15:46:40-- https://secure.nic.cz/files/knot-resolver/knot-resolver-release.deb
Resolving secure.nic.cz (secure.nic.cz)... 217.31.202.45, 2001:1488:ffff::45
Connecting to secure.nic.cz (secure.nic.cz)|217.31.202.45|:443... connected.
Manually inspecting the URL shows a 3.3K file there, seems corrupted since wget freezeshttps://gitlab.nic.cz/knot/knot-resolver/-/issues/697Unnecessarily performed tasks of kresd instances2022-01-16T17:41:24+01:00Aleš MrázekUnnecessarily performed tasks of kresd instancesBy default some tasks are unnecessarily performed on all running kresd instances. This means tasks that only need to be performed once.
- **cache prefilling:** It only needs to be performed once. Prefilling can also take a relatively lo...By default some tasks are unnecessarily performed on all running kresd instances. This means tasks that only need to be performed once.
- **cache prefilling:** It only needs to be performed once. Prefilling can also take a relatively long time([#417](https://gitlab.nic.cz/knot/knot-resolver/-/issues/417)). Maybe it should be done by some separate process.
- **secret for TLS session resumption:** By default, each instance has/generates its own secret. Therefore, the clients session tickets for a particular kresd instance are not compatible with other instances. The secret should be the same for all instances and should change automatically at intervals. This ensures compatibility between kresd instances and increases security.https://gitlab.nic.cz/knot/knot-resolver/-/issues/696datamodel: progress in configuration modeling2022-06-21T11:56:39+02:00Aleš Mrázekdatamodel: progress in configuration modelingThis issue is used to track the progress of modeling configuration designed in the [table](https://docs.google.com/spreadsheets/d/1MelBh9b20_OVoUvjy7qMinIJt7sJZ50frdYDStA9dtw/edit#gid=421811660).
Modeling also includes creating a jinja2 ...This issue is used to track the progress of modeling configuration designed in the [table](https://docs.google.com/spreadsheets/d/1MelBh9b20_OVoUvjy7qMinIJt7sJZ50frdYDStA9dtw/edit#gid=421811660).
Modeling also includes creating a jinja2 template to generate Lua configuration.
Sections:
- [x] server
- [x] options
- [x] network
- [x] static-hints
- [x] slices
- [x] view
- [x] policy/daf
- [x] stub-zones
- [x] forward-zones
- [x] rpz
- [x] dnssec
- [x] cache
- [x] dns64
- [x] logging
- [x] monitoring
- [x] luaAleš MrázekAleš Mrázek