Documentation
Secure Domains website العربية

Protect Guide

Configuring the DNS Armor™ Protect DNS firewall: network services, bypass domains and dynamic DNS, local rulesets, security policies, threat feeds, DNS monitoring, analytics and AI threat detection.

Configuring Networks, Security Policies, and Monitoring for the DNS Armor™ DNS Firewall

1. Introduction

This guide covers DNS Armor™ Protect — the DNS Firewall (protective DNS) service of the DNS Armor™ platform. It describes everything under the DNS Firewall block of the portal sidebar: the DNS servers and networks your traffic is matched against, the rulesets and security policies that decide what is blocked, allowed, or redirected, the threat-intelligence and RPZ feeds that keep those decisions current, and the monitoring and analytics surfaces you use to see what the firewall did.

1.1 What DNS Armor™ Protect Is

DNS Armor™ Protect answers the DNS queries of your users and devices from the DNS Armor™ resolver network and filters them as they are answered. Every query is evaluated against the security policy that matches its source — an external (public) network, a private network behind a Local Resolver, or an individual endpoint running the Endpoint Agent — and is answered normally, blocked (NXDOMAIN or NODATA), explicitly allowed (PASSTHRU), or redirected to a landing page.

Because filtering happens at the DNS layer, protection applies to every application on the device rather than to browser traffic alone, and it is enforced before a connection to a malicious destination is ever opened. The decision inputs are:

  • Built-in threat feeds maintained by Secure Domains — malware, phishing, command-and-control, newly registered domains, and related categories, plus AI-driven detections such as DNS tunnelling (§3.3.1)
  • External RPZ feeds you subscribe to or publish yourself (§3.3.2)
  • Local rulesets — your own domain, IP, and PTR match rules (§3.1)
  • Bypass domains and Dynamic DNS records for internal names that must resolve locally (§2.3, §2.4)

DNS Armor™ Protect is available in two deployment options: Cloud Delivered (fully managed security-as-a-service) and Cloud Managed (on-premise deployment with cloud management). Its real-time threat intelligence comprises over 10 million threat indicators, updated continuously.

1.2 Who This Guide Is For

Network administrators, security engineers, and SOC analysts who configure or operate the DNS firewall for one or more tenants — whether you administer a single organization or manage many tenants as an MSP. Familiarity with DNS concepts (recursive resolution, zones, record types, RPZ) is assumed; portal account setup, tenants, users, and roles are not covered here — they live in the Administration Guide.

1.3 Licensing

DNS Armor™ Protect (DNS Firewall) and DNS Armor™ Resolve (Authoritative DNS) are two separate licenses. Resolve is not an add-on to Protect, and Protect is not a prerequisite for Resolve. A tenant may hold either license on its own, or both; each is purchased and enabled independently, and neither depends on the other. Where a customer takes both, they can be purchased together on a single invoice — that is a billing convenience, not a dependency between the products.

What you see in the portal follows the license(s) your tenant holds. Everything in this guide requires the Protect license: without it the DNS Firewall sidebar block, its pages, and its Security roles are not shown. The pages themselves are further governed by role-based access control — each section below carries a Views and Access block naming the RBAC service and the roles that grant read or write access.

1.4 Prerequisites

  • An active DNS Armor™ tenant licensed for DNS Armor™ Protect
  • A portal account with a Security role (Security Operator for write access, Security Analyst for read-only) or an Admin/Root role, scoped to the tenant you are configuring
  • Your DNS traffic reaching the DNS Armor™ resolvers by at least one of the supported paths: public source IPs registered as external networks, a Local Resolver appliance forwarding from inside your network, or the Endpoint Agent installed on roaming devices
  • For RPZ import or export, network reachability between your DNS infrastructure and the assigned RPZ distribution servers (§2.1)
  • DNS Armor™ Administration Guide — the shared platform: architecture and multi-tenancy, the role catalogue and RBAC model, getting started and account self-service, master-tenant administration (tenants, users, audit, API codes, downloads), normal-tenant administration, troubleshooting, and the glossary. Read it first if you are new to the portal.
  • DNS Armor™ Resolve (Authoritative DNS) Guide — hosting your own zones and records on the DNS Armor™ authoritative name-server network, with DNSSEC. A separately licensed service, unrelated to the firewall configuration described here.
  • DNS Armor™ Local Resolver Deployment Guide — deploying the on-premise virtual appliance that forwards internal DNS traffic to DNS Armor™, including Active Directory integration, high availability, and syslog/SIEM streaming. Use it together with the private-network and bypass-domain configuration in §2.
  • DNS Armor™ Endpoint Agent Guide — installing and mass-deploying the Windows, macOS, and Linux agent that protects roaming devices. Endpoints appear as policy targets in §3.2 and are monitored in §4.9.
  • DNS Armor™ Self-Service Guide — for accounts created online: signup, plans, seats, and billing.

For technical assistance, contact support@secure-domains.org.

2. Network Services Configuration

This section covers the configuration of DNS servers, networks, and Local Resolver integration.

2.1 DNS Server Management

Where to find it: Sidebar → Cloud Servers

The Assigned Cloud Servers page lists the DNS servers assigned to your organization — for both DNS Armor™ services. Use it to confirm which recursive resolvers, RPZ servers, and authoritative nodes your traffic is being directed to and to verify their geographic distribution.

2.1.1 What You See on the Page

Each server entry shows the DNS server name, type, public and private IP, region, resource group, and assigned customers. The server types are:

  • Recursive – DNS Armor™ Protect (DNS Firewall) resolvers that answer DNS queries with security enforcement applied
  • RPZ (Response Policy Zone) – Servers that distribute RPZ feed data to subscribed secondary servers
  • AuthDNS – DNS Armor™ Resolve (Authoritative DNS) nodes that serve your hosted zones

2.1.2 Views and Access

  • Master Tenant view: See and manage every resolver assigned across the platform
  • Normal Tenant view: See only the resolvers assigned to the user's tenant
  • RBAC: The Resolver service controls visibility. Resolver provisioning and edits are typically restricted to Root and MSP Admin roles; tenant administrators have read access

Filtering and search run server-side across all assigned servers.

  • Search DNS servers – Free-text search across name and IP (press Enter)
  • Type – Recursive, RPZ, AuthDNS
  • Region – Multi-select of available regions
  • Customers – Entity picker (platform administrators)

2.1.4 Create DNS Server Modal

