Filtering

Part of the Security features, filtering allows for matching DNS traffic against policy rules to determine whether or not the filtering engine should intervene. Filtering can be enabled on the following components:

dnsdist
Recursor

Concepts

Important concepts to understanding filtering are the following:

Feeds: Provides categorized lists of domains which can be referenced in policy rules
Subscribers & Devices: Provides means of identifying DNS traffic for fine-grained filtering
vHosts: Virtual hosts in dnsdist which can be assigned specific policy rules and/or filter settings

These concepts can then be applied in different types of filtering:

Static Filtering: Filtering which statically applies policies to all inbound traffic or traffic received over a specific vHost
Dynamic Filtering: Filtering which can be defined to act on the source of DNS traffic, typically by identifying a subscriber/device and applying subscriber/device specific policies. Dynamic filtering also provides an administrative GUI & API through which policies and much more can be managed at runtime.

Feeds

Feeds provide input to the filtering engine to help determine how a request or response should be treated.

Crucial to understanding feeds are the following concepts:

DomainPath: A domain name (example.com) which can optionally contain a path (example.com/some/path)
Category: A collection of DomainPaths referenced by a code (By default a code is a numerical ID, but can also be complemented with an alphanumerical name if needed)
A DomainPath can be assigned to multiple categories

We consider the combination of these DomainPaths and corresponding categories a "feed". The table below shows a simple example of such a feed:

Category Code	Category Title	DomainPaths
`1`	`documentation`	`doc.powerdns.com`
`2`	`examples`	`example.com` `example.co.uk` `example.net` `example.nl`
`3`	`netherlands`	`example.nl`

This version of Cloud Control has the following sources of feeds available:

Subscribers and Devices

Subscribers and their devices can be identified and considered in filtering policies in deployments where the necessary information is available to the filtering engine. This data can currently be provided via the following means:

Subscribers: If RADIUS is available in your overall architecture, the Radius Listener component can be configured to receive RADIUS messages containing information which can be used to identify subscribers
Devices: If you have subscribers identified via Radius Listener, you can enable Device Register to attempt to further distinguish between individual devices for each subscriber

vHosts

vHosts are a concept restricted to dnsdist, allowing for a single dnsdist instance set to be exposed via multiple different Services and applying a different set of policies to the traffic received via each vHost.

For example, a deployment where dnsdist has 3 vHosts defined:

Static Filtering

Static filtering allows for the configuration of policy rules which either react the same to all inbound traffic, or to subsets of traffic if you have filtering enabled in dnsdist with vHosts for traffic segregation. The concepts subscribers and devices are not available in this filtering mode.

In its most basic form, static filtering can be isolated to the Userplane in which the filtering-enabled dnsdist or Recursor resides. This limits you to policies and data sources (domain lists, categories, etc) which are statically defined in the Userplane Helm Chart's values overrides.

In a more advanced deployment, you can consume feeds from a Controlplane deployment and limit the Userplane's filtering configuration to policies which act based on data retrieved from the feeds. In a deployment with 1 Controlplane and 2 Userplanes this would look similar to the below diagram:

You can also combine multiple concepts, such as vHosts and feeds:

Details on how to configure these items:

Userplane: Filter Settings
Controlplane: Feeds

Dynamic Filtering

Dynamic filtering enables usage of all previously described concepts, but also has a larger footprint and requires more configuration to get up and running. Required for any dynamic filtering deployment is to enable deployment of the dynamic filtering blueprint in a Controlplane. This will provide you with the following:

In the above blueprint you can see the following components:

Admin: Administrative component with both a GUI and an API through which dynamic filtering settings (such as policy rules, domain lists, subscribers, etc) can be managed.
Postgres: Database backend for the Admin, stores all persistent data. Makes use of the Cloud Control Postgres database
Redis: In-memory database which holds all data (except for feeds) needed by Userplane deployments to make filtering decisions. Makes use of the Cloud Control Redis deployment
Feeds: Category Overrides & Domain Lists are feeds automatically made available if the Controlplane dynamic filtering blueprint is enabled. These are based on the HTTP API Downloader and obtain their data from the Admin API.
NATS: Messaging system to enable communication between Controlplane components and to act as a hub when Userplanes are configured to perform dynamic filtering. Makes use of the Cloud Control NATS deployment

Once deployed in the Controlplane, dynamic filtering can be enabled on Userplane deployments. In order to do so, the Userplane needs to be configured to make all the relevant data from the Controlplane available. With the minimal deployment of dynamic filtering in the Controlplane this looks as follows:

In this above diagram, you can see the following happens when the Userplane is configured for dynamic filtering:

A Redis (mirror) deployment is created, which replicates from the Redis (read-write) deployment in the Controlplane
The 2 default feeds are consumed by the Userplane
NATS deployment in the Userplane joins the larger mesh by connecting to the Controlplane's NATS hub Service

In this topology you have the benefits of dynamic filtering and management via the Admin GUI/API, but there are no sources yet for identifying subscribers or devices. The following chapters show how the blueprint changes when those are added.

Identifying subscribers

Subscribers are identified by receiving RADIUS messages, parsing them and storing the necessary data for filtering decisions. This is accomplished by 2 additional components:

Radius Listener: Receive and parse inbound RADIUS messages
IP Mapper: Store output of Radius listener in a manner that allows them to be used by the filtering engine

Note: IP Mapper is essential for Radius Listener to function, as a result you can enable Radius Listener and will have IP Mapper automatically enabled and configured in conjunction with Radius Listener.

When adding RADIUS support to your deployment, you need to consider the scope:

Global: If you wish to have RADIUS support covering all Userplanes which you connect to your Controlplane
Local: If you wish to have RADIUS support specific to Userplanes

Based on that choice, you can choose where to enable RADIUS support:

Global: Enable RADIUS support in the Controlplane
Local: Enable RADIUS support in the Userplane

When you deploy RADIUS support in the Controlplane it looks as follows:

Or alternatively, with RADIUS support in a Userplane:

Note: When RADIUS support is enabled in the Userplane, a Redis deployment is needed to which it can write. Since the existing Redis deployment is a mirror without write support, IP Mapper is paired with a dedicated Redis deployment separate from the existing mirror.

Identifying devices

If you have RADIUS support enabled and you are able to identify subscribers, you can also enable identification & registration of the devices used by these subscribers for further fine-grained ability to apply filtering. This is done by enabling Device Register, which consists of a new component in both the Userplane deployments & Controlplane deployment:

As you can see in diagram, you will now have:

Device Register in Controlplane in consumer mode: This listens for incoming messages over NATS and stores information about devices in the Controlplane Redis (which is then replicated to the Userplanes)
Device Register in Userplane in producer mode: This listens for messages from the filtering engine in dnsdist/Recursor and broadcasts information about devices over NATS to the consumer in the Controlplane