Resolve Guide

Hosting authoritative DNS on DNS Armor™ Resolve: zones and records, DNSSEC and key rollover, smart routing and failover, query ACLs, TSIG, zone transfers, and statistics.

Comprehensive Guide for Hosting, Signing, and Steering Authoritative DNS Zones with DNS Armor™ Resolve

1. Introduction#

DNS Armor™ Resolve (Authoritative DNS) is the authoritative-DNS product delivered through the DNS Armor cloud portal, alongside DNS Armor™ Protect (DNS Firewall). Where Protect secures the recursive queries your users make, Resolve publishes the authoritative answers for domains you own — the A, AAAA, MX, TXT, and other records the rest of the internet looks up to reach your services. The same portal, tenants, roles, and API codes you already use for Protect manage Resolve, so there is no separate console to learn. In the portal sidebar the product appears as the Authoritative DNS menu block.

1.1 What Resolve Provides#

• Zone hosting — create and manage primary zones, or mirror existing zones as secondaries (AXFR-in), through the portal or the programmatic API.
• Platform-managed NS and SOA — nameserver records, glue, and the SOA are generated and maintained by the platform, so delegation data can never drift out of step with the serving fleet.
• DNSSEC — signing driven by reusable per-tenant DNSSEC Profiles, with fully automatic key rollover, downloadable DS records, and proactive rollover and parent-DS email reminders.
• Smart Routing — unified traffic steering per record: geographic segments, priority-group failover, optional health checks, and latency-based answer ordering in a single policy.
• Zone access and transfer control — Query ACLs (source-IP access), TSIG keys, and Transfer ACLs for authenticated zone transfer to external secondaries.
• Statistics and analytics — fleet-wide and per-zone query analytics with response-code, transport, query-type, and geographic breakdowns, exportable to CSV and Excel.

1.2 How It Differs from DNS Armor™ Protect (DNS Firewall)#

The two products are independent. A customer may hold one, the other, or both. Enabling Resolve never changes your Protect configuration.

1.3 Sovereign Zone Storage#

Your zone records never live inside the portal database. Each zone is stored as a standard zone file in your own tenant cloud storage (the same Azure or Huawei storage already used by your tenant), and the portal manages it by safely downloading, editing, and re-uploading the file under a per-zone lock. The portal database holds only metadata — the SOA settings and serial, DNSSEC profile and DS information, record and zone counts, your Smart Routing policies, and the definitions of your Query ACLs, TSIG keys, and Transfer ACLs. The DNSSEC signing keys themselves are kept as an encrypted key bundle alongside the zone file in your cloud storage. This keeps full ownership of your zone data with you and honours regional data residency.

1.4 Global, Resilient Serving#

Zones are served from DNS Armor's distributed authoritative network. New or changed zones propagate to every serving node automatically, with no per-node setup. Every serving node loads zones independently from the source of truth, so there is no single point of failure, and each node answers with location-aware and health-aware responses. You can serve a zone from all servers assigned to your account or pin it to specific servers (§3.4); the zone's NS records and glue always follow that assignment automatically. DNSSEC signing is consistent across the whole fleet — every node serves the same DNSKEY set — so a single DS record at your registrar validates answers from every node.

1.5 Prerequisites#

• An active DNS Armor tenant with the Auth DNS license assigned (§2.1).
• A role that grants access to the Authoritative DNS services — Admin, Read-only, DNS Zone Operator, or DNS Zone Reader (§2.2).
• Access to your domain registrar (for delegation and, if you enable DNSSEC, to publish the DS record).

2. Access, Licensing, and Roles#

2.1 The Auth DNS License#

DNS Armor™ Resolve (Authoritative DNS) is licensed separately from DNS Armor™ Protect (DNS Firewall). They are two independent licenses: a tenant may hold either one or both, and neither depends on the other — Resolve is not an extension of Protect. The Authoritative DNS block appears in the sidebar only for tenants that hold the Auth DNS license; tenants without it continue to see only their existing Protect menus, unchanged, just as a Resolve-only tenant sees no Protect menus. Licensing is assigned per customer and per tenant:

• Standard customers — the license is set on the customer and inherited by all of that customer's tenants.
• MSP / reseller customers — the reseller's master tenant inherits the license; each child tenant is assigned the license individually (a child tenant can only be granted services the reseller itself holds).

Role assignment is license-aware: when creating or editing a user, the role list only offers the DNS Zone roles if the target tenant actually holds the Auth DNS license, so a role can never be granted for a product the tenant cannot use. The same rule is enforced when the user is saved. Likewise, the Security Operator and Security Analyst roles require the DNS Firewall license, while License roles are product-independent.

Self-service accounts can purchase Resolve on its own or alongside Protect; both may appear on one invoice, which is a billing convenience rather than a dependency. Resolve is billed in blocks of zones and records that adjust automatically with usage — see the Self-Signup Guide for details.

If you expect to use Resolve but do not see the menu, ask your administrator or account team to confirm the license is assigned to your tenant, then sign out and back in.

2.2 Roles and RBAC Services#

Resolve adds two combinable roles to the role catalogue, in addition to the existing Admin and Read-only roles:

A user may hold up to three combinable roles — one Security role, one License role, and one DNS Zone role — so an operator can, for example, run security policies and manage zones without being a full Admin. DNS Zone Operator and DNS Zone Reader are mutually exclusive.

The Authoritative DNS pages are governed by four RBAC services: AuthZone (zones, records, profiles, ACLs, and keys), AuthDnssec (DNSSEC and DNSSEC Profiles), AuthGeoHealth (Smart Routing policies), and AuthDnsStats (statistics, read-only for everyone). If a button is greyed out, your role grants read but not write on that service; ask for DNS Zone Operator (or Admin) to gain write access.

2.3 Tenant Scoping#

Zone visibility follows the same scoping as the rest of the portal: Root and App Root users see all customers; an MSP master tenant sees all tenants within its customer; a normal tenant sees only its own zones. Super-users choose the customer and tenant from selectors on each Authoritative DNS page.

3. Zones#

Where to find it: Sidebar → Authoritative DNS → Zones

3.1 The Zones Page#

The Zones page lists every zone in the selected scope. Each row shows the zone name (secondary zones carry a Secondary chip), the owning customer and tenant (where your scope shows them), the record count, current SOA serial, DNSSEC state (a Signed chip or Off), and the zone status. The toolbar provides a zone search box, server-side filters for Status (Active, Disabled, PendingDelete), Zone type, and DNSSEC, a refresh button, and Create Zone. Filters and search run against the full dataset on the server, not just the rows currently displayed.

Where your plan or tenant carries zone and record allowances, usage chips at the top of the page show consumption against the limit (for example Zones: 3 / 10, and likewise for records), with a tooltip stating whether the allowance is pooled across the customer or set per tenant; creating zones or records beyond the allowance is refused with a clear error. Click any row to open the zone. A primary zone opens with four tabs — Records, DNSSEC, Smart Routing, and Zone Settings; a secondary zone shows Records, Transfer Status, and Zone Settings.

3.2 Creating a Zone#

Click Create Zone and complete:

• Zone name (required) — the apex domain, e.g. example.com. Names are normalised automatically (lower-cased, trailing dot removed) and must be globally unique.
• Zone type — Primary (the platform hosts and serves the zone you edit here) or Secondary (AXFR-in) (a read-only mirror of a zone hosted elsewhere, §3.5).
• Customer and Tenant — shown for super-users, MSP masters, and multi-tenant scopes.
• Configuration — Configure directly, or Use a profile to attach a Zone Profile (§3.6) that supplies the zone-wide settings. With a profile selected, the zone type follows the profile.
• Admin email (optional, primary zones) — the SOA contact; a default is used if left blank. When a profile is used, this comes from the profile.
• Authoritative servers — serve from All assigned servers (customer default) or Choose specific servers for this zone. The dialog previews the resulting nameservers and glue, and warns if fewer than two servers are selected. When a profile is used, server assignment comes from the profile.