This modal is available to platform administrators only. The toolbar also offers a Sync Security Policies action to push the current policy set to the cloud servers.

  1. Open Sidebar → Cloud Servers.
  2. Click Create DNS Server.
  3. Complete the modal:
    • Customers – Required; multi-select (Assign Customers step)
    • DNS Server Name – Required; must be unique within the region
    • Subscription Name – Required
    • Type – Required; Recursive, RPZ, or AuthDNS
    • Public IP – Required; valid IPv4 address
    • Private IP – Optional; valid IPv4 address
    • Region – Required; pick from the regions list
    • Resource Group Name – Optional
    • Virtual Network / Subnet – Optional
    • Network Security Group – Optional
  4. Click Save.

2.1.5 How to Use It

  1. Open Sidebar → Cloud Servers.
  2. Review the list to identify the recursive and RPZ servers assigned to your tenant.
  3. Note the server IP addresses for use when configuring your local DNS forwarders, Local Resolver appliances, or third-party RPZ subscribers.
  4. If your traffic should be routed to a different geographic region, contact support to request a server reassignment.

2.2 Network Configuration

Where to find it: Sidebar → DNS Firewall → Setup → Networks

The Networks page is where you register the external (public/NAT) and private (internal) network ranges that DNS Armor™ uses to attribute DNS requests to a tenant and apply the correct policy. The page is split into two tabs — External Networks and Private Networks.

2.2.0 Views and Access

  • Master Tenant view: Manage networks for any tenant the account is authorized for
  • Normal Tenant view: Manage only networks belonging to the assigned tenant
  • RBAC: The ExternalNetwork service governs both tabs. Admin users can create, edit, and delete; Read-Only users can view only

Filtering and search run server-side across all networks in scope.

  • Search networks – Free-text search on description and address (press Enter)
  • Tab – Toggle between External Networks and Private Networks
  • RPZ Support – Active / Inactive (External Networks tab)
  • Customer / Reseller – Entity picker (platform administrators)
  • Tenant – Entity picker

2.2.1 External Networks

External networks define public or NAT network addresses from which the Assigned Cloud Servers will receive requests. These networks represent the external-facing IP addresses that serve as routing points for DNS traffic. External networks are essential for establishing the source context of DNS requests in cloud-based filtering scenarios.

2.2.1.1 Network Type Support
  • IPv4 Only: Currently, only IPv4 addressing is supported for external networks
  • Public/NAT Addresses: Must correspond to actual NAT public address(es) used for routing
  • Routing Context: These addresses identify the source of DNS requests reaching the cloud infrastructure

Direct Forwarding:

  • Configure external network mapping to match the public NAT addresses from which DNS requests originate
  • Ensures proper request attribution and policy application

Local Resolver as Forwarder:

  • Create external network entries corresponding to Local Resolver's external-facing addresses
  • Maintains traffic flow visibility and control
2.2.1.2 Create Network Modal — Single Network
  1. Open Sidebar → DNS Firewall → Setup → Networks.
  2. Select the External Networks tab.
  3. Click Create Network and choose the Single Network tab.
  4. Complete the modal:
    • Customer – Required (Root and App Root users)
    • Tenant – Required
    • Network Description – Optional; meaningful identifier
    • Network Address – Required; valid CIDR notation (e.g. 10.0.0.0/8); must be unique within the tenant
  5. Click Save.
2.2.1.2.1 Create Network Modal — Bulk Upload
  1. In the Create Network dialog, switch to the Bulk Upload tab.
  2. Upload a CSV file containing one network address per row (or comma-separated list).
  3. Review the result panel — created networks are listed alongside any failed rows with the rejection reason.
2.2.1.2.2 Edit Network Modal
  • Network Address – Editable
  • Description – Editable
  • Activate / Deactivate RPZ – Toggle (External networks only)
2.2.1.2.3 Delete Protection for Networks In Use

Networks cannot be deleted while other configuration still depends on them. The portal refuses the deletion and names the blocking objects so you can clean up dependencies first:

  • External networks – Cannot be deleted while referenced by one or more Security Policies; an RPZ-activated external network must be deactivated before it can be deleted.
  • Private networks – Cannot be deleted while referenced by Security Policies or by Local Resolver configurations.

Remove the network from the listed policies (or resolvers) and retry the deletion.

2.2.1.3 RPZ Feed Export Configuration
Activate for RPZ Functionality

The "Activate for RPZ" option, available in the Action column for external networks only, enables automated feed exports to third-party systems.

Key Features:
  • Access Control: Functions as an ACL to authorize specific sources for feed retrieval
  • Threat Feeds Export: Enables export of Threats, Web Filters, and Applications feeds
  • AXFR Support: Utilizes DNS Zone Transfer (AXFR) protocol for feed distribution
  • Feed Source: RPZ DNS address serves as the primary source for DNS Zone transfers
Use Cases:
  • Integration with third-party security systems
  • Centralized threat intelligence distribution
  • Automated policy synchronization across multiple platforms

2.2.2 Private Networks

Private networks correspond to internal addressing spaces within corporate network infrastructure. These networks work in conjunction with external networks within security policies to enforce granular access controls across different network segments and VLANs.

2.2.2.1 Network Segmentation Strategy
Granular Policy Control

Private networks enable administrators to implement different security policies across various internal network segments, providing:

  • Subnet-Level Control: Individual policies for different subnets
  • VLAN Segmentation: Separate security rules for different VLANs
  • Department Isolation: Customized filtering based on organizational structure
  • Risk-Based Policies: Tailored security measures based on network segment risk profiles
2.2.2.2 Integration with Security Policies

Private networks function as policy enforcement points by:

  • Mapping Internal Traffic: Identifying the internal source subnet of DNS requests
  • Policy Association: Linking specific network segments to appropriate security policies
  • Traffic Differentiation: Enabling different treatment for various internal network zones
2.2.2.3 Network Creation Process
Configuration Requirements
  • Active Tenants Only: Only activated tenants appear in the tenant selection dropdown
  • Network Description: Descriptive identifier for network purpose and scope
  • Network Address: CIDR notation defining the network range
Best Practices
  1. Logical Grouping: Organize networks by function, department, or security requirements
  2. Consistent Naming: Use standardized naming conventions for easy identification
  3. Regular Review: Periodically audit network definitions for accuracy and relevance

2.3 Bypass Domains

Where to find it: Sidebar → DNS Firewall → Setup → Bypass Domains

Bypass Domains tell DNS Armor™ which DNS names should skip the cloud enforcement pipeline and resolve through your own resolvers instead. This is most often used for internal Active Directory zones, private application namespaces, and trusted partner domains.

2.3.1 What You See on the Page

The page lists each bypass configuration with the following columns:

  • Name – Friendly identifier you assign to the configuration
  • Description – Optional change-control note
  • Domains – The DNS names this configuration covers
  • DNS Servers – The resolvers that will answer for the listed domains
  • Mode – Simple (one resolver list for all domains) or Advanced (different resolvers per domain group)
  • Fallback – Strict (fail closed) or Cloud (fall back to DNS Armor™ if your resolvers are unreachable)

