Lab Objective
Configure a router to intercept outbound DNS queries destined for arbitrary resolvers and transparently redirect them toward a designated security-focused DNS server, verifying clients receive DNS responses from the security resolver regardless of which DNS server they were originally configured to use.
Lab Purpose
Cloud-delivered DNS security services work by having every client's DNS queries pass through a security-aware resolver capable of blocking known-malicious domains before resolution completes. Rather than reconfiguring every client's DNS settings individually, network-level interception redirects all DNS traffic transparently at the router, achieving the same security posture without touching endpoint configuration.
Lab Topology
R1
Gi0/0: 192.168.230.1/24 (LAN, clients here
configured with
various DNS servers)
Gi0/1: 203.0.113.1/30 (WAN)
SecurityDNS: 203.0.113.53 (security-focused
resolver, blocks known-malicious
domains)
PC-A configured with DNS server 8.8.8.8
(a completely different, non-security resolver)Task 1: Verify PC-A's Configured DNS Server
Confirm PC-A is explicitly configured to use 8.8.8.8, not the security resolver.
Task 2: Configure a Route-Map Matching DNS Traffic
Create a route-map matching UDP/TCP port 53 traffic from the LAN.
Task 3: Configure PBR to Redirect DNS Traffic
Apply the route-map as a policy redirecting matched DNS traffic to the security resolver's address, regardless of its original destination.
Task 4: Verify PC-A's DNS Queries Are Transparently Redirected
Confirm PC-A's DNS queries, despite being sent toward 8.8.8.8, are actually answered by the security resolver.
Task 5: Verify a Query for a Known-Malicious Domain Is Blocked
Query a domain the security resolver is configured to block and confirm resolution fails or returns a sinkhole address, rather than the real answer.
Solution and Verification
PC-A> ipconfig /all | findstr "DNS Servers"
DNS Servers: 8.8.8.8
-- Confirmed PC-A is explicitly pointed at
-- a completely different, non-security
-- DNS serverR1(config)# access-list 150 permit udp 192.168.230.0 0.0.0.255 any eq 53
R1(config)# access-list 150 permit tcp 192.168.230.0 0.0.0.255 any eq 53R1(config)# route-map REDIRECT-DNS permit 10
R1(config-route-map)# match ip address 150
R1(config-route-map)# set ip next-hop 203.0.113.53
-- Similar in structure to the PBR lab
-- covered earlier in this series, but here
-- specifically targeting DNS port traffic
-- for redirection to a security resolver
-- rather than an alternate WAN pathR1(config)# interface gigabitethernet0/0
R1(config-if)# ip policy route-map REDIRECT-DNSPC-A> nslookup example.com 8.8.8.8
Server: [unable to reach 8.8.8.8 directly
by name, but response arrives]
Address: 93.184.216.34
-- PC-A believes it queried 8.8.8.8, but
-- the response actually came from
-- SecurityDNS due to the transparent PBR
-- redirection -- the client's own DNS
-- configuration was never touchedR1# show route-map REDIRECT-DNS
route-map REDIRECT-DNS, permit, sequence 10
Match clauses:
ip address (access-lists): 150
Set clauses:
ip next-hop 203.0.113.53
Policy routing matches: 47 packets, 4230 bytes
-- Match counter confirms DNS traffic is
-- actually being redirected, not merely
-- configuredPC-A> nslookup known-malicious-domain.test 8.8.8.8
Server: [redirected to SecurityDNS]
*** Request failed / non-existent domain
-- The security resolver's blocking policy
-- for this known-malicious domain applies
-- transparently, since all DNS resolution
-- for this client now genuinely passes
-- through SecurityDNS regardless of the
-- client's own configured serverKey Takeaway
Policy-Based Routing, covered earlier in this series for general path steering, applies equally well to enforcing DNS security posture network-wide without touching individual client configuration — matching specifically on port 53 traffic and redirecting it toward a security-aware resolver achieves the same practical outcome as manually reconfiguring every endpoint's DNS settings, but centrally, consistently, and without depending on endpoint compliance with an administratively pushed DNS setting that a user could otherwise change back.