Course contents

Unit 6: Advanced securityLesson 6.12 (8 of 11 in this unit)10 of 25 in the Advanced Cisco SD-WAN course

DNS web layer security

Sending DNS queries to a cloud resolver for filtering: how the policy is applied, local domains, the order of DNS and web filtering, and failure behaviour.

Advanced · 11 min read

You'll learn to explain how DNS queries from a service VPN reach a cloud resolver, keep internal domains local, predict what DNS filtering misses, and verify the policy.

Technical definition

DNS-layer security sends clients' DNS queries to a cloud resolver that refuses to answer for malicious or policy-blocked domains. The connection is stopped at the name lookup, before any traffic goes to the site.

Stopping the lookup before the connection

Almost every connection to a named site begins with a DNS query (see the DNS lesson). Malware and phishing sites need names too. If the resolver refuses to give their addresses, the connection does not start and the other web controls have nothing to do. That is the idea of DNS-layer security. Cisco's service for it has been called Umbrella. Product names and packaging change, so check the current naming in the documentation.

How the edge applies it

On a WAN Edge (cEdge/vEdge) the feature is built from an SD-WAN Manager policy that is attached to service VPNs. The edge intercepts DNS queries from clients in those VPNs and forwards them to the cloud resolver, instead of letting them go to the DNS server the client was given.

  1. A client at BR-01 in VPN 10 asks for a name. The query goes to the router, which is the client's DNS path or sits in front of it.
  2. The DNS security policy matches the VPN. The edge checks the name against the local domain list.
  3. If the name is a listed local domain, the query goes to internal DNS as before.
  4. Otherwise it goes to the cloud resolver, with information that identifies the organisation (see below).
  5. The resolver compares the name with the organisation's policy. If it is blocked, the answer points to a block page or fails. If it is allowed, the true address comes back and the client connects.
Stopping the lookup before the connection
Stopping the lookup before the connectionA user's device asks BR-02 to resolve a domain. BR-02 sends the lookup to a cloud DNS-layer security service. If the domain is malicious, the service answers with a block, so the connection never starts. If it is safe, the real address is returned and the user connects. Local domains are kept out of this path and resolved by the internal DNS server.DeviceBR-0210.255.2.2Cloud DNS securityInternal DNScorp.example local onlyMalicious domain: blocked at the lookupSafe domain: address returned, user connects

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Blocking at the lookup is cheap and early. Keep internal names local, and decide what happens if the cloud resolver cannot be reached.

Identifying the organisation to the service

The cloud service must know whose policy to apply. In SD-WAN the edge is registered with the service using credentials or an API token created in the cloud console, and queries carry an identity such as the device or network identity. Where you enter the token in SD-WAN Manager, and which identity options exist, depends on your release. Keep tokens out of documents and tickets: store them in the Manager only, and rotate them if exposed. This lesson does not show example secrets.

Local domains must stay local

A public cloud resolver does not know your private zones. If a query for corp.example.net or an Active Directory name goes to it, the answer is an error, and logins or file shares fail. The policy therefore has a list of local domains that bypass the cloud and go to internal DNS.

Local domains must stay local
Local domains must stay localQuery; Goes to; Reason. app.corp.example.net (internal application, 10.20.1.0/24): Internal DNS On the local domain list _ldap._tcp.dc._msdcs.corp.example.net (Active Directory service lookup): Internal DNS Same private zone www.example.org: Cloud resolver Public name, filtered by the serviceQueryGoes toReasonapp.corp.example.net(internal application,10.20.1.0/24)Internal DNSOn the local domain list_ldap._tcp.dc._msdcs.corp.example.net (ActiveDirectory servicelookup)Internal DNSSame private zonewww.example.orgCloud resolverPublic name, filtered by the service

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Read each row across: the left box names the item, the others describe it.

Include every private zone: reverse zones, split-horizon names and partner zones reached over the overlay. A missing entry usually shows up as one application that cannot resolve a name while the web works.

Encrypting the DNS path