2.3.1.1 Views and Access

  • Master Tenant view: Manage bypass configurations for any tenant the account is authorized for
  • Normal Tenant view: Manage only configurations belonging to the assigned tenant
  • RBAC: The BypassDomainConfig service governs the page. Admin users can create, edit, and delete; Read-Only users can view only

Filtering and search run server-side across all configurations in scope.

  • Search bypass domains – Free-text search across configuration name and domain (press Enter)
  • Mode – Fallback behavior: Strict / Cloud
  • Customer / Reseller – Entity picker (platform administrators)
  • Tenant – Entity picker

2.3.2 Create a Bypass Configuration

  1. Open Sidebar → DNS Firewall → Setup → Bypass Domains.
  2. Click Add Bypass Domain.
  3. Complete the modal:
    • Configuration Name – Required; must be unique within the tenant
    • Customer – Required (Root and App Root users)
    • Tenant – Required
    • Shared DNS Servers – At least one valid IPv4 address; click Add Server to add more
    • Domains – Required; choose the configuration mode:
      • Simple – Comma-separated list. Use the shared resolvers for every domain. Recommended for a single Active Directory forest.
      • Advanced – Per-domain table with Domain (FQDN, required) and DNS Servers (multi-select, required) for each row. Recommended when multiple forests, DMZ services, or partner zones require different resolution paths.
    • Fallback Behavior – Strict (fail closed) or Cloud (fall back to DNS Armor™)
  4. Click Save. The configuration takes effect on the next policy push.

2.3.3 Manage an Existing Configuration

  • Edit – Update the domain list, resolvers, or fallback option.
  • Delete – Remove the configuration after the confirmation prompt. A configuration that is still assigned to one or more Local Resolvers cannot be deleted — the error names the resolvers; unassign it there first.
  • View – Open the configuration detail panel.
  • Search – Filter the table by name.
  • Export – Download the table to CSV.

✅ BEST PRACTICE: Verify every domain and resolver IP against your internal DNS records before activating the bypass — an incorrect entry can divert sensitive lookups to unintended resolvers.

2.4 Dynamic DNS

Where to find it: Sidebar → DNS Firewall → Setup → DDNS Names

Dynamic DNS lets you register dynamic DNS hostnames — typically remote sites, gateways, or services with a changing public IP — so DNS Armor™ keeps their IP mappings up to date as they change.

2.4.1 What You See on the Page

The page opens with two charts that summarize record health (status distribution and update activity over time), followed by a table with one row per DDNS record:

  • Hostname – The dynamic DNS name
  • IP Address – Most recent IP reported for the hostname
  • Status – Active, Failed, Pending, or Disabled
  • Last Update – Time of the most recent successful update
  • Test Result – Result of the most recent connectivity check

2.4.1.1 Views and Access

  • Master Tenant view: Manage DDNS records for any tenant the account is authorized for
  • Normal Tenant view: Manage only records belonging to the assigned tenant
  • RBAC: The DDNSName service governs the page. Admin users can create, edit, test, and delete; Read-Only users can view only

Filtering and search run server-side across all records in scope.

  • Search DDNS names – Free-text search across hostname (press Enter)
  • Status – Filter by Active, Failed, Pending, or Disabled
  • IP Version – IPv4 / IPv6
  • Customer / Reseller – Entity picker (platform administrators)
  • Tenant – Entity picker

2.4.2 Add a DDNS Record

  1. Open Sidebar → DNS Firewall → Setup → DDNS Names.
  2. Click Add DDNS Name.
  3. Complete the modal:
    • Customer – Required (Root and App Root users)
    • Tenant – Required
    • Description – Optional
    • Hostnames – Required; one or more FQDNs separated by comma, semicolon, newline, or tab. Each entry is validated against the FQDN pattern and shown as a chip; invalid entries are highlighted
  4. Click Save. Successful entries appear in the table with status Pending until verified; failed entries are listed with their rejection reason.

2.4.3 Bulk Import Records

  1. Click Import on the page toolbar.
  2. Upload a CSV file with one hostname per row.
  3. Review the validation summary; rows with errors are flagged and skipped.
  4. Click Confirm to register the valid rows.

2.4.4 Manage an Existing Record

  • Edit – Change the hostname or IP.
  • Delete – Remove the record after the confirmation prompt. A DDNS name that is still used by one or more Security Policies cannot be deleted — the error names the policies; remove it from them first.
  • Test – Trigger an immediate connectivity check to confirm the hostname resolves to the expected IP.
  • Pause / Resume – Temporarily stop automatic IP refreshes without deleting the record.
  • Export – Download the table to CSV.

3. Security Policy Management

Security policies provide comprehensive control over DNS filtering rules, schedules, and network mappings.

3.1 Local Rulesets

Where to find it: Sidebar → DNS Firewall → Security → Rulesets

Rulesets are local Response Policy Zones (RPZ) that act as Access Control Lists — letting you allow-list or block-list specific domains, IP addresses, or PTR records. Rules defined here take precedence over standard DNS responses and are referenced by Security Policies for enforcement.

3.1.0 Views and Access

  • Master Tenant view: Manage rulesets for any tenant the account is authorized for
  • Normal Tenant view: Manage only rulesets belonging to the assigned tenant
  • RBAC: The LocalRuleset service governs the page. Admin users can create, edit, enable/disable, and delete; Read-Only users can view only

Filtering and search run server-side across all rulesets in scope.

  • Search rulesets – Free-text search across ruleset name (press Enter)
  • Type – Standard / Exclusive Allowlist
  • Customer / Reseller – Entity picker (platform administrators)
  • Tenant – Entity picker

ℹ️ NOTE: A ruleset cannot be deleted while it is associated with a Security Policy or in use by a Local Resolver — the error identifies where it is used; remove those references first.

3.1.1 Creating Local Rulesets

3.1.1.1 Basic Configuration

To create a new local ruleset, administrators must first select the customer and tenant information. Only active tenants will appear in the tenant selection dropdown.

3.1.1.2 Ruleset Configuration

Each local ruleset consists of the following components:

Ruleset Details
  • Ruleset Name: A descriptive identifier for the ruleset
  • Customer & Tenant Association: Links the ruleset to specific organizational units

3.1.2 Rule Types

Local rulesets support three distinct rule types, each serving different filtering purposes:

3.1.2.1 Domain Match Rule
3.1.2.2 IP Match Rule
  • Purpose: Matches IP addresses in DNS A/AAAA responses
  • Supported Formats:
    • IPv4: 11.12.55.0/24
    • IPv6: 2001:0db8:0000:0000:0000:0000:0000:6666/128
  • Note: Only classful subnet notation is supported for both IPv4 and IPv6
  • Examples: 192.168.1.0/24, 10.0.0.0/8, 172.16.0.0/16
