What the product does
The selected deployment may use network routing, roaming endpoints or another supported method according to the customer architecture.
Guardian DNS Protection combines compatible DNS-layer security with Damocles policy management, activity visibility, investigation support, exceptions and Guardian actions.
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.
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.
The selected deployment may use network routing, roaming endpoints or another supported method according to the customer architecture.
The level of attribution depends on the selected deployment and available identity context.
Customer business policy and approval authority remain explicit.
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.
Apply approved threat and category policy before users and devices connect to known harmful destinations.
Use available user, device, site, policy and destination context to make blocked or monitored events useful.
Create investigation, endpoint, training or customer actions when activity suggests a broader issue.
The selected deployment may use network routing, roaming endpoints or another supported method according to the customer architecture.
Block supported malicious, phishing, malware and command-and-control destination categories.
Apply agreed category controls, policy groups, exceptions and business requirements.
Associate activity with available users, devices, sites or networks where the deployment supports it.
Present blocked, allowed, monitored and policy activity through customer-readable Guardian records.
Record allow-list, policy bypass and category exceptions with owner, reason and review date.
Link material or repeated activity to investigation, endpoint follow-up, human-risk remediation or All Actions.
The level of attribution depends on the selected deployment and available identity context.
Protected users, devices, sites or networks and the current service or connector state.
Blocked, allowed and monitored requests by category, policy, destination and available identity.
Identify devices, users or sites producing repeated malicious or suspicious DNS activity.
Customer-approved allow lists, bypasses, category overrides, owners and expiry dates.
Endpoint review, credential response, user education, application validation or policy change where appropriate.
Coverage, policy, material events, exceptions, actions and unresolved deployment gaps.
Customer business policy and approval authority remain explicit.
Select the supported routing, roaming, site or hybrid deployment model and validate DNS dependencies.
Maintain approved threat, category, group, allow-list and exception policy.
Track connector, resolver, endpoint or site state required for the protected scope.
Review material blocked or monitored activity and available identity or device context.
Coordinate endpoint, identity, training or customer actions when the DNS event indicates broader risk.
Review coverage, event patterns, exceptions, deployment gaps and policy changes with the customer or MSP.
Deployment is validated carefully because DNS is a critical dependency for users, devices and applications.
Map resolvers, sites, roaming users, devices, identities, applications, split DNS and operational dependencies.
Confirm threat, category, group, exception, logging and customer-approval requirements.
Validate routing, identity, policy behaviour, false positives, application dependencies and fallback.
Roll out the approved network, site or endpoint method across the covered scope.
Review health, material events, exceptions, repeated patterns and required customer action.
Tune approved policy, resolve coverage gaps and report the current protected state.
The deployment can be adapted to business, remote-worker, provider and participant-support contexts without assuming identical device ownership.
Protect staff and business devices through a managed DNS policy without requiring a large internal security team.
Extend compatible DNS protection to authorised users or devices away from the office.
Operate customer-scoped policy, deployment state, events, exceptions and wholesale entitlements.
Protect the agreed provider-owned staff estate while keeping Participant Free separate from paid managed control.
Use malicious-destination activity as context for endpoint, identity or investigation follow-up.
Apply agreed categories and business exceptions while keeping policy ownership and expiry visible.
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.
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.
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.
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.
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.
The exact answer is confirmed in the proposal and package schedule, but these points should be understood before activation.
Yes where a supported connector and deployment model provide the health, policy, event and identity information required.
Potentially, using a compatible roaming or endpoint deployment. The selected method and supported devices are confirmed during design.
Yes within the supported platform and approved policy. Business exceptions retain ownership and review dates.
Not automatically. Event context and repeated behaviour may require endpoint or identity investigation before a conclusion is reached.
No continuous paid DNS service is included in Participant Free. Sponsored or paid protection requires a product entitlement.
The deployment includes the supported failover and support design, and Guardian shows the unavailable or degraded state rather than hiding the gap.
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.
We will map DNS dependencies, deployment options, identity context, policy, exceptions, event review and managed responsibilities.