Palo Alto Networks DNS Security Deep Dive (PCNSE Focus)

DNS Security is a critical component of the Palo Alto Networks platform, designed to combat threats that leverage the Domain Name System (DNS). It utilizes a combination of cloud-based threat intelligence, machine learning, and firewall policy enforcement to prevent connections to malicious domains associated with malware, command-and-control (C2), phishing, and other threats like DNS Tunneling and Domain Generation Algorithms (DGA).

Enable DNS Security

Base DNS Security functionality is enabled by configuring DNS policy actions within an Anti-Spyware profile and applying that profile to Security Policy rule(s) that permit DNS traffic (typically UDP/53 and TCP/53).

Prerequisites & Initial Verification

1. Licenses: Verify active DNS Security AND Threat Prevention (or Advanced Threat Prevention / Advanced URL Filtering) licenses under Device > Licenses . DNS Security leverages TP threat intelligence. The specific categories available may depend on the exact license bundle.
2. Content Database: Ensure the firewall has a recent Applications and Threats content database installed ( Device > Dynamic Updates ). DNS signatures are delivered via these updates.
3. Connectivity: The firewall requires HTTPS (TCP/443) connectivity to the Palo Alto Networks DNS Security cloud ( dns.service.paloaltonetworks.com globally, or regional clouds like dns.eu.service.paloaltonetworks.com ). Configure Service Routes ( Device > Setup > Services > Service Route Configuration ) if the Management interface lacks internet access. Verify connectivity using show dns-proxy dns-signature info .
4. App-ID Allow (Perimeter): If management/service route traffic traverses another firewall, ensure the paloalto-dns-security App-ID is allowed on that perimeter device.
5. DNS Proxy/Resolution: The firewall itself must be able to resolve external FQDNs for cloud connectivity. Configure DNS servers under Device > Setup > Services . Consider using DNS Proxy ( Network > DNS Proxy ) for internal clients if you want the firewall to handle their DNS requests directly.

Configuration Steps (PAN-OS 10.x/11.x+)

The main configuration is done within an Anti-Spyware profile.

1. Navigate to Objects > Security Profiles > Anti-Spyware .
2. Create a new profile or clone/modify an existing one (cloning 'default' is a good starting point). Give it a descriptive name.
3. Select the DNS Policies tab.
4. Configure Actions per Signature Source: This section lists DNS threat categories derived from cloud lookups and content updates. For each category (Malware, C2, Phishing, DGA, DNS Tunneling, Grayware, Parked, DDNS, Newly Registered Domain (NRD), etc.):
   • Set the desired Policy Action :
     • allow : Permits the DNS query. Useful for benign categories or for monitoring specific threats without blocking (set Log Severity appropriately).
     • block : Drops the DNS query. The client typically receives a timeout or server failure error from its resolver.
     • sinkhole : Forges a DNS response, redirecting the client to a configured Sinkhole IP address. This is the recommended action for many malicious categories (Malware, C2, Phishing) as it helps identify potentially compromised hosts.
     • default : Uses the Palo Alto Networks recommended action for the category (viewable in the profile). It's generally advised to explicitly set actions rather than relying on default.
   • Set the Log Severity (Critical, High, Medium, Low, Informational, None). Logging is crucial for visibility. Best practice often involves logging Medium, High, and Critical events. Informational might be used for categories like Parked or NRD if monitoring is desired.
   • (Optional) Enable Packet Capture : single-packet or extended-capture for deeper analysis of specific threat types, though this increases resource usage.
   PCNSE Exam Focus: Know the available actions (allow, block, sinkhole) and their effects. Understand that sinkhole is used for *identification* of potentially compromised hosts by redirecting their malicious requests. Recognize common category names (Malware, C2, DGA, Tunneling, Phishing, NRD, Grayware, Parked, DDNS).