3.1.2.3 PTR (Reverse DNS) Match Rule
  • Purpose: Matches DNS PTR type resolution requests
  • Supported Formats:
    • IPv4: 11.12.55.99
    • IPv6: 2001:0db8:0000:0000:0000:0000:0000:6666
  • Examples: 192.168.1.1, 8.8.8.8, 2001:0db8::1

3.1.3 Rule Actions

3.1.3.1 Available Actions

Each rule can be configured with one of the following actions:

1. NXDOMAIN (Block)
  • Returns NXDOMAIN DNS response code to matched queries
  • Indicates the domain does not exist
2. NODATA
  • Returns an empty response to matched queries
  • Query receives no data in response
3. PASSTHRU (Allow)
  • Allows matched queries to be resolved normally
  • Bypasses other filtering mechanisms
4. REDIRECT
  • Returns DNS CNAME response to matched queries
  • Redirects traffic to specified domain
  • Note: Only domain redirection is supported
3.1.3.2 Rule Processing Logic
  • Priority Order: Rules are processed using a "first match, first action" approach, similar to traditional ACL processing
  • Multiple Rules: A single ruleset can contain multiple rules with different types and actions
  • Precedence: Rules are evaluated in the order they are configured
  • Whitelisting Strategy: To whitelist domains blocked by RPZ or web filter feeds, create a local ruleset with PASSTHRU action and ensure it has higher precedence than blocking rules

3.2 Security Policies

Where to find it: Sidebar → DNS Firewall → Security → Cloud Policies

The Security Policies page (menu item Cloud Policies) is the central place to define how DNS requests are filtered for each tenant and network segment. A policy combines a network mapping, a schedule, and a set of security rules drawn from Rulesets, Automated Feeds, and built-in threat or web-filter categories.

3.2.0 Views and Access

  • Master Tenant view: Manage policies for any tenant the account is authorized for
  • Normal Tenant view: Manage only policies belonging to the assigned tenant
  • RBAC: The SecurityPolicy service governs the page. Admin users can create, edit, enable/disable, and delete; Read-Only users can view only

Filtering and search run server-side across all policies in scope.

  • Search policies – Free-text search across policy name (press Enter)
  • Status – Enabled / Disabled
  • Activation – Time-based / Always active
  • Sharing – Shared / Not shared
  • Customer / Reseller – Entity picker (platform administrators)
  • Tenant – Entity picker
  • Calendar view toggle – Switch between Tabular and Calendar layouts to see policy effectiveness over time

3.2.1 Policy Management Views

3.2.1.1 Tabular View

The default tabular view provides a comprehensive overview of all configured security policies, displaying:

  • Policy names and descriptions
  • Associated tenants and customers
  • Active status and schedule information
  • Rule counts and configuration summaries
3.2.1.2 Calendar View

The calendar view offers a time-based perspective of policy schedules, enabling administrators to:

  • Visualize policy activation periods
  • Identify scheduling conflicts
  • Plan policy changes around business requirements
  • Monitor time-based policy effectiveness

3.2.2 Policy Creation Process

3.2.2.1 Step 1: Tenant Information

Only active tenants are available for policy association

3.2.2.2 Step 2: Basic Settings
Policy Identification
  • Policy Name: Descriptive identifier for the security policy
Time-Based Activation (Optional)

When enabled, provides scheduled policy enforcement:

Schedule Configuration:
  • Start/End Dates: Define the overall policy validity period
  • Start/End Times: Specify daily activation windows
  • Active Days: Select specific days of the week for policy enforcement
    • Individual day selection (Monday through Sunday)
    • "Everyday" option for continuous enforcement
Important Notes:
  • Time-based activation is optional
  • Without time restrictions, policies remain active continuously
  • Schedule conflicts should be avoided to prevent overlapping policies action
3.2.2.3 Step 3: Network Mapping

Network mapping enables differentiated security policies across various network segments, providing granular control over DNS filtering behavior.

External Network Selection
  • Purpose: Identifies the public source IP ranges for DNS requests
  • Routing Control: Ensures proper request attribution and policy application
Private Network Selection
  • Purpose: Defines internal subnet ranges subject to policy enforcement
  • Granular Control: Enables different policies for different internal network segments
Endpoints Selection

Allows associating available endpoints with the security policy. Only enabled endpoints will be visible in the dropdown list.

3.2.2.4 Step 4: Security Rules
Rule Categories

RPZ Feeds (Threat Intelligence)

  • Pre-configured threat intelligence feeds
  • Automated updates from security vendors
  • Category-based threat blocking (malware, phishing, etc.)

Local Rulesets

  • Custom administrator-defined rules
  • Organization-specific blocking/allowing policies
  • Override capabilities for automated feeds

Applications

  • Application-specific filtering rules
  • Productivity and security-focused blocking
  • Category-based application control

Web Filters

  • Content category filtering
  • Industry-standard web filtering categories
Rule Priority Management

Processing Logic:

  • First Match Principle: Rules are processed in priority order with first match determining action
  • ACL-Style Processing: Similar to traditional Access Control List evaluation

Whitelisting Strategy: To whitelist domains blocked by RPZ or web filter feeds:

  1. Create a local ruleset with PASSTHRU action
  2. Configure the whitelist rule with higher precedence than blocking rules
  3. Ensure proper rule ordering in the priority list

Priority Order Management:

  • Drag-and-drop interface for rule reordering
  • Visual indicators showing rule precedence
Available Actions

Default Action

NXDOMAIN

  • Returns NXDOMAIN DNS response code
  • Indicates domain does not exist

NODATA

  • Returns empty DNS response
  • Query receives no data

No Response

  • Ignores the query completely
  • No DNS response sent to client

PASS-THRU

  • Allows normal DNS resolution
  • Bypasses all filtering mechanisms

REDIRECT

  • Domain redirection only (IP redirection not supported)
  • Redirects to specified alternate domain

3.2.3 Policy Operations

3.2.3.1 Edit Policy
  • Follows the same multi-step process as creation
  • Allows modification of all policy components
3.2.3.2 Delete Policy
  • Complete policy removal from the system
  • Requires confirmation to prevent accidental deletion
  • May require dependency resolution if policy is actively referenced
3.2.3.3 View Policy Details

Comprehensive policy information accessible via the eye icon includes:

  • Complete rule configuration
  • Network mapping details
  • Schedule and activation status

