Cloud DNS turns a Sign In Enterprise network into a managed, filtering resolver. Start from the categories Netgraph curates, add lists of your own, always allow the domains you trust, and shape it into policies that apply to the whole network or a single site, on a schedule. Delivered through your Service Gateway, with nothing to run on site.
Every network on Sign In Enterprise already sends its DNS somewhere. Cloud DNS replaces that plain forwarding with a resolver you control. Instead of every lookup passing straight through, each one is checked against the policy you set. Is this domain in a category you block, or on a list of your own? Is it one you always allow? Does a policy cover this part of the network, at this time of day? Then it resolves, or it does not.
You compose that policy from a few simple parts: categories that Netgraph curates and keeps current, blocklists of your own, and allowlists that always take precedence. A policy ties them together and decides where it applies and when. Most networks start from the recommended categories and are protected within minutes.
A blocklist is just a list of domains, so a list of your own can carry any policy you can name, not only the subjects the catalogue covers. Subscribe to a published list, write your own, or generate one for exactly what you want off the network: the streaming domains that turn a parking or transit network into a hangout, say. The policy is yours to define.
Netgraph curates a catalogue of blocklists and keeps them current, each one covering a single subject. Two are recommended for almost any network, and a network with no policy yet can start from them in one step. Every category says what it covers and, just as important, what it does not.
When a category blocks something your network needs, keep the category and put the domain on an allowlist: you keep the protection and make one exception. What is specific to your organization goes on a list of your own, and a policy combines both.
A policy takes the categories and lists you chose, subtracts the domains you always allow, and lands on one clear result: the effective list, the set of domains this policy blocks. Add where it applies and when, and the whole policy fits on a card, with its status and the number of domains it blocks right there.
No guesswork about what a policy really does. Look up any domain and every policy answers at once: blocked or not, whether the name itself or a parent domain is listed, and which category or list of yours causes it. And a Statistics page shows how many queries the network answered and how many it blocked, from today back to twelve months.
A catalogue of blocklists Netgraph maintains and keeps current, each covering one subject. Pick the ones your network needs in a policy. There is nothing to source, subscribe to or refresh, and when a category is updated, every policy that uses it follows.
For what is specific to you: subscribe to a published list by its URL and let Cloud DNS keep it refreshed, or maintain a list by hand. An entry covers the domain and everything under it, so one line is enough.
Some domains must always resolve: your payment provider, your booking system, your own services. An allowlist entry removes that exact name from what the policy blocks, whichever category or list contains it, so you can keep a broad category and make one exception.
Apply a policy everywhere in the network, or only to the sites you choose. One network, different policy where it needs to differ.
Give a policy hours on a week calendar when it should only apply some of the time, in your own time zone. Leave the schedule off and it applies around the clock.
Point an internal hostname straight at an IP. Handy for on-site services that never make it into public DNS, answered by the resolver itself.
A bad domain that never resolves can never load. Start from the two recommended categories and every device on the network is covered, with nothing to install and nothing to keep up to date yourself.
Free Wi-Fi at a parking garage, a charging point or a transit stop should let people pay, verify with their bank app and be on their way, not become somewhere to stream and scroll all day. Block the content categories broadly, and allowlist the domains the network exists for.
Filter distractions during school or work hours and lift the policy after. One policy, a weekly schedule, no switch to flip by hand.
Run a tighter policy at one site and a looser one at another from the same place, by scoping policies to the sites they belong to.
DNS filtering is a sharp, low-cost layer. Knowing exactly where it stops is part of using it well.
Cloud DNS is an add-on to Sign In Enterprise, not a standalone product. It uses the same organizations, sites and roles you already manage.
Your Service Gateway already carries the network's DNS to Netgraph. Cisco router as Service Gateway and Cisco SD-WAN are both supported.
Turn the network from plain DNS to Cloud DNS, start from the recommended categories, and shape the policy from there: which categories, which lists of your own, where it applies and when.
The captive-portal service Cloud DNS is an add-on to. Onboarding, sites and roles all come from here.
Read moreThe integration that carries a network to Netgraph. It is what routes DNS to Cloud DNS in the first place.
How it connectsThe service description: the categories, how policies resolve, and what your network needs to provide.
Read the docs Cookies help us improve this site. With your consent we also measure how it is used, with our own analytics and Google Analytics, configured with no advertising or cross-site tracking. Read our Privacy Policy for more.
When you visit our website it may store or retrieve information in your browser, mostly as cookies. This information is used to make the site work as you expect and, with your consent, to understand how it is used. Because we respect your privacy, you can choose not to allow some cookies. Note that blocking some of them may affect your experience.
These cookies are needed for the website to function and cannot be switched off. They are usually set only
in response to actions you take, such as signing in to internal areas or filling in a form. They store no
information that identifies you personally (cookie: ng_learn_session).
With your consent, we measure how the site is used: unique and returning visitors, approximate city and
region, time on a page, and entry and exit pages. This runs on our own first-party cookies
(ng_consent, ng_vid, ng_sid) and on Google Analytics
(_ga), configured so Google gets no advertising or cross-site signals. We never store your IP
address. If you do not allow this, we use only privacy-friendly, cookieless measurement.