5. Configure DNS Sinkhole Settings:
   • Enable the Sinkhole checkbox if using the sinkhole action for any category.
   • Configure Sinkhole IPv4 and/or Sinkhole IPv6 .
     • Default FQDN: sinkhole.paloaltonetworks.com . Easiest to manage as PAN updates the IP. Relies on client/internal DNS correctly resolving the CNAME provided by the firewall in the forged response.
     • Palo Alto Networks IP: 72.5.65.111 (IPv4). Use this if clients might bypass internal DNS or have issues resolving the FQDN CNAME.
     • Custom IP: An internal server IP (configured with a web server or listener) or a loopback address on the firewall. Allows monitoring traffic *to* the sinkhole IP via firewall logs or the internal server.
   PCNSE Exam Focus: Understand sinkhole configuration options, the difference between FQDN and IP, and when to use each based on client DNS behavior. Know the default Palo Alto sinkhole IP.
6. (Optional in DNS Policies Tab) Block ECH RR Types: Block specific DNS Resource Record types (SVCB Type 64, HTTPS Type 65, ANY Type 255) if policy requires preventing Encrypted Client Hello negotiation.
7. Click OK to save the Anti-Spyware profile.
8. Apply Profile to Security Policy:**
   • Navigate to Policies > Security .
   • Identify or create rule(s) allowing outbound DNS traffic. Ensure the rule correctly identifies DNS traffic:
     • Application: Should ideally be set to dns to catch DNS on standard and non-standard ports. Using specific App-IDs like google-dns is possible but less comprehensive.
     • Service: application-default (uses standard ports defined for the matched application) or a custom service object for UDP/53 and TCP/53.
   • Go to the rule's Actions tab.
   • Under Profile Setting > Type: Select Profiles .
   • In the Anti-Spyware dropdown, select the configured DNS Security profile.
   • Ensure Log at Session End is checked for general traffic visibility. DNS Security actions generate Threat logs independently based on profile severity settings.
   • Click OK .
9. Commit the configuration changes to the firewall.

PAN-OS 10.0+ Upgrade Note: Upon upgrading to PAN-OS 10.0 or later, the DNS Security categories are restructured. This means any custom actions (block/sinkhole/allow) or logging severities configured for the older categories will be overwritten by the default settings of the *new* categories. You MUST review and reapply your desired settings to the new categories within the Anti-Spyware profile after such an upgrade.

Verification Methods

• **Test Domains:** Access Palo Alto Networks test domains (listed previously, e.g., test-malware.testpanw.com , test-c2.testpanw.com ) from a client behind the firewall to trigger alerts/blocks/sinkholes based on your policy.
• **Threat Logs:** Check Monitor > Logs > Threat . This is the primary log for DNS Security events.
  • Filter by subtype: ( subtype eq 'dns' )
  • Filter by action: ( action eq sinkhole ) or ( action eq block ) or ( action eq allow )
  • Filter by category: ( category-of-threatid eq dns-malware ) , ( category-of-threatid eq dns-c2 ) , etc. (Use `adns-` prefix for Advanced DNS categories).
  • Examine log details: Look at Threat Name (often includes the queried domain), Category, Action Taken, Source/Destination IP, Rule matched.
• **Traffic Logs:** Check Monitor > Logs > Traffic to see if the initial DNS sessions themselves are allowed or denied by Security Policy rules.
• **Sinkhole Verification:** If using sinkholing, check Threat Logs for entries related to the sinkholed category. Also, attempt to connect from the client to the Sinkhole IP address configured on the firewall - Security Policy should ideally block or alert on this traffic for easy identification of potentially compromised hosts.
• **CLI - Check Category:** test dns-proxy dns-signature fqdn - Shows the cloud-cached category, Global Threat ID (GTID), and Time-To-Live (TTL) for a domain.
• **CLI - Check Cloud Connection:** show dns-proxy dns-signature info - Verifies connectivity status to the base DNS Security cloud service.
• **CLI - Show Counters:** show counter global filter aspect dns | match signature - Shows counters for DNS signature processing, cache hits/misses, lookups etc.