3.2.4 Best Practices

  1. Policy Naming: Use descriptive names reflecting policy purpose and scope
  2. Rule Organization: Group related rules within logical categories
  3. Testing: Validate policies in test environments before production deployment
  4. Documentation: Maintain detailed records of policy purposes and changes
  5. Regular Review: Periodically audit policies for continued effectiveness and relevance
  6. Conflict Resolution: Monitor for scheduling and rule conflicts across policies
Policy Type Schedule Use Case
Business Hours Mon-Fri 8AM-6PM Relaxed filtering during work hours
After Hours Mon-Fri 6PM-8AM, Weekends Strict filtering when IT is unavailable
Maintenance Window Sun 2AM-6AM Allow all for updates
School Hours Mon-Fri 7AM-3PM Educational content only

3.3 Automated Feeds

Where to find it: Sidebar → DNS Firewall → Security → Automated Feeds

The Automated Feeds page is the single location for managing all feed-based intelligence used by your security policies. From this page you can review the platform's built-in feed categories and register your own External RPZ Feeds.

3.3.1 Built-in Feed Categories

The page is organised into category cards, each showing its group and feed counts:

  • Web Filters – URL categorization and content-filtering datasets
  • Geo Filtering – Country/region-based filtering feeds
  • Apps – Application-specific filtering rules, browsable by category
  • Threats – Real-time security threat data streams (the AI tunneling-detection feed is part of this intelligence — see §3.3.3)
  • External RPZ – Your own RPZ zones brought into the platform (§3.3.2)

To use a built-in feed, open Sidebar → DNS Firewall → Security → Cloud Policies, edit (or create) a policy, and add the feed in the security rules step.

3.3.2 External RPZ Feeds

External RPZ Feeds let you bring your own threat intelligence — for example commercial RPZ providers, ISAC feeds, or internally curated zones — into DNS Armor™ so they can be referenced in Security Policies alongside the built-in feeds. The External RPZ card opens two panels: Name Server Groups (the upstream servers that host your RPZ zones) and External RPZ Feeds (the zones themselves).

3.3.2.1 What You See on the Page

The Name Server Groups panel lists each group with its customer and tenant, its servers (IP:port), a TSIG indicator when TSIG authentication is enabled, and how many feeds use it (Used by N feeds); its quick filters are With TSIG / No TSIG and In Use / Not Used. The External RPZ Feeds panel lists each feed with its RPZ feed name, customer and tenant, its NameServer Group (first server IP:port, plus a TSIG indicator when the group uses TSIG), zone-file state (Zone File Ready / No Zone File) with the zone file size, and actions to download the zone file or refresh zone statistics; its quick filters are With Zone File / No Zone File. Each panel has its own search box (Search groups... / Search feeds...).

3.3.2.2 Add an External RPZ Feed
  1. From Sidebar → DNS Firewall → Security → Automated Feeds, open the External RPZ card.
  2. If needed, click Create Group to define a NameServer Group first:
    • Customer / Tenant – Required (Customer is shown to Root and App Root users)
    • Group Name – Required
    • Primary Name Servers (1-10) – Server N IP and Port per entry; click Add Server for more (up to 10)
    • Enable TSIG Authentication – Optional; supply TSIG Key Name, TSIG Algorithm, and TSIG Secret
    • Clone from Existing Group – Optionally copy the technical settings of another group
  3. Click Create Feed and complete the Create External RPZ Feed modal:
    • Customer – Required (Root and App Root users)
    • Tenant – Required
    • RPZ Feed Name – Required; the name of the RPZ zone to transfer from the upstream servers
    • NameServer Group – Required; the group that hosts the zone. Create New NameServer Group jumps to the group modal
  4. Click Create. The feed appears in the External RPZ Feeds panel and its zone file is transferred from the upstream servers.
  5. Reference the feed in a policy (Sidebar → DNS Firewall → Security → Cloud Policies) so it is enforced for the targeted networks.
3.3.2.2.1 Views, Filters, and Access
  • Master Tenant view: Manage feeds for any tenant the account is authorized for
  • Normal Tenant view: Manage only feeds belonging to the assigned tenant
  • RBAC: The RemoteRPZFeeds service controls the menu entry; the ExternalRPZ and NameServerGroup services govern feed and group operations. Admin users can create, edit, and delete; Read-Only users can view only and trigger no destructive actions
3.3.2.3 Manage an Existing Feed
  • Edit – Update the RPZ feed name or NameServer Group (customer and tenant are fixed).
  • Delete – Remove the feed after the confirmation prompt. Feeds that are still referenced by a policy must be removed from the policy first.
  • Download Zone File – Save the most recently transferred zone data.
  • Refresh Zone Stats – Re-read entry counts and transfer state for the feed.

ℹ️ NOTE: A NameServer Group cannot be deleted while any External RPZ Feed still depends on it — the dialog lists the dependent feeds. Remove or reassign them first.

3.3.3 RPZ Zone Master Configuration

Each feed is assigned a unique name that serves as the RPZ zone master identifier. These zone master names follow standardized formats and are critical for external system integration, enabling secondary DNS servers to locate and retrieve specific feed data.

3.3.3.1 Zone Naming Formats

Web Filtering Feeds: Securedomains.Web-Filtering.

Examples: Securedomains.Web-Filtering.Adult, Securedomains.Web-Filtering.Gambling

Threat Feeds: Securedomains.Threats.

Examples: Securedomains.Threats.Malware, Securedomains.Threats.Phishing

Application Feeds:

Examples: FACEBOOK, TIKTOK, YOUTUBE

AI Detection: Securedomains.AI.Tunneling

Note: This feed must be selected in your security policy to enable AI-based tunneling detection.

3.3.3.2 Integration Example

Sample Bind Configuration for External Secondary Server:

# RPZ Cloud Server IP: 203.0.113.50
# Configure AXFR transfers for multiple feeds

zone "Securedomains.Web-Filtering.Social" {
    type slave;
    masters { 203.0.113.50; };
    file "rpz-social.db";
};

zone "Securedomains.Threats.Botnet" {
    type slave;
    masters { 203.0.113.50; };
    file "rpz-botnet.db";
};

zone "NETFLIX" {
    type slave;
    masters { 203.0.113.50; };
    file "rpz-netflix.db";
};

4. Monitoring and Analytics

The Monitoring menu provides every reporting and analytics surface in the portal. Sections §4.1 through §4.4 cover the main DNS Monitor page (Sidebar → DNS Firewall → Monitoring → DNS Monitor), which is where you investigate individual queries, drill into firewall events, and export raw data. Sections §4.5 through §4.9 cover the rollup dashboards and specialized tools — Daily DNS Analytics, AI Threat Detection, Discovery Analytics, Domain Lookup, and Endpoints — each reachable from its own item in the Monitoring menu. The menu also contains DNS Statistics (an aggregate query-statistics dashboard complementing the daily rollups) and Domain Intelligence (a research tool visible to platform administrators only).