On save, the portal creates the zone (reserving the unique name), writes the initial zone file to your cloud storage, and the zone begins serving from the authoritative network. Point your registrar's delegation (NS records and glue) at the nameservers shown for the zone to go live.

3.3 Platform-Managed NS and SOA#

Resolve manages the zone's structural records for you:

• NS records and glue are generated automatically from the zone's server assignment and appear in the Records tab marked Auto nameserver, read-only. To change them, change the server selection on the Zone Settings tab — you never edit them by hand. While no server is assigned yet, the zone carries a single placeholder NS record, ns1.<zone>, without glue, which is replaced by the real nameservers once servers are assigned. Additional custom NS records of your own (for example, delegations of child zones) can still be added and edited normally.
• The SOA is zone metadata, not a record row. There is no SOA line to edit (or corrupt) in the Records tab; the SOA primary nameserver is derived automatically as ns1.<zone>, and the timers and contact are edited on the Zone Settings tab (§3.4). The SOA serial is date-based (YYYYMMDDnn) and is bumped automatically on every change, always strictly greater than any previous serial, so you never manage serials by hand.
• Trailing dots are normalised consistently — zone and record names may be entered with or without a trailing dot, and the SOA nameserver and contact are always stored in absolute form, so names can never be accidentally doubled against the zone origin. Record names are also lower-cased, and a name equal to the zone apex is stored as @.

3.4 Zone Settings Tab#

Open a zone → Zone Settings. The tab groups three areas:

• SOA and TTL settings — SOA Serial (read-only), Primary NS, Admin email, and the Refresh, Retry, Expire, Minimum TTL, and Default TTL timers (all in seconds). Saving re-renders the zone file and bumps the SOA serial. For zones attached to a Zone Profile, the timers, default TTL, and admin email come from the profile and are read-only here; for secondary zones the SOA is mirrored from the primary and is read-only.
• Steering & access (primary zones) — switch the zone between Configure directly and Use a profile. In direct mode you pick the zone's Query ACL (Source IP access) (or Open (no ACL)), toggle Block non-matching sources (geo) (sources matched by no geo rule receive NODATA), and toggle Allow AXFR-out to external secondaries together with its AXFR-out allow-list (§7).
• Authoritative servers — choose All assigned servers (customer default) or Choose specific servers for this zone. The page previews the resulting nameservers with their glue addresses and, after a change, reminds you to update your registrar delegation and wait out the parent TTL before removing an old server. For profile-attached zones, server assignment is governed by the profile. On self-service plans, server assignment is managed by the platform.

3.5 Secondary Zones (AXFR-in)#

A secondary zone is a read-only mirror of a zone whose primary lives outside DNS Armor — useful for serving an existing zone from the Resolve network without migrating its management. Records arrive via AXFR and cannot be edited in the portal; DNSSEC and Smart Routing are managed by the primary and are not available on the mirror.

• Transfer source — configured directly (Primary servers, one per line as host or host@port; an optional TSIG key for authenticated transfer; and Serve expired data if the primary is unreachable) or supplied by a secondary-type Zone Profile. It is set at creation and edited later on the Zone Settings tab.
• Transfer Status tab — shows the per-edge transfer state reported by each authoritative server: last AXFR, current serial, and whether each edge is in sync, pending, or failed.

3.6 Zone Profiles#

Where to find it: Sidebar → Authoritative DNS → Zone Profiles

A Zone Profile bundles zone-wide options once so you can apply them to many zones at a time — editing a profile automatically re-applies it to every linked zone. Profiles are per-tenant, and a zone may only use a profile of its own type:

• Primary profiles carry the DNSSEC setting (enable + signing profile), the Query ACL, the geo-block option, the edge-server assignment, an SOA / TTL template, and the AXFR-out setting.
• Secondary profiles carry only the transfer source: upstream primary servers, the transfer TSIG key, and the serve-stale behaviour.