Enable Advanced DNS Security

Advanced DNS Security (requires PAN-OS 11.2+, Content 8832+) enhances protection by adding real-time analysis of DNS responses using cloud-based machine learning to detect DNS hijacking (malicious redirection) and monitoring configured zones for DNS misconfigurations.

Prerequisites & Licensing

1. Base DNS Security configured and functional.
2. PAN-OS 11.2+ and Applications and Threats Content Release 8832+.
3. Active Advanced DNS Security license (subsumes base DNS Security license). Verify under Device > Licenses .
   The Advanced DNS Security license subsumes the base DNS Security license. If you have both, the Advanced license governs functionality and expiry. Downgrading PAN-OS retains base DNS functionality under the Advanced license.
4. Updated Firewall Device Certificate ( Device > Certificates > Device Certificates ) for cloud authentication.
5. Connectivity to Advanced DNS Security cloud (`adv-dns.service.paloaltonetworks.com`).
6. (If applicable) Proxy server configured for Inline Cloud Services ( Device > Setup > Services , PAN-OS 11.2.3+).

Configuration Steps

1. Navigate to the relevant Anti-Spyware profile's DNS Policies tab ( Objects > Security Profiles > Anti-Spyware ).
2. Configure Log Severity and Policy Action for the "Advanced DNS Security" categories:
   • DNS Misconfiguration Domains : Detects issues like dangling records within your own configured zones. Action typically alert or allow with logging.
   • Hijacking Domains : Detects malicious redirection in DNS responses. Action typically block or sinkhole .
   • (PAN-OS 11.2+) Additional categories like adns-malware , adns-c2 etc., based on real-time response analysis. Configure actions according to security policy.
   PCNSE Exam Focus: Differentiate Advanced categories (Hijacking, Misconfiguration) from base categories. Note the adns- prefix in logs for threats found via *response* analysis.
3. (Optional) Add your organization's public parent domains (e.g., `mycompany.com`) to the DNS Zone Misconfigurations list within the profile's DNS Policies tab to enable monitoring of those specific zones. TLDs/root domains cannot be added.
4. (Optional) Adjust the Advanced DNS Security Timeout under Device > Setup > Content-ID > Advanced DNS Security (Default: 100ms). CLI: set deviceconfig setting adns-setting max-latency . If lookup exceeds timeout, analysis is skipped for that query.
5. Commit changes.

Verification Methods

• **Threat Logs:** Check Monitor > Logs > Threat . Filter for Advanced categories, e.g., `( category-of-threatid eq adns-hijacking )`. Examine Threat ID details for specifics (e.g., hijacked IP).
• **CLI - Cloud Connection:** show ctd-agent status security-client - Verify `ADNS` and `AdnsTelemetry` clients show 'connected'.
• **CLI - Latency:** debug dataplane show ctd feature-forward stats - Check `PAN_CTDF_DETECT_SERVICE_ADNS` round-trip time (RTT) stats.
• **Strata Cloud Manager:** View Dashboards > More Dashboards > DNS Security for Misconfigured Domains and Hijacked Domains widgets (requires cloud connection and AIOps/SLS).

DNS Security Over TLS (DoT) Inspection

DoT encrypts standard DNS queries using TLS, typically over TCP port 853 . Inspection requires decrypting this specific traffic.

1. Decryption Policy:** Create a rule in Policies > Decryption .
   • Rule Name: e.g., `Decrypt-DoT`
   • Source/Destination Zones/Addresses: Define as needed to match potential DoT traffic flows.
   • Service: Create a custom service object for tcp/853 .
   • URL Category: Typically `any` unless targeting specific DoT servers.
   • Action: Set to Decrypt .
   • Type: Select SSL Forward Proxy .
   • Profile: Attach an appropriate Decryption Profile (e.g., one that blocks sessions with untrusted issuers or expired certificates).
