Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2021-12-22T11:04:19+01:00https://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/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/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/581improved handling of malformed messages over TCP/TLS2021-12-03T16:31:19+01:00Tomas Krizekimproved handling of malformed messages over TCP/TLSCurrently, if kresd receives malformed DNS message, it will close the TCP stream. It was probably meant as a heuristic that orientation in TCP stream was lost. However, this isn't necessarily true, since the client might have sent query ...Currently, if kresd receives malformed DNS message, it will close the TCP stream. It was probably meant as a heuristic that orientation in TCP stream was lost. However, this isn't necessarily true, since the client might have sent query that isn't possible to parse, but prefixed with correct message length.
This can be troublesome in some cases, because closing the stream also means no responses will be sent to the pipelined queries. While sending malformed queries probably isn't the common, it can certainly happen when replaying or mirroring traffic.
Perhaps the condition to close the stream could be relaxed: The stream would be closed only if the dns message length would be less than the header size.
Related #471https://gitlab.nic.cz/knot/knot-resolver/-/issues/184test dnstap module2021-11-25T18:34:58+01:00Petr Špačektest dnstap modulehttps://gitlab.nic.cz/knot/knot-resolver/-/issues/183test daf module ("DNS application firewall")2021-11-25T16:42:44+01:00Petr Špačektest daf module ("DNS application firewall")https://gitlab.nic.cz/knot/knot-resolver/-/issues/466move docker image to registry.labs.nic.cz2021-11-25T16:26:11+01:00Tomas Krizekmove docker image to registry.labs.nic.czDocker image for knot-resolver should be moved to our own upstream registry. The effect for end users would be to switch the image name from `cznic/knot-resolver` to something like `registry.labs.nic.cz/knot/knot-resolver`
The issues wi...Docker image for knot-resolver should be moved to our own upstream registry. The effect for end users would be to switch the image name from `cznic/knot-resolver` to something like `registry.labs.nic.cz/knot/knot-resolver`
The issues with current setup in docker hub:
- after their recent "update", automated build require **administrative** access to source code repository
> This service account should have access to any repositories to be built, and must have administrative access to the source code repositories so it can manage deploy keys. (source: https://docs.docker.com/docker-hub/builds/#service-users-for-team-autobuilds )
I have no idea what is "managing deploy keys" and why an administrative access to make a build from publicly pushed branch / tag would even be required in the first place.
- providing docker hub with unneeded privileges goes against good security practices and ends up as one would expect (https://news.ycombinator.com/item?id=19763413)
---
Since we already have our own registry and CI/CD infrastructure, I think we should take advantage of it and use it for docker image builds for both latest master branch and tagged versions.
This would fix the currently broken automation of image builds and also simplify the entire process (using docker hub requires github, so we need to mirror there first, then build an image from there...)
@dsalzman Do you think this would make sense for Knot DNS image as well?https://gitlab.nic.cz/knot/knot-resolver/-/issues/657policy: actions don't populate OPT when they should2021-11-23T19:52:44+01:00Vladimír Čunátvladimir.cunat@nic.czpolicy: actions don't populate OPT when they should[RFC 6891](https://tools.ietf.org/html/rfc6891#section-6.1.1):
> If an OPT record is present in a received request, compliant responders MUST include an OPT record in their respective responses.
Original report: https://forum.turris.cz...[RFC 6891](https://tools.ietf.org/html/rfc6891#section-6.1.1):
> If an OPT record is present in a received request, compliant responders MUST include an OPT record in their respective responses.
Original report: https://forum.turris.cz/t/kresd-response-missing-opt-pseudo-rr/14437
It causes practical issues with systemd-resolved (see the report).https://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/667After TCP connect succeeds, resolver gets stuck if the authoritative doesn't ...2021-11-08T13:40:26+01:00Štěpán BalážikAfter TCP connect succeeds, resolver gets stuck if the authoritative doesn't send a replyCurrently resolution of `tipsport.cz A` triggers this sometimes, so let's use it as example:
There are 8 authoritative server for `tipsport.cz`:
```
$ dig @a.ns.nic.cz tipsport.cz NS
[…]
;; QUESTION SECTION:
;tipsport.cz. IN NS
;; A...Currently resolution of `tipsport.cz A` triggers this sometimes, so let's use it as example:
There are 8 authoritative server for `tipsport.cz`:
```
$ dig @a.ns.nic.cz tipsport.cz NS
[…]
;; QUESTION SECTION:
;tipsport.cz. IN NS
;; AUTHORITY SECTION:
tipsport.cz. 3600 IN NS ns1.tipsport.cz.
tipsport.cz. 3600 IN NS ns2.tipsport.cz.
tipsport.cz. 3600 IN NS ns3.tipsport.cz.
tipsport.cz. 3600 IN NS ns4.tipsport.cz.
;; ADDITIONAL SECTION:
ns1.tipsport.cz. 3600 IN A 195.39.239.11
ns1.tipsport.cz. 3600 IN AAAA 2001:678:320:0:f5::1
ns2.tipsport.cz. 3600 IN A 195.39.239.12
ns2.tipsport.cz. 3600 IN AAAA 2001:678:320:0:f5::2
ns3.tipsport.cz. 3600 IN A 195.39.239.13
ns3.tipsport.cz. 3600 IN AAAA 2001:678:320:0:f5::3
ns4.tipsport.cz. 3600 IN A 195.39.239.14
ns4.tipsport.cz. 3600 IN AAAA 2001:678:320:0:f5::4
```
None of the IPv6 will answer the query `tipsport.cz A` but all will accept a TCP connection to them.
The reply to `tipsport.cz A` is too big and the working servers will reply with TC=1.
So, if the resolver chooses one of the working servers first, gets a TC bit and then chooses to connect over TCP to one of the not working ones, the request will starve and eventually be cancelled by a timer and resolver replies with a SERVFAIL.
```
[16708.11][iter] 'tipsport.cz.' type 'A' new uid was assigned .14, parent uid .00
[16708.14][slct] => id: '27900' choosing: 'ns4.tipsport.cz.'@'195.39.239.14#00053' with timeout 1600 ms zone cut: 'tipsport.cz.'
[16708.14][resl] => id: '27900' querying: 'ns4.tipsport.cz.'@'195.39.239.14#00053' zone cut: 'tipsport.cz.' qname: 'tIPSpOrt.cZ.' qtype: 'A' proto: 'udp'
[16708.14][slct] => id: '27900' updating: 'ns4.tipsport.cz.'@'195.39.239.14#00053' zone cut: 'tipsport.cz.' with rtt 14 to srtt: 14 and variance: 7
[16708.14][iter] <= answer received:
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 27900
;; Flags: qr aa tc QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 4096 B; ext-rcode: Unused
;; QUESTION SECTION
tipsport.cz. A
;; ADDITIONAL SECTION
[16708.14][iter] <= truncated response, failover to TCP
[16708.14][slct] => id: '27900' noting selection error: 'ns4.tipsport.cz.'@'195.39.239.14#00053' zone cut: 'tipsport.cz.' error: 12 TRUNCATED
[16708.14][iter] 'tipsport.cz.' type 'A' new uid was assigned .15, parent uid .00
[16708.15][slct] => id: '23152' choosing: 'ns4.tipsport.cz.'@'2001:678:320:0:f5::4#00053' with timeout 1600 ms zone cut: 'tipsport.cz.'
[16708.15][resl] => id: '23152' querying: 'ns4.tipsport.cz.'@'2001:678:320:0:f5::4#00053' zone cut: 'tipsport.cz.' qname: 'TipsPoRt.cz.' qtype: 'A' proto: 'tcp'
[16708.15][wrkr] => connecting to: '2001:678:320:0:f5::4#00053'
[wrkr]=> connected to '2001:678:320:0:f5::4#00053'
… long wait here, the whole request will timeout …
[16708.13][resl] AD: request NOT classified as SECURE
[16708.15][resl] finished in state: 8, queries: 3, mempool: 49200 B
[16708.00][dbg ] answer packet:
;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 16708
;; Flags: qr rd ra QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: Unused
;; QUESTION SECTION
tipsport.cz. A
;; ADDITIONAL SECTION
[io] => closing connection to '2001:678:320:0:f5::4#00053'
```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/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/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/645FORMERR does not trigger EDNS fallback2021-10-11T13:06:06+02:00Petr ŠpačekFORMERR does not trigger EDNS fallbackVersion: 5.2.0
Domain `spam.molax.co.kr.` qtype `A` does not work with EDNS. Auth servers correctly return FORMERR but kresd 5.2.0 does not fallback to non-EDNS and SERVFAILs request from client.
[spam.molax.co.kr.A.log](/uploads/edde7...Version: 5.2.0
Domain `spam.molax.co.kr.` qtype `A` does not work with EDNS. Auth servers correctly return FORMERR but kresd 5.2.0 does not fallback to non-EDNS and SERVFAILs request from client.
[spam.molax.co.kr.A.log](/uploads/edde70e988fcf6ab810e693802c8896d/spam.molax.co.kr.A.log)
We need to:
- fix kresd
- investigate why test https://gitlab.nic.cz/knot/deckard/-/blob/master/sets/resolver/iter_formerr.rpl did not detect this and fix it!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/478Handling of PTR records in DNS64 module2021-08-25T13:32:54+02:00Ondřej CaletkaHandling of PTR records in DNS64 moduleI know this omision is [documented](https://knot-resolver.readthedocs.io/en/stable/modules.html?highlight=PTR+synthesis#dns64), but still [RFC 6147](https://tools.ietf.org/html/rfc6147#section-5.3.1) requires proper handling of PTR recor...I know this omision is [documented](https://knot-resolver.readthedocs.io/en/stable/modules.html?highlight=PTR+synthesis#dns64), but still [RFC 6147](https://tools.ietf.org/html/rfc6147#section-5.3.1) requires proper handling of PTR records for the DNS64 translation prefix.
Since DNS64-enabled instances of Knot resolver are being deployed both by [Cloudflare](https://developers.cloudflare.com/1.1.1.1/support-nat64/) and [RIPE NCC](https://ripe78.ripe.net/on-site/tech-info/ipv6-only-network/), it would help a lot, especially during tracerouting, to have the PTR handling implemented properly.Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/527fine-grained logging2021-07-29T14:01:56+02:00Petr Špačekfine-grained loggingCurrent logging configuration is just one bit: verbosity on/off. This makes it hard to monitor and debug large instances.
Let's collect ideas for improvement in this ticket:
- [x] per-request logging - ability to run single request with...Current logging configuration is just one bit: verbosity on/off. This makes it hard to monitor and debug large instances.
Let's collect ideas for improvement in this ticket:
- [x] per-request logging - ability to run single request with verbose logging is very handy for debugging. We have a prototype in `/trace` endpoint in HTTP module but this module does not log everything for a given request, and also it should be much easier to use than full HTTP.
- [x] per-type logging - it might be handy to enable/disable certain types of logging, e.g. control socket log might be too noisy if there is enough API traffic etc.
- [x] fine grained log levels exposed to the logging system - external log collectors need to know if given message is debug/info/error etc.
- [ ] structured logging? log some rudimentary metadata in structured form - e.g. query name + type + rcode? This might be very handy for network operations centers etc.https://gitlab.nic.cz/knot/knot-resolver/-/issues/495improve error reporting and handling2021-06-01T11:02:38+02:00Tomas Krizekimprove error reporting and handlingCurrently, some assertions seem to be used as a way to report unlikely events, and when these are used in production, they can cause needless crashes (even though they're then handled by systemd's `Restart=on-abnormal` facility)
I propo...Currently, some assertions seem to be used as a way to report unlikely events, and when these are used in production, they can cause needless crashes (even though they're then handled by systemd's `Restart=on-abnormal` facility)
I propose the following changes:
- The code should not rely on assertions, if it does, it's a bug that should be fixed.
- Errors, even unlikely ones (currently handled by assertions) should be logged properly.
- ~~There could be an option (off by default) to enable reporting these remotely.~~Tomas KrizekTomas Krizekhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/616doh2: process input headers2021-05-25T14:44:37+02:00Tomas Krizekdoh2: process input headersAs of 5.2.0, the DoH(2) implementation ignores all headers (including some pseudoheaders).
At least some (pseudo)headers should be processed, e.g.:
- `content-type`
- `:path` (currently, any endpoint answers to DoH queries)
There could...As of 5.2.0, the DoH(2) implementation ignores all headers (including some pseudoheaders).
At least some (pseudo)headers should be processed, e.g.:
- `content-type`
- `:path` (currently, any endpoint answers to DoH queries)
There could also be a mechanism for modules to request certain headers that would be passed along with a request.Tomas KrizekTomas Krizek