The profile editor walks through the relevant steps (Basics, then DNSSEC, Access & steering, Edge servers, SOA / TTL, and AXFR-out for primary profiles; Basics and Transfer source for secondary ones). A profile's type cannot be changed after creation. One profile per tenant can be marked as the Default (with the Make default star in the list), which is offered first when creating new zones. Zones attached to a profile have the matching inline controls locked so they cannot drift from it; to detach a zone, switch it to Configure directly on its Zone Settings tab. The list shows each profile's type, DNSSEC state, Query ACL, geo-block setting, and how many zones use it; a profile that still has zones attached cannot be deleted until they are reassigned.

3.7 Deleting a Zone#

Warning: deleting a zone removes its zone file and all of its companion files (including its DNSSEC signing keys and Smart Routing configuration) from cloud storage, de-provisions it from every authoritative server (including the on-server zone files), and removes its historical query statistics — the domain stops resolving through DNS Armor and the deletion cannot be undone. Export or note the records first if you may need them. Deletion requires write access on AuthZone.

4. Records#

Where to find it: Sidebar → Authoritative DNS → Zones → open a zone → Records tab

4.1 Supported Record Types#

A, AAAA, CNAME, MX, TXT, NS, SRV, CAA, and PTR records are supported. Each record carries a name (relative to the zone or @ for the apex), a TTL, and a type-specific value entered in a single Value field — for example a priority and target for MX and SRV (10 mail.example.com), or flags/tag/value for CAA (0 issue "ca.example").

4.2 Editing Records — Draft and Save#

Adds and deletes are collected as a local draft — an Unsaved changes chip appears while edits are pending — and committed together with Save changes, which validates the set, produces a single serial bump, and performs one upload rather than one per record. Use Discard to abandon a draft. The table offers a live search across name, type, and value.

4.3 Batch Add#

The Batch action opens a paste box for adding many records in one operation — useful when migrating an existing zone. The format is one record per line: name type [ttl] value. The whole batch is validated and applied atomically: if any entry is invalid, none are written, and the error identifies the offending line.

4.4 Validation and Managed Records#

• IP addresses, FQDNs, TTLs, and priorities are syntax-checked before upload; address records verify the value matches the record family (IPv4 for A, IPv6 for AAAA).
• A CNAME cannot exist at the zone apex, and a name with a CNAME cannot also carry other record types (no coexistence). Exact duplicate records (same name, type, and value) are rejected with a "Duplicate record" error.
• Records marked Auto nameserver are generated from the zone's server assignment and are read-only (§3.3).
• A record owned by a Smart Routing policy shows as Managed with live health chips and is read-only in the Records tab — its answers are edited on the Smart Routing tab (§6.6). Attempting to add or edit a record that a policy owns is refused with a message pointing you to the policy.
• The SOA serial is bumped automatically on every successful change.

4.5 Large Zones#

For zones with many records, the Records table supports server-side pagination and filtering so you can find and edit a record without loading the entire zone. Concurrent edits to the same zone are serialised by a per-zone lock; if another edit is in progress you may briefly see a "Zone is busy, please retry." message — retry and it will proceed.

5. DNSSEC#

Where to find it: open a zone → DNSSEC tab, and Sidebar → Authoritative DNS → DNSSEC Profiles

5.1 Enabling DNSSEC on a Zone#

On a zone's DNSSEC tab, switch DNSSEC signing on. Keys are generated for you and signing is automatic and consistent across the whole serving fleet — there are no manual re-signing chores. The tab shows which DNSSEC profile the zone uses (with its algorithm, KSK/ZSK lifetimes, and NSEC3 setting summarised); pick a different profile and click Apply profile to change it. Below that, the tab lists the DS Records to publish at your registrar and the live Keys with their tags, algorithms, and roles (KSK/ZSK), plus the current key/signature expiry when reported. For zones attached to a Zone Profile, DNSSEC is governed by that profile and the inline controls are locked. If the signing nodes have not reported recently, a warning notes that the displayed DS records may be stale.

