Cloud DNS

Cloud DNS is a managed, filtering DNS resolver that Netgraph runs for a Sign In Enterprise network. It replaces plain DNS forwarding with a resolver that applies the customer’s policy to every lookup: it blocks domains on the chosen blocklists, always resolves domains on the allowlists, and can scope filtering to parts of the network and to times of day. It is delivered as an add-on to Sign In Enterprise and reaches the network through the customer’s Service Gateway. There is nothing for the customer to run on site.

Service at a glance

Purpose

Managed filtering DNS for a Sign In Enterprise network, without running a resolver yourself

Filtering

Remote blocklists Available · Custom blocklists Available · Allowlists Available · Scheduled rulesets Available

Best for

Reducing malware, phishing and ad domains; acceptable-use control; time-based and per-site policy

Licensed by

Add-on to Sign In Enterprise, delivered via the Service Gateway

Key prerequisite

A network on Sign In Enterprise with DNS routed through the Service Gateway to Cloud DNS

1. Purpose and use cases

Cloud DNS filters at the DNS layer, so a domain that never resolves can never load, on any device on the network, with nothing to install. It is used to reduce exposure to malware, phishing and tracker domains; to keep guest and public networks focused by blocking streaming, gambling or social domains; to apply different policy at different hours or on different sites; and to publish internal names that never make it into public DNS. Each of these is expressed with the same building blocks: lists, allowlists, and rulesets.

The lists are defined by the customer and are not limited to security categories. A common use is a purpose-limited network: free Wi-Fi at a parking facility, charging site or transit stop that is meant for paying, verification and similar essential traffic. Allowlisting the domains the network exists for, and blocking high-draw categories such as streaming and social media, keeps the network useful for its purpose without making it attractive to linger on.

2. Service scope and modes

Cloud DNS is configured per network. A network runs in one of two modes:

Mode	Behaviour	Typical use
Plain	DNS is forwarded to the configured upstream resolvers, with optional static host records. No filtering is applied.	A network that only needs resolution and a few local records
Cloud DNS	DNS is served by a managed filtering resolver that applies the network’s blocklists, allowlists and rulesets before answering.	A network that needs content filtering, acceptable-use or time-based policy

Switching a network to Cloud DNS mode takes effect on the network as a live change. Switching back to Plain returns it to simple forwarding.

3. Key functions

• Upstream resolvers. Primary and secondary upstream resolvers are configurable per network.
• Remote blocklists. Subscribe to any published blocklist by its URL. Cloud DNS fetches the list and keeps it refreshed, and reports the last fetch status and entry count. A list can be enabled or disabled without deleting it.
• Custom blocklists. Build your own named lists of domains, by hand or by bulk import. Domain entries support wildcards, so one entry can cover a domain and everything under it.
• Allowlists. Named lists of domains that must always resolve. Allowlisted domains override every blocklist.
• Custom DNS records. Static host-to-IP records for internal names, resolved directly by Cloud DNS.
• Rulesets. A ruleset combines the lists above with an audience and an optional schedule (see section 5). It is the unit that decides what is blocked, for whom, and when.
• Effective list. For each ruleset, Cloud DNS resolves the chosen blocklists minus the allowlists into one effective list, the exact set of domains that ruleset blocks. The effective list can be downloaded for review.
• Bulk import and export. Blocklists and list entries can be imported and exported in bulk.

4. Architecture and how it works

Cloud DNS runs as a managed resolver for the network, reached through the customer’s Service Gateway. When the network is in Cloud DNS mode, the Service Gateway directs the network’s DNS to the resolver. For each lookup, the resolver evaluates the rulesets that apply to the requesting client, at the current time, and answers accordingly:

• If a matching, active ruleset blocks the domain, the lookup is dropped. There is no block page and no prompt; the name simply does not resolve.
• If the domain is on an allowlist referenced by a matching ruleset, it always resolves.
• Otherwise, the lookup is resolved through the configured upstream resolvers.
• Custom DNS records are answered directly.

Behind the scenes, each ruleset’s effective list is computed centrally and kept current as its lists change, so the resolver applies an up-to-date policy without the customer republishing anything.

5. Rulesets, audience, and scheduling

A ruleset ties the policy together:

