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

6.4.2: cache.prefetch.expiring runaway - internal requests 8000x baseline with a stack-overflow flood, decoupled from client traffic

by Daniel C

Hello,I run a small public DNSSEC-validating recursive resolver on Knot Resolver 6.4.2 and hit an eleven-minute outage that I think is a bug in expiring prefetch. I have aggregate metrics across the whole event but no query-level data, for reasons I explain at the end. I would appreciate a steer on whether this is known, and on the two questions at the bottom. WHAT HAPPENED ------------- On 2026-08-13 between 04:01 and 04:12 UTC: - resolver_request_internal_total rose from a steady 1.34/s to a peak of 10,901/s and stayed elevated for about eleven minutes - the workers logged 285,480 "[system] error: stack overflow" messages, peaking at 94,675 in a single minute - the resolver stopped answering; my end-to-end probes failed on all six transport/family combinations at 04:08, 04:10 and 04:14 - it ended on its own at 04:12 and has not recurred since Client query rate never changed. Roughly 6.5 million internal requests were generated in ten minutes against a real client demand of about 8.6 queries per second. No worker crashed or restarted. MEASUREMENTS ------------ At the peak, against the same counters ten hours later: peak normal resolver_request_internal_total 5,204/s 1.34/s (max sample) 10,901/s resolver_request_udp+tcp_total 8.6/s 8.9/s dnsdist_queries (real client demand) 7.5/s 7.7/s resolver_answer_total 4,800/s 10.3/s cache hit ratio 0.06% ~30% CPU busy 30% 3% load1 2.06 0.25 p99 resolver_response_latency 1.5s 0.4s Per worker, over the burst: kresd0 0 overflow messages kresd1 92,474 kresd2 90,143 kresd3 102,863 One worker in four was completely untouched, which I cannot explain. RESOURCE EFFECT --------------- Memory available fell from 2,862 MB to 622 MB and the kernel swapped 1,798 MB. The three affected workers were exactly the three that ended up in swap (596, 537 and 524 MB) and each took roughly 240,000 major page faults, against 30 for the entire process lifetime before the event. The resolver was serving its LMDB cache from disk for the ten hours until I restarted the container. ENVIRONMENT ----------- Version 6.4.2.dev1+f73d6f (kresd --version) Image cznic/knot-resolver, tag v6.4.2 sha256:b589bfe67a61e2d3c1d6ea3836904e4ed2ec70c77c5db9127473 ed092d31d638 Deployed Docker, host networking, non-root, read-only root filesystem Workers 4 Host 4 vCPU, 3852 MB RAM, Ubuntu 26.04 LTS, kernel 7.0.0-29 Cache LMDB, size-max 1536M, persistent Role recursive resolver behind dnsdist 2.1.1 over loopback Relevant configuration: workers: 4 logging: level: info groups: [system, module, devel, io] cache: size-max: 1536M prefetch: expiring: true # prediction deliberately left disabled options: minimize: true serve-stale is NOT enabled, so this is not issue #957. WHAT I RULED OUT ---------------- - Not client-driven. dnsdist_queries is flat across the whole window. No query spike, no new source, no rate-limit rule hit. - Not a crash. No worker restarted; the only spawn lines in the container log are from process start. - Not serve_stale (#957). Not enabled. - Not cache exhaustion. LMDB is 1536 MB and was not full. - Not a one-off message. Isolated "stack overflow" lines occur at a background rate of roughly 0.1/hour, on 6.4.1 and 6.4.2 alike, without any internal-request spike. Only this event showed the runaway. Possibly two related phenomena. I also enabled debug logging for the system, module, devel and io groups before this happened. They show no precursor at all: normal traffic, then stack overflow messages at microsecond intervals. HYPOTHESIS ---------- This is a guess about mechanism rather than a diagnosis. Prefetch of expiring records is, as I understand it, answer-triggered: a record is refreshed when the resolver answers with it at under 1% TTL or under 5 seconds remaining. If a prefetch's own resolution itself answers with a near-expired record, that would trigger a further prefetch, and the loop could sustain itself with no client involvement. What I can state from the data is only that internal request generation became self-sustaining and decoupled from demand. QUESTIONS --------- 1. Is "[system] error: stack overflow" a caught Lua or LuaJIT stack limit? Is the affected request abandoned, or retried? A retry would explain the self-sustaining behaviour. 2. Is there any rate limit or de-duplication on expiring prefetch, or a guard preventing a prefetch from triggering further prefetches? 3. Does one worker of four being entirely unaffected suggest per-worker state as the trigger? WHAT I CAN PROVIDE ------------------ The service has a published no-query-logging policy, so query names and client addresses were never captured and do not exist. I realise that is the first thing you would normally ask for, and I am sorry not to have it. I do have: - full system/io/module/devel debug logs for the window, about 40 MB, containing only upstream authoritative server addresses - Prometheus series for any exported counter across the event - the complete configuration I am happy to run with cache.prefetch.expiring set to false to confirm the association, or to carry a patch or an extra debug group if that would help narrow it down. The resolver is low-traffic and I can experiment on it freely. Thanks for your time, and for the resolver.