5.2 DNSSEC Profiles#

A DNSSEC Profile is a named, reusable signing policy defined per tenant: Profile name, Algorithm (§5.3), KSK lifetime (days, 0 = no rollover), ZSK lifetime (days, 0 = never), and Use NSEC3. One profile per tenant is the Default, applied when DNSSEC is first enabled on a zone without choosing a profile; move it with the Make default star, and override it per zone. Manage profiles at Authoritative DNS → DNSSEC Profiles (RBAC service AuthDnssec). Editing a profile automatically re-applies the change to every DNSSEC-enabled zone that uses it — no per-zone action is needed.

5.3 Supported Algorithms#

5.4 Publishing the DS Record#

1. Enable DNSSEC on the zone and wait for the DS record(s) to appear on the DNSSEC tab.
2. Copy each DS row with its copy button, or use Download DS file to save all DS records as a ready-to-submit text file in the standard DS presentation format that registrars accept, then add them at your domain registrar (the parent zone).
3. Allow the parent's TTL to elapse; validation is then active end-to-end. You can confirm with dig +dnssec or any DNSSEC validator.

Do not remove delegation or disable DNSSEC at the registrar while the DS is published — withdraw the DS first to avoid resolution failures.

5.5 Automatic Key Rollover#

Key rollover is scheduled from the profile lifetimes and executed by the platform using the pre-publish method:

• ZSK rollover is fully automatic and invisible to your registrar: when the active ZSK reaches its lifetime, a new key is published alongside it, and the old key is dropped after an overlap window.
• KSK rollover changes the DS at the parent, so it is deliberately conservative: the new KSK is minted and published alongside the old one, and both DS records are shown on the DNSSEC tab. The old key is retired only after the platform confirms the new DS is present at the parent (§5.6) and the overlap has elapsed — the zone never goes insecure mid-roll. A profile with KSK lifetime 0 never rolls the KSK.

The next scheduled KSK rollover date is derived from when DNSSEC was enabled and the profile's KSK lifetime (the enable date plus a whole number of KSK lifetimes), and drives the reminder emails below. A profile with KSK lifetime 0 has no scheduled KSK rollover, so no reminder emails are sent.

5.6 Rollover Reminders and Parent-DS Checks#

DNS Armor sends two kinds of DNSSEC advisories, checked daily:

• KSK-rollover reminders — 60, 30, and 0 days before a zone's next scheduled KSK rollover, reminding you to make sure your registrar carries the current DS record (chiefly relevant for registrars without automated CDS/CDNSKEY processing).
• Parent-DS alerts — the platform itself queries the parent zone for each signed zone's DS records and emails you when a zone has DNSSEC enabled but the DS is missing or does not match the current keys at the parent.

Notifications are grouped into one email per tenant, never per zone. Standard customers are notified at the customer contact email; for MSP customers, alerts for the master tenant's zones go to the reseller contact, and alerts for a child tenant's zones go to both the reseller contact and the tenant's own contact.

6. Smart Routing (Traffic Steering and Failover)#

Where to find it: open a zone → Smart Routing tab (RBAC service AuthGeoHealth)

Smart Routing is unified traffic steering for DNS Armor™ Resolve (Authoritative DNS): geographic segments, priority-group failover, optional health checks, and latency-based answer ordering combine in a single policy per record. It replaces the earlier separate traffic-steering and health-check policies with one editor and one live status view.

6.1 How a Policy Is Structured#

Each policy targets one record — a name plus a type (A, AAAA, or CNAME) — and contains:

• Segments — slices of traffic matched by client source. A policy either serves All clients with one rule set, or splits By client source into geo/subnet segments plus a Default (any other) segment for unmatched sources.
• Priority groups — inside each segment, one or more groups of answers ordered by priority. The highest-priority group with at least one healthy answer wins; lower tiers are failover.
• Health checks — each group can optionally be probed; unhealthy answers are removed from rotation and the group fails over when none remain (§6.4).