Ordinary DNS is plain text on UDP or TCP port 53, so anyone on the path can read or alter it. The cloud service supports encrypting the path between the edge and the resolver. The name used by that service for its protocol is DNSCrypt. Check whether your release offers the option, and whether your platform and service combination supports it. It protects the path to the cloud. It does not change what the policy blocks.

Where it sits in the order of controls

DNS-layer blocking acts first, at the lookup. If a name is blocked, the connection does not happen, so URL filtering and the file scanning behind it do not see it. If a name is allowed, URL filtering and the other web controls still apply to the connection afterwards. The layers add up: DNS filtering is cheap and early, while URL filtering is more detailed.

The gaps worth knowing:

  • IP-literal connections. There is no lookup, so DNS filtering cannot act.
  • Other resolvers. A client or application that uses a different DNS server directly, or DNS over HTTPS to a public provider, goes around the edge's interception. If the policy needs to cover them, block those paths with firewall policy and keep clients on the intended resolver. Test with a client that has its own DNS settings.
  • Cached answers. A name resolved before the block may keep working until its cache entry expires.
Why is DNS-over-HTTPS a problem for this design?

DNS over HTTPS looks like ordinary HTTPS traffic to a web server. The edge cannot tell it from browsing unless it knows the resolver's addresses or names. A browser configured to use such a resolver skips the cloud security policy entirely. Organisations that rely on DNS-layer security often block known public DoH resolvers and set the browser policy centrally.

If the cloud resolver cannot be reached

The edge depends on the resolver for every external name. If the path fails, queries can time out, and users see a total web outage even though the circuit is up. A release may let the edge fall back to another resolver, which keeps users working but loses the filtering. Failing (no answer) is safer for security, falling back is safer for availability. This is a design decision, so check what your release offers, decide on purpose, and test it by blocking the path in the lab.

Verifying the policy

  1. In SD-WAN Manager, confirm the DNS security policy is attached to the intended VPNs only (for example 10 and 30 in the lab, not 20 voice) and that the template push succeeded.
  2. Confirm the local domain list contains every private zone.
  3. From a client in the VPN, look up a public name and an internal name.
  4. Use the test domain the service provides for checking that blocking works. The service documents how: look it up in the current documentation, since names and addresses change.
  5. Confirm the event shows in the cloud console against the organisation's identity.
nslookup app.corp.example.net nslookup www.example.org

Run on a client in VPN 10. The first name should answer from the internal DNS server. The second should answer from the cloud resolver's path. Compare the answering server's address in each output.

Example output written for this lesson, simplified; real output has more fields and a different layout
C:\>nslookup app.corp.example.net
Server:   dns.corp.example.net
Address:  10.20.1.53

Name:     app.corp.example.net
Address:  10.20.1.20
Example output for the lab. The internal name was answered by an internal server, which is what the local domain bypass should give. If the answer was an error from a public address, the domain is missing from the bypass list.

Test yourself on DNS-layer security

Predict · scenario 1

After DNS security is enabled for VPN 10, the web works but domain logins to app.corp.example.net fail. What is the likely fix?

Predict · scenario 2

A user connects directly to http://203.0.113.45 and reaches a site the cloud policy blocks by name. Why?

Predict · scenario 3

Which control sees the connection first for an allowed name: DNS-layer security or URL filtering?

Predict · scenario 4

A browser on a branch PC uses DNS over HTTPS to a public provider, and a blocked domain loads. What do you check?

FAQ

Where is the list of blocked domains defined?
In the cloud security service, not on the edge. The edge's policy decides which VPNs send queries to the service and which domains stay local. The service's own policy decides what is blocked for your organisation.
Will this break Active Directory?
It can, if internal domain names are sent to a public resolver that does not know them. Add the internal domains to the local domain bypass list so those queries go to internal DNS. Test with a domain-joined client before the rollout.
Does DNS filtering stop a user who types an IP address?
No. A connection to an IP address needs no DNS lookup, so there is nothing for the DNS layer to block. Other controls, such as a firewall policy or URL filtering, cover that case.