1 den, 12 hodin

2
3
0 0

Knot Resolver 6.4.2

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.4.2 has been released! Bugfixes: - cache: avoid excessive logging introduced in the last release (!1869) - /options/serve-stale: avoid SIGSEGV from a LuaJIT bug (#957) Improvements: - DoH: add unencrypted mode for reverese proxies (alpha, !1877) - deal with LMDB 1.0.0 switching format (!1880) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.4.2/NEWS Sources: https://knot-resolver.nic.cz/release/knot-resolver-6.4.2.tar.xz GPG signature: https://knot-resolver.nic.cz/release/knot-resolver-6.4.2.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.4.2/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

1 týden, 6 dní

1
0
0 0

Knot Resolver 5.7.8

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.7.8 has been released! Bugfixes: - cache: avoid excessive logging introduced in the last release (!1871) - /options/serve-stale: avoid SIGSEGV from a LuaJIT bug (#957) Improvements: - cache: deal with LMDB 1.0.0 switching format (!1872) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.7.8/NEWS Sources: https://knot-resolver.nic.cz/release/knot-resolver-5.7.8.tar.xz GPG signature: https://knot-resolver.nic.cz/release/knot-resolver-5.7.8.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v5.7.8/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

1 týden, 6 dní

1
0
0 0

stash failed, ret = 1

by Stefan Schweizer

Hi, I just upgraded knot-resolver from 5.7.5 to 6.4.1 and now I'm seeing the following error message regularly: kresd[48937]: [cache ] [16128.01] stash failed, ret = 1 kresd[48937]: [cache ] [37316.01] stash failed, ret = 1 Can someone explain what that means? -- Stefan Schweizer

3 týdny, 4 dny

2
1
0 0

Knot Resolver 6.4.1

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.4.1 has been released! Security: - DNS-over-QUIC (DoQ) had severe issues, allowing even RCE Many people reported (some of) these issues to us. - DNSSEC correctness issues, acting mainly through the aggressive cache: * dealing with Labels field in RRSIGs being smaller than the signer's * dealing with NSEC's next-name pointing outside of the zone Special thanks to Qifan Zhang from Palo Alto Networks. Improvements: - docker: upgrade to Debian 13 (!1856) - update IANA's certificate for root trust anchor bootstrapping (!1845) Bugfixes: - /local-data/addresses*: make multiple addresses work (#808, #954) - views: fix protocol-based matching for DoQ Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.4.1/NEWS Sources: https://knot-resolver.nic.cz/release/knot-resolver-6.4.1.tar.xz GPG signature: https://knot-resolver.nic.cz/release/knot-resolver-6.4.1.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.4.1/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

3 týdny, 6 dní

1
0
0 0

Knot Resolver 5.7.7

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 5.7.7 has been released! Security: - DNSSEC correctness issues, acting mainly through the aggressive cache: * dealing with Labels field in RRSIGs being smaller than the signer's * dealing with NSEC's next-name pointing outside of the zone Special thanks to Qifan Zhang from Palo Alto Networks. Improvements: - support cmocka 2.0.0 - avoid AD=1 in reply if ANSWER+AUTHORITY are empty (#914) - packaging: rpm: require python3-setuptools (!1831) - packaging: rpm: provide user/group (!1838) This should also resolve the issue with user and group configuration during installation (GH#130). - make DoH cache-control header respect our cache's TTL limits (!1832) - support libdnssec merged into libknot, as planned for knot >= 3.6 (!1833) - update IANA's certificate for root trust anchor bootstrapping (!1862) Bugfixes: - respect disablement of QNAME case randomization even after TCP issues - cache: fix wrong TTL in some cases, typically 32768 - reduce excessive caching of some uncommon failed answers (!1832) - dns64: fix CNAME problems again (#797, !1862) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.7.7/NEWS Sources: https://knot-resolver.nic.cz/release/knot-resolver-5.7.7.tar.xz GPG signature: https://knot-resolver.nic.cz/release/knot-resolver-5.7.7.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v5.7.7/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

3 týdny, 6 dní

1
0
0 0

Knot Resolver 6.4.0

by Aleš Mrázek

Dear Knot Resolver users, Knot Resolver 6.4.0 has been released! Improvements: - packaging: rpm: require python3-setuptools (!1830, #952) - packaging: rpm: provide user/group (!1837) - controller: improved error handling when sending commands to workers (!1834) Bugfixes: - dns64: fix CNAME problems again (#797, !1840) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v6.4.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.4.0.tar.xz <https://secure.nic.cz/files/knot-resolver/knot-resolver-6.4.0.tar.xz> GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-6.4.0.tar.xz.asc Documentation: https://www.knot-resolver.cz/documentation/v6.4.0/ -- Ales Mrazek PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE

2 měsíce

1
0
0 0

Is it possible to disable "aggressive caching" (RFC 8198) ?

by Jiri Masek

Hi, is it somehow possible to disable RFC 8198 - aggressive caching in knot-resolver 6? I cannot find any information about that in docs. Unnamed chatbot is sure that it can be done with "cache.aggressive = false" in LUA script. But since it is undocumented, I would like to confirm that. Regards Jiri Masek

2 měsíce, 1 týden

2
7
0 0

dnssec issue with .hsd1.tn.comcast.net

by matthias+cznic＠zu-con.org

Hello, I'm evaluating knot resolver and noticed that domains like c-50-149-161-131.hsd1.tn.comcast.net can't be resolved by knot resolver: $ dig @127.0.0.1 c-50-149-161-131.hsd1.tn.comcast.net a ; <<>> DiG 9.18.47-1~deb12u1-Debian <<>> @127.0.0.1 c-50-149-161-131.hsd1.tn.comcast.net a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20156 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; EDE: 10 (RRSIGs Missing): (JZAJ) ;; QUESTION SECTION: ;c-50-149-161-131.hsd1.tn.comcast.net. IN A ;; Query time: 484 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Mon May 04 17:07:27 CEST 2026 ;; MSG SIZE rcvd: 75 other recursors are happy with it: $ dig @1.1.1.1 c-50-149-161-131.hsd1.tn.comcast.net a ; <<>> DiG 9.18.47-1~deb12u1-Debian <<>> @1.1.1.1 c-50-149-161-131.hsd1.tn.comcast.net a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11935 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;c-50-149-161-131.hsd1.tn.comcast.net. IN A ;; ANSWER SECTION: c-50-149-161-131.hsd1.tn.comcast.net. 1302 IN A 50.149.161.131 ;; Query time: 8 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP) ;; WHEN: Mon May 04 17:14:30 CEST 2026 ;; MSG SIZE rcvd: 81 delv seems to be happy, too: delv @1.1.1.1 +vtrace c-50-149-161-131.hsd1.tn.comcast.net a [...] ;; validating hsd1.tn.comcast.net/DS: in validator_callback_nsec ;; validating hsd1.tn.comcast.net/DS: looking for relevant NSEC ;; validating hsd1.tn.comcast.net/DS: nsec proves name exists (owner) data=0 ;; validating hsd1.tn.comcast.net/DS: resuming validate_nx ;; validating hsd1.tn.comcast.net/DS: nonexistence proof(s) found ;; validating c-50-149-161-131.hsd1.tn.comcast.net/A: in fetch_callback_ds ;; validating c-50-149-161-131.hsd1.tn.comcast.net/A: marking as answer (fetch_callback_ds) ; unsigned answer c-50-149-161-131.hsd1.tn.comcast.net. 7200 IN A 50.149.161.131 here's the knot resolver debug output: Mai 04 17:22:14 [rules ][64917.00] => view selected action: policy.tags_assign_bitmap(0ULL) Mai 04 17:22:14 [iterat][64917.00] 'c-50-149-161-131.hsd1.tn.comcast.net.' type 'A' new uid was assigned .01, parent uid .00 Mai 04 17:22:14 [resolv][64917.01] => using root hints Mai 04 17:22:14 [iterat][64917.01] 'c-50-149-161-131.hsd1.tn.comcast.net.' type 'A' new uid was assigned .02, parent uid .00 Mai 04 17:22:14 [resolv][64917.02] >< TA: '.' Mai 04 17:22:14 [plan ][64917.02] plan '.' type 'DNSKEY' uid [64917.03] Mai 04 17:22:14 [iterat][64917.03] '.' type 'DNSKEY' new uid was assigned .04, parent uid .02 Mai 04 17:22:14 [select][64917.04] => id: '12737' choosing from addresses: 13 v4 + 13 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is KO Mai 04 17:22:14 [select][64917.04] => id: '12737' choosing: 'm.root-servers.net.'@'202.12.27.33#00053' with timeout 400 ms zone cut: '.' Mai 04 17:22:14 [resolv][64917.04] => id: '12737' querying: 'm.root-servers.net.'@'202.12.27.33#00053' zone cut: '.' qname: '.' qtype: 'DNSKEY' proto: 'udp' Mai 04 17:22:14 [select][64917.04] => id: '12737' updating: 'm.root-servers.net.'@'202.12.27.33#00053' zone cut: '.' with rtt 16 to srtt: 16 and variance: 8 Mai 04 17:22:14 [iterat][64917.04] <= rcode: NOERROR Mai 04 17:22:14 [valdtr][64917.04] <= parent: updating DNSKEY Mai 04 17:22:14 [valdtr][64917.04] <= answer valid, OK Mai 04 17:22:14 [cache ][64917.04] => stashed . DNSKEY, rank 060, 1090 B total, incl. 1 RRSIGs Mai 04 17:22:14 [iterat][64917.02] 'c-50-149-161-131.hsd1.tn.comcast.net.' type 'A' new uid was assigned .05, parent uid .00 Mai 04 17:22:14 [select][64917.05] => id: '58885' choosing from addresses: 13 v4 + 13 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is KO Mai 04 17:22:14 [select][64917.05] => id: '58885' choosing: 'c.root-servers.net.'@'192.33.4.12#00053' with timeout 400 ms zone cut: '.' Mai 04 17:22:14 [resolv][64917.05] => id: '58885' querying: 'c.root-servers.net.'@'192.33.4.12#00053' zone cut: '.' qname: 'net.' qtype: 'NS' proto: 'udp' Mai 04 17:22:14 [iterat][65570.00] '_ta-4f66-9728.' type 'NULL' new uid was assigned .01, parent uid .00 Mai 04 17:22:14 [resolv][65570.01] => using root hints Mai 04 17:22:14 [iterat][65570.01] '_ta-4f66-9728.' type 'NULL' new uid was assigned .02, parent uid .00 Mai 04 17:22:14 [resolv][65570.02] >< TA: '.' Mai 04 17:22:14 [plan ][65570.02] plan '.' type 'DNSKEY' uid [65570.03] Mai 04 17:22:14 [iterat][65570.03] '.' type 'DNSKEY' new uid was assigned .04, parent uid .02 Mai 04 17:22:14 [cache ][65570.04] => satisfied by exact RRset: rank 060, new TTL 86400 Mai 04 17:22:14 [iterat][65570.04] <= rcode: NOERROR Mai 04 17:22:14 [valdtr][65570.04] <= parent: updating DNSKEY Mai 04 17:22:14 [valdtr][65570.04] <= answer valid, OK Mai 04 17:22:14 [iterat][65570.02] '_ta-4f66-9728.' type 'NULL' new uid was assigned .05, parent uid .00 Mai 04 17:22:14 [select][65570.05] => id: '08979' choosing from addresses: 13 v4 + 13 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is KO Mai 04 17:22:14 [select][65570.05] => id: '08979' choosing: 'j.root-servers.net.'@'192.58.128.30#00053' with timeout 400 ms zone cut: '.' Mai 04 17:22:14 [resolv][65570.05] => id: '08979' querying: 'j.root-servers.net.'@'192.58.128.30#00053' zone cut: '.' qname: '_ta-4f66-9728.' qtype: 'NULL' proto: 'udp' Mai 04 17:22:14 [select][64917.05] => id: '58885' updating: 'c.root-servers.net.'@'192.33.4.12#00053' zone cut: '.' with rtt 7 to srtt: 7 and variance: 3 Mai 04 17:22:14 [iterat][64917.05] <= authority: many glue NSs, skipping the rest Mai 04 17:22:14 [iterat][64917.05] <= loaded 26 glue addresses Mai 04 17:22:14 [iterat][64917.05] <= referral response, follow Mai 04 17:22:14 [valdtr][64917.05] <= DS: OK Mai 04 17:22:14 [valdtr][64917.05] <= answer valid, OK Mai 04 17:22:14 [cache ][64917.05] => stashed net. DS, rank 060, 330 B total, incl. 1 RRSIGs Mai 04 17:22:14 [cache ][64917.05] => stashed net. NS, rank 002, 300 B total, incl. 0 RRSIGs Mai 04 17:22:14 [cache ][64917.05] => stashed also 26 nonauth RRsets Mai 04 17:22:14 [iterat][64917.05] 'c-50-149-161-131.hsd1.tn.comcast.net.' type 'A' new uid was assigned .06, parent uid .00 Mai 04 17:22:14 [plan ][64917.06] plan 'net.' type 'DNSKEY' uid [64917.07] Mai 04 17:22:14 [iterat][64917.07] 'net.' type 'DNSKEY' new uid was assigned .08, parent uid .06 Mai 04 17:22:14 [cache ][64917.08] => no NSEC* cached for zone: net. Mai 04 17:22:14 [cache ][64917.08] => skipping zone: net., NSEC, hash 0;new TTL -123456789, ret -2 Mai 04 17:22:14 [cache ][64917.08] => skipping zone: net., NSEC, hash 0;new TTL -123456789, ret -2 Mai 04 17:22:14 [select][64917.08] => id: '33392' choosing from addresses: 13 v4 + 13 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is KO Mai 04 17:22:14 [select][64917.08] => id: '33392' choosing: 'k.gtld-servers.net.'@'192.52.178.30#00053' with timeout 400 ms zone cut: 'net.' Mai 04 17:22:14 [resolv][64917.08] => id: '33392' querying: 'k.gtld-servers.net.'@'192.52.178.30#00053' zone cut: 'net.' qname: 'net.' qtype: 'DNSKEY' proto: 'udp' Mai 04 17:22:14 [select][65570.05] => id: '08979' updating: 'j.root-servers.net.'@'192.58.128.30#00053' zone cut: '.' with rtt 7 to srtt: 7 and variance: 3 Mai 04 17:22:14 [iterat][65570.05] <= rcode: NXDOMAIN Mai 04 17:22:14 [valdtr][65570.05] <= answer valid, OK Mai 04 17:22:14 [cache ][65570.05] => stashed . NSEC, rank 060, 310 B total, incl. 1 RRSIGs Mai 04 17:22:14 [cache ][65570.05] => stashed . SOA, rank 060, 358 B total, incl. 1 RRSIGs Mai 04 17:22:14 [cache ][65570.05] => nsec_p stashed for . (new, hash: 0) Mai 04 17:22:14 [resolv][65570.05] AD: request classified as SECURE Mai 04 17:22:14 [resolv][65570.05] finished in state: 4, queries: 2, mempool: 98352 B Mai 04 17:22:14 [select][64917.08] => id: '33392' updating: 'k.gtld-servers.net.'@'192.52.178.30#00053' zone cut: 'net.' with rtt 25 to srtt: 25 and variance: 12 Mai 04 17:22:14 [iterat][64917.08] <= rcode: NOERROR Mai 04 17:22:14 [valdtr][64917.08] <= parent: updating DNSKEY Mai 04 17:22:14 [valdtr][64917.08] <= answer valid, OK Mai 04 17:22:14 [cache ][64917.08] => stashed net. DNSKEY, rank 060, 244 B total, incl. 1 RRSIGs Mai 04 17:22:14 [iterat][64917.06] 'c-50-149-161-131.hsd1.tn.comcast.net.' type 'A' new uid was assigned .09, parent uid .00 Mai 04 17:22:14 [select][64917.09] => id: '14990' choosing from addresses: 13 v4 + 13 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is KO Mai 04 17:22:14 [select][64917.09] => id: '14990' choosing: 'f.gtld-servers.net.'@'192.35.51.30#00053' with timeout 400 ms zone cut: 'net.' Mai 04 17:22:14 [resolv][64917.09] => id: '14990' querying: 'f.gtld-servers.net.'@'192.35.51.30#00053' zone cut: 'net.' qname: 'comcast.net.' qtype: 'NS' proto: 'udp' Mai 04 17:22:14 [select][64917.09] => id: '14990' updating: 'f.gtld-servers.net.'@'192.35.51.30#00053' zone cut: 'net.' with rtt 8 to srtt: 8 and variance: 4 Mai 04 17:22:14 [iterat][64917.09] <= loaded 10 glue addresses Mai 04 17:22:14 [iterat][64917.09] <= referral response, follow Mai 04 17:22:14 [valdtr][64917.09] <= DS: OK Mai 04 17:22:14 [valdtr][64917.09] <= answer valid, OK Mai 04 17:22:14 [cache ][64917.09] => stashed comcast.net. DS, rank 060, 168 B total, incl. 1 RRSIGs Mai 04 17:22:14 [cache ][64917.09] => stashed comcast.net. NS, rank 002, 124 B total, incl. 0 RRSIGs Mai 04 17:22:14 [cache ][64917.09] => stashed also 10 nonauth RRsets Mai 04 17:22:14 [iterat][64917.09] 'c-50-149-161-131.hsd1.tn.comcast.net.' type 'A' new uid was assigned .10, parent uid .00 Mai 04 17:22:14 [plan ][64917.10] plan 'comcast.net.' type 'DNSKEY' uid [64917.11] Mai 04 17:22:14 [iterat][64917.11] 'comcast.net.' type 'DNSKEY' new uid was assigned .12, parent uid .10 Mai 04 17:22:14 [cache ][64917.12] => no NSEC* cached for zone: comcast.net. Mai 04 17:22:14 [cache ][64917.12] => skipping zone: comcast.net., NSEC, hash 0;new TTL -123456789, ret -2 Mai 04 17:22:14 [cache ][64917.12] => skipping zone: comcast.net., NSEC, hash 0;new TTL -123456789, ret -2 Mai 04 17:22:14 [select][64917.12] => id: '06051' choosing from addresses: 5 v4 + 5 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is KO Mai 04 17:22:14 [select][64917.12] => id: '06051' choosing: 'dns101.comcast.net.'@'69.252.250.103#00053' with timeout 400 ms zone cut: 'comcast.net.' Mai 04 17:22:14 [resolv][64917.12] => id: '06051' querying: 'dns101.comcast.net.'@'69.252.250.103#00053' zone cut: 'comcast.net.' qname: 'comcast.net.' qtype: 'DNSKEY' proto: 'udp' Mai 04 17:22:14 [select][64917.12] => id: '06051' updating: 'dns101.comcast.net.'@'69.252.250.103#00053' zone cut: 'comcast.net.' with rtt 115 to srtt: 115 and variance: 57 Mai 04 17:22:14 [iterat][64917.12] <= rcode: NOERROR Mai 04 17:22:14 [valdtr][64917.12] <= parent: updating DNSKEY Mai 04 17:22:14 [valdtr][64917.12] <= answer valid, OK Mai 04 17:22:14 [cache ][64917.12] => stashed comcast.net. DNSKEY, rank 060, 870 B total, incl. 2 RRSIGs Mai 04 17:22:14 [iterat][64917.10] 'c-50-149-161-131.hsd1.tn.comcast.net.' type 'A' new uid was assigned .13, parent uid .00 Mai 04 17:22:14 [select][64917.13] => id: '54966' choosing from addresses: 5 v4 + 5 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is KO Mai 04 17:22:14 [select][64917.13] => id: '54966' choosing: 'dns105.comcast.net.'@'68.87.72.244#00053' with timeout 400 ms zone cut: 'comcast.net.' Mai 04 17:22:14 [resolv][64917.13] => id: '54966' querying: 'dns105.comcast.net.'@'68.87.72.244#00053' zone cut: 'comcast.net.' qname: 'tn.comcast.net.' qtype: 'NS' proto: 'udp' Mai 04 17:22:14 [select][64917.13] => id: '54966' updating: 'dns105.comcast.net.'@'68.87.72.244#00053' zone cut: 'comcast.net.' with rtt 142 to srtt: 142 and variance: 71 Mai 04 17:22:14 [iterat][64917.13] <= rcode: NOERROR Mai 04 17:22:14 [iterat][64917.13] <= retrying with non-minimized name Mai 04 17:22:14 [iterat][64917.13] 'c-50-149-161-131.hsd1.tn.comcast.net.' type 'A' new uid was assigned .14, parent uid .00 Mai 04 17:22:14 [select][64917.14] => id: '27279' choosing from addresses: 5 v4 + 5 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is KO Mai 04 17:22:14 [select][64917.14] => id: '27279' choosing: 'dns103.comcast.net.'@'68.87.76.228#00053' with timeout 400 ms zone cut: 'comcast.net.' Mai 04 17:22:14 [resolv][64917.14] => id: '27279' querying: 'dns103.comcast.net.'@'68.87.76.228#00053' zone cut: 'comcast.net.' qname: 'c-50-149-161-131.hsd1.tn.comcast.net.' qtype: 'A' proto: 'udp' Mai 04 17:22:15 [select][64917.14] => id: '27279' updating: 'dns103.comcast.net.'@'68.87.76.228#00053' zone cut: 'comcast.net.' with rtt 180 to srtt: 180 and variance: 90 Mai 04 17:22:15 [iterat][64917.14] <= rcode: NOERROR Mai 04 17:22:15 [valdtr][64917.14] >< cut changed, needs revalidation Mai 04 17:22:15 [resolv][64917.14] => resuming yielded answer Mai 04 17:22:15 [valdtr][64917.14] >< no valid RRSIGs found: c-50-149-161-131.hsd1.tn.comcast.net. A (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) Mai 04 17:22:15 [plan ][64917.14] plan 'tn.comcast.net.' type 'DS' uid [64917.15] Mai 04 17:22:15 [iterat][64917.15] 'tn.comcast.net.' type 'DS' new uid was assigned .16, parent uid .14 Mai 04 17:22:15 [cache ][64917.16] => no NSEC* cached for zone: comcast.net. Mai 04 17:22:15 [cache ][64917.16] => skipping zone: comcast.net., NSEC, hash 0;new TTL -123456789, ret -2 Mai 04 17:22:15 [cache ][64917.16] => skipping zone: comcast.net., NSEC, hash 0;new TTL -123456789, ret -2 Mai 04 17:22:15 [select][64917.16] => id: '58255' choosing from addresses: 5 v4 + 5 v6; names to resolve: 0 v4 + 0 v6; force_resolve: 0; NO6: IPv6 is KO Mai 04 17:22:15 [select][64917.16] => id: '58255' choosing: 'dns104.comcast.net.'@'68.87.68.244#00053' with timeout 400 ms zone cut: 'comcast.net.' Mai 04 17:22:15 [resolv][64917.16] => id: '58255' querying: 'dns104.comcast.net.'@'68.87.68.244#00053' zone cut: 'comcast.net.' qname: 'tn.comcast.net.' qtype: 'DS' proto: 'udp' Mai 04 17:22:15 [select][64917.16] => id: '58255' updating: 'dns104.comcast.net.'@'68.87.68.244#00053' zone cut: 'comcast.net.' with rtt 149 to srtt: 149 and variance: 74 Mai 04 17:22:15 [iterat][64917.16] <= rcode: NOERROR Mai 04 17:22:15 [valdtr][64917.16] <= parent: updating DS Mai 04 17:22:15 [valdtr][64917.16] <= answer valid, OK Mai 04 17:22:15 [cache ][64917.16] => stashed tmwtwabv02w-cisco-cbmr.comcast.net. NSEC, rank 060, 212 B total, incl. 1 RRSIGs Mai 04 17:22:15 [cache ][64917.16] => stashed comcast.net. SOA, rank 060, 248 B total, incl. 1 RRSIGs Mai 04 17:22:15 [cache ][64917.16] => nsec_p stashed for comcast.net. (new, hash: 0) Mai 04 17:22:15 [resolv][64917.14] => resuming yielded answer Mai 04 17:22:15 [valdtr][64917.14] >< no valid RRSIGs found: c-50-149-161-131.hsd1.tn.comcast.net. A (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) Mai 04 17:22:15 [plan ][64917.14] plan 'tn.comcast.net.' type 'DS' uid [64917.17] Mai 04 17:22:15 [iterat][64917.17] 'tn.comcast.net.' type 'DS' new uid was assigned .18, parent uid .14 Mai 04 17:22:15 [cache ][64917.18] => trying zone: comcast.net., NSEC, hash 0 Mai 04 17:22:15 [cache ][64917.18] => NSEC sname: covered by: tmwtwabv02w-cisco-cbmr.comcast.net. -> andrsn01.tn.comcast.net., new TTL 900 Mai 04 17:22:15 [cache ][64917.18] => NSEC sname: empty non-terminal by the same RR Mai 04 17:22:15 [iterat][64917.18] <= rcode: NOERROR Mai 04 17:22:15 [valdtr][64917.18] <= parent: updating DS Mai 04 17:22:15 [valdtr][64917.18] <= answer valid, OK Mai 04 17:22:15 [resolv][64917.14] => resuming yielded answer Mai 04 17:22:15 [valdtr][64917.14] >< no valid RRSIGs found: c-50-149-161-131.hsd1.tn.comcast.net. A (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) Mai 04 17:22:15 [valdtr][64917.14] <= continuous revalidation, fails Mai 04 17:22:15 [cache ][64917.14] => stashed c-50-149-161-131.hsd1.tn.comcast.net. A, rank 027, 20 B total, incl. 0 RRSIGs Mai 04 17:22:15 [cache ][64917.14] => not overwriting A c-50-149-161-131.hsd1.tn.comcast.net. Mai 04 17:22:15 [resolv][64917.00] request failed, answering with empty SERVFAIL Mai 04 17:22:15 [resolv][64917.14] finished in state: 8, queries: 5, mempool: 98400 B I'm wondering what's wrong here and if it's possible to mitigate that. Best regards, Matthias

2 měsíce, 2 týdny

3
2
0 0

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

3 měsíce, 2 týdny

3
3
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

knot-resolver-users