TTechclick ⚡ XP 0% All lessons
Palo Alto · Cloud-Delivered Security · DNS SecurityInteractive · L1 / L2 / L3

Palo Alto DNS Security: — Block Malicious Domains, Catch DGA & Tunneling, and Sinkhole to Find Patient Zero

Almost every malware infection makes a DNS call before it does anything else — that is the moment to catch it. This lesson shows how Palo Alto's cloud DNS Security service blocks malicious domains, spots DGA and DNS tunneling, and how the sinkhole action turns a hidden infection into the exact PC you need to clean.

📅 2026-06-11 · ⏱ 12 min · 3 live demos · 4 infographics · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

Palo Alto DNS Security for PCNSE/PCNSA: cloud DNS policies inside Anti-Spyware, DGA & DNS tunneling detection, and DNS sinkholing to find the infected host (patient zero).

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

Why DNS Security

Malware calls home by DNS — catch it at the lookup.

 2

Inside Anti-Spyware

DNS Policies, the cloud, and the four actions.

 3

Sinkhole = patient zero

Forge the reply, then read the traffic log.

 4

Exceptions, licence, exam

False positives, the licence, PCNSE angle.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. On a Palo Alto firewall, where do you configure DNS Security policy?

Answered in Why DNS Security.

2. Your internal AD DNS server sits between users and the firewall. With plain 'block', whose IP does the threat log show for a malware lookup?

Answered in Sinkhole = patient zero.

3. What does the 'sinkhole' action actually do to a malicious DNS query?

Answered in Inside Anti-Spyware.

Most engineers think…

Most engineers hear "DNS Security" and assume it's a separate security profile you add — like Antivirus or URL Filtering — and that turning it to block is the strong, finished setup.

Wrong on both counts, and it costs you in incident response. DNS Security is not its own profile — it's a set of DNS Policies inside the Anti-Spyware profile that phone a cloud service for a per-domain verdict. And plain block is actually the weaker choice when an internal DNS server is in the path: it stops the call but the threat log only shows the DNS server as the source, so you can't tell which PC is infected. The stronger setting is sinkhole — it forges the answer so the real infected host reveals itself in your traffic log. Block hides patient zero; sinkhole hands you their name.

① Why DNS Security — malware phones home before it does anything

Meet Sneha, an L1 SOC analyst at Infosys. A laptop on the trust zone gets infected. Before that malware steals a single file, it has to find its boss — the attacker's command-and-control server. And the very first thing it does is a DNS lookup for a domain like evil-c2.example. Unit 42's research found that nearly 80% of malware uses DNS to kick off C2. That lookup is the earliest, cheapest place to catch an infection — long before any payload moves.

So why not just keep a blocklist of bad domains? Because modern malware is built to defeat exactly that. DGA malware generates thousands of throwaway domains from an algorithm — by date, by a cryptographic seed — and the attacker registers just one. By the time a human adds it to a blocklist, the malware has moved to tomorrow's domain. Other malware hides data inside DNS itself: DNS tunneling smuggles stolen files out one TXT record at a time, riding the port-53 traffic almost every firewall allows.

That is what DNS Security is built for. Instead of a small static list, the firewall asks a cloud service about every domain in real time, and that cloud runs inline machine-learning models trained on tens of billions of domains. It catches the algorithmically-generated domain it has never seen before, and the tunneling pattern hidden in otherwise-normal queries. This lesson ties straight back to blog 03's Anti-Spyware profile — because that is literally where DNS Security lives.