2. Security Policy:** Ensure a Security Policy rule allows the decrypted DNS traffic.
   • Rule Name: e.g., `Allow-Decrypted-DNS`
   • Source/Destination: As needed.
   • Application: Match dns-base (this is what the decrypted DoT traffic becomes).
   • Service: Match standard DNS ports (e.g., service-udp-53 , service-tcp-53 or use application-default if the `dns-base` app definition includes these).
   • Action: `Allow`.
   • Profiles: Attach the Anti-Spyware profile containing your DNS Security settings.
3. Commit changes.

DNS Security Over DoH Inspection

DoH tunnels DNS requests inside HTTPS traffic, typically over TCP port 443 . Inspection requires targeted decryption of known DoH resolvers, as decrypting all HTTPS is impractical and potentially undesirable.

1. Custom URL Category:** Create a list ( Objects > Custom Objects > URL Category ) named e.g., `Approved-DoH-Resolvers`. Add the specific FQDNs/URLs of the DoH resolvers your organization permits (e.g., `cloudflare-dns.com`, `dns.google`, `dns.quad9.net`).
2. Decryption Policy:** Create a rule in Policies > Decryption .
   • Rule Name: e.g., `Decrypt-Approved-DoH`
   • Source/Destination: Define as needed.
   • URL Category: Select the Approved-DoH-Resolvers custom category created above.
   • Service: Typically `service-https` or `any`.
   • Action: Set to Decrypt .
   • Type: SSL Forward Proxy .
   • Apply an appropriate Decryption Profile.
3. Security Policy (Allow Approved):** Create a Security Policy rule placed above general web browsing rules.
   • Rule Name: e.g., `Allow-Inspect-DoH`
   • Source/Destination: As needed.
   • Application: Match dns-over-https .
   • URL Category: Match the Approved-DoH-Resolvers custom category.
   • Service: `application-default` (will resolve to port 443 for DoH).
   • Action: Allow .
   • Profiles: Attach the Anti-Spyware profile with DNS Security settings enabled.
4. Security Policy (Block Unapproved - Recommended):** Create a Security Policy rule below the allow rule, but generally above broad web access rules.
   • Rule Name: e.g., `Block-Unapproved-DoH`
   • Source/Destination: As needed.
   • Application: Match dns-over-https .
   • URL Category: Match the predefined category encrypted-dns (this category identifies known DoH services).
   • Service: `application-default`.
   • Action: Deny .
5. Commit changes.

Domain Exceptions and Allow / Block Lists

Overrides are configured within the relevant Anti-Spyware profile ( Objects > Security Profiles > Anti-Spyware ).

• DNS Exceptions Tab > Show all signatures: To handle a false positive where DNS Security incorrectly flags a domain, find the specific DNS-related Threat ID in the Threat Logs. Add this Threat ID to the exception list within the profile and set its action to exception . This overrides the default category action *only* for that specific signature.
• DNS Exceptions Tab > DNS Domain/FQDN Allow List: To completely trust certain domains (e.g., internal domains, critical partners) and bypass *all* DNS Security checks (including category lookups and signature checks) for them, add the FQDN (e.g., `server.internal.corp`) or domain with a wildcard (e.g., *.trustedpartner.com ) to this list. This has the absolute highest precedence .
• DNS Policies Tab > External Dynamic Lists (EDL): You can reference Domain-type EDLs within the DNS Policies rules. You can assign actions like `allow`, `block`, or `sinkhole` to domains matching the EDL.
  If a domain matches both an EDL rule and a built-in DNS Security category rule, the action defined for the built-in category takes precedence if there's a conflict (e.g., EDL says allow, Category says block -> it will be blocked). Use the FQDN Allow List for guaranteed allow actions.

Mermaid Diagrams

DNS Security Basic Flow (Sinkhole Example)

DoH Decryption and DNS Security Flow

DNS Security Quiz