6.2 Creating a Policy#

Click Add Smart Routing policy. The editor is a five-step wizard — Record, Segments, Groups, Options, Review:

1. Record — the record name and type, and the Routing mode: All clients — one rule set or By client source — geo or subnet.
2. Segments (source mode) — choose what to Match source by (§6.3) and add segments, each with one or more match values picked from validated lists. A Bulk edit option accepts one segment per line (match value, then its answers) for fast entry.
3. Groups — per segment, define the priority groups: a priority, an optional label, the answer set, and optionally Health check this group with its probe settings.
4. Options — the answer Selection within the active tier and the behaviour When all tiers fail (§6.5), plus Block non-matching sources in source mode.
5. Review — a summary of every segment, group, and probe before saving.

6.3 Matching Traffic by Source#

• Country — ISO country codes chosen from a validated list (e.g. US, SA).
• Continent — continent-level matching for coarse regional steering.
• City — a city within a country (e.g. SA/Riyadh), using the same GeoIP database the serving network resolves against.
• IP / Subnet — client source networks in CIDR form, IPv4 or IPv6 — useful for routing internal or partner ranges to dedicated endpoints.

Sources that match no segment fall to the Default (any other) segment. Alternatively, enable Block non-matching sources to return NODATA to unmatched sources instead of a catch-all answer — a simple geo-fence for the record.

6.4 Health Checks#

Any priority group can be health-checked. A probe is defined by its Protocol (tcp, http, https, or icmp), a Port (for tcp/http/https), a Path (for http/https), the probe Interval and Timeout in seconds, and Rise/Fall thresholds — the number of consecutive successes or failures that flip an answer's state, which prevents flapping. Unhealthy answers are withdrawn from the group; when every answer in the active group is down, the next priority tier takes over, and recovered answers return to rotation automatically. On a state change the record is updated — and re-signed if the zone uses DNSSEC — within seconds. Each authoritative edge probes the targets independently, so failover reflects what each region actually observes.

6.5 Answer Selection and Exhaustion#

