[Dnsmasq-discuss] nftset: existing element timeout is not refreshed unlike ipset

[Maxim Kurbatov]

Hi,

I'm using dnsmasq --nftset on OpenWrt for policy routing and ran into a
difference between --ipset and --nftset when sets have timeouts.

With ipset, adding an existing element with -exist refreshes its timeout.
With nftables,

add element ... { <address> }

does not refresh the timeout if the element already exists.

For example, with a 2 hour set timeout:

00:00  dnsmasq adds 192.0.2.1
       -> expires at ~02:00

01:00  dnsmasq gets the same address again
       -> add element 192.0.2.1

The element still expires at ~02:00 rather than ~03:00.

This means an address can disappear from the nft set even though dnsmasq
has received it again recently. If dnsmasq still has the DNS record cached,
clients may continue using that address while it no longer matches the
nftables set. This is particularly noticeable when the set is used for
firewalling or policy routing.

I found that this difference was already mentioned during the original
nftset work in 2020
<https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q3/014212.html>.
Qi-An Fu noted that ipset add resets the timeout while nftables add element
does not.

As far as I can tell, nftables doesn't provide a userspace equivalent of
the packet-path update operation for refreshing an element timeout. An
existing element needs to be removed and added again.

Would it make sense for dnsmasq to provide ipset-like refresh behavior for
--nftset?

With recent nftables, one possible way would be an atomic transaction
containing:

destroy element <family> <table> <set> { <address> }
add element <family> <table> <set> { <address> }

For compatibility with versions without destroy element, something like
this could be used instead:

add element <family> <table> <set> { <address> }
delete element <family> <table> <set> { <address> }
add element <family> <table> <set> { <address> }

provided the whole operation is submitted atomically.

If changing the existing --nftset behavior is undesirable, this could also
be an optional mode/modifier.

If this makes sense, I'm happy to look into preparing and testing a patch.

Best regards,
Maxim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20260918/c3ecb796/attachment.htm>