Optional managed protection product

Block known malicious destinations before the connection and make policy exceptions accountable.

Guardian DNS Protection combines compatible DNS-layer security with Damocles policy management, activity visibility, investigation support, exceptions and Guardian actions.

Australian data residency

Guardian for Australian customers is built, operated and hosted in Australia. All Guardian customer and platform data, including backups and recovery copies, is maintained and stored within Australia.

Vendor-neutral DNS modelManaged security policyUser, device and site contextInvestigation and action follow-up
Buyer decision summary

Know what Guardian DNS Protection does, what the customer sees and what Damocles is responsible for before activation.

Guardian retains supported event, destination, category, action, policy, identity and device context needed for customer review. Credentials, resolver secrets, raw platform payloads and unrelated tenant data remain restricted.

The proposal identifies protected scope, deployment method, connector, policy, identity mapping, event retention, support, exceptions, reporting and any minimum tenant charge or managed-service boundary.

The product does not claim that every malicious destination will be known or blocked, that every event proves compromise, or that policy can be applied to unsupported devices and network paths.

01

What the product does

The selected deployment may use network routing, roaming endpoints or another supported method according to the customer architecture.

02

What the customer sees

The level of attribution depends on the selected deployment and available identity context.

03

What Damocles manages

Customer business policy and approval authority remain explicit.

The operational problem

DNS is used by almost every application and device, but blocking alone is not enough if nobody can explain the event, user, policy or required response.

A DNS-layer control can stop known malicious, phishing and command-and-control destinations before a connection completes. Its operational value depends on correct routing, identity mapping, policy, exceptions, event visibility and follow-up when activity indicates a compromised device or unsafe user behaviour.

Guardian provides the customer and provider workflow around the selected compatible DNS security technology. Damocles manages the agreed policy and follow-up, while the customer retains authority over business exceptions, identity and remediation decisions.

01

Reduce avoidable malicious connections

Apply approved threat and category policy before users and devices connect to known harmful destinations.

02

Explain who and what was affected

Use available user, device, site, policy and destination context to make blocked or monitored events useful.

03

Turn repeated activity into response

Create investigation, endpoint, training or customer actions when activity suggests a broader issue.

Product capability

Managed DNS-layer protection for the agreed users, devices and sites.

The selected deployment may use network routing, roaming endpoints or another supported method according to the customer architecture.

TP

Threat protection

Block supported malicious, phishing, malware and command-and-control destination categories.

CP

Category and acceptable-use policy

Apply agreed category controls, policy groups, exceptions and business requirements.

ID

Identity and device context

Associate activity with available users, devices, sites or networks where the deployment supports it.

EV

Event visibility

Present blocked, allowed, monitored and policy activity through customer-readable Guardian records.

EX

Exception governance

Record allow-list, policy bypass and category exceptions with owner, reason and review date.

RA

Investigation and actions

Link material or repeated activity to investigation, endpoint follow-up, human-risk remediation or All Actions.

What the customer sees

Customers see protection state, policy and material activity without operating the DNS platform.

The level of attribution depends on the selected deployment and available identity context.

PS

Protection status

Protected users, devices, sites or networks and the current service or connector state.

PA

Policy activity

Blocked, allowed and monitored requests by category, policy, destination and available identity.

PR

Repeated-risk patterns

Identify devices, users or sites producing repeated malicious or suspicious DNS activity.

EX

Exceptions

Customer-approved allow lists, bypasses, category overrides, owners and expiry dates.

AC

Required actions

Endpoint review, credential response, user education, application validation or policy change where appropriate.

RP

Service reporting

Coverage, policy, material events, exceptions, actions and unresolved deployment gaps.

What Damocles manages

Damocles manages the agreed DNS policy, deployment health and operational follow-up.

Customer business policy and approval authority remain explicit.

DS

Deployment design

Select the supported routing, roaming, site or hybrid deployment model and validate DNS dependencies.

PM

Policy management

Maintain approved threat, category, group, allow-list and exception policy.

HM

Health monitoring

Track connector, resolver, endpoint or site state required for the protected scope.

ER

Event review

Review material blocked or monitored activity and available identity or device context.

IF

Investigation follow-up

Coordinate endpoint, identity, training or customer actions when the DNS event indicates broader risk.

SR

Service review

Review coverage, event patterns, exceptions, deployment gaps and policy changes with the customer or MSP.

Operating lifecycle

From DNS-routing design to policy, event review and accountable response.

Deployment is validated carefully because DNS is a critical dependency for users, devices and applications.

01

Discover

Map resolvers, sites, roaming users, devices, identities, applications, split DNS and operational dependencies.

02

Design policy

Confirm threat, category, group, exception, logging and customer-approval requirements.

03

Pilot

Validate routing, identity, policy behaviour, false positives, application dependencies and fallback.

04

Deploy

Roll out the approved network, site or endpoint method across the covered scope.

05

Operate

Review health, material events, exceptions, repeated patterns and required customer action.

06

Improve

