<div dir="ltr"><div class="gmail_quote gmail_quote_container"><div dir="ltr"><p><span>Hi,</span></p><p><span>I'm using dnsmasq </span><code dir="ltr"><span>--nftset</span></code><span> on OpenWrt for policy routing and ran into a difference between </span><code dir="ltr"><span>--ipset</span></code><span> and </span><code dir="ltr"><span>--nftset</span></code><span> when sets have timeouts.</span></p><p><span>With ipset, adding an existing element with </span><code dir="ltr"><span>-exist</span></code><span> refreshes its timeout. With nftables,</span></p><pre dir="ltr"><code dir="ltr"><span>add element ... { <address> }</span></code></pre><p><span>does not refresh the timeout if the element already exists.</span></p><p><span>For example, with a 2 hour set timeout:</span></p><pre dir="ltr"><code dir="ltr"><span>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</span></code></pre><p><span>The element still expires at ~02:00 rather than ~03:00.</span></p><p><span>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.</span></p><p><span>I found that this difference was <a href="https://link.kurb.me/CL0/https:%2F%2Flists.thekelleys.org.uk%2Fpipermail%2Fdnsmasq-discuss%2F2020q3%2F014212.html/1/010701a0b34ada48-ef8b7f56-2aea-46d7-a050-d4838ce91e54-000000/YaydaHfkLcvOdkL67abTupyZc_Lqu719qxrZDhmeskQ=258" target="_blank">already mentioned during the original nftset work in 2020</a>. Qi-An Fu noted that </span><code dir="ltr"><span>ipset add</span></code><span> resets the timeout while nftables </span><code dir="ltr"><span>add element</span></code><span> does not.</span></p><p><span>As far as I can tell, nftables doesn't provide a userspace equivalent of the packet-path </span><code dir="ltr"><span>update</span></code><span> operation for refreshing an element timeout. An existing element needs to be removed and added again.</span></p><p><span>Would it make sense for dnsmasq to provide ipset-like refresh behavior for </span><code dir="ltr"><span>--nftset</span></code><span>?</span></p><p><span>With recent nftables, one possible way would be an atomic transaction containing:</span></p><pre dir="ltr"><code dir="ltr"><span>destroy element <family> <table> <set> { <address> }
add element <family> <table> <set> { <address> }</span></code></pre><p><span>For compatibility with versions without </span><code dir="ltr"><span>destroy element</span></code><span>, something like this could be used instead:</span></p><pre dir="ltr"><code dir="ltr"><span>add element <family> <table> <set> { <address> }
delete element <family> <table> <set> { <address> }
add element <family> <table> <set> { <address> }</span></code></pre><p><span>provided the whole operation is submitted atomically.</span></p><p><span>If changing the existing </span><code dir="ltr"><span>--nftset</span></code><span> behavior is undesirable, this could also be an optional mode/modifier.</span></p><p><span>If this makes sense, I'm happy to look into preparing and testing a patch.</span></p><p><span>Best regards,</span><br><span>Maxim</span></p><br></div>
</div></div>
<img alt="" src="http://link.kurb.me/CI0/010701a0b34ada48-ef8b7f56-2aea-46d7-a050-d4838ce91e54-000000/uuAIcjAfqgsyPgmXZFGUfKE5wQ5miytQn2wM6I6kCM8=258" style="display: none; width: 1px; height: 1px;">