- knot-resolver-users - lists.nic.cz

Re: is there a way to force DNS64 synthesis for specific domains that have native AAAA records?

by Vladimír Čunát

On 12/01/2026 00.11, * wrote: > However, I cannot use it in my production environment as this returns > NODATA globally (all views) for security.ubuntu.com. > I have several views not using dns64 for which the AAAA record should > be the existing original answer. While on Lua level it's not ergonomic, tags are supported in these APIs, so you can do a tiny change, e.g.: lua: policy-script: | assert(C.kr_rule_local_data_ins( kres.rrset(kres.str2dname('security.ubuntu.com.'), kres.type.AAAA, nil, C.KR_RULE_TTL_DEFAULT), nil, policy.get_tagset({'myTag'}), C.KR_RULE_OPTS_DEFAULT ) == 0) and then you just need to add myTag to the views where you want to apply this rule (in YAML). You can read more about tags and views in the docs, around page https://www.knot-resolver.cz/documentation/latest/config-policy-new.html

6 dní, 9 hodin

3
2
0 0

Knot Resolver 6.0.16

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.0.16 (early-access) has been released! Improvements: - reduce validation strictness for domain names (#934, !1727) - manager: force a configuration reload via management HTTP API 'api/reload/force' (#939, !1748) - kresctl: reload: added '--force' flag - /fallback: add this feature/module (!1733) - systemd: do not force-fail knot-resolver.service on OOM (!1724) In basically all cases the OOM killer will kill a kresd process and supervisord will just restart it, and everything will keep working. Bugfixes: - /options/query-case-randomization: respect this even on TCP issues (!1732) - prometheus metrics: make the latency histogram cumulative (!1731, GH#117) - fix file permission checks when running as root (!1741) - /network/address-renumbering: fix conversion to Lua configuration (!1739) - manager: avoid uncommon bugs when starting/quitting policy-loader (!1742) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.16/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.16.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.16.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.0.16/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

1 týden, 1 den

3
4
0 0

Knot Resolver 6.0.17

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.0.17 (early-access) has been released! Improvements: - kresctl migrate: new command for migrating the configuration to a newer version (!1672) - manager: basic support for non-Linux systems (macOS, FreeBSD) (!1758) - cache: collect garbage based on usage statistics (!1726) This results in using the cache space better, and in practice it reduces latency especially in case of answers that are *not* fully cached. Incompatible changes: See upgrading guide for incompatible configuration changes: https://www.knot-resolver.cz/documentation/v6.0.17/upgrading.html - Removed options from declarative configuration model (YAML). (!1672, !1754) These are mostly experimental and debugging/testing options that are not useful for general users (remain in Lua): - /dnssec/refresh-time - /dnssec/hold-down-time - /dnssec/time-skew-detection - /dnssec/keep-removed - /local-data/root-fallback-addresses* - /logging/debugging - /max-workers - /network/tls/auto-discovery - /webmgmt - Renamed/moved options in the declarative configuration model (YAML). (!1672) - /cache/garbage-collector -> /cache/garbage-collector/enable - /cache/prefetch/prediction -> /cache/prefetch/prediction/enable - /defer/enabled -> /defer/enable - /dns64: true|false -> /dns64/enable: true|false - /dns64/rev-ttl -> /dns64/reverse-ttl - /dnssec: true|false -> /dnssec/enable: true|false - /dnssec/trust-anchor-sentinel -> /dnssec/sentinel - /dnssec/trust-anchor-signal-query -> /dnssec/signal-query - /logging/dnstap -> /logging/dnstap/enable - /logging/dnssec-bogus -> /dnssec/log-bogus - /monitoring/enabled -> /monitoring/metrics - /monitoring/graphite -> /monitoring/graphite/enable - /network/proxy_protocol -> /network/proxy_protocol/enable - /network/tls/files-watchdog -> /network/tls/watchdog - /rate-limiting -> /rate-limiting/enable - Changed default values in declarative configuration model (YAML). (!1672) - /logging/dnstap/log-queries: true -> false - /logging/dnstap/log-responses: true -> false - /logging/dnstap/log-tcp-rtt: true -> false Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.17/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.17.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.17.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.0.17/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

1 týden, 4 dny

5
8
0 0

Knot Resolver 6.1.0 (stable)

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.1.0, the first officially stable version 6, has been released! As of this release, version 6 is preferred over version 5. Improvements: - logging: improved logging groups (!1768) - support libdnssec merged into libknot, as planned for knot >= 3.6 (!1769) - support cmocka 2.0.0 (!1772) - avoid AD=1 in reply if ANSWER+AUTHORITY are empty (#914, !1780) - defer: enabled by default in declarative configuration (!1785) - /defer/enable: false -> true - datamodel: lua: added Lua scripts for policy-loader (!1771) Bugfixes: - reload did not apply changes to /fallback (!1763) - fix config.cache.clear test on apple silicon (!1766) - cache: fix wrong TTL in some cases, typically 32768 (!1774) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.1.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.1.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.1.0.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.1.0/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

1 týden, 4 dny

1
0
0 0

kresd 5.7.6, secondary NS-es may not be tried if single auth NS fails

by Paweł Małachowski

There is a domain delegated to 4 NS-es. If I block network connectivity with auth NS 1, kresd sometimes returns and caches SERVFAIL without trying secondary NS-es 2-4. Impact: single faulty auth NS affects multi-NS domain resolvability. How to reproduce: knot-resolver 5.7.6-cznic.1~bookworm amd64 -- Network interface configuration net.listen('127.0.0.1', 53, { kind = 'dns' }) net.listen('::1', 53, { kind = 'dns', freebind = true }) net.listen('127.0.0.1', 8452, { kind = 'webmgmt' }) modules = { 'hints > iterate', -- Allow loading /etc/hosts or custom root hints 'stats', -- Track internal statistics 'http', 'cache', } cache.size = 100 * MB let's use domain: trafficmanager.net name server tm1.dns-tm.com. trafficmanager.net name server tm1.edgedns-tm.info. trafficmanager.net name server tm2.dns-tm.com. trafficmanager.net name server tm2.edgedns-tm.info. Intentionally block communication with tm2.dns-tm.com (tm2.dns-tm.com has address 150.171.16.240): # ip route add blackhole 150.171.16.240 or table inet filter { chain input { type filter hook input priority filter; } chain forward { type filter hook forward priority filter; } chain output { type filter hook output priority filter; ip daddr 150.171.16.240 drop } } Flush kresd cache: # echo 'cache.clear()' | socat - UNIX-CONNECT:/run/knot-resolver/control/1 Query admin.exchange.microsoft.com. Repeat cache.flush and query few times if needed). If kresd tries faulty NS as first, it returns and caches SERVFAIL. All following queries will also return SERVFAIL. Please note, when this happens, other auth NS-es (tm1.dns-tm.com., tm1.edgedns-tm.info., tm2.edgedns-tm.info.) are reachable but not tried. # while sleep 1; do host admin.exchange.microsoft.com 127.0.0.1 | grep admin; done Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) [...] admin.exchange.microsoft.com is an alias for admin.exchange.trafficmanager.net. admin.exchange.trafficmanager.net is an alias for eacafdprod-fzakegfrabbub0ab.z01.azurefd.net. admin.exchange.microsoft.com is an alias for admin.exchange.trafficmanager.net. admin.exchange.trafficmanager.net is an alias for eacafdprod-fzakegfrabbub0ab.z01.azurefd.net. admin.exchange.microsoft.com is an alias for admin.exchange.trafficmanager.net. admin.exchange.trafficmanager.net is an alias for eacafdprod-fzakegfrabbub0ab.z01.azurefd.net. admin.exchange.microsoft.com is an alias for admin.exchange.trafficmanager.net. [...] Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) Host admin.exchange.microsoft.com not found: 2(SERVFAIL) ^C # curl http://localhost:8452/trace/admin.exchange.trafficmanager.net [iterat][66079.00] 'admin.exchange.trafficmanager.net.' type 'A' new uid was assigned .01, parent uid .00 [cache ][66079.01] => no NSEC* cached for zone: trafficmanager.net. [cache ][66079.01] => skipping zone: trafficmanager.net., NSEC, hash 0;new TTL -123456789, ret -2 [cache ][66079.01] => skipping zone: trafficmanager.net., NSEC, hash 0;new TTL -123456789, ret -2 [zoncut][66079.01] found cut: trafficmanager.net. (rank 010 return codes: DS 1, DNSKEY 1) [resolv][66079.01] => NS is provably without DS, going insecure [select][66079.01] => id: '03790' choosing from addresses: 2 v4 + 0 v6; names to resolve: 2 v4 + 4 v6; force_resolve: 0; NO6: IPv6 is KO [select][66079.01] => id: '03790' choosing: 'tm2.dns-tm.com.'@'150.171.16.240#00053' with timeout 400 ms zone cut: 'trafficmanager.net.' [resolv][66079.01] => id: '03790' querying: 'tm2.dns-tm.com.'@'150.171.16.240#00053' zone cut: 'trafficmanager.net.' qname: 'exchange.trafficmanager.net.' qtype: 'NS' proto: 'udp' [resolv][66079.00] request failed, answering with empty SERVFAIL [resolv][66079.01] finished in state: 8, queries: 0, mempool: 81952 B /PM

1 týden, 5 dní

2
2
0 0

Introduction and questions about RPZ support

by Francis Turner

HI there, I work for ThreatSTOP, a company that distributes DNS policies using RPZ to our customers. One prospective customer uses knot-resolver and so they have asked us to look at what we can support with respect to importing our data into knot-resolver. I have read the documentation and I have done some testing with 5.7.2 that is the version in Ubuntu 24.04 I have also read some of the documentation for version 6.x I have a few questions The first is fairly basic. What is the status of 6.x? >From what I can see it seems to be undergoing development and not to be considered as stable. Is this correct? And therefore we should not recommend it to our users? Assuming that is the case, it's unfortunate because RPZ support seems to be considerably better in 6.x. however I'm still a bit confused as to the RPZ support and would appreciate being pointed to a spec. The 6.x documentation was not clear to me Also I have questions about policy limitations, which I don't see in the documentation for 5.x How large can an RPZ be? How many policies can you have? For example I'd like an ALLOW, a DENY and perhaps one to three A record rewrite policies. The total across all RPZs would be in the 500k-1M records. Also assuming it is supported, what are the performance impacts of large (say 500k+) RPZ policies? I intend to test some of this, but if there are known limits that can be shown that will help both the testing and the recommendations to our customers Finally is there a place to publicize a script that does a zone transfer of a policy from an external server (e.g. ours) and outputs 3 or 4 zones in the right format for knot-resolver to import? Regards Francis Francis Turner Threat STOP Global SE JP Cell: +81-8080404701 | US Cell: +1-760-402-7676 Office: +1-760-542-1550 | Line: francisturner francis(a)threatstop.com<mailto:francis@threatstop.com> | www.threatstop.com<http://www.threatstop.com/> Weaponize Your Threat Intelligence "If You Don't Build It, They Definitely Will Not Come" - P. Vixie

1 týden, 6 dní

2
8
0 0

Re: Knot Resolver 6.0.17

by Leo Vandewoestijne

Hi, Between countless parcel notifications in my inbox, I suddenly found this message... ...just moments after I posted my modification (which is entirely focussed on setup.py): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292197 I'm now merging that with what's suggested here. So it's getting further than before, but is not yet completing successfully. Leo. On Fri, 02 Jan 2026, Michael Grimm wrote: > Vladim??r ??un??t via knot-resolver-users <knot-resolver-users(a)lists.nic.cz> wrote: > > On 31/12/2025 13.37, Michael Grimm via knot-resolver-users wrote: > > >> FYI: This is FreeBSD and kresctl tool isn't available here. > > > OK, that's a complication. In 6.0.17 we added FreeBSD support to code added in 6.x, and now we're in contact with the maintainer of the [port], but the last version I saw didn't seem to package all parts needed for YAML (e.g. executables called knot-resolver and kresctl). > > In March 2024 I tried to create a FreeBSD port for knot-resolver-6.0.8. I got it compiled after applying the following changes (see tar file attached). I do remember that I could use kresctl in a poudriere testport jail, only, but I can't reproduce that as of today, sorry. > > (This is intended as a FYI, just in case it helps.) > > 1) files/patch-meson_options.txt > > This adds a manager section to meson_options.txt. > With that I could tell meson to use '-Dmanager=enabled' within the port's Makefile > > This section is missing in 6.0.17 as well. If added meson log file tells me that a manager is enabled. > > I do not have the knowledge if that is necessary at all, though > > > 2) files/patch-controller_supervisord_plugin_notifymodule.c > > This patch addresses: > > #) include sys/ucred.h > #) use LOCAL_PEERCRED instead of SO_PASSCRED > #) use 'struct xucred' instead of 'struct ucred' > #) use SCM_CREDS instead of SCM_CREDENTIALS > #) use cred.cr_pid instead of cred.pid as returned value > > Again, I do not have the knowledge if that is of relevance at all. > > > I applied both patches to Leo's port and modified the Makefile accordingly (see tar), and it compiles successfully; but is still lacking kresctl and knot-resolver. > > > I hope that this might be of interest for you. > > Regards, > Michael >

2 týdny

2
1
0 0

Re: Knot Resolver 6.0.17

by Vladimír Čunát

On 02/01/2026 16.45, Michael Grimm wrote: > 1) files/patch-meson_options.txt This patch adds the option but doesn't act on the option in any way. (i.e. it doesn't affect the result except for some lines in the log) > 2) files/patch-controller_supervisord_plugin_notifymodule.c This patch might be interesting, though we just avoided the notify module on non-Linux since 6.0.17, so it's not really needed anymore. Maybe we'd need that notify-free code-path anyway for some other BSD or macOS; I don't remember details about this. --Vladimir