👉 So far: malware does DNS first, static blocklists lose to DGA and tunneling, so DNS Security asks a cloud brain per domain. Next: where exactly it sits and the four actions it can take.
Figure 1 — Where DNS Security actually sits
DNS Security is not its own profile — it is a set of DNS policies living inside the Anti-Spyware profile, asking the cloud about every domain An architecture diagram. On the left, an infected internal host on the trust zone makes a DNS query. The query passes the Palo Alto NGFW, which carries an Anti-Spyware security profile. Inside that profile sit two engines: the local DNS signatures downloaded with content updates, and the DNS Policies tab that calls the cloud DNS Security service over HTTPS for a real-time verdict on every domain. The verdict drives one of four actions: allow, alert, block or sinkhole. Red marks the malicious domain on the internet; blue marks the trusted inspected path; amber marks the policy decision point; green marks the clean allowed path. DNS Security lives INSIDE the Anti-Spyware profile — not a profile of its own Infected host10.20.30.15 · trust zonequeries evil-c2.exampleDNS → 10.20.30.10 (AD DNS) PA NGFW · Anti-Spyware profile Local DNS signaturesdownloaded with content updates · ~on-box listsmall, static — first line DNS Policies tab → DNS Security cloudC2 · DGA · DNS tunneling · Malware · NRD …real-time lookup per domain (HTTPS) action = allow · alert · block · sinkhole DNS Security cloudUnit 42 · inline-ML verdictstens of billions of domains Attacker C2 server203.0.113.66 · the real bad IP DNS query ask cloud would-be real reply (forged away) Key: the profile NAME is Anti-Spyware; DNS Security is the cloud brain it phones malicious / internettrusted / inspectedDNS policy decisionkey insightclean / allowed
Look for the nesting: the profile is named Anti-Spyware; the DNS Policies tab is the part that phones the DNS Security cloud. Local signatures are the small on-box first line; the cloud is the real-time brain.
Daily-life analogy — the society guard checking a visitor against a live list

Think of your apartment society's guard at the gate. An old guard had a paper register of banned visitors (the static blocklist) — useless if the troublemaker shows up under a new name. DNS Security is the guard who radios the central control room for every single visitor: "Anyone with this face or this behaviour, even a new name?" The control room (the cloud) has seen the scam across every society in the city and recognises the pattern, not just the name. That live check is why DGA's daily new domains still get caught.

The four threats DNS Security is really aimed at

Tap each card — these are the DNS-borne threats a static blocklist can't keep up with, and the headline categories you'll set actions on.

📡
C2 callback
tap to flip

Malware does a DNS lookup to find its boss server. Catch the lookup and the infection is cut off before it acts.

🎲
DGA domains
tap to flip

Algorithm spins thousands of throwaway domains daily; attacker registers one. Cloud ML spots the pattern a blocklist never can.

🕳️
DNS tunneling
tap to flip

Stolen data hidden inside DNS queries on port 53. Looks like normal lookups; ML flags the smuggling behaviour.

🆕
Newly-registered
tap to flip

Domains minted in the last ~32 days are statistically risky. A category you can alert or block on outright.

Quick check · Q1 of 10

Rahul at TCS argues: "We already have a blocklist of 50,000 bad domains, so DNS Security is overkill." What's the single best reason DNS Security still matters?