• Selection within the active tier — Round-robin across healthy answers, or Latency-ordered (serve the fastest answer first, using each edge's measured probe latency).
• When all tiers fail — Stop serving (withdraw the record), or Serve the last-known answers so the name keeps resolving to the most recent healthy set.
• CNAME policies are geo-only: a name cannot be probed, so health checks and latency ordering do not apply, and each segment uses a single CNAME target.

6.6 Managed Records and Live Health#

A Smart Routing policy owns its record's answers: the matching record is created and kept in sync automatically, shows as Managed and read-only in the Records tab, and any pre-existing hand-authored record of the same name and type is taken over when the policy is saved (the editor warns before replacing its value). The policy list shows what each policy serves now, and an expandable per-edge health panel shows the health — and, for latency policies, the measured latency — of every answer as seen by each authoritative edge.

6.7 Location Accuracy (ECS)#

Geographic decisions use the client's network when the recursive resolver forwards it via EDNS Client Subnet (ECS); otherwise the resolver's own address is used. Public resolvers that send ECS therefore steer with end-user accuracy, and the geographic analytics (§8.2) prefer ECS data for the same reason.

7. Zone Access and Transfers#

Three per-tenant object libraries control who may query your zones and who may transfer them. Each is attached to zones from the Zone Settings tab or through a Zone Profile.

7.1 Query ACLs#

Where to find it: Sidebar → Authoritative DNS → Query ACLs

A Query ACL is a source-IP access list for DNS queries: a Default action (allow — open, block only the listed sources; or deny — closed, answer only the listed sources) plus an ordered list of CIDR rules, each with its own allow/deny action. Blocked sources receive a NOTAUTH response. Attach an ACL to a zone in Zone Settings (or via a profile); a zone without one is Open (no ACL). Deleting an ACL returns the zones that used it to open access.

7.2 TSIG Keys#

Where to find it: Sidebar → Authoritative DNS → TSIG Keys

TSIG keys authenticate zone transfers in both directions — securing AXFR-in for secondary zones and authenticating external secondaries that pull from us. A key has a Key name (the TSIG name sent on the wire), an Algorithm (hmac-sha256 by default, with hmac-sha384 and hmac-sha512; older hmac-sha224, hmac-sha1, and hmac-md5 are flagged as legacy interop options), and a base64 Secret — leave it blank to have a fresh key minted for you. The secret can be revealed later for configuring the far end; treat it like a password, since anyone holding it can transfer the zone.

7.3 Transfer ACLs (AXFR-out)#

Where to find it: Sidebar → Authoritative DNS → Transfer ACLs

A Transfer ACL is an allow-list of who may AXFR a zone from DNS Armor: a named set of source CIDRs, optionally requiring a specific TSIG key. To let external secondaries mirror a zone, enable Allow AXFR-out to external secondaries on the zone (Zone Settings → Steering & access) and select the allow-list. Deleting a Transfer ACL disables AXFR-out on the zones that used it.

8. Statistics and Analytics#

Where to find it: Sidebar → Authoritative DNS → Statistics (RBAC service AuthDnsStats, read-only for all roles)

The Statistics page has two views, switched by an Overview / Analytics toggle, with a shared date-range picker and zone selector.

8.1 Overview#

• Metric cards — Configured zones, Records, Active zones, Total queries, NXDOMAIN rate, and Tenants for the selected scope.
• Fleet query volume — query volume across all zones, charted over the selected range.
• Top zones by volume and Zones needing attention — the busiest zones and any zones with elevated error rates.
• Config counts — zones and records per customer and tenant, updated as you edit, exportable as CSV.
• Per-zone query volume — a searchable, paginated table of daily query counts per zone and per serving edge, with NXDOMAIN and SERVFAIL columns, exportable as CSV. Clicking a zone jumps to its Analytics view.

8.2 Analytics#

Select a zone to drill into its traffic: query-trend charts with sparkline deltas, per serving edge or aggregated; donut breakdowns of Response codes, Transport, Query types, and NODATA; a Geo distribution map of queries by client country (ECS-preferred); ranked tables of Top records, Top NXDOMAIN names, and Top client subnets (keyed to the end-user subnet when ECS is present, otherwise to the resolver); a Per-edge breakdown of queries, errors, TCP, and DNSSEC-requesting traffic per serving edge; and query/reply size histograms. A health chip summarises the zone's Smart Routing target state at a glance.

8.3 Exports and Refresh#

The Export Excel button exports what you are looking at — the fleet Overview, or the selected zone's full analytics — and each ranked table also offers its own CSV export. An auto-refresh toggle re-loads the page data every 30 seconds for live monitoring.

8.4 MSP Auth DNS Analytics Dashboard#

For MSP scopes, the Tenants page (Sidebar → Administration → Tenants) includes the MSP Auth DNS Analytics Dashboard: provisioned limits versus actual usage across MSP tenants, comparing each tenant's Auth DNS Max Zones and Auth DNS Max Records against its real zone and record counts, together with tenant counts (active with a valid subscription, and active including expired). An Include master tenants toggle adds or removes the resellers' master tenants, and super-users (Root and App Root users) get a Filter MSP resellers picker (default All MSP resellers) to focus on one reseller. Tenants that draw from a customer-wide shared pool are labelled as such, with the customer-level total shown on each. The per-tenant limits themselves are set in the tenant's edit dialog on the same page. The Tenants Analytics Dashboard alongside it charts the distribution of MSP Service Licenses (Auth DNS, DNS Firewall, both, or none).

9. Troubleshooting#

For assistance with DNS Armor™ Resolve (Authoritative DNS), contact support@secure-domains.org. See also the DNS Armor Administration Guide for tenants, users, roles, and the shared Cloud Servers screen.