2 týdny

1
0
0 0

kresd 5.7.6 NODATA cache TTL

by pawmal-knot＠freebsd.lublin.pl

Hello, it seems vanilla kresd (5.7.6-cznic.1~bookworm), when receives NODATA response (NOERROR, all RRs: 0) from remote authoritative server, stores record in cache with TTL=32768. Where is this value coming from/how can we alter it? (Seems hardcoded, not derived from SOA expiry or TTL.) Impact: may get negative ~9h cache for domains delegated to a server randomly returning NODATA Workaround: sacrifice cache hit ratio with cache.max_ttl(low_value) Reproduction: // wait 5-30 minutes while true; do echo 'cache.clear("mr-z01.tm-azurefd.net")' | socat - UNIX-CONNECT:/run/knot-resolver/control/1 >/dev/null; sleep 1; host -vvvvt a mr-z01.tm-azurefd.net 127.0.0.1; curl -s http://localhost:8451/trace/mr-z01.tm-azurefd.net; echo DONE; done 2>&1 | tee -a issue.log Watch log: // captured with cache.min_ttl(77), irrelevant here [cache ][65604.03] => satisfied by exact CNAME: rank 030, new TTL 16 [cache ][65604.05] => satisfied by exact RRset: rank 030, new TTL 16 [cache ][65605.01] => satisfied by exact packet: rank 030, new TTL 32768 <------ auth server return NODATA response (reason unknown) [cache ][65606.01] => satisfied by exact packet: rank 030, new TTL 32768 [cache ][65607.01] => satisfied by exact RRset: rank 030, new TTL 77 [cache ][65608.01] => satisfied by exact RRset: rank 030, new TTL 77 [cache ][65609.01] => satisfied by exact CNAME: rank 030, new TTL 77 [cache ][65609.03] => satisfied by exact CNAME: rank 030, new TTL 11 [cache ][65609.05] => satisfied by exact RRset: rank 030, new TTL 11 [cache ][65610.01] => satisfied by exact CNAME: rank 030, new TTL 77 [cache ][65610.03] => satisfied by exact CNAME: rank 030, new TTL 10 [cache ][65610.05] => satisfied by exact RRset: rank 030, new TTL 10 [cache ][65611.01] => satisfied by exact CNAME: rank 030, new TTL 77 [cache ][65611.03] => satisfied by exact CNAME: rank 030, new TTL 9 [cache ][65611.05] => satisfied by exact RRset: rank 030, new TTL 9 [cache ][65612.01] => satisfied by exact packet: rank 030, new TTL 32768 [cache ][65613.01] => satisfied by exact RRset: rank 030, new TTL 77 [cache ][65614.01] => satisfied by exact RRset: rank 030, new TTL 77 // host Trying "mr-z01.tm-azurefd.net" Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62752 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;mr-z01.tm-azurefd.net. IN A Received 39 bytes from 127.0.0.1#53 in 4 ms // kresd trace [iterat][65612.00] 'mr-z01.tm-azurefd.net.' type 'A' new uid was assigned .01, parent uid .00 [cache ][65612.01] => satisfied by exact packet: rank 030, new TTL 32768 [iterat][65612.01] <= answer received: ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 43459 ;; Flags: qr aa QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: Unused ;; QUESTION SECTION mr-z01.tm-azurefd.net. A ;; ADDITIONAL SECTION [iterat][65612.01] <= rcode: NOERROR [resolv][65612.01] AD: request NOT classified as SECURE [resolv][65612.01] finished in state: 4, queries: 1, mempool: 81952 B // cache miss trace [iterat][65637.03] <= rcode: NOERROR [cache ][65637.03] => stashed tm2.dns-tm.com. A, rank 030, 20 B total, incl. 0 RRSIGs [iterat][65637.01] 'mr-z01.tm-azurefd.net.' type 'A' new uid was assigned .04, parent uid .00 [select][65637.04] => id: '43668' choosing from addresses: 1 v4 + 0 v6; names to resolve: 2 v4 + 3 v6; force_resolve: 0; NO6: IPv6 is KO [select][65637.04] => id: '43668' choosing: 'tm2.dns-tm.com.'@'150.171.16.240#00053' with timeout 22 ms zone cut: 'tm-azurefd.net.' [resolv][65637.04] => id: '43668' querying: 'tm2.dns-tm.com.'@'150.171.16.240#00053' zone cut: 'tm-azurefd.net.' qname: 'mr-z01.tm-azurefd.net.' qtype: 'A' proto: 'udp' [select][65637.04] => id: '43668' updating: 'tm2.dns-tm.com.'@'150.171.16.240#00053' zone cut: 'tm-azurefd.net.' with rtt 4 to srtt: 2 and variance: 1 [iterat][65637.04] <= answer received: ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 43668 ;; Flags: qr aa QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: Unused ;; QUESTION SECTION mr-z01.tm-azurefd.net. A ;; ADDITIONAL SECTION [iterat][65637.04] <= rcode: NOERROR [cache ][65637.04] => stashed packet: rank 030, TTL 32768, A mr-z01.tm-azurefd.net. (62 B) [resolv][65637.04] AD: request NOT classified as SECURE [resolv][65637.04] finished in state: 4, queries: 2, mempool: 81952 B ;; selected from ANSWER sections: ; ranked rrset to_wire false, rank 030 (auth insecure), cached true, qry_uid 3, revalidations 0 tm2.dns-tm.com. 300 A 150.171.16.240

