There has been one fix to dnsmasq related to nftset and it came in 2.92. So you should try to reproduce the problem on OpenWrt snapshot with dnsmasq 2.92 and if it repeats, report it as a bug upstream to the dnsmasq mailing list.
2 Likes
Note that if you are using an nftset with DNSMasq there is a limit of 1024 characters, furthermore there was a bug in DNSMasq handling nft which is corrected in DNSMasq 2.92
Not sure if this applies to your situation but the easiest thing might be to update to DNSMasq 2.92 and see if that solves the problem
1 Like
I do not use nftset at all.
I consider it an outdated and unreliable mechanism.
My configuration uses only ipset in dnsmasq, and nftset is completely disabled.
The problem is reproducible even with ipset fully disabled.
dnsmasq terminates by itself without logs, segfaults, or signals recorded by procd or the kernel.
Because of this, the issue does not appear to be related to nftset.
Your strace showed:
17416 16:01:15.058173 write(23, "Feb 4 16:01:15 dnsmasq[17416]: 137 2001:67c:abcd:1:8af:cc8d:a2e1:33bf/30245 nftset add 4 inet fw4 vpn_tiktok4 138.113.159.37 tiktokcdn.com\n", 140) = 140
Which is nftset. Your answers are inconsistent with the information you are writing. Find your minimum dnsmasq configuration to replicate the problem and post that strace.
3 Likes
Also to add to the confusion, your dhcp config earlier lists 4 upstream DoH proxy instances, but your dnsmasq is using 9 upstream proxies listening on 127.0.0.1. What are the other 4 (Stubby)?
Feb 4 16:00:25 dnsmasq[17416]: 122 2001:67c:...:33bf/30245 query[A] pull-flv-f1-gcp01.tiktokcdn.com from 2001:67c:abcd:...:33bf
Feb 4 16:00:25 dnsmasq[17416]: 122 2001:67c:...:33bf/30245 forwarded pull-flv-f1-gcp01.tiktokcdn.com to 127.0.0.1#5455
Feb 4 16:00:25 dnsmasq[17416]: 137 2001:67c:...:33bf/30245 query[A] pull-flv-f1-gcp01.tiktokcdn.com from 2001:67c:...:33bf
Feb 4 16:00:25 dnsmasq[17416]: 137 2001:67c:...:33bf/30245 forwarded pull-flv-f1-gcp01.tiktokcdn.com to 127.0.0.1#5453
Feb 4 16:00:25 dnsmasq[17416]: 137 2001:67c:...:33bf/30245 forwarded pull-flv-f1-gcp01.tiktokcdn.com to 127.0.0.1#5454
Feb 4 16:00:25 dnsmasq[17416]: 137 2001:67c:...:33bf/30245 forwarded pull-flv-f1-gcp01.tiktokcdn.com to 127.0.0.1#5455
Feb 4 16:00:25 dnsmasq[17416]: 137 2001:67c:...:33bf/30245 forwarded pull-flv-f1-gcp01.tiktokcdn.com to 127.0.0.1#5456
Feb 4 16:00:25 dnsmasq[17416]: 137 2001:67c:...:33bf/30245 forwarded pull-flv-f1-gcp01.tiktokcdn.com to 127.0.0.1#5053
Feb 4 16:00:25 dnsmasq[17416]: 137 2001:67c:...:33bf/30245 forwarded pull-flv-f1-gcp01.tiktokcdn.com to 127.0.0.1#5054
Feb 4 16:00:25 dnsmasq[17416]: 137 2001:67c:...:33bf/30245 forwarded pull-flv-f1-gcp01.tiktokcdn.com to 127.0.0.1#5055
Feb 4 16:00:25 dnsmasq[17416]: 137 2001:67c:...:33bf/30245 forwarded pull-flv-f1-gcp01.tiktokcdn.com to 127.0.0.1#5056
Feb 4 16:01:14 dnsmasq[17416]: 137 2001:67c:...:33bf/30245 validation result is INSECURE
Feb 4 16:01:14 dnsmasq[17416]: 137 2001:67c:...:33bf/30245 reply pull-flv-f1-gcp01.tiktokcdn.com is <CNAME>
Feb 4 16:01:15 dnsmasq[17416]: 137 2001:67c:...:33bf/30245 nftset add 4 inet fw4 vpn_tiktok4 138.113.159.37 tiktokcdn.com
Feb 4 16:01:15 dnsmasq[17416]: 137 2001:67c:...:33bf/30245 reply pull-flv-f1-gcp01.tiktokcdn.com.wsdvs.com is 138.113.159.37
You won't get any helpful responses until you are willing to share openly what you're doing and how your router and dnsmasq are configured.
EDIT: The last recvmsg in your strace refers to doh_ms6 and fw4 which must be another nftset.
Can you explain a few things about these options:
- How did you arrive at the specific parameters and syntax given that these are not normally available via OpenWrt's implementation? Was this ported from another OS, suggestions found online, AI suggestions, or some other origin?
- What was the intent of adding these lines?
- If they don't have any effect, why are they still there?
1 Like
Regarding dnsmasq options which are not exposed to/via UCI directly:
You can use /etc/dnsmasq.conf to store dnsmasq nativ options as documented at https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
Could please everyone here calm down? Yes, ten years ago he/she/it would have used translate.google.com; and back then, 10 years earlier the user would have used a dictionary.
But attacking someone because of languages skills is <insert insult here>.
Yes, even if a chatbot is used here, everyone who would have been willing would have noticed that its not unreviewed AI slop. I'm pretty pissed and shocked by many statements in this thread! If you don't wanna help because of some snobby shithead behavior, then leave the user alone for fukks sake! Deal instead with the really annoying kids who think that we here offer free consulting and fixing their stuff for them. But from the first post on by @viroot I see no reason to distrust the user. 
8 Likes
These parameters were added based on dnsmasq documentation and configurations from other Linux distributions,
but they are not supported in OpenWrt. The dnsmasq build used in OpenWrt does not include implementations of
max_file_limit or bind-dynamic, so they remained in the configuration even though they have no effect on the
operation or stability of dnsmasq.
They do not cause any errors because dnsmasq in OpenWrt simply ignores unknown or disabled options. This is
normal behavior — such lines can remain in the configuration for years without affecting the service in any way.
Yes, I’m aware that native dnsmasq options can be placed in /etc/dnsmasq.conf.
However, these particular options (max_file_limit and bind-dynamic) are not
implemented in the OpenWrt dnsmasq build. They exist in upstream dnsmasq
documentation, but OpenWrt compiles dnsmasq without these features.
That’s why they remain in the config but have no effect — dnsmasq simply
ignores unsupported options without throwing an error. They also cannot be
responsible for crashes or instability.
Thank you for your support. I really appreciate your words.
I don’t speak English, and that’s true — I use AI only as a translation tool.
For me it’s simply a way to communicate here without making the discussion harder
for others. AI translates my thoughts much more accurately than a regular
translator, so it helps me avoid misunderstandings and express myself clearly.
I always review and edit the translated text before posting, so everything I write
reflects my own thoughts, not “AI slop”. I’m here in good faith, trying to solve
a technical problem and learn from the community.
Thanks again for standing up for me. It means a lot.
2 Likes
Yes, that’s correct. I’m not hiding anything — I have a large number of ipset
definitions under config ipset in the DHCP configuration. These entries are
just domain-to-ipset mappings, and they do not affect the stability or crashes
of dnsmasq in any way.
All of these ipset blocks are standard dnsmasq/ipset usage. They simply tell
dnsmasq to resolve certain domains and place the resulting IPs into the
corresponding ipset. This mechanism is well-supported and has no relation to
the issue I’m troubleshooting.
The presence of many ipset sections does not cause dnsmasq to crash. The crash
happens before dnsmasq even interacts with any sets, so these entries are not
involved in the problem.
That’s why you saw these tables in the logs — they come from the ipset
definitions in my DHCP configuration. But these ipset entries are fully allowed
for dnsmasq and do not cause any problems. They are standard domain-to-ipset
rules, and dnsmasq handles them normally.
Their presence in the logs only means that dnsmasq is reading the configuration
as expected. They have no negative effect.
I’m not going to post the entire ipset list because it’s very large and
irrelevant to the issue. dnsmasq does not forbid using these rules, and they
are not related to the crash.
But there are problems/crashes reported with nftsets which are solved in DNSMasq 2.92, hence my advice to update and see if that solves your problem.
Fact is that to solve a problem it can help if we can see the whole picture/config
Anyway good luck with solving your problem
Based on the information you posted, I would say the ipsets are very related to the problem. But you seem to have other information that we do not have because you claim nothing we suggest is related to the crash.
Are you still calling this problem a “crash” or did you decide it was a “freeze”?
Do you have timeouts configured for your ipsets in the firewall config? How large are the sets when dnsmasq has the problem? Are there any sets defined in dhcp config but not existing in the firewall config?
3 Likes
I agree with @dave14305 that you should try upgrading dnsmasq to 2.92. I and others have had problems with older versions of dnsmasq-full using nftset. See:
Assuming you're running OpenWRT stable (24.10.x) you can find builds of dnsmasq 2.92 here for a few platforms:
You can also find other platform builds on the GitHub issue.
2 Likes
You can also compile a newer version of a package on your own for your target release. Not quiet sure if this was already mentioned or not.
You just need to update the package definition and point to the new release, compile that single package, copy it to your router , install, and test....
1 Like
I want to share long‑term stability results for dnsmasq-full 2.92, tested on real hardware under continuous high load.
Hardware / Firmware:
- Model: FriendlyElec NanoPi R3S
- Architecture: ARMv8 Processor rev 0
- Target: rockchip/armv8
- Firmware: OpenWrt 24.10.5 r29087-d9c5716d1d
- LuCI: openwrt‑24.10 branch (25.340.26705~d88390b)
Test conditions:
- ~20000 DNS queries
- DNSSEC enabled
- heavy negative caching
- DHCPv6 + RA
- IPv4 + IPv6 mixed load
- PPPoE reconnect events
- netlink events
- continuous operation for 3 days
- no manual restarts
- watchdog inactive
Results:
- 0 crashes
- 0 hangs
- 0 spontaneous restarts
- IPv6 remains stable
- DNSSEC does not trigger failures
- DHCPv6/RA stable
- memory usage predictable
- no race conditions observed
This strongly suggests that the long‑standing instability seen in dnsmasq 2.90 / 2.91 (race condition triggered by DHCPv6, RA, netlink and DNSSEC interactions) is fixed in version 2.92.
Important note: Several forum members previously pointed out that the issue was not caused by configuration, but by an internal dnsmasq bug. After running 2.92 for several days under real‑world load, I can confirm that they were absolutely correct. The configuration was fine — the problem was the bug, and 2.92 resolves it completely.
Conclusion: dnsmasq 2.92 appears to be the first fully stable version after the regression. Anyone experiencing crashes on 24.10.x should consider testing 2.92 from snapshot.
If needed, I can provide logs, configs, or build instructions.
3 Likes
Exactly, thanks for confirming 
1 Like
I'm too late to the party but if I was in time, I would have been quite irritated by OP's responses. It's not because the are translated - it's because they are obviously AI-generated from first to last word, and that AI obviously is not just translating input text but actually synthesizing competely new text with hallucinated and inconsistent claims which the author either didn't or couldn't review. This is extremely confusing and disruptive to people who are trying to help. And somewhat comical.
2 Likes
That is exactly the "danger" of using AI if you do not have the skills to check it and why we are hesitant to allow it on the forum.
But I admit it can be a wonderful tool.
2 Likes
Dear antonk, English is not my native language, and I do not speak it fluently. I write my questions in my own language first, and then translate them into English. A proper translation is not word‑for‑word — different languages require different structure and phrasing to stay clear and readable. Even if the original text is dry and technical, the translated version may sound smoother simply because English works differently. I do use AI to translate the text, but only for translation — the content, meaning, and technical details are mine. The translation just helps express them accurately so others can understand them.