Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2020-12-11T09:46:52+01:00https://gitlab.nic.cz/knot/knot-resolver/-/issues/654insufficient caching of some uncommon wildcards2020-12-11T09:46:52+01:00Vladimír Čunátvladimir.cunat@nic.czinsufficient caching of some uncommon wildcardsIn an NSEC3-signed zone, if a wildcard is nested deeper than directly under the apex, positive expansions from it may not be cached properly (but they succeed). Testing example: `foo.t.cunat.cz AAAA`.
The issue is that aggressive cache...In an NSEC3-signed zone, if a wildcard is nested deeper than directly under the apex, positive expansions from it may not be cached properly (but they succeed). Testing example: `foo.t.cunat.cz AAAA`.
The issue is that aggressive cache thinks it needs to additionally provide an NSEC3 record matching the closest (provable) encloser, but that's not true in this case (because the wildcard record proves encloser's existence). This NSEC3 record must exist but resolver probably hasn't obtained it, so synthesis from cache (usually) fails.
Fortunately, typical wildcard usage I see is directly under the apex `*.example.com`. We may also be "saved" by queries for non-existing types on the same name (e.g. AAAA), as those need this NSEC3 record and thus the only downside would be its "unneeded" addition into the corresponding positive wildcard expansions.Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/651dnstap module spawns a thread2020-12-07T11:00:36+01:00Vladimír Čunátvladimir.cunat@nic.czdnstap module spawns a threadThat's not consistent with kresd architecture, though I can't think of a particular reason why it might cause a problem. Note that this thread will get spawned for each kresd process, so it might be a bit wasteful.
We might prefer to r...That's not consistent with kresd architecture, though I can't think of a particular reason why it might cause a problem. Note that this thread will get spawned for each kresd process, so it might be a bit wasteful.
We might prefer to rewrite the module by utilizing the shared libuv loop (to know when socket is ready to receive more data), but maybe the [fstrm tools](https://farsightsec.github.io/fstrm/overview.html) don't provide good support for that. If we drop the thread, this library might not be worth depending on anymore (as the framing is trivial).https://gitlab.nic.cz/knot/knot-resolver/-/issues/603cache: get rid of mdb_env_sync()2020-09-07T17:52:07+02:00Petr Špačekcache: get rid of mdb_env_sync()Explicit cache sync does not seem necessary and might be counterproductive, see other comments in the thread:
The following discussion from !1042 should be addressed:
- [ ] @pspacek started a [discussion](https://gitlab.nic.cz/knot/kno...Explicit cache sync does not seem necessary and might be counterproductive, see other comments in the thread:
The following discussion from !1042 should be addressed:
- [ ] @pspacek started a [discussion](https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1042#note_169608): (+1 comment)
> Out of curiosity, why the sync is necessary here?https://gitlab.nic.cz/knot/knot-resolver/-/issues/573net.tls() allow usage of multiple certificates2020-10-08T11:43:59+02:00Tomas Krizeknet.tls() allow usage of multiple certificatesECC certificates provide superior performance to RSA keys of comparable security. Supporting multiple certificate files in `net.tls()` could lead to improved DNS-over-TLS performance without sacrificng compatibility with older clients, i...ECC certificates provide superior performance to RSA keys of comparable security. Supporting multiple certificate files in `net.tls()` could lead to improved DNS-over-TLS performance without sacrificng compatibility with older clients, if both ECC and RSA certificates could be used simulataneously.https://gitlab.nic.cz/knot/knot-resolver/-/issues/446test huge pages2019-02-06T17:37:48+01:00Petr Špačektest huge pagesWe might test if some variant of huge pages can help with performance ... it is of uncertainly value but it is one more idea we can test during benchmarking.
See https://fosdem.org/2019/schedule/event/hugepages_databases/We might test if some variant of huge pages can help with performance ... it is of uncertainly value but it is one more idea we can test during benchmarking.
See https://fosdem.org/2019/schedule/event/hugepages_databases/https://gitlab.nic.cz/knot/knot-resolver/-/issues/316improve cache performance with qname minimization2018-07-11T13:43:37+02:00Petr Špačekimprove cache performance with qname minimizationIt seems that resolver sends more queries than necessary.
Following list in format summarizes queries made by resolver 2.1.1 sent to upstream servers.
Apparently `corp.microsoft.com. NS` (which does not exist and is denied by insecure ...It seems that resolver sends more queries than necessary.
Following list in format summarizes queries made by resolver 2.1.1 sent to upstream servers.
Apparently `corp.microsoft.com. NS` (which does not exist and is denied by insecure SOA RR with TTL 3600 s) is not cached properly. @vcunat told me that this is related to caching qname minimization steps and that fix might not be trivial because of some interdependency on iterator implementation (blah).
Format: (count, qname, qtype as number)
```
1 BiTLOckErRecoVeRY.CORp.MICRoSofT.cOM 1
1 BiTloCKErreCoVERY.RMB.CORP.miCrOSoFt.COM 1
1 CO1-Na-DC-01.NOrthAmErICa.corp.MICRoSoFT.cOm 1
1 CO1w7fS01b.cOrP.MIcRoSOfT.cOM 1
1 Co1vfScluSt02.CORP.MIcRoSOFT.coM 1
1 Cy1-eU-dc-02.eUrope.CORp.MicrOsoFt.CoM 1
1 DB3-REd-dC-01.COrp.mICRosOfT.COm 1
1 DB3-eu-Dc-08.EuROpe.coRp.microsOFT.com 1
1 DB3WefpRoD1.eurOPe.corP.mIcrOSofT.COm 1
1 DB3wEFPROd10.EUROPe.CORp.MICROSOFT.cOM 1
1 Db3-Red-dC-04.CORp.MiCroSofT.COM 1
1 Db3-af-DC-02.aFRIcA.cORP.mICrOsOFt.com 1
1 Db3WEfpROD3.EuropE.COrP.MiCRosOFT.COM 1
1 Db3WeFPROd6.EUroPE.cOrP.MICrosofT.COm 1
1 Db3WeFprOd9.EuroPe.corP.MiCroSofT.COm 1
1 Db3wefPrOD4.eURoPE.CorP.micrOsofT.Com 1
1 Db3wefPrOd8.eUROpe.CoRp.mIcrosOfT.com 1
1 EURopE.CORp.micrOsOft.COm 6
1 EmeAcAT.EUROPE.corP.micROSOfT.COM 1
1 LS2WeB.RedMOnD.CorP.MiCrosOft.coM 1
1 UDE.GuesT.coRp.MIcroSOft.coM 1
1 UDE.LHWKsta.cOrP.MIcRosOfT.COm 1
1 UDE.SoUTHPaciFiC.coRp.mIcroSOFT.COM 1
1 UDE.rMB.CoRP.mICROSOFt.CoM 1
1 UDe.NoRTHaMerIcA.corp.MICROSOFt.COm 1
1 UDe.ReDmoND.coRP.mICrOsOFT.com 1
1 UDe.Sys-WiNGROUP.ntDEv.coRp.micROSoFT.coM 1
1 UdE.MIdDlEEaSt.cORp.miCroSoFT.cOM 1
1 UdE.SeGROup.wiNSE.cORP.MicROsOft.cOm 1
1 UdE.sOuthaMERiCa.CorP.MiCROsOFt.CoM 1
1 Ude.AfRiCA.coRP.miCROsoFT.COm 1
1 WPAD.NTDev.cOrp.mIcRoSofT.COM 1
1 WPaD.NOrthaMErIca.coRP.miCroSoFt.CoM 1
1 WPaD.afRica.coRp.mICROsofT.Com 1
1 WpAd.Sys-wIngROup.NTdEv.cOrP.mICRoSoFT.com 1
1 WpAd.midDlEeAST.cOrp.MICrosOft.COm 1
1 WpaD.MslPa.corp.MICROSofT.COM 1
1 WpaD.euroPe.cOrp.miCRoSofT.COM 1
1 Wpad.reDMond.cORP.micrOsOFT.COM 1
1 _LDAp._TcP.eU-iE-DuBdC._sItES.DC._MSdCs.fAreAst.cOrP.MiCrOsOFT.CoM 33
1 _LDaP._TcP.EU-IE-dUBdc._siTes.Dc._MsDCs.nOrTHaMEriCA.coRp.MicrOsoFT.COm 33
1 _LdAp._tcP.eu-iE-DUbDC._SItes.AFRIcA.corp.micRoSoFT.COM 33
1 _Ldap._TCp.eu-ie-DubDc._SitEs.farEast.CORp.miCroSOft.cOM 33
1 _lDaP._tcp.EU-ie-DUbdC._siTES.dC._MsDcs.a-jINOvo-NB2.EuropE.COrP.mIcRosoft.COM 33
1 _lDap._TCP.PDC._MSDCS.EuroPE.CorP.MicRoSOFT.COM 33
1 _ldAp._Tcp.Eu-Ie-DuBdc._SitEs.COrp.MiCROsoFT.cOm 33
1 a-jinoVO-nB2.EuRoPe.cOrP.MicrOSOfT.com 6
1 aZeu1MP03.EUrOPe.CoRP.MICrOsOfT.cOm 1
1 biTLOCKerrEcOvEry.GuEst.corp.mICroSOFT.com 1
1 cO1-fE-dC-05.fArEASt.cOrp.MicROSoFt.cOM 1
1 cY1Cdmvfs1.cOrp.MicrOsoFT.cOm 1
1 corp.MICROsOft.COm 6
1 dB3WEFprOD7.eURoPe.CoRP.miCROSoFt.cOM 1
1 dB3WefProd2.EuROPE.coRp.MICRosOft.COm 1
1 dR._dns-SD._UDp.COrP.MicrosOft.CoM 12
1 db3-eU-DC-03.eurOPe.cORP.Microsoft.CoM 1
1 db3WEfprOd5.europe.CoRP.MICRosOft.cOM 1
1 suhriN-dEvopS.eURope.cOrP.mICrOsoft.cOM 6
1 tRYlEK-z240.eUrOpE.COrp.MicROSoFt.CoM 6
1 uDE.CorP.MICRosOft.Com 1
1 uDE.MSlpA.CORP.MicROsoFt.cOm 1
1 uDE.wINSE.coRp.MICroSofT.Com 1
1 uDe.faREASt.corP.micRoSOfT.Com 1
1 udE.eUROpE.CORP.MiCROSoFt.Com 1
1 udE.ntDev.CORp.mICrosOFt.COm 1
1 wPAD.GUest.CoRp.mICROSOFt.cOm 1
1 wPAD.Lhwksta.cORP.MicRoSOfT.cOm 1
1 wPaD.sOUtHAmERiCa.CORP.MIcRosoFt.CoM 1
1 wPaD.wiNSe.corP.MICroSOft.COm 1
1 wpAD.cORP.microsOfT.cOM 1
1 wpAd.SouThpACiFIc.CORp.MICrOSOFt.cOm 1
1 wpAd.rMb.CORP.MIcROSOft.COm 1
1 wpaD.fAReAst.cORp.MIcROsOfT.CoM 1
1 wpaD.seGrOuP.wINsE.coRP.mICROsoFt.cOM 1
57 CORP.MIcRosoft.com 2
```https://gitlab.nic.cz/knot/knot-resolver/-/issues/311policy.TLS_FORWARD should hold open a connection2020-02-28T10:01:04+01:00Daniel Kahn Gillmorpolicy.TLS_FORWARD should hold open a connectionI have an example `kresd` instance configured with the following policy:
policy.add(policy.all(policy.TLS_FORWARD({{'9.9.9.9', hostname="dns.quad9.net", ca_file="/etc/ssl/certs/ca-certificates.crt"}})))
If i make one request to thi...I have an example `kresd` instance configured with the following policy:
policy.add(policy.all(policy.TLS_FORWARD({{'9.9.9.9', hostname="dns.quad9.net", ca_file="/etc/ssl/certs/ca-certificates.crt"}})))
If i make one request to this local `kresd` instance, it sets up the TLS session to `quad9`, exchanges traffic with it, and then (about 2 seconds later) it tears down the connection to `quad9`. TLS session creation and teardown is pretty high overhead, and the `quad9` servers tolerate significantly longer periods of idle time.
Barring a good reason for early teardown, a forwarding client should hold open a session for at least 20 seconds -- but this should probably also be an adjustable configuration for a forwarder as different forwarders may have different policies.
Note that the configuration choice for timeout for `kresd` as a client forwarding over TLS should be distinct from the configuration choice for the delay tolerated by `kresd` when operating as a TLS listener.https://gitlab.nic.cz/knot/knot-resolver/-/issues/298improving latency of nameserver chasing2021-01-04T11:26:09+01:00Vladimír Čunátvladimir.cunat@nic.czimproving latency of nameserver chasingWhen chasing addresses of nameservers, kresd by default only trusts glue addresses if in bailiwick of the zone we asked. This isn't optimal even in some common cases, e.g. `com` and `net` TLD zones are served by the same set of servers,...When chasing addresses of nameservers, kresd by default only trusts glue addresses if in bailiwick of the zone we asked. This isn't optimal even in some common cases, e.g. `com` and `net` TLD zones are served by the same set of servers, so when a delegation from either has `NS` records from the other, we *could* safely trust the glue. Doing this check generally won't be trivial, but it might be worth the latency gains on cold cache; some nameservers cause us to chase through multiple zones until we find a trusted glue.
On a related note, we might also accept the glue if the child zone is signed. (seems easier to implement)https://gitlab.nic.cz/knot/knot-resolver/-/issues/36lib: parallel queries2020-07-20T13:49:49+02:00Ghost Userlib: parallel queriesSome queries can be made in parallel (A+AAAA).
The current `rplan` can only work with the current query at the top of the stack.
The change would be to store a pointer to `current` that would be chosen when the
answer comes based on f...Some queries can be made in parallel (A+AAAA).
The current `rplan` can only work with the current query at the top of the stack.
The change would be to store a pointer to `current` that would be chosen when the
answer comes based on following criteria: `msgid + <qname, qtype, qclass> match`,
and the query MUST NOT have a parent. This could be later used for look-ahead queries (DNSKEY),
but then a care must be taken as the answers MAY come out of order, while they MUST be processed in order.