Correct: a. DGA malware mints thousands of brand-new domains a day and tunneling hides in normal-looking queries — a static 50k list can't keep up. DNS Security asks a cloud service running inline ML per domain. It isn't about speed; it lives inside Anti-Spyware (doesn't replace it); and it inspects DNS, it doesn't encrypt it.

Pause & Predict

Predict: if 80% of malware uses DNS for its first C2 call, what's the advantage of stopping the attack at the DNS lookup rather than waiting to block the C2 connection later? Type your guess.

Answer: You cut the attack off at its earliest, cheapest point — before any session to the C2 server is even attempted, before payloads or stolen data move. The DNS query happens first, so a verdict there is a verdict before damage. It's also lighter than deep-inspecting every later packet, and it works even when the eventual C2 IP is one you've never seen — because you matched the domain, not the destination IP.

② Inside the Anti-Spyware profile — DNS Policies, the cloud, and the four actions

Here is the part that trips up every new admin: there is no "DNS Security" profile in the GUI. You configure it under Objects > Security Profiles > Anti-Spyware, then open the DNS Policies tab. That ties DNS Security to blog 03's Anti-Spyware lesson — the same profile that catches spyware phone-home traffic also carries your DNS rules. Once configured, you attach the Anti-Spyware profile to a Security policy rule (or, better, a Security Profile Group) — exactly as you learned for the other profiles.

Inside DNS Policies you'll see two kinds of signature source. Local DNS signatures are a smaller set downloaded with your regular content updates — they work even with no cloud reachability, but they're static. Below them sits the DNS Security source: the live cloud categories. With a valid licence the firewall queries the cloud per domain and gets back a category and a verdict.

Each DNS Security category — Command-and-Control, Malware, DGA, DNS Tunneling, Newly Registered Domains, Phishing, Dynamic DNS, Grayware, Parked, Proxy Avoidance — gets its own policy action and log severity. The four actions are allow, alert, block, and sinkhole. Palo Alto's recommended default for the malicious DNS categories is sinkhole — and the next section is the whole reason why.

🖥️ This is the screen you'll use — Objects > Security Profiles > Anti-Spyware > (your profile) > DNS Policies. Set the cloud categories to sinkhole and enable the sinkhole IPs. (Recreated for clarity — your console matches this.)
PA-VM · Objects · Security Profiles · Anti-Spyware · DNS Policies
1
Signature Source
DNS Security (cloud)
2
Command-and-Control Domains
sinkhole
Malware Domains
sinkhole
Log Severity
medium
3
DNS Sinkhole Settings · enable
✓ Sinkhole
4
Sinkhole IPv4
sinkhole.paloaltonetworks.com (default)
Sinkhole IPv6
::1 (default)
OK

About those defaults: the Sinkhole IPv4 ships as the loopback FQDN sinkhole.paloaltonetworks.com and Sinkhole IPv6 as ::1. The FQDN resolves to a Palo-Alto-hosted address — which, importantly, changed from the old 72.5.65.111 to 198.135.184.22. If your team ever hard-coded the old IP into an EDL or a security rule, that stale entry will quietly break your sinkhole detection. Many shops instead point the sinkhole at an unused internal IP (say 172.16.255.1) so the bogus connections never leave the building.

▶ Watch one malicious lookup get sinkholed

An infected host at the Wipro Pune branch tries to reach its C2 server. Follow the DNS query through the firewall as DNS Security forges the answer. Press Play for the healthy path, then Break it to see the failure.

① Query10.20.30.15 asks AD DNS 10.20.30.10 for evil-c2.example
▼
② Cloud verdictDNS server recurses out; firewall asks cloud → Command-and-Control, action = sinkhole
▼
③ Forge replyfirewall returns A record = sinkhole IP, not the real C2 203.0.113.66
▼
④ Host self-reports10.20.30.15 connects to sinkhole IP → Traffic log names the host
Press Play to step through the healthy path. Then press Break it.
CLI — confirm DNS Security is licensed and the cloud is reachable
admin@PA-VM> show dns-security counters cloud all
admin@PA-VM> request license info
Expected output
DNS Security cloud connection:    connected
Last query latency (ms):          42
Queries sent / replies:           18342 / 18342
Cache hit ratio:                  0.91

License: DNS Security        Expires: November 30 2026
License: Threat Prevention   Expires: November 30 2026
Common mistake — "DNS Security is on, but nothing is being caught"

Symptom: you set the categories to sinkhole, but the threat log is empty even for test-c2.testpanw.com. Cause is almost always one of three things: (1) the Anti-Spyware profile is configured but not attached to the Security rule the traffic actually hits; (2) the DNS Security licence isn't active, so only the small local signature set runs; or (3) the rule allowing DNS doesn't have logging enabled. Fix: attach the profile (or its Security Profile Group) to the right rule, confirm request license info shows DNS Security active, and enable log forwarding.

Quick check · Q2 of 10

Aditya at HCL says: "I added a DNS Security profile to my rule but it does nothing." What's the most likely conceptual error?

Correct: c. DNS Security isn't a separate profile — it lives in the Anti-Spyware profile's DNS Policies tab, and that Anti-Spyware profile (ideally in a Security Profile Group) must be attached to the Security rule the traffic hits. No reboot is needed, it isn't 12.x-only, and it inspects transit data-plane DNS, not the management interface.

Pause & Predict

Predict: the DNS Sinkhole Settings ship with IPv4 = sinkhole.paloaltonetworks.com and IPv6 = ::1. Why might a security team change the IPv4 to an unused INTERNAL address like 172.16.255.1 instead? Type your guess.

Answer: So the forged 'connect to sinkhole' traffic never leaves their network. With the default hosted FQDN, infected hosts try to reach a Palo-Alto-hosted public IP, which works but sends odd traffic toward the internet and depends on that hosted IP not changing (it did — 72.5.65.111 → 198.135.184.22). Pointing the sinkhole at an unused internal IP keeps the bogus connections inside, where the firewall still logs them as source = real host, and there's nothing live there to actually connect to. The detection value is identical; the traffic stays home.

③ Sinkhole vs block — finding patient zero behind the DNS server

Now the heart of the lesson. In almost every real network, users don't query the internet directly — they ask an internal DNS server (a Windows AD DNS box), which recurses out through the firewall. That detail breaks naive blocking. When malware on 10.20.30.15 looks up a bad domain, the query the firewall sees comes from 10.20.30.10 — the DNS server, not the infected PC. So if you just block, the threat log says the DNS server is the source. You know an infection exists; you have no idea which machine.

Sinkholing solves exactly this. Instead of dropping the query, the firewall forges the DNS answer: it tells the DNS server (which tells the host) that evil-c2.example resolves to the sinkhole IP. The infected host then tries to connect to that sinkhole IP — and that connection is sourced from the real host, 10.20.30.15. It lands in your traffic log with the actual endpoint as the source. You've found patient zero.

Figure 2 — Block-only vs Sinkhole — who shows up in the log
Same infection, two logs: without sinkhole the DNS server hides the host; with sinkhole the real PC shows up so you can quarantine it A two-column comparison. Left, block-only with no sinkhole: when an internal DNS server is in the path, the firewall only sees the DNS server as the source of the malicious query, so the threat log blames 10.20.30.10 for every infected PC and you cannot tell which endpoint is compromised. Right, sinkhole enabled: the firewall forges the answer to a sinkhole IP, the infected host then tries to connect to that IP directly, and the traffic log shows the real host 10.20.30.15 so you can isolate it. Red marks the blind old behaviour; green marks the actionable result. Block-only vs Sinkhole — who shows up in the log Block only — no sinkhole ✗ internal AD DNS server sits in the path ✗ firewall sees DNS server as the query source ✗ threat log SRC = 10.20.30.10 for every host ✗ infection confirmed — but WHICH PC? unknown ✗ you can't quarantine an IP you can't see 3 infected PCs.15 / .22 / .39 DNS server .10all logs blame this One suspect, three real victims hidden Sinkhole enabled ✓ firewall forges reply → sinkhole IP ✓ each infected host calls the sinkhole IP itself ✓ traffic log SRC = the REAL host (.15/.22/.39) ✓ filter (action eq sinkhole) → exact endpoint list ✓ isolate + clean the right PCs in minutes 3 infected PCsall visible sinkhole IPeach host → here Three names, three tickets, three clean-ups Block stops the call; sinkhole ALSO tells you whose machine to fix
Compare the two columns. Left (red): block-only, internal DNS server in the path → every infected PC hides behind 10.20.30.10. Right (green): sinkhole → each real host (.15/.22/.39) connects to the sinkhole IP and names itself in the traffic log.
Figure 3 — How sinkhole turns a hidden infection into a name
Sinkhole forges the DNS reply so the infected host calls a fake IP — and THAT call, sourced from the real host, lands in your traffic log A five-step inspection flow. Step 1 the infected host asks the internal AD DNS server for a malicious domain. Step 2 the DNS server recurses out through the firewall, where DNS Security flags the domain. Step 3 with the sinkhole action, the firewall forges a DNS answer pointing at the sinkhole IP instead of the real attacker IP. Step 4 the host receives the sinkhole IP and tries to connect to it. Step 5 that connection, sourced from the real infected host, is logged in the traffic log to the sinkhole address — that is how you find patient zero. A break note shows what happens with no sinkhole: only the DNS server shows up. How sinkhole turns a hidden infection into a name in your log Infected host10.20.30.15malware on board AD DNS server10.20.30.10recurses outward PA NGFWDNS Security · sinkholeforges the answer 1· query evil-c2.example 2· recurse → flagged C2 3· forged A record = sinkhole IP DNS hands host the sinkhole IP 4· host tries to reach sinkhole IP — sourced from 10.20.30.15, the REAL hostsinkhole.paloaltonetworks.com (IPv4) · ::1 (IPv6) are the defaults 5· Traffic log: SRC 10.20.30.15 → DST sinkhole IP → patient zero foundMonitor > Logs > Traffic (addr.dst in sinkhole-ip) · Threat: (action eq sinkhole) Without sinkhole: the THREAT log shows SRC 10.20.30.10 (the DNS server) — every host looks the sameyou see the infection exists, but not WHICH PC — sinkhole is what unmasks the host malicious / internettrusted / inspectedDNS policy decisionkey insightclean / allowed
Follow the numbered arrows: query (1), recurse + cloud-flag (2), forged sinkhole answer (3), host connects to sinkhole IP sourced from the real host (4), and the traffic log names it (5). Bottom red strip = what you'd see WITHOUT sinkhole.

The find-the-host workflow, step by step. First, confirm the sinkhole is firing: Monitor > Logs > Threat, filter (action eq sinkhole) — each line is a sinkholed lookup with the DNS server as source (that's expected at the DNS layer). Then pivot to Monitor > Logs > Traffic and filter on the sinkhole IP as destination — (addr.dst in 172.16.255.1) — and now the source column shows the real infected hosts. Those source IPs are your quarantine list.

CLI / log filter — list the real infected hosts hitting the sinkhole
# Threat log: confirm sinkhole is acting
(action eq sinkhole)

# Traffic log: the SOURCE column is now patient zero
(addr.dst in 172.16.255.1) and (app eq dns or app eq web-browsing)
Expected output
RECEIVE_TIME        TYPE     SRC IP        DST IP          APP           ACTION
2026-06-11 11:04:18 threat   10.20.30.10   198.51.100.4    dns           sinkhole
2026-06-11 11:04:21 traffic  10.20.30.15   172.16.255.1    web-browsing  allow
2026-06-11 11:06:02 traffic  10.20.30.22   172.16.255.1    web-browsing  allow
2026-06-11 11:09:47 traffic  10.20.30.39   172.16.255.1    web-browsing  allow
# → .15, .22 and .39 are the infected hosts. Quarantine these.

Priya at ICICI faces this

Priya, an L1 analyst, gets a SIEM alert: a known C2 domain was queried from the data centre. The Palo Alto threat log shows the query was blocked — but the source is the AD DNS server (10.20.30.10), so she can't tell which of 400 endpoints is actually infected.

Likely cause

The Anti-Spyware DNS policy is set to block, not sinkhole. With an internal DNS server recursing on behalf of clients, block-only logs the DNS server as the source of every malicious lookup, hiding the real host.

Diagnosis

She switches the malicious DNS categories to sinkhole, points the sinkhole at an unused internal IP, and waits for the malware to query again. Then she reads the TRAFFIC log (not just the threat log) for connections to that sinkhole IP.

Objects > Security Profiles > Anti-Spyware > DNS Policies (set sinkhole) → then Monitor > Logs > Traffic (addr.dst in 172.16.255.1)
Fix

Set the C2/Malware/DGA/Tunneling categories to sinkhole, enable the sinkhole IPs, commit, and confirm the profile is attached to the data-centre Security rule with logging on.

Verify

Within the hour the traffic log shows source 10.20.30.15 connecting to the sinkhole IP — the exact infected host. She isolates that endpoint, and the (action eq sinkhole) threat filter confirms the domain is still being caught.

Prove sinkhole works without waiting for real malware

Don't wait for an infection to test it. From a client behind the firewall, resolve the Palo Alto test domains: nslookup test-c2.testpanw.com, test-dnstun.testpanw.com, test-dga.testpanw.com. If your policy is right, the lookup resolves to the sinkhole IP (not the real address), and Monitor > Logs > Threat filtered on (action eq sinkhole) shows a fresh entry. No hit means the profile isn't attached, the licence is inactive, or logging is off — check those three.

Quick check · Q3 of 10

Karthik at Flipkart asks: "Block already stops the malware reaching its C2. Why bother with sinkhole instead?"

Correct: c. Both stop the C2 call, but with an internal DNS server in the path, block logs only the DNS server as the source — you can't find the infected PC. Sinkhole forges the answer so the host itself connects to the sinkhole IP, putting the real source in the traffic log. It's not about speed, encryption, or IP version.

Pause & Predict

Predict: after enabling sinkhole, the THREAT log still shows the DNS server (10.20.30.10) as the source of the sinkholed query — not the infected host. Is that a misconfiguration? Type your guess.

Answer: No — that's expected and correct. The DNS QUERY genuinely comes from the recursing DNS server, so the threat-log entry for the sinkhole action shows the server. The trick is the next step: because the firewall forged the answer to a sinkhole IP, the infected host then makes its OWN connection to that IP. That connection appears in the TRAFFIC log with the real host as source. So you read the threat log to confirm sinkholing is happening, and the traffic log (filtered on the sinkhole IP) to identify the actual endpoint.

④ Exceptions, the recent CVE, the licence & the exam

No detection is perfect, and one day DNS Security will flag a domain your business genuinely needs — a partner's odd-looking SaaS hostname caught as Grayware, say. The fix is a DNS Exception, not turning the whole category off. Go to Objects > Security Profiles > Anti-Spyware > DNS Exceptions and add the domain to the DNS Domain/FQDN Allow List. That single FQDN is exempted while every other malicious domain stays sinkholed.

One sharp gotcha here: an EDL does not override a DNS Security cloud action. If you try to 'allow' a domain by putting it in a domain EDL, DNS Security can still sinkhole it — the proper exemption path is the DNS Exceptions allow list. Mixing these up is a classic support ticket.

👉 So far: exempt false positives via DNS Exceptions, and EDLs don't override the cloud. Next: a real recent CVE that makes patching non-optional, the licence, and the exam angle.

A sober, current note. Because DNS Security parses untrusted DNS, it has been a target. In December 2024, CVE-2024-3393 — a DoS in the DNS Security feature — was actively exploited: a crafted packet through the data plane could reboot the firewall, and repeated hits dropped it into maintenance mode. More recently, CVE-2026-0229 (published 11 February 2026, CVSS 6.6) is a DoS in the newer Advanced DNS Security feature, triggered when ADNS is enabled with a spyware profile set to block, sinkhole or alert (any non-allow action); it's fixed in PAN-OS 11.2.10 / 12.1.4. The lesson: keeping DNS Security up means keeping PAN-OS patched — a security feature that can be DoS'd is a liability if you skip updates.

Licensing, briefly, because the exam asks: DNS Security needs an active DNS Security licence alongside Threat Prevention (or Advanced Threat Prevention); Advanced DNS Security is its own licence and needs PAN-OS 11.2+. Without the licence, only the small local DNS signatures from content updates apply — fine as a backstop, but it won't catch fresh DGA or tunneling. That local-vs-cloud distinction is a favourite PCNSE question.

Figure 4 — DNS Security — the cheat-sheet
Palo Alto DNS Security on one card — where it lives, the actions, the sinkhole defaults, the find-the-host workflow and the test domains A nine-tile cheat sheet. Tiles cover where DNS Security lives, the four DNS policy actions, the categories, the default sinkhole IPs, the find patient zero log filters, the DNS Exceptions allow list for false positives, local signatures versus the cloud service, the licence requirement, and the test domains plus a recent CVE. DNS Security — your one-glance card Where it livesObjects > Security Profiles >Anti-Spyware > DNS Policiesattach profile to a Security rule 4 policy actionsallow · alert · block · sinkholePAN DNS sigs default = sinkholeblock kills visibility — prefer sinkhole CategoriesC2 · DGA · DNS tunnelingMalware · NRD · Phishing · DDNSeach = own action + log severity Sinkhole defaultsIPv4: sinkhole.paloaltonetworks.comIPv6: ::1hosted IP moved 72.5.65.111→198.135.184.22 Find patient zeroMonitor>Logs>Threat(action eq sinkhole)Traffic: (addr.dst in <sinkhole-ip>) False positive?Anti-Spyware > DNS Exceptionsadd to DNS Domain/FQDN Allow ListEDLs do NOT override cloud action Local vs cloudlocal sigs: in content updates, smallcloud DNS Security: real-time, hugeAdvanced DNS Security = inline ML LicenceDNS Security + Threat Prevention(or Advanced DNS Security)no licence → local sigs only Prove + patchtest-c2.testpanw.comtest-dnstun · test-dga …CVE-2024-3393 / CVE-2026-0229 → patch
Your one-card map of this lesson: where DNS Security lives, the four actions, the categories, the sinkhole defaults, the find-patient-zero filters, exceptions, local-vs-cloud, the licence, and the test domains + CVEs to patch.
Daily-life analogy — the bank's fake-OTP honeypot

Imagine a bank that suspects a scam call centre is phishing its customers. Instead of just blocking the calls (and never learning who fell for it), it sets up a decoy OTP line: anyone tricked into 'confirming' their details gets routed to a harmless internal desk that records who called. The scam is neutralised AND the bank gets a list of exactly which customers to warn. That decoy line is a sinkhole: the malicious lookup is defused, and the real victim reveals themselves so you can help them. Plain block is just slamming the phone down — safe, but you never find the victim.

Refresher: Security Policy FundamentalsSibling: URL Filtering
Prove you own DNS Security

Cold, in 60 seconds: where does DNS Security live (Anti-Spyware > DNS Policies, not its own profile)? Name the four actions (allow / alert / block / sinkhole). Why is sinkhole better than block (it names patient zero when an internal DNS server hides the host)? Where do you find the infected host (Traffic log, addr.dst in the sinkhole IP)? How do you exempt a false positive (DNS Exceptions allow list)? If that's fluent, you're ready for the PCNSE DNS questions and the next lesson.

Quick check · Q4 of 10

An interviewer asks Meera: "Two engineers configure DNS Security. One sets malicious categories to block; the other to sinkhole, pointed at an unused internal IP. The network has an internal AD DNS server. Whose design lets the SOC quarantine the right machine fastest, and why?"

Correct: d. With an internal DNS server recursing, block-only logs the DNS server as the source, hiding which PC is infected. Sinkhole forges the answer so the real host connects to the sinkhole IP, exposing it in the traffic log — the SOC gets a precise quarantine list. Block doesn't make the host irrelevant; the logs are not identical; and sinkhole is specifically the answer FOR the internal-DNS-server case.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from Palo Alto docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

📝 Wrap-up assessment — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Remember

On a Palo Alto firewall, where is DNS Security configured?

Correct: c. DNS Security is not a standalone profile — it's the DNS Policies tab inside the Anti-Spyware profile, which you then attach to a Security rule. Device > Setup is for the firewall's own DNS, and DNS Proxy is an unrelated forwarding feature.
Q6 · Apply

You want malicious DNS categories (C2, Malware, DGA) handled so that you can also identify which internal host is infected. Which action do you set?

Correct: b. Sinkhole forges a reply to a sinkhole IP so the infected host connects to it and appears in the traffic log — that's what lets you find the host. Block stops the call but hides the host behind the DNS server; alert only logs; allow does nothing.
Q7 · Apply

DNS Security flags a legitimate partner SaaS domain as Grayware and starts sinkholing it. What's the correct way to allow just that one domain?

Correct: d. DNS Exceptions is the supported way to exempt one FQDN while keeping every other domain protected. Disabling the whole category is too broad; an EDL does NOT override a DNS Security cloud action; and setting allow for all categories disables protection entirely.
Q8 · Analyze

Sinkhole is enabled. The THREAT log shows sinkholed queries with source = 10.20.30.10 (the AD DNS server), and you're worried you still can't see the infected PC. Where do you actually find patient zero?

Correct: c. The threat-log source is correctly the recursing DNS server. The infected host reveals itself when it connects to the sinkhole IP — that connection is in the TRAFFIC log, filtered on addr.dst = sinkhole IP, with the real host as source. Block would hide the host further, the System log isn't where this lands, and the DNS server is not the infected machine.
Q9 · Analyze

A firewall has the Anti-Spyware profile with sinkhole configured and attached, but a brand-new DGA domain is sailing through with nothing in the threat log. License check shows Threat Prevention active but DNS Security expired. Why is the DGA domain missed?

Correct: a. Without an active DNS Security licence the firewall falls back to the small local DNS signature set; a never-seen DGA domain isn't in it, and the cloud's inline-ML lookup (which would catch it) is unavailable. URL Filtering doesn't cover DNS-layer DGA, the sinkhole IP doesn't gate detection, and no reboot is required.
Q10 · Evaluate

Your manager says: "DNS Security is just an extra blocklist — set everything to block and we're done, no need to patch PAN-OS for it." Evaluate this.

Correct: d. Block stops the call but, with an internal DNS server, hides which host is infected — sinkhole is what surfaces patient zero. And DNS Security isn't risk-free: it processes untrusted DNS and has had real, even actively-exploited, DoS CVEs, so keeping PAN-OS patched is essential. The other options accept the false premise that block is strongest and CVEs are irrelevant.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: In one line, why does the 'sinkhole' action find the infected host when plain 'block' can't, in a network with an internal DNS server? Then compare to the expert version.

Expert version: Because block only logs the recursing DNS server as the query source, but sinkhole forges the DNS reply to a sinkhole IP so the infected host makes its own connection to that IP — and that connection appears in the traffic log sourced from the real host, naming patient zero.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📖 Glossary

DNS Security
Palo Alto's cloud-delivered service that gives the firewall a real-time, ML-backed verdict on every domain queried.
Anti-Spyware profile
The security profile that carries DNS Security; configure it under the DNS Policies tab, then attach it to a Security rule.
DNS sinkholing
Forging a DNS answer to point a malicious domain at a sinkhole IP so the infected host reveals itself in the traffic log.
Sinkhole IP
The address the firewall returns for malicious domains. Defaults: IPv4 sinkhole.paloaltonetworks.com, IPv6 ::1; often set to an internal unused IP.
Patient zero
The actual infected host in an incident — the specific PC making malicious lookups, which sinkhole exposes.
DGA
Domain Generation Algorithm — malware mints thousands of throwaway C2 domains; cloud ML detects the pattern a blocklist can't.
DNS tunneling
Hiding non-DNS data (commands, stolen files) inside DNS queries/responses to slip past firewalls that allow port 53.
Command-and-Control (C2)
Domains/servers malware contacts for instructions or to exfiltrate data; the top DNS Security category.
Newly Registered Domain (NRD)
A domain registered in roughly the last 32 days — statistically high-risk; its own DNS Security category.
DNS Exceptions
The Anti-Spyware tab where you add a false-positive FQDN to the DNS Domain/FQDN Allow List to exempt it.
Local DNS signatures
A smaller static DNS blocklist shipped in content updates; works offline but can't catch fresh DGA/tunneling like the cloud.
Advanced DNS Security
The inline-ML upgrade to DNS Security; needs PAN-OS 11.2+ and its own licence. Subject of CVE-2026-0229.

📚 Sources

  1. PAN-OS / Advanced Threat Prevention Admin Guide — "How DNS Sinkholing Works" (without sinkhole the threat log shows the local DNS resolver, not the infected host; forged response redirects clients to the sinkhole IP). docs.paloaltonetworks.com/advanced-threat-prevention/administration/configure-threat-prevention/use-dns-queries-to-identify-infected-hosts-on-the-network/how-dns-sinkholing-works
  2. PAN-OS Admin Guide — "Configure DNS Sinkholing" + "See Infected Hosts that Attempted to Connect to a Malicious Domain" (Objects > Security Profiles > Anti-Spyware > DNS Policies; default Sinkhole IPv4 = sinkhole.paloaltonetworks.com, IPv6 = ::1; Monitor > Logs > Threat filter (action eq sinkhole) then Traffic log on the sinkhole IP). docs.paloaltonetworks.com/advanced-threat-prevention/administration/configure-threat-prevention/use-dns-queries-to-identify-infected-hosts-on-the-network/configure-dns-sinkholing
  3. DNS Security Administration — "Cloud-Delivered DNS Signatures and Protections" + "Security Profile: DNS Security" (categories: C2, Malware, DGA, DNS Tunneling, NRD, Phishing, Dynamic DNS, Grayware, Parked, Proxy Avoidance; per-category action + log severity; DNS Exceptions allow list; EDLs do not override cloud actions; local vs cloud signatures). docs.paloaltonetworks.com/dns-security/administration/about-dns-security/cloud-delivered-dns-signatures
  4. LIVEcommunity — "New Update in Palo Alto Networks Hosted Sinkhole IP Address" (hosted sinkhole IP changed from 72.5.65.111 to 198.135.184.22; update any EDL/rule that hard-coded the old IP) + "DNS Sinkhole — working or not?" practitioner thread (verify with test domains and the (action eq sinkhole) filter). live.paloaltonetworks.com/t5/community-blogs/new-update-in-palo-alto-networks-hosted-sinkhole-ip-address/ba-p/1224043
  5. Palo Alto Security Advisories — CVE-2024-3393 (DNS Security DoS, actively exploited Dec 2024, reboot/maintenance mode) and CVE-2026-0229 (Advanced DNS Security DoS, CVSS 6.6, published 11 Feb 2026, affects PAN-OS 11.2.0–11.2.9 / 12.1.0–12.1.3, fixed 11.2.10 / 12.1.4, triggered with ADNS + non-allow spyware action). security.paloaltonetworks.com/CVE-2026-0229 · security.paloaltonetworks.com/CVE-2024-3393
  6. Palo Alto PCNSE/PCNSA exam blueprints + DNS Security test domains (test-c2/test-dnstun/test-dga/test-malware.testpanw.com) — Content-ID/Threat-Prevention domain tests DNS sinkhole action, finding infected hosts, local vs cloud signatures and licensing. docs.paloaltonetworks.com/dns-security/administration/configure-dns-security/dns-security-test-domains · paloaltonetworks.com/services/education/certification

What's next?

DNS Security stops the threats that ride DNS. Next we move to the perimeter itself — how Zone Protection and DoS Protection shield your firewall and servers from floods, recon scans and resource-exhaustion attacks before a single policy is even evaluated.

Next · Zone & DoS Protection → Practice on exam.techclick.in →