4.1 Filter Configuration

Where to find it: Sidebar → DNS Firewall → Monitoring → DNS Monitor (click Select Filters — Update Filters once a tenant is selected — to launch the filter modal)

The Filter modal scopes every chart, table, and export on the DNS Monitor page. Configure it before reviewing data so the result set matches the tenants, time window, and other criteria you care about.

4.1.0 Views and Access

  • Master Tenant view: Pick any authorized tenant (the Tenant picker is single-select)
  • Normal Tenant view: Restricted to the assigned tenant
  • RBAC: The Dns service governs DNS Monitor. Read-Only users can view and export; destructive actions are not exposed on this page

4.1.0.1 Filter Modal Fields

The Filter DNS Statistics dialog is grouped into five blocks:

  • Scope Configuration – Customer picker (platform administrators only) and a single-select Tenant picker
  • Time Window – Time Range quick-select presets (15 min, 30 min, 1 hour, 6 hours, 12 hours, 1 day, 2 days, 3 days; default 1 hour) or a Custom Range with From Date/Time and To Date/Time (maximum 72 hours), plus a Timezone selector (defaults to the browser's timezone)
  • Data Settings – Data Source (All Sources = cloud + on-premise, the default; Cloud Only; or On-Premise Only), Fetch Limit (default 100K; see §4.1.2.1), and — when On-Premise Only is selected — a Local Resolvers multi-select (default All Local Resolvers)
  • IP Filter (titled Source IP Filters on MSP private-cloud deployments) – Optional Source IPs and Internal IPs (IPv4 or IPv6 addresses)
  • Endpoints & Firewall Mode (Endpoint Agents & Firewall Mode on MSP private-cloud deployments) – Optional endpoint multi-select and Firewall Mode: All (default), Blocking, or Monitoring

Click Apply Filters to load data. Results appear on two tabs, DNS Firewall and DNS Query (tables DNS Firewall Events and DNS Query Events) — the tab, not a filter field, switches between firewall events and DNS queries. The page additionally provides a server-side search box that supports AND, OR, !, and grouping with parentheses, an Export All CSV button (exports the active tab), and a per-table Export current table data to CSV icon (see §4.4).

4.1.1 Tenant Selection

  • Active Tenants Only: Filter dropdown displays only activated tenants
  • Multi-tenant Support: Access controls ensure users see only authorized tenant data
  • Scope Control: Determines the data scope for all subsequent filtering and analysis

4.1.2 Data Volume Management

4.1.2.1 Data Fetch Limits

The system provides configurable limits to balance performance with data completeness:

Available Options:
  • 100K records: Suitable for quick analysis and real-time monitoring
  • 500K records: Balanced option for moderate traffic volumes
  • 1M records: Comprehensive analysis for high-traffic environments
  • 1.5M records: Extended analysis for detailed investigations
  • 2M records: Large-scale traffic analysis
  • 2.5M records: Comprehensive historical analysis
  • 3M records: Maximum data volume for extensive investigations
4.1.2.2 Performance Considerations
  • Browser Performance: Higher limits may impact browser responsiveness
  • Load Time: Larger datasets require longer initial loading times
  • Memory Usage: Consider client system capabilities when selecting limits
4.1.2.3 Progressive Data Loading
  • Automatic Loading: Initial dataset loads based on configured limit
  • Load More Functionality: Additional data can be retrieved incrementally
  • Real-time Updates: New events appear automatically within the selected timeframe

4.1.3 Timezone Configuration

4.1.3.1 Timezone Detection
  • Local Timezone: System automatically detects and applies local timezone settings
  • Display Consistency: All timestamps reflect the selected timezone
  • Query Alignment: Time range selections use the configured timezone
4.1.3.2 Timezone Selection
  • Global Timezone Options: Support for international operations
  • Business Hours Alignment: Configure timezone to match business operations
  • Multi-location Support: Consistent time reference across geographically distributed teams

4.1.4 Time Range Selection

Search queries are restricted to a 72-hour window to ensure browser stability. DNS and firewall logs can contain millions of entries, which would overwhelm browser memory and processing capabilities if larger time spans were allowed.

Selection Options
  • Preset Ranges: Common time periods (last hour, 24 hours, etc.)
  • Custom Ranges: Flexible start and end time selection
  • Business Context: Align monitoring periods with operational requirements

4.2 Monitoring Dashboard

Where to find it: Sidebar → DNS Firewall → Monitoring → DNS Monitor (charts at the top of the page)

The Monitoring Dashboard is the chart strip at the top of the DNS Monitor page. It visualizes the queries and events selected by your filters so you can spot trends and anomalies before drilling into individual events.

4.2.1 DNS Activity Timeline

Real-time graphical representation of DNS query volume and patterns:

  • Traffic Visualization: Trend analysis over selected time periods
  • Peak Identification: Highlight unusual traffic spikes or patterns
  • Baseline Establishment: Historical context for current activity levels

4.2.2 Key Metrics Display

4.2.2.1 DNS Events Summary
  • Total Query Count: Aggregate DNS requests processed
  • Firewall Events: Security policy enforcement statistics
  • Event Distribution: Breakdown by event types and categories
4.2.2.2 Traffic Analysis
  • Query Types: Distribution of DNS record types (A, AAAA, CNAME, etc.)
  • Response Codes: Analysis of DNS response patterns
  • Security Actions: Categorization of security policy enforcement actions

4.3 Event Details and Analysis

Where to find it: Sidebar → DNS Firewall → Monitoring → DNS Monitor (events table below the dashboard)

The Event Details table on the DNS Monitor page lists every individual DNS query that matches your active filters. Use it to investigate specific events, validate policy decisions, and gather context for incident response.

4.3.1 Event Details Table

4.3.1.1 Comprehensive Event Logging

Each DNS event record includes:

  • Timestamp: Precise timing of DNS query
  • Source Information: Client IP and network context
  • Query Details: Domain requested and query type
  • Policy Information: Applied security policy and rule
  • Action Applied: Specific enforcement action taken
  • Response Details: DNS response code and data
4.3.1.2 Event Categorization
  • DNS Firewall Events: Security policy enforcement actions
  • DNS Query Events: Standard resolution requests
  • Policy Matches: Rule-based filtering outcomes
  • Security Policies: Applied policy identification

4.4 Data Export Options

Where to find it: Sidebar → DNS Firewall → Monitoring → DNS Monitor (export controls in the toolbar)

The DNS Monitor page offers two export modes for offline analysis and compliance reporting. Choose the mode that matches the size and scope of the dataset you need.

4.4.1 Complete Dataset Export (Export All CSV)

The complete dataset export feature enables users to export all events within the selected time range, providing comprehensive data that includes all available event attributes. This functionality supports extensive log exports for analysis, with robust large file handling capabilities to accommodate high-volume datasets. The export utilizes standard CSV format, ensuring compatibility with external analysis tools and allowing seamless integration into existing data processing workflows.

4.4.2 Filtered Export (Table CSV Export)

Click the CSV export icon in the table section to export currently displayed browser data. This method works well for small to medium datasets but is constrained by browser memory limitations. For large-scale exports, use the Complete Dataset Export (section 4.4.1) which bypasses browser restrictions and handles extensive datasets more efficiently. Browser resource usage and processing time increase with dataset size, potentially causing performance degradation or export failures when attempting large exports through the table interface.

4.5 Daily DNS Analytics

Where to find it: Sidebar → DNS Firewall → Monitoring → Daily DNS Analytics

Daily DNS Analytics is the daily-rollup dashboard for DNS activity. It summarizes query volume, threats blocked, web-filter hits, and identified applications across the tenants you have access to, so you can see day-over-day trends at a glance.

4.5.1 What You See on the Page

The page opens with executive KPI cards followed by charts:

  • Total DNS Queries – All tenant queries in the selected period
  • DNS Firewall Hits – Security blocks recorded
  • Match Rate – Threat detection rate (blocked as a share of total)
  • Security Posture – Overall health rating (Excellent / Moderate concerns / High risk)

Below the cards, the page shows a Tenant Activity panel ranking tenants By DNS Queries and By Firewall Matches (not shown to self-signed accounts), a Daily DNS Stat Trends chart where you can compare up to five sources (or view all sources aggregated) by queries, blocked count, or block-rate percentage, DNS Activity Trends and Source Distribution charts, and a Tenant Security Overview of per-tenant cards (DNS Queries, FW Hits, Block Rate, Security Health).

4.5.2 Views and Access

  • Master Tenant view: Aggregated metrics across every authorized tenant
  • Normal Tenant view: Restricted to the assigned tenant
  • RBAC: The DnsDailyStats service governs the page. Read-Only users can view and export

4.5.3 Filters and Controls

  • Date Range – From / To dates, maximum 90 days; presets Last 7, 14, 30, 60, and 90 days (default: last 7 days)
  • Tenant Filter – Optional multi-select of up to 10 tenants; leave empty for all
  • Refresh – Re-fetch the dashboard
  • Export – Download the current dataset

4.5.4 View Details Modal

Selecting a tenant card opens a detail modal with a security-health rating and three tabs:

  • Security Overview – Security Metrics cards (DNS Queries, FW Hits, Threats, Web Filter, Apps, Local Rules)
  • Timeline Analysis – DNS Activity Overview and Threat Category Breakdown charts, plus a Daily Breakdown table (date, queries, blocked, threats, block rate)
  • Network Intelligence – Daily Network Activity table (date, queries, blocked, DNS FW IPs, Query IPs); click a date to list the DNS Firewall IPs and DNS Query IPs observed

4.5.5 How to Use It

  1. Open Sidebar → DNS Firewall → Monitoring → Daily DNS Analytics.
  2. Use the Filters dialog to set the date range and (optionally) select tenants.
  3. Click any tenant card in the Tenant Security Overview to open the per-tenant detail modal.
  4. Click Refresh to pull the latest data, or Export to download the filtered dataset.

4.6 AI Threat Detection

Where to find it: Sidebar → DNS Firewall → Monitoring → AI Threat Detection

AI Threat Detection lists DNS queries that the platform's machine-learning models flagged as suspicious — most commonly DNS tunneling and exfiltration attempts. Use it to review what the models are catching across your tenants and to clear entries you have investigated.

4.6.1 What You See on the Page

Summary cards at the top show AI Detections (total, with a last-24-hours count), Source Distribution, Affected Domains (unique domains), Customer Distribution, and Tenant Distribution — the filter icon on the source, domain, customer, and tenant cards narrows the table to one value. The table below has one row per detection with the following columns:

  • Customer / Reseller and Tenant – Where the detection originated
  • Type – Detection classification
  • Domain – The domain that triggered the detection
  • Detection Time – When the detection fired
  • Source – The detection source
  • Last Update – Most recent update to the record

Charts summarize the Source Distribution and Detection Type Distribution for the current view.

4.6.2 Views and Access

  • Master Tenant view: See detections across every authorized tenant
  • Normal Tenant view: Restricted to the assigned tenant
  • RBAC: The DnsTunnelling service governs the page. Admin users can delete detections; Read-Only users can view and export

4.6.3 Filters and Controls

  • Search in all columns... – Free-text search across customer, tenant, domain, type, and source
  • Table filters – The filter icon in the search box shows Customer, Tenant, Domain, Type, and Source dropdowns
  • Card filters – Filter by detection source, by specific domain, by customer, or by tenant directly from the summary cards
  • Auto-Refresh – Toolbar toggle with a configurable interval (30 seconds to 10 minutes); supports pause/resume
  • Refresh – Manual re-fetch

4.6.4 How to Use It

  1. Open Sidebar → DNS Firewall → Monitoring → AI Threat Detection.
  2. Apply the card filters or search to narrow the table.
  3. Investigate flagged domains — the DNS Monitor page (§4.1) gives the full query context for the same time window, and Domain Lookup (§4.8) shows the domain's classification.
  4. Select one or more rows and click Delete in the selection bar to clear stale or known-good detections, then confirm in the Confirm Bulk Delete dialog (this cannot be undone). Detections have no per-row actions or approval workflow.
  5. Click Export to CSV to download the current view.

4.7 Discovery Analytics

Where to find it: Sidebar → DNS Firewall → Monitoring → Discovery Analytics

Discovery Analytics summarizes the apps, web-filter categories, threats, and geo locations discovered from DNS Firewall traffic across your environment. Use it to spot shadow IT, confirm that web-filter coverage matches your needs, and see where traffic is going geographically.

4.7.1 What You See on the Page

The page opens with an Overview of cross-category insights — Total Discoveries (with total hits), Apps Discovered, Web Filters, Threats Detected, Countries Detected, Threat Ratio, and Active Tenants — followed by four category tabs:

  • Apps – Discovered applications, grouped by app category
  • Web Filters – Discovered web-filter category hits
  • Threats – Discovered threat-feed matches
  • Geo Locations – Countries observed in resolved traffic

Each tab shows KPI cards (total hits, unique items, top item / top country), charts (Top 5 Distribution — Top 5 Countries on the Geo Locations tab — and Daily Trend, plus App Categories on the Apps tab and an interactive map on the Geo Locations tab), and a searchable list of every discovered item. Clicking a list item (or a country on the map) opens an Item Trend Analysis modal (daily trend and per-tenant/source distribution); the magnifier icon (View top domains) opens a Domain Breakdown modal listing the domains behind the item. When more than one tenant is in scope, the Overview also shows a Top Tenants section ranking tenants by apps, filters, threats, and geo hits.

4.7.2 Views and Access

  • Master Tenant view: See discoveries across every authorized tenant
  • Normal Tenant view: Restricted to the assigned tenant
  • RBAC: The DnsDailyStats service governs the page (shared with Daily DNS Analytics — §4.5). Read-Only users can view and export

4.7.3 Filters and Controls

  • Filter dialog – Filter Discovery Data: Date Range (presets Last 7–90 days, maximum 90 days, default last 7 days), Tenant Selection (up to 10 tenants; leave empty for all), Source Filter, and Top Tenants Display (Top 10 / Top 100 / Top 1000)
  • Search – Per-list search boxes for countries, apps, web filters, and threats
  • Refresh – Re-fetch the discovery data
  • Export – Export to CSV on each item list, Export Categories to CSV for the App Categories list on the Apps tab, and Export CSV in the Domain Breakdown modal

4.7.4 How to Use It

  1. Open Sidebar → DNS Firewall → Monitoring → Discovery Analytics.
  2. Set the date range and tenant scope in the Filter dialog.
  3. Start on the Overview, then switch to the Apps, Web Filters, Threats, or Geo Locations tab to drill into a category.
  4. Use the per-list search to locate a specific app, category, threat, or country, and review Top Tenants to see who generated the traffic.
  5. Click Export to CSV on a list to download the filtered items.

4.8 Domain Lookup

Where to find it: Sidebar → DNS Firewall → Monitoring → Domain Lookup

Domain Lookup is an on-demand query tool. Enter any domain or IP address and the platform returns which of your configured rules and feeds it matches, its WHOIS registration data, and the security policies and Local Resolvers it is associated with — useful for incident triage, ticket attachments, and customer enquiries.

4.8.1 What You See on the Page

After running a lookup the Search Results header shows the match count, response time, and the query (an A-record lookup) with a copy icon, followed by:

  • Zone Matches – The zones/rules the query matches (typed as Threat Feed, Web-Filtering Feed, or App/Service), flagged as an exact match or a wildcard pattern match
  • WHOIS Information – Registrar, creation date, last updated, expiration date, and name servers
  • Associated Policies & Resolvers – The Security Policies that would act on the name (including the first-match rule), the Local Resolvers involved, and the networks with matches

4.8.2 How to Use It

  1. Open Sidebar → DNS Firewall → Monitoring → Domain Lookup.
  2. Enter a domain or IP address (for example example.com) and click Lookup.
  3. Review the Zone Matches to see which rule or feed entry matches and whether the match is exact or wildcard.
  4. Check Associated Policies & Resolvers to confirm which Security Policy would act on the name and on which networks.

4.9 Endpoints

Where to find it: Sidebar → DNS Firewall → Monitoring → Endpoints

The Endpoints page lists every device that has the DNS Armor™ Endpoint Agent installed. Use it to confirm an agent is online, review each device's identity, network, and location details, and enable or disable protection (Admin Status) on individual devices or in bulk.

4.9.1 What You See on the Page

The page opens with a Geographic Intelligence map of endpoint distribution (City View / Country View, By Continent, with Top Countries, Top Cities, and Top Regions). Summary cards then show total endpoints, connection-status breakdown (online vs offline), admin-status split (enabled vs disabled), customer/tenant distribution, and endpoint version and OS breakdowns; the status, admin-status, and version entries double as quick filters. The table below has one row per endpoint:

  • Customer / Reseller and Tenant – Ownership (hidden for self-signed accounts)
  • Public IP / Private IP – Last reported addresses
  • Mac Address – Device hardware address
  • Identity – Hostname or device identifier
  • Admin Status – Enabled or Disabled (whether protection is administratively on)
  • Status – Online, Offline, Connected-Enabled, Connected-Disabled, Disconnected, or Requires Update
  • Type – Endpoint type reported by the agent (summarized in the Endpoint Versions card)
  • Last Seen – Time of the last heartbeat

4.9.2 Endpoint Status Meanings

Status What It Means
Online The agent is running and reporting heartbeats.
Offline No recent heartbeat — the agent or device is unreachable.
Connected-Enabled The agent is online and protection is enabled.
Connected-Disabled The agent is online but protection has been paused by an administrator.
Disconnected The agent has dropped its connection to the cloud.
Requires Update The installed agent version is out of date and should be upgraded.

4.9.3 Views and Access

  • Master Tenant view: See endpoints across every authorized tenant
  • Normal Tenant view: Restricted to the assigned tenant
  • RBAC: The Endpoint service governs the page. Admin users can enable or disable Admin Status and delete endpoints; Read-Only users can view and export

4.9.4 Filters and Controls

Filtering and search run server-side across the full endpoint inventory.

  • Search endpoints – Free-text search across customers, tenants, and endpoints (press Enter; at least 3 characters) — matches IP address, MAC address, serial number, identity, and (for platform and master-tenant administrators) customer/tenant names
  • Status – Connected-Enabled, Connected-Disabled, Online, Offline
  • Admin Status – Enabled, Disabled
  • Type – Endpoint type
  • Customer / Reseller – Entity picker (platform administrators)
  • Tenant – Entity picker
  • Auto-Refresh – Toolbar toggle with a configurable interval; supports pause/resume

4.9.5 Endpoint Detail Modal

Selecting an endpoint opens an Endpoint Details modal containing:

  • Customer & Tenant Information – Ownership context
  • Network Information – Current Public IP, Private IP, and MAC Address, plus a Network History block with the Historic IPs list of previous addresses
  • Endpoint Identity – Device name, domain, source, and OS, with System Information (Hostname, Architecture, Serial Number)
  • Additional Information – Endpoint type
  • Status Information – Admin Status, Status, First Seen, and Last Seen
  • Location Information – Country, region, city, and coordinates derived from the public IP
  • Actions – Close, Enable Admin Status / Disable Admin Status, and Delete

4.9.6 How to Use It

  1. Open Sidebar → DNS Firewall → Monitoring → Endpoints.
  2. Use the filters above to find specific endpoints.
  3. Click an endpoint row to open the detail modal.
  4. Use the Enable / Disable Admin Status action on a row to pause or resume protection for that device.
  5. Select multiple endpoints and use the bulk actions to enable, disable, or delete many at once. An endpoint that is associated with a Security Policy cannot be deleted until it is removed from the policy.
  6. Click Refresh (or enable auto-refresh) to pull the latest heartbeat data, or the Export to CSV icon to download the inventory.