• Lists. Any combination of remote blocklists, custom blocklists, and allowlists.
• Audience. A ruleset applies either to the whole network or to selected sites. When it is scoped to sites, it applies to the network ranges of those sites, so a site needs a defined network for the ruleset to reach any client there.
• Schedule. A ruleset can carry an optional weekly schedule with day-and-hour windows in a chosen timezone. When a schedule is set, the ruleset is only active inside those windows. A ruleset with no schedule is always active. Outside its active windows, a scheduled ruleset does not filter.

This is what makes time-based and per-site policy possible: for example, a ruleset that blocks distraction domains on the student network, on selected sites, Monday to Friday between 08:00 and 17:00, and lifts automatically outside those hours.

6. Customer requirements and DNS enforcement

Item	Requirement
Parent service	An active Sign In Enterprise subscription
Delivery	A supported integration through the customer’s Service Gateway (Cisco router as Service Gateway, or Cisco SD-WAN)
DNS routing	The network’s DNS directed to Cloud DNS
Sites	For per-site rulesets, sites with a defined network range

For filtering to be effective, DNS has to go through Cloud DNS. If clients can reach other resolvers, they can step around the policy, so the customer is responsible for closing those paths at the gateway:

• DNS over UDP and TCP port 53 to external resolvers.
• DNS over HTTPS (DoH) on port 443.
• DNS over TLS (DoT) on port 853.

This includes well-known public resolvers such as Google (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1) and Quad9 (9.9.9.9). Where these paths are left open, clients can obtain unfiltered resolution, which is outside the intended scope of the service. Network connectivity is summarised in Network Requirements.

7. Integrations and dependencies

Cloud DNS depends on Sign In Enterprise for the network, its sites and its administration, and on the customer’s Service Gateway to carry the network’s DNS to the resolver. It is not a standalone product and is not offered as a public DNS service. See Integrations and the Sign In deployment overview.

8. Roles and responsibilities

Role	Surface	Capabilities
Organization administrator	Administration Portal	Configure the network’s DNS mode, upstream resolvers, blocklists, allowlists, custom records, and rulesets

Cloud DNS is administered per network alongside the rest of that network’s Sign In configuration. The customer is responsible for choosing appropriate blocklists, maintaining their own lists and allowlists, and enforcing DNS routing at the gateway. See Roles and Administration Levels.

9. Licensing and activation

Cloud DNS is licensed as an add-on to Sign In Enterprise. The add-on is independent of the number of connected clients and of DNS query volume, and it inherits the SLA of the customer’s Sign In Enterprise license. Authoritative terms and requirements are on the Cloud DNS License page; the platform model is summarised in Licensing and Service Levels. Licenses are sold through authorized partners.

10. Security, logging, and data protection

Cloud DNS performs no deep packet inspection and no content or URL analysis; it operates on domain names. DNS data is processed only to provide the service and for troubleshooting, and is handled according to the Netgraph Data Privacy Sheet. Platform-wide protections are described in Security and Data Protection and Logging, Reporting, and Retention.

11. Limitations and exclusions

• Cloud DNS is not a replacement for advanced security functions such as intrusion prevention, malware detection, URL filtering, or traffic inspection. Run it alongside those, not instead of them.
• Filtering is at the domain level. A blocked domain is blocked everywhere; it cannot allow one path and block another on the same host.
• A blocked lookup is dropped, not answered. No block page or user notification is shown.
• Filtering only applies to DNS served by Cloud DNS. If DoH, DoT, or external port 53 is not blocked at the gateway, clients can bypass the policy.
• Effectiveness follows the lists in use. Cloud DNS enforces the policy you set; curating good blocklists is the customer’s responsibility.

12. Related services and when to use

Use Cloud DNS when a Sign In Enterprise network needs DNS-level filtering: blocking unwanted or unsafe domains, keeping a guest network on task, or applying time-based and per-site policy. It complements the rest of the platform:

• Sign In is the parent service that provides the network, its onboarding, and its sites. Cloud DNS is an add-on to Sign In Enterprise.
• For authenticated network access with 802.1X, Identity PSK, or RADIUS proxy, see EntryPoint.

Cloud DNS is not a public resolver, a firewall, or a security suite; it is a focused DNS filtering layer for networks the platform already delivers.