Bug 14034 - Knot Resolver: Infinite stream of NS queries if it asked twice when the result is NXDOMAIN.
Summary: Knot Resolver: Infinite stream of NS queries if it asked twice when the resul...
Status: NEW
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: x86_64 All
: - Unknown - Major Usability
Assignee: Assigned to nobody - feel free to grab it and work on it
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-07-31 00:16 UTC by Piers Wombwell
Modified: 2026-07-31 14:17 UTC (History)
0 users

See Also:


Attachments
knot resolver watchdog (1000 bytes, application/x-sh)
2026-07-31 14:17 UTC, Piers Wombwell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Piers Wombwell 2026-07-31 00:16:05 UTC
If I query a nonexistent domain a few times, Knot Resolver starts continuously issuing upstream NS queries for that domain. The queries continue indefinitely until knot-resolver is restarted.

On my network this overwhelms my BT Smart Hub, which eventually blocks all traffic until Knot Resolver is stopped.

I can reproduce it every time.

In one terminal on the IPFire box:
tcpdump -ni red0 port 53 | grep -i buzz

In another terminal (perhaps on the IPFire), run this three or four times:
dig @192.168.0.1 thebuzztube.com A

(just press cursor-up return a few times)

The tcpdump output will fill with lines like:
01:05:25.600434 IP 192.168.1.167.56635 > 8.8.8.8.53: 44106+ [1au] NS? ThEBuZZTube.CoM. (44)
01:05:25.607460 IP 192.168.1.167.44978 > 8.8.8.8.53: 29612+ [1au] NS? TheBuZZTuBE.CoM. (44)
01:05:25.614293 IP 192.168.1.167.58214 > 8.8.8.8.53: 47996+ [1au] NS? tHEbuZzTubE.Com. (44)
01:05:25.621020 IP 192.168.1.167.40581 > 8.8.8.8.53: 32179+ [1au] NS? THEbuZztube.CoM. (44)
01:05:25.628239 IP 192.168.1.167.41308 > 8.8.8.8.53: 52107+ [1au] NS? thebUZZtUbe.COM. (44)
01:05:25.635851 IP 192.168.1.167.45349 > 8.8.8.8.53: 48533+ [1au] NS? thEBUzzTubE.cOm. (44)
01:05:25.643750 IP 192.168.1.167.52264 > 8.8.8.8.53: 10262+ [1au] NS? THebUZZTuBe.CoM. (44)
01:05:25.650462 IP 192.168.1.167.47777 > 8.8.8.8.53: 14883+ [1au] NS? THeBuzztUBE.cOM. (44)
01:05:25.657012 IP 192.168.1.167.41902 > 8.8.8.8.53: 20753+ [1au] NS? THEBuZzTuBE.coM. (44)
01:05:25.662795 IP 192.168.1.167.55134 > 8.8.8.8.53: 24352+ [1au] NS? ThEbuZzTubE.COM. (44)
01:05:25.670876 IP 192.168.1.167.33558 > 8.8.8.8.53: 37509+ [1au] NS? ThEbuzZtube.cOm. (44)
01:05:25.677453 IP 192.168.1.167.37189 > 8.8.8.8.53: 36957+ [1au] NS? THebUZztUbe.COM. (44)
01:05:25.685446 IP 192.168.1.167.44980 > 8.8.8.8.53: 31812+ [1au] NS? thebUzZTUbe.com. (44)
01:05:25.693957 IP 192.168.1.167.45555 > 8.8.8.8.53: 12162+ [1au] NS? ThEbUZZTUbE.com. (44)
01:05:25.702210 IP 192.168.1.167.50045 > 8.8.8.8.53: 26806+ [1au] NS? thEBuZZtUbe.CoM. (44)
01:05:25.709615 IP 192.168.1.167.35032 > 8.8.8.8.53: 59829+ [1au] NS? thEbuZztUBe.cOM. (44)
01:05:25.717184 IP 192.168.1.167.36112 > 8.8.8.8.53: 41060+ [1au] NS? ThebUZztUbe.cOM. (44)
01:05:25.725096 IP 192.168.1.167.34905 > 8.8.8.8.53: 48200+ [1au] NS? thebUzZtUBE.COM. (44)
01:05:25.731575 IP 192.168.1.167.50863 > 8.8.8.8.53: 63612+ [1au] NS? thebUZzTUbe.cOm. (44)
01:05:25.738304 IP 192.168.1.167.46300 > 8.8.8.8.53: 53225+ [1au] NS? tHEbuZZtuBE.CoM. (44)

'top' shows two kresd processes creeping up in CPU usage.

'/etc/rc.d/init.d/knot-resolver restart' immediately stops the stream, and some minutes later the BT hub recovers.
Comment 1 Piers Wombwell 2026-07-31 14:15:59 UTC
My earlier assumption that this was specific to NXDOMAIN responses was incorrect. I run 20k different lookups overnight, and I've managed to reproduce the problem with the following short list.

I'm running a watchdog that counts outbound DNS packets in 10-second windows and restarts Knot Resolver when it enters the runaway state to avoid the IPFire and BT hubs getting in a state. The IPFire runs at 100% CPU without it being restarted.

Running the overnight failures manually, I can reliably reproduce failures with the following sites. Each domain has its own threshold, but the threshold is consistent for me.

thebuzztube.com – just two lookups reliably trigger the problem (generating 1263 outbound DNS packets in 10s):
for i in $(seq 1 2); do dig @192.168.0.1 thebuzztube.com A;  done

hdonline.vn – twenty lookups (alternating A/AAAA) trigger the problem, and I see 1152 outbound DNS packets in 10s:
for i in $(seq 1 10); do dig @192.168.0.1 hdonline.vn A; dig @192.168.0.1 hdonline.vn AAAA;  done

ksjdfusdjdshfjhsdk.com – ten A lookups trigger the problem (1129 outbound DNS packets in 10s):
for i in $(seq 1 10); do dig @192.168.0.1 ksjdfusdjdshfjhsdk.com A;  done

rojadirectatv.tv – twenty lookups (alternating A/AAAA) trigger the problem (2714 outbound DNS packets in 10s):
for i in $(seq 1 10); do dig @192.168.0.1 rojadirectatv.tv A; dig @192.168.0.1 rojadirectatv.tv AAAA; done
Comment 2 Piers Wombwell 2026-07-31 14:17:35 UTC
Created attachment 1740 [details]
knot resolver watchdog

(written by ChatGPT)