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 lists, 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.

Filtering starts from a catalogue of categories that Netgraph curates and keeps current, so a network can be protected without anyone sourcing a blocklist first. Customers add their own lists alongside the categories where they need something specific.

Service at a glance

Purpose

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

Filtering

Curated categories Available · Own blocklists, by URL or maintained in the console Available · Allowlists Available · Scheduled policies 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: categories, the customer’s own lists, allowlists, and policies.

Most networks start from the categories and never need more. Where an organization has domains of its own to block, it keeps its own lists beside them, and a policy can combine both. 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. Blocking the content categories broadly, and allowlisting the domains the network exists for, 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 policies before answering.	A network that needs content filtering, acceptable-use or time-based policy

Switching a network to Cloud DNS mode takes effect as a live change, and opens a Cloud DNS section in the administration portal for that network. Switching back to Plain returns it to simple forwarding and keeps the policies and lists, so the network can be switched back without rebuilding them.

3. Key functions

• Categories. A catalogue of curated blocklists that Netgraph maintains and keeps current, grouped as Security, Content, and Ads and tracking. Each category states what it covers, how many domains it holds and when its content was last updated. Two are marked as recommended, and a network with no policy yet can be created directly from them. Nothing has to be sourced, subscribed to or maintained by the customer. The categories are built from third-party sources by technical classification rather than by review, so a legitimate domain can occasionally be included; the remedy is an allowlist entry. A category the platform switches off leaves the catalogue; a policy that had selected it keeps it, marked inactive, until it is active again.
• Own blocklists by URL. 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.
• Own blocklists maintained in the console. Build named lists of domains, by hand or by bulk import. An entry covers the domain and everything under it, so no wildcard is needed; entries are normalised on save and must be valid domain names.
• Allowlists. Named lists of exceptions. An allowlist entry removes exactly that name from what a policy blocks, whichever list contains it; it does not cover the names under it and does not override a block that comes from a parent domain.
• Internal DNS records. Static host-to-IP records for internal names, resolved directly by Cloud DNS.
• Upstream resolvers. Primary and secondary upstream resolvers are configurable per network.
• Policies. A policy 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 policy, Cloud DNS resolves the chosen blocklists minus the allowlists into one effective list, the set of domains that policy blocks. The list itself is not exported; the console answers the question it was used for directly, through the domain lookup below.
• Domain lookup. The Policies page checks one domain against every policy in the network and answers per policy: blocked or not, whether the name itself or a parent domain is listed, which category or own list carries the entry, whether an allowlist entry fails to cover it because the block comes from a parent domain, and what a policy that has not been built yet will do.
• Policy status. Each policy shows whether it is always on, in force right now, outside its scheduled hours, or too large to apply, together with the number of domains it currently blocks and when that list was built. A policy that cannot be refreshed keeps its previous list in use and is flagged on the Policies page.
• Bulk import and export. The network’s own blocklists, allowlists and URL subscriptions can be imported and exported in bulk. Category content is never exported.
• Usage statistics. A Statistics page shows how many DNS queries the network answered and how many it blocked, as totals and a trend for today, 7 days, 30 days, 6 months or 12 months. Usage is sampled every few minutes and counted per network; there is no per-client or per-domain breakdown and no per-query log.

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 policies that apply to the requesting client, at the current time, and answers accordingly:

• If a matching, active policy blocks the domain, the lookup is dropped. There is no block page and no prompt; the name simply does not resolve.
• If the exact name is on an allowlist referenced by a matching policy, it resolves. A blocklist entry covers the domain and everything under it; an allowlist entry covers the one name it holds.
• Otherwise, the lookup is resolved through the configured upstream resolvers.
• Internal DNS records are answered directly.

Behind the scenes, each policy’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. Category content is maintained by Netgraph: when a category is updated, every policy that selected it follows, with nothing for the customer to do.

5. Policies, audience, and scheduling

A policy ties the filtering together. It is administered from the Cloud DNS section of the network’s administration portal, and the service API refers to the same object as a ruleset.

• Lists. Any combination of categories, the network’s own blocklists, and allowlists.
• Audience. A policy applies either everywhere in the 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 policy to reach any client there.
• Schedule. A policy can carry an optional weekly schedule with day-and-hour windows in a chosen timezone, set on a week calendar in half-hour steps. When the schedule is switched on, the policy is only active inside those windows, and at least one window is required. A policy with the schedule switched off is always active. Outside its active windows, a scheduled policy does not filter.

This is what makes time-based and per-site policy possible: for example, a policy 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.

Changes to a policy or its lists take effect at the next resolver refresh, within minutes. Switching the network’s DNS mode takes effect immediately.

A policy can serve at most five million domains in total, and may select at most 50 categories and 50 of each kind of the network’s own lists. If a change would exceed the domain limit, the policy keeps its previous effective list and is flagged in the portal rather than applying partially; a new policy over the limit filters nothing until it is reduced.

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 policies, 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 with the context’s connector-manager role	Administration Portal	Configure the network’s DNS mode, upstream resolvers, policies, own blocklists, allowlists, and internal DNS records, and select from the category catalogue
Organization administrator with a role that reads the context’s statistics, such as the context owner	Administration Portal	Follow usage on the Statistics page: queries answered and blocked, as totals and a trend

Cloud DNS is administered per network alongside the rest of that network’s Sign In configuration, by the same role that manages the network’s Service Gateway settings; the Cloud DNS configuration pages are shown to that role only, while the Statistics page follows the roles that read the context’s other statistics. Every configuration change is recorded in the administration audit log. Netgraph curates and maintains the category catalogue. Partners provision the network and its Service Gateway from the MSP Portal, but Cloud DNS itself has no partner-side configuration. The customer is responsible for choosing which categories and lists to apply, maintaining any lists of its own, 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. The categories are curated and kept current by Netgraph, but no blocklist is exhaustive, and the customer chooses which to apply.
• Categories cover subjects that are common to many organizations. Domains specific to one organization belong on a list of its own.
• Reporting is aggregate. The Statistics page counts queries answered and blocked per network; there is no per-query log and no per-client or per-domain reporting. The domain lookup in the portal shows what the policies select for a name, not what a given client was answered.
• Category content is not exported. The network’s own lists can be exported; the domains a category holds are applied by the resolver and can be checked name by name through the domain lookup.

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.