Tune approved policy, resolve coverage gaps and report the current protected state.

Common use cases

Common DNS-protection use cases.

The deployment can be adapted to business, remote-worker, provider and participant-support contexts without assuming identical device ownership.

SB

Small-business protection

Protect staff and business devices through a managed DNS policy without requiring a large internal security team.

RW

Remote and roaming users

Extend compatible DNS protection to authorised users or devices away from the office.

MS

MSP customer sites

Operate customer-scoped policy, deployment state, events, exceptions and wholesale entitlements.

ND

NDIS provider staff

Protect the agreed provider-owned staff estate while keeping Participant Free separate from paid managed control.

IR

Incident support

Use malicious-destination activity as context for endpoint, identity or investigation follow-up.

AC

Acceptable-use policy

Apply agreed categories and business exceptions while keeping policy ownership and expiry visible.

Operating model

How Guardian DNS Protection is onboarded, integrated, evidenced and scoped commercially.

These details remain explicit before activation, but are grouped into one operating view so buyers can review the responsibilities without working through four separate page sections.

ON

Onboarding and implementation

Implementation begins with DNS dependency mapping and a controlled pilot. Damocles documents current resolvers, network paths, DHCP, VPN, remote users, directory or identity sources, device ownership, critical applications, split DNS, guest access, failover and support contacts. The deployment method is selected only after these dependencies are understood. A pilot validates resolution, performance, identity attribution, threat and category policy, application compatibility, allow-list behaviour, roaming operation and rollback. Policy owners approve business categories and exceptions before broader deployment. Go-live includes protected-scope mapping, health monitoring, support and escalation, exception workflow, event review, customer reporting and a process for new sites, devices, user groups and applications.

IN

Connector and integration model

Guardian presents one DNS-protection product while supporting compatible implementation options. A supported connector must expose protected scope, service health, policy groups, event category, destination, action, timestamp and available user, device or site context. The selected DNS technology may be customer-owned, provider-operated or Damocles-provided. The public site does not make one vendor mandatory. The proposal identifies the selected connector, deployment method, supported fields, identity capability, retention and commercial unit. New connectors are assessed for policy control, source health, event quality, identity mapping, tenant isolation, deployment safety, supportability and the ability to preserve customer actions and evidence in Guardian.

EV

Data, evidence and reporting

DNS records support investigation and policy review without exposing unsafe raw data. Guardian retains supported event, destination, category, action, policy, identity and device context needed for customer review. Credentials, resolver secrets, raw platform payloads and unrelated tenant data remain restricted. Reports distinguish blocked activity from confirmed compromise. A malicious-category event may require investigation, but it is not automatically represented as proof that a device or user was compromised. Policy and exception history records what changed, who approved it and when it should be reviewed. Source-health gaps remain visible so missing DNS data is not treated as a clean result.

CM

Commercial unit and responsibilities

Commercial scope is based on protected users, devices, sites or another agreed estate unit. The proposal identifies protected scope, deployment method, connector, policy, identity mapping, event retention, support, exceptions, reporting and any minimum tenant charge or managed-service boundary. Participant Free does not include continuous personal DNS protection. Paid participant, user or provider-sponsored coverage requires an explicit product entitlement and supported deployment. The customer owns business policy, application exceptions, identity accuracy and remediation decisions. Damocles owns the managed policy, health and follow-up listed in the service schedule.

Frequently asked questions

Questions buyers ask about Guardian DNS Protection.

The exact answer is confirmed in the proposal and package schedule, but these points should be understood before activation.

Q1

Can Guardian use our existing DNS security platform?

Yes where a supported connector and deployment model provide the health, policy, event and identity information required.

Q2

Will DNS Protection work away from the office?

Potentially, using a compatible roaming or endpoint deployment. The selected method and supported devices are confirmed during design.

Q3

Can categories be customised?

Yes within the supported platform and approved policy. Business exceptions retain ownership and review dates.

Q4

Does a blocked event mean the device is compromised?

Not automatically. Event context and repeated behaviour may require endpoint or identity investigation before a conclusion is reached.

Q5

Can participants receive it for free?

No continuous paid DNS service is included in Participant Free. Sponsored or paid protection requires a product entitlement.

Q6

What happens if the service is unavailable?

The deployment includes the supported failover and support design, and Guardian shows the unavailable or degraded state rather than hiding the gap.

Scope and boundaries

DNS Protection is a complementary control and does not replace endpoint, firewall or security-operations capability.

The product does not claim that every malicious destination will be known or blocked, that every event proves compromise, or that policy can be applied to unsupported devices and network paths.

Coverage depends on the approved routing or endpoint deployment, service availability, identity context and customer-controlled DNS behaviour.

Application troubleshooting, network redesign, incident response and complex remediation remain separate unless included in the service schedule.

Take the next practical step

Review the users, devices and sites that need DNS-layer protection and clear policy ownership.

We will map DNS dependencies, deployment options, identity context, policy, exceptions, event review and managed responsibilities.