pfSense

I have a similar situation here. An alias acting as Whitelist, with two DDNS. When both DDNS are in the same location, they share the same address, so the table is created with only that address. But whenever one of the DDNS moves outside, the older address is deleted and the new one is added, causing the second DDNS to lose access.

DDNS1 ----> 1.2.3.4
DDNS2 ----> 1.2.3.4: Both have access. Table contains 1.2.3.4 only.

1.2.3.4---> DDNS1 ---> 5.6.7.8: Only DDNS1 has access. Table contains 5.6.7.8 only.

1.2.3.4---> DDNS2 ---> 5.5.6.6: Both regain access. Table contains 5.6.7.8 and 5.5.6.6

I'd point out too that filterdns isn't updating the alias with the valid IP on its next run, it seems to be assuming the valid IP is already in the table. So access (by allow rule) is lost permanently until the IP of that FQDN changes. (or someone runs "killall filterdns" and Status > Filter Reload) If there's not a significant "cost" it could just add each IP at every filterdns update interval, or maybe every "n" runs, as a workaround.

I had linked my thread in one of the duplicate redmine entries so will also link it here: https://forum.netgate.com/topic/196927/filterdns-has-stopped-resolving-hostnames-in-firewall-aliases/

I assume Netgate engineers have already worked out a good way of fixing the various problems with Filterdns. So this is probably not relevant but, this problem was rediscovered and solutions contemplated here https://forum.netgate.com/post/1231744

We hit this in production on pfSense 2.8.1: a host alias containing domains with single rotating A records (Cloudflare) loses addresses on every filterdns reload — only the current answer stays in the pf table, so LAN rule traffic sometimes routes via the wrong gateway.

Root-cause analysis confirms filterdns replaces/differs the full address set per hostname each cycle (the non-injective address->hostname assumption noted here). For rotating single-answer DNS this leaves the alias table perpetually incomplete.

Our fix, applied as a System Patch on 2.8.1 and now submitted as a PR to master behind a settings toggle:

- resolve_alias_host_addresses() samples the resolver several times (default 3), follows CNAME chains, and retains previously observed addresses from /var/db/dnscache so the full address set persists across reloads (interleaves with filterdns without waiting for every fqdn entry to poll).
- filter_generate_nested_alias_recurse() resolves hostname entries inline and emits literal "pf <ip> <alias>" filterdns watches for every resolved address.
- New setting "Resolve and retain all FQDN addresses" (System > Advanced > Firewall/NAT, default ON) gates the behavior; off preserves the exact legacy path.

The fix has been submitted upstream as a pull request:
https://github.com/pfsense/pfsense/pull/4763
(PR #4763 — "Add 'Resolve and retain all FQDN addresses' setting for host aliases", links this ticket).

That sounds more like a solution for https://docs.netgate.com/pfsense/en/latest/firewall/aliases-features.html#:~:text=round%2Drobin ?

Here the issue is that specific IPs should be included in the alias but are being incorrectly removed because some other hostname changed its IP, even though this one did not. Not that previously-resolved IPs should still be valid.