4 týdny

4
9
0 0

udp/tcp transport fallback strategy

by pawmal-knot＠freebsd.lublin.pl

Hi, it seems kresd 5.7.6 falls back from UDP to TCP transport but never retries over UDP. Impact: udp/53-only services (incorrect but happens in the wild[1]) may become ~permanently (long TTL) unreachable when udp/53 is not 100% reliable. When temporal udp/53 communication error occurs, kresd will fall back to tcp/53, fail to connect, store negative information and return SERVFAIL. Since retries only consider tcp/53 transport, there is no easy way to recover for udp/53-only domains. I believe it would be nice to retry with UDP as well as TCP (other implementations do this) to handle such cases more gently. [iterat][55073123.04] <= rcode: NOERROR [valdtr][55073123.04] <= cached insecure response, going insecure [iterat][55073123.02] 'www.somefooservice.com.' type 'A' new uid was assigned .05, parent uid .00 [select][55073123.05] => id: '37763' choosing from addresses: 0 v4 + 0 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is OK [select][55073123.05] => id: '37763' no suitable transport, zone cut: 'www.somefooservice.com.' [iterat][55073123.05] 'www.somefooservice.com.' type 'A' new uid was assigned .06, parent uid .00 [select][55073123.06] => id: '27070' choosing from addresses: 0 v4 + 0 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is OK [select][55073123.06] => id: '27070' no suitable transport, zone cut: 'www.somefooservice.com.' [resolv][55073123.06] AD: request NOT classified as SECURE [resolv][55073123.06] finished in state: 8, queries: 2, mempool: 81952 B Workaround: cache.max_ttl() - haven't tried cache.clear('FQDN record affected') does NOT work cache.clear('entire TLD affected') does NOT work cache.clear('.') DOES work cache.clear() DOES work [1] It took us some time to reach major mobile device producer and convince them to expose tcp/53 ;) /PM

1 měsíc

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

knot-resolver-users