pfSense

In the current design of filterdns, each hostname thread wake periodically and performs a NS lookup, comparing its current list of mapped addresses to the new addresses returned by the lookup. It then generates add/delete actions for every table the hostname is associated with, and those tables are updated accordingly. This design does not account for the fact that the relation of address -> hostname is not injective, and there will be intersections the sets of addresses associated with hostnames that must be resolved. This can be demonstrated by fabricating NS records for hosts:

a.foo.com (1.1.1.1)
b.foo.com (2.2.2.2)

Then add a.foo.com and b.foo.com entries to a new alias bar , and observe that the bar table is created and populated.

Modify the record for a.foo.com to resolve to 2.2.2.2, causing 2.2.2.2 to have a one-to-many relationship with hostnames a.foo.com and b.foo.com
Wait for the update interval on filterdns to expire
Note in debug logs that address 1.1.1.1 is removed from a.foo.com and 2.2.2.2 is discovered as a new address for a.foo.com
Note that an action is taken for a.foo.com to remove 1.1.1.1 from the table bar for which it is a member
Restore the record for a.foo.com to 1.1.1.1
Wait for the update interval on filterdns to expire
Note in debug logs that address 2.2.2.2 is removed from a.foo.com and 1.1.1.1 is discovered as a new address for a.foo.com
Note that an action is taken for a.foo.com to remove 2.2.2.2 from the table bar for which it is a member
The set of addresses in the table is now incorrect, the address 2.2.2.2 has been removed even though it is still referenced by b.foo.com

To resolve this issue, it is necessary to model the set of addresses associated with each table and maintain a reference count. The creation and deletion of these address associations should drive the add/delete events in the table rather than the set of addresses associated with a hostname.