Infrastructure
DNS PATROL is a system typically consisting of several resolvers, some of which may sit directly inside the organization’s network. These resolvers obtain their configuration from the backend, which is controlled through the administration web portal. Resolvers send query data to the database, with which the web portal also communicates for analytics.
Systems
This section describes the individual components of the DNS PATROL system.
Resolvers
DNS queries are resolved by instances of KNOT Resolver. A resolver can be located inside the organization’s internal network, where it also communicates with the Active Directory Domain Controller to resolve internal domain names. For subnets within the wider corporate network, additional resolvers may be deployed. For end devices outside the organization’s network, an external resolver is available, queried via unique DoH URLs.
Alongside the resolver runs a collector, which captures information about every resolved query and publishes it to Kafka.
Kafka
Kafka acts as the communication broker between the resolvers and the backend services. It also serves as a short-term buffer for DNS queries in case the main database fails.
Communication is bidirectional: resolvers publish query records into Kafka and consume configuration files (zones, blacklists and other rules) from Kafka, supplied by the core according to the current settings in the portal.
DNS PATROL Core
The core of the system, controlled through the administration portal. Through Kafka it updates the resolvers’ configuration according to the current settings and, in live mode, receives DNS queries. It stores system configuration in the databases and queries them for long-term analytical data. User authentication is provided by external OpenID providers, such as MojeID.
For fast lookups of registered devices and zones, the core uses a Redis cache, which it updates on every change to the registered devices or configuration.
The backend can forward audit events for administrator actions in the portal to external information systems over the syslog protocol, typically for integration with a corporate SIEM.
Administration portal
The administration portal is a web application; its usage is described in detail in the Web portal section.
Databases
PostgreSQL: Network structure, users, devices, policy configuration, etc.
ClickHouse: Handles large volumes of analytical data, stores query history for statistics and search in the portal
Redis: In-memory cache of registered devices and zones for low-latency lookups.
End devices
End devices using the external resolver register into the system via a client application and a one-time registration code issued from the administration portal.
The client application on the device sends the registration code together with the hostname, MAC address and operating system information to DNS PATROL Core. The core validates the code, creates a new device record bound to the user who owns the code, and returns to the client an identity token and a unique DoH URL. The device then routes all its DNS queries to that URL.
Browser extension
On Windows devices, the client application is accompanied by an extension for Chrome and Edge. When the resolver blocks a domain, it attaches the reason to its answer as an Extended DNS Error (RFC 8914). The browser ignores it, but the extension requests it through the client application and, instead of the browser’s default error page, shows a page with an explanation and a reference code that identifies the event in the resolver’s logs. The extension itself makes no network connections. See Browser extension for details.
Zones, subnets and rule sets
The logical structuring of the network and policies in DNS PATROL is built on three entities. A zone is the top-level unit and groups together a set of resolvers. Within a zone, subnets form a tree hierarchy based on address range. Rule sets are then attached to subnets and determine which DNS queries are allowed, blocked or merely audited at that point in the hierarchy.
Zones
A zone groups a set of resolvers managed under one configuration. A zone can be internal (for the corporate network) or external (for end devices outside the network). An external zone has a DoH URL set, to which the client applications on devices connect. Each zone contains exactly one root subnet, from which the entire subnet hierarchy descends.
Subnets
A subnet is defined by IPv4 or IPv6 address ranges and may contain any number of further subnets as children. The subnet tree makes it possible to structure the corporate network according to its actual topology. One or more rule sets can be attached to each subnet. A subnet inherits the rule sets settings of its parent, however it can be rewritten.
Rule sets
A rule set is a named list of domain names. A set can be either in the form of a block list (blacklist) or an exception list (whitelist). It can optionally have an attached ML model for evaluating queries beyond the static list.
A rule set is attached to a subnet with a specific action: allow, block or audit (record the query without blocking). The resulting zone configuration is published to the resolvers via Kafka.