Project

General

Profile

Actions

Bug #13792

open

Filterdns assumes sets of resolved addresses for each hostname are nonintersecting

Added by Reid Linnemann about 1 year ago. Updated 15 days ago.

Status:
New
Priority:
Normal
Category:
FilterDNS
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
24.07
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

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.


Related issues

Related to Bug #9296: Alias content is sometimes incomplete when an alias contains both FQDN and IP address entriesResolvedReid Linnemann

Actions
Actions #1

Updated by Reid Linnemann about 1 year ago

  • Related to Bug #9296: Alias content is sometimes incomplete when an alias contains both FQDN and IP address entries added
Actions #2

Updated by Jim Pingle 11 months ago

  • Plus Target Version changed from 23.05 to 23.09
Actions #3

Updated by Marcos M 9 months ago

  • Target version changed from 2.7.0 to CE-Next
  • Plus Target Version changed from 23.09 to Plus-Next
Actions #4

Updated by Jim Pingle 9 months ago

  • Plus Target Version changed from Plus-Next to 23.09
Actions #5

Updated by Jim Pingle 6 months ago

  • Plus Target Version changed from 23.09 to 24.01
Actions #6

Updated by Jim Pingle 6 months ago

  • Plus Target Version changed from 24.01 to 24.03
Actions #7

Updated by Jim Pingle 15 days ago

  • Plus Target Version changed from 24.03 to 24.07
Actions

Also available in: Atom PDF