0

I need to apply an nftables rule to all traffic originating from a specific host, but the packets will not necessarily include the proper FQDN, so I need to rely on the IP address(s). The issue is that there are multiple redundant IP's returned for the FQDN that may change order/priority from time to time, or may even be replace entirely.

Because there are multiple IP's returned, I have to use a mutable named set, but I need that set to update somewhat regularly to ensure we have an up to date list of IP's to match against.

We have BIND9 (named) on the server so my thought is that I could have a cron job script that:

  1. Flush the local dns resolver for the the FQDN with rdnc flushname...,
  2. Then dig against it to update the resolver cache with dig +short...,
  3. Run nft add element... with the new ones,
  4. Flush the old named set with nft delete element...

Is this the right way to go about this, or have I overthought something thats already been solved another way?

oucil
  • 241
  • 1
  • 2
  • 9
  • See this for some pointers https://unix.stackexchange.com/questions/466336/how-to-make-systemd-resolved-stop-trying-to-use-offline-dns-servers/466358#466358 – Rui F Ribeiro May 26 '20 at 20:00
  • @RuiFRibeiro If you're referring to deferring to an anycast service, that would be great but they don't support it. Otherwise, I'm only trying to base my own accounting on traffic originating from their IP's, this isn't mission critical and the host will not suffer as a result of out of date info. – oucil May 26 '20 at 20:17

2 Answers2

1

You should create the new element before you delete the old one. That way there is always a set to match, no lost packets because of a firewall update. The short gap would probably not cause any problems but there is no reason not to do it this way.

Hauke Laging
  • 88,146
  • 18
  • 125
  • 174
0

Actually, you could make use of nftables atomic loading behavior with nft -f . In that file, you would issue a flush for the set first, then add only the elements that your current DNS dig returns. There's no need to drop the ones which are no longer to be in the set, because you declare the set contents from scratch. Should be easier to implement ...

TMA
  • 1
  • 1