Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2020-12-04T16:34:21+01:00https://gitlab.nic.cz/knot/knot-resolver/-/issues/638[discussion] cache backend redesign2020-12-04T16:34:21+01:00Petr Špaček[discussion] cache backend redesignLet's discuss problems we have with current LMDB-based cache backend. We need to analyze if these are fixable or we need to redesign cache backend.
Problems with LMDB itself
- Database overfill leads to irrecoverable state where while D...Let's discuss problems we have with current LMDB-based cache backend. We need to analyze if these are fixable or we need to redesign cache backend.
Problems with LMDB itself
- Database overfill leads to irrecoverable state where while DB practically becomes read only and the only ways forward are either enlarge database or delete it. Together with inability to detect if committing a transaction will lead to this state prevents us from reliably keeping cache with constant size, leading to race conditions in overflow handling etc. (#605)
- Transactions have [undefined limits](https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/message/VI7K5NWV46J6DACITXVS7X2SM3HZIXVB/) on them, forcing us to [jump through hoops](https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1042/diffs?commit_id=c651fbf24017f26435b86e69e9ce73c7f5976b97).
- LMDB depends on unique PID values - this assumption does not hold when sharing cache across containers (#637).
Other cache-related problems: #602, #604https://gitlab.nic.cz/knot/knot-resolver/-/issues/405Improving TCP/TLS timer logic for long-lived connections2018-10-31T15:51:37+01:00BaptisteImproving TCP/TLS timer logic for long-lived connectionsI am testing long-lived client connections to Knot resolver over TCP or TLS.
Currently, the idle timeout is quite short: `kresd` closes a client TCP connection after just a few seconds when no request is made. While investigating this p...I am testing long-lived client connections to Knot resolver over TCP or TLS.
Currently, the idle timeout is quite short: `kresd` closes a client TCP connection after just a few seconds when no request is made. While investigating this part of the code, I found that the idle timeout strategy is quite complex, and mixes up the timeout values for "downstream" TCP connections and "upstream" TCP connections (while in reality, they have very different requirements).
Below is an attempt at documenting the current behaviour, so that we can discuss how to improve it.
This is related to #311 (short idle timeout for outgoing TLS connections) and #378 ("unificate processing of inbound and outbound TCP connections where it possible")https://gitlab.nic.cz/knot/knot-resolver/-/issues/349How to localize, not forward queries for a domain name?2019-12-18T19:15:02+01:00jodaHow to localize, not forward queries for a domain name?Hi all,
I own a turris router and let's assume I own a domain name example.org.
My router's external interface has a public IP.
I setup a dynamic DNS record for the router home.example.org.
Any unknown sub-domain DNS record like x.y.exa...Hi all,
I own a turris router and let's assume I own a domain name example.org.
My router's external interface has a public IP.
I setup a dynamic DNS record for the router home.example.org.
Any unknown sub-domain DNS record like x.y.example.org resolves to IP of example.org.
Now I want a local DNS overlay provided by knot resolver (dnsmasq supports this feature).
All my devices at home get an non-public network IP address like:
```
host1.lan.example.org
host2.lan.example.org
host3.lan.example.org
```
Every internal network client gets an internal DNS name with the suffix lan.example.org.
knot-resolver automatically sets up the hostnames from DHCP leases provided by odhcpd.
I was unable to localize the queries for my local network. By localizing I mean that knot resolver resolves the quieries locally from it's "DHCP cache", but does not forward them to the upstream DNS servers.
Solution that fail to work:
1. Always forwarding: unknown (local) hostname like "does-not-exist.lan.example.org" returns external IP of example.org (instead of NXDOMAIN)
1. Blocking lan.example.org: If I used POLIC.DENY to block resolving hosts with suffix lan.example.org then "does-not-exist.lan.example.org" get NXDOMAIN, but all other hosts fail to resolve, too :-/
1. I tried using Policy.PASS for lan.example.org (in order to just look-up the DNS name up from "hints cache"), but that did not work properly. Either queries are not properly answered (not resolved against hints cache) or the DNS requests are send to the upstream DNS again (getting an reply with the external IP).
It's been a while since I spent time troubleshooting my setup.
Please tell me what information you need. I read a lot of your documentation, but failed to find a solution.
My custom.conf for kresd (aka. knot-resolver):
```
-- Comment
--local trace_rule = policy.add(policy.suffix(policy.QTRACE, {todname('lan.example.org.')}))
--policy.del(trace_rule.id)
--table.insert(policy.rules, 1, trace_rule)
-- local hints_rule = policy.add(policy.suffix(policy.all(kres.YIELD),{todname('lan.example.org.')}))
local hints_rule = policy.add(policy.suffix(function(state, req)
local qry = req:current()
--print('Local DNS ',qry.sname,' hints "','"')
--print('Local DNS "',ffi.string(qry.sname,sizeof(qry.sname)), '" hints ""')
--print('Local DNS ',qry.sname,' hints "',hints.get(qry.sname),'"')
--ffi.C.knot_dname_is_sub(qry.sname, todname('ip6.arpa.'))
--if hints.get(qry.sname) == '{ result: [] }' then
return policy.DENY
--else
-- return policy.PASS
--end
end
,{todname('lan.example.org.')}))
--local hints_rule = policy.add(policy.suffix(policy.FLAGS('',kres.query.ALWAYS_CUT),{todname('lan.example.org.')}))
policy.del(hints_rule.id)
table.insert(policy.rules, 1, hints_rule)
--policy.add(policy.all(policy.FORWARD({ '<upstream IPv4 DNS>' })))
```
Current Knot DNS Resolver, version 1.5.1 (turris OS v3.9.6).https://gitlab.nic.cz/knot/knot-resolver/-/issues/244track network changes and reconfigure as validating stub / resolver automatic...2021-06-24T13:38:33+02:00Petr Špačektrack network changes and reconfigure as validating stub / resolver automaticallyTaken from https://github.com/CZ-NIC/knot-resolver/issues/7
There should be a module to track changes in the network and environment to detect when the resolver is in an:
- Environment that blocks DNS queries altogether (and revert to s...Taken from https://github.com/CZ-NIC/knot-resolver/issues/7
There should be a module to track changes in the network and environment to detect when the resolver is in an:
- Environment that blocks DNS queries altogether (and revert to stub mode)
- Environment with DNSSEC-unaware resolver (do validation)
- Open environment (full recursive resolver)
This would make it as painless as possible for the end users with frequent network transitions (hotel wifi, workplace, home, ...)
Fallback to https://github.com/fcambus/rrda if the DNS is filtered/unreachable.https://gitlab.nic.cz/knot/knot-resolver/-/issues/226handling out-of-bailiwick CNAME chains from authoritative servers2017-10-10T10:12:12+02:00Vladimír Čunátvladimir.cunat@nic.czhandling out-of-bailiwick CNAME chains from authoritative serversSome servers incorrectly answer like this:
```
$ kdig @2a02:4a8:ac24:100::96:2 www.rozpocetverejne.cz.
;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 41711
;; Flags: qr aa rd; Q...Some servers incorrectly answer like this:
```
$ kdig @2a02:4a8:ac24:100::96:2 www.rozpocetverejne.cz.
;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 41711
;; Flags: qr aa rd; QUERY: 1; ANSWER: 1; AUTHORITY: 1; ADDITIONAL: 0
;; QUESTION SECTION:
;; www.rozpocetverejne.cz. IN A
;; ANSWER SECTION:
www.rozpocetverejne.cz. 600 IN CNAME ghs.google.com.
;; AUTHORITY SECTION:
google.com. 3600 IN SOA alfa.ns.active24.cz. hostmaster.active24.cz. 2017042405 10800 1800 1209600 3600
;; Received 132 B
;; Time 2017-07-28 10:26:52 CEST
;; From 2a02:4a8:ac24:100::96:2@53(UDP) in 5.3 ms
```
That claims two wrong things: that the server is authoritative for google.com and that name ghs.google.com doesn't exist. (For RCODE meaning with CNAMEs see https://tools.ietf.org/html/rfc6604#section-3) We found multiple instances of this, e.g. also from wedos: www.silvidesign.cz.
Kresd currently SERVFAILs on this (validation); it would be better to use the in-bailiwick information (the CNAME) and discard the rest of the information, even in this case.https://gitlab.nic.cz/knot/knot-resolver/-/issues/210RFC 4035 sec 5.2: downgrade to insecure when only unknown algorithms are used...2019-07-09T17:12:39+02:00Vladimír Čunátvladimir.cunat@nic.czRFC 4035 sec 5.2: downgrade to insecure when only unknown algorithms are used (provably)Currently these lead to SERVFAIL, as detected by https://rootcanary.org/test.html
This will probably be about handling the `DNSSEC_INVALID_DS_ALGORITHM` return code from libdnssec.
https://tools.ietf.org/html/rfc4035#section-5.2
...Currently these lead to SERVFAIL, as detected by https://rootcanary.org/test.html
This will probably be about handling the `DNSSEC_INVALID_DS_ALGORITHM` return code from libdnssec.
https://tools.ietf.org/html/rfc4035#section-5.2
> If the validator does not support any of the algorithms listed in an
authenticated DS RRset, then the resolver has no supported
authentication path leading from the parent to the child. The
resolver should treat this case as it would the case of an
authenticated NSEC RRset proving that no DS RRset exists, as
described above.https://gitlab.nic.cz/knot/knot-resolver/-/issues/32lib: child-side NS records are not always fetched2021-01-04T11:28:06+01:00Ghost Userlib: child-side NS records are not always fetched