Introduction to DNS and its Security Importance

What is DNS?

The Domain Name System (DNS) is often called the "phonebook of the internet." It translates human-readable domain names (like www.paloaltonetworks.com ) into machine-readable Internet Protocol (IP) addresses (like 199.167.52.137 ). Without DNS, navigating the internet would require remembering complex numerical IP addresses for every website or service.

This translation process involves a hierarchical and distributed system of DNS servers:

• Recursive Resolvers: Typically provided by your ISP or a public DNS service (like Google's 8.8.8.8 or Cloudflare's 1.1.1.1), these resolvers receive your query and find the authoritative answer.
• Root Servers: There are 13 root server clusters globally that direct queries to the correct Top-Level Domain (TLD) servers.
• TLD Servers: These servers manage specific top-level domains like .com , .org , .net , .gov , etc. They point the resolver to the authoritative nameserver for the specific domain.
• Authoritative Nameservers: These servers hold the actual DNS records (A, AAAA, CNAME, MX, TXT, etc.) for a specific domain and provide the definitive IP address or other requested information.

Why is DNS Security Crucial?

Because DNS is fundamental to nearly all internet activity, it's a prime target for attackers. Compromising DNS can lead to:

• Redirecting users to malicious sites: Phishing, malware distribution.
• Disrupting access to legitimate services: Denial of Service (DoS).
• Data exfiltration: Using DNS queries to sneak data out of a network (DNS Tunneling).
• Command and Control (C2) communication: Malware using DNS to contact attacker servers.

Traditional security measures often overlook DNS traffic, treating it as implicitly trusted over UDP/TCP port 53. However, securing the DNS protocol is a critical layer in a defense-in-depth security strategy, especially with the rise of encrypted DNS methods like DNS over HTTPS (DoH).

Common DNS Threats Explained

Attackers employ various techniques to exploit DNS vulnerabilities. Understanding these threats in detail is key to implementing effective defenses.

DNS Cache Poisoning (Spoofing)

How it Works:

The goal is to corrupt the cache of a recursive DNS resolver by injecting false information. When legitimate users query this resolver for a targeted domain, they receive the attacker's malicious IP address instead of the real one. This is typically achieved by exploiting the small window of time after a resolver queries an authoritative server but before it receives the legitimate response. The attacker floods the resolver with forged responses, hoping the resolver accepts the fake one first (often by guessing the DNS transaction ID and source port, though modern resolvers have better protections). Alternatively, an attacker might compromise an authoritative server or trick a resolver into caching incorrect "glue records" (IPs of nameservers).

Example:

A user wants to visit `www.trustedbank.com`. Their client queries their ISP's recursive resolver. The resolver doesn't have it cached and queries the authoritative server for `trustedbank.com`. An attacker, monitoring or predicting this query, rapidly sends numerous fake responses to the ISP resolver claiming `www.trustedbank.com` is at `1.2.3.4` (the attacker's phishing site IP). If the fake response arrives and is accepted before the real one, the ISP resolver caches `www.trustedbank.com -> 1.2.3.4`. Subsequent users using the *same ISP resolver* will be directed to the phishing site.

Diagram:

DNS Tunneling

How it Works:

This technique abuses the DNS protocol to encapsulate non-DNS data within DNS queries and responses, effectively creating a covert communication channel. It's commonly used for Command & Control (C2) or data exfiltration, bypassing firewalls that might allow DNS traffic (port 53) but block other outbound protocols. Data is typically encoded (e.g., Base64) and split into chunks, placed into the subdomain labels of DNS queries (e.g., `[encoded_data].attacker.com`) or sometimes within TXT record queries/responses.

Example (Data Exfiltration):

Malware on an infected host needs to send out a stolen file `secret.txt`. It encodes the file content using Base64, splits it into chunks (`chunk1`, `chunk2`, ...), and makes DNS queries like:

• `chunk1.file_id.exfil.attacker.com`
• `chunk2.file_id.exfil.attacker.com`
• ...

The attacker controls the `attacker.com` domain and runs a custom DNS server. This server receives these queries, extracts the encoded data (`chunk1`, `chunk2`), decodes it, and reconstructs the `secret.txt` file. The DNS responses themselves might be minimal or contain covert commands.

Diagram:

Domain Generation Algorithms (DGAs)

How it Works:

Malware equipped with a DGA generates a large list of pseudo-random domain names based on a shared algorithm and seed (often the current date/time or other dynamic factors). The malware attempts to resolve these domains sequentially until it finds one that resolves to the attacker's active C2 server. The attacker only needs to register one or a few of the generated domains for that specific time period to establish communication. This makes static blocklists ineffective, as the C2 domains change rapidly (often daily).

Example:

On May 4th, 2025, malware uses a DGA seeded with the date to generate 1000 domains like `ghjkwerpoiu.com`, `zxcvbnmlkjt.net`, `asdfqwertyu.org`, etc. The attacker, knowing the algorithm, pre-registers `zxcvbnmlkjt.net` and points it to their C2 server `5.6.7.8`. The malware tries resolving the generated domains: `ghjkwerpoiu.com` (fails), `zxcvbnmlkjt.net` (succeeds, gets IP `5.6.7.8`), connects to C2. On May 5th, a completely new list is generated.

Diagram:

DNS Amplification/Reflection Attacks (DDoS)

How it Works:

This is a Distributed Denial of Service (DDoS) technique that exploits open (publicly accessible) DNS resolvers. The attacker sends DNS queries to these resolvers but spoofs the source IP address to be the victim's IP. The key is that the attacker crafts queries that elicit a much larger response than the query itself (e.g., querying for `ANY` record type or large TXT/DNSKEY records). The open resolvers dutifully send these large responses to the spoofed source IP (the victim). By leveraging many open resolvers simultaneously, the attacker multiplies (amplifies) the traffic volume directed at the victim, overwhelming their network bandwidth or resources.

Example:

An attacker wants to DDoS Victim IP `V`. The attacker sends a 60-byte DNS query for `domain.com` `ANY` records to Open Resolver `R1`, spoofing the source as `V`. `R1` sends a 4000-byte response to `V`. The attacker repeats this rapidly, sending queries to hundreds or thousands of other open resolvers (`R2`, `R3`, ...), all spoofing `V` as the source. The victim `V` is flooded with unsolicited, large DNS responses from `R1`, `R2`, `R3`, etc., consuming all available bandwidth.

Diagram:

DNS Amplification/Reflection DDoS attack flow.

NXDomain Attacks

How it Works:

This attack targets a specific *recursive* DNS resolver (like an ISP's resolver or an enterprise's internal resolver) to cause a Denial of Service. The attacker floods the target resolver with a high volume of DNS queries for domain names that *do not exist* (Non-Existent Domains or NXDomains). For each query, the recursive resolver must perform the full lookup process: query root servers, then TLD servers, then attempt to query authoritative servers, only to eventually determine the domain doesn't exist. This legitimate but ultimately fruitless work consumes the resolver's resources (CPU, memory, network sockets, cache space), potentially making it slow or unresponsive to legitimate user queries.

Example:

An attacker directs a botnet to bombard ISP-Resolver (`192.0.2.53`) with millions of queries per second for domains like `a1b2c3d4.nonexistent-domain.xyz`, `e5f6g7h8.another-fake-domain.pqr`, etc. The ISP-Resolver becomes overwhelmed trying to resolve these invalid domains and legitimate users of that ISP experience slow or failed DNS resolution.

Diagram:

NXDomain attack exhausting resources of the target recursive resolver.

Phantom Domain Attacks

How it Works:

Similar in goal to NXDomain attacks (exhausting recursive resolver resources), but uses a different tactic. Instead of querying domains that don't exist at all, the attacker floods the target recursive resolver with queries for domains (or subdomains) whose *authoritative* nameservers are deliberately configured to be extremely slow or completely unresponsive (i.e., they never answer). The recursive resolver sends the query to these "phantom" authoritative servers and gets stuck waiting for a response, eventually timing out. Each waiting query ties up resources (like connection slots) on the recursive resolver. A high volume of such queries can exhaust the resolver's capacity to handle legitimate requests.

Example:

An attacker controls the nameservers for `phantom-domain.com` and configures them to never respond to DNS queries. The attacker then uses a botnet to flood ISP-Resolver (`192.0.2.53`) with queries for `sub1.phantom-domain.com`, `sub2.phantom-domain.com`, etc. The ISP-Resolver forwards these queries to the attacker's unresponsive nameservers and waits. Many concurrent waiting queries exhaust the resolver's connection table or other resources.

Diagram:

Phantom Domain attack tying up resolver resources waiting for unresponsive authoritative servers.

Random Subdomain Attacks

How it Works:

This attack is similar to an NXDomain attack, but its primary target is usually the *authoritative* nameserver(s) for a *specific victim domain*, rather than a recursive resolver. The attacker generates and sends a high volume of queries for random, non-existent subdomains of the target domain (e.g., `[random_string].victim.com`). Because these subdomains don't exist, the authoritative server still has to process the query and determine it's invalid before responding (typically with NXDomain). A massive flood of these queries can overwhelm the authoritative server's resources, making it unable to respond to legitimate queries for the victim's actual domain or subdomains, effectively causing a DoS for the victim's DNS presence.

Example:

An attacker wants to disrupt `www.victim-corp.com`. They use a botnet to send millions of queries like `a7g3h9q.victim-corp.com?`, `k2m5n1p.victim-corp.com?`, etc., directly to the authoritative nameservers listed for `victim-corp.com`. These nameservers get bogged down processing and responding to the flood of invalid queries, potentially becoming unresponsive to legitimate requests for `www.victim-corp.com` or `mail.victim-corp.com`.

Diagram:

Random Subdomain attack targeting the victim's authoritative nameserver.

DoH: DNS over HTTPS Implications

DNS over HTTPS (DoH) is a protocol for performing DNS resolution via the HTTPS protocol, typically over TCP port 443. It was developed primarily to enhance user privacy and security.

Why DoH?

• Privacy: Traditional DNS queries (UDP/TCP 53) are sent in plaintext. Anyone on the path (e.g., ISP, Wi-Fi provider, network sniffers) can see which websites a user is visiting. DoH encrypts these queries within standard HTTPS traffic, shielding them from eavesdropping.
• Integrity: Encrypting DNS prevents on-path attackers from easily modifying DNS responses to redirect users to malicious sites (similar goal to DNSSEC, but achieved via transport encryption).
• Bypassing Censorship/Filtering: Encrypted DNS can bypass simple DNS-based filtering or redirection implemented at the network level (e.g., by ISPs or governments blocking access via standard DNS manipulation).

How it Differs from Traditional DNS:

• Transport: Uses HTTPS (usually TCP/443) instead of UDP/53 or TCP/53.
• Encryption: DNS queries and responses are encrypted as part of the HTTPS payload.
• Appearance: DoH traffic looks like regular web browsing traffic to network monitoring tools that only look at ports/protocols.

Security Implications for Enterprises:

While DoH offers benefits for individual user privacy on untrusted networks, it presents significant challenges within managed enterprise environments:

• Loss of Visibility: Security appliances like firewalls traditionally monitor port 53 traffic for threat intelligence (e.g., identifying C2 domains, sinkholing malicious requests, detecting tunneling). When DNS queries are hidden inside encrypted HTTPS traffic to external DoH resolvers (like Google, Cloudflare), this visibility is lost.
• Bypassing Security Controls: Malware can leverage DoH to bypass enterprise DNS security policies. If an organization blocks known malicious domains using internal DNS servers or firewall DNS filtering on port 53, malware using DoH can simply resolve its C2 domains via an external encrypted channel, rendering the security controls ineffective.
• Policy Enforcement Issues: Organizations often use DNS filtering for enforcing Acceptable Use Policies (AUPs). DoH allows users or applications to bypass these internal controls.
• Incident Response Difficulty: Identifying compromised devices based on malicious DNS query patterns becomes much harder if the queries are encrypted and sent directly to external resolvers.

Palo Alto Networks & DoH:

Palo Alto Networks firewalls can address the DoH challenge through several mechanisms:

• App-ID: PAN-OS has App-IDs to identify DoH traffic itself (e.g., `dns-over-https`). This allows creating policies to block or control DoH traffic flows.
• URL Filtering/Application Control: Known public DoH resolver services can be blocked by category using URL Filtering or by blocking the specific DoH application via App-ID.
• SSL Decryption: If SSL Forward Proxy decryption is enabled for traffic to external DoH resolvers, the firewall can potentially decrypt the HTTPS session, revealing the underlying DNS queries and allowing DNS Security profiles to inspect them. However, this requires careful certificate management and has privacy implications.

Palo Alto Networks DNS Security Capabilities: Overview

Palo Alto Networks Next-Generation Firewalls (NGFWs) provide a multi-faceted approach to DNS security, integrating several features within PAN-OS and offering advanced cloud-delivered services.

Key PAN-OS Components for DNS Security:

• Anti-Spyware Security Profiles: Contain settings for DNS Sinkholing and signatures to detect known DNS-based threats and C2 channels operating over standard DNS (port 53).
• URL Filtering Security Profiles: Categorize domains (including potentially malicious ones or known DoH providers) using PAN-DB and allow policy-based blocking or alerting.
• DNS Proxy: Allows the firewall to act as an intermediary for DNS requests, providing visibility and control over standard DNS traffic from specific clients or zones.
• Security Policy Rules: The foundation for controlling traffic flow. You can create rules specifically for DNS traffic (App-ID `dns`, Service `application-default`) and also for DoH traffic (App-ID `dns-over-https`) and apply relevant Security Profiles or Actions (Block).
• Threat Prevention Profiles (IPS): Include signatures to detect and block various network attacks, some of which might leverage DNS or target DNS servers (e.g., DoS protection signatures).
• WildFire Integration: Suspicious domains encountered in DNS queries or observed in traffic can be submitted to WildFire for analysis. Verdicts (malicious, benign, grayware) can then be used in policy.
• App-ID: Identifies applications, including `dns` and `dns-over-https`, allowing granular policy control independent of port.
• SSL Decryption: Can provide visibility into encrypted traffic like DoH, allowing inspection engines (DNS Security, Anti-Spyware) to see the underlying DNS queries (requires careful implementation).

Advanced Protection with DNS Security Subscription:

• Cloud-Delivered Service: Leverages global threat intelligence and machine learning in the cloud for real-time analysis and protection against threats using standard DNS.
• Predictive Analytics: Detects threats like DGAs, DNS Tunneling, and newly generated malicious domains *before* they are widely known, primarily analyzing standard DNS traffic.
• Shared Intelligence: Benefits from threat data gathered across the entire Palo Alto Networks ecosystem.
• Note: While DNS Security focuses on analyzing DNS query/response data, controlling DoH traffic itself typically relies on App-ID, URL Filtering, and potentially SSL Decryption.

These components work together to provide comprehensive protection against the threats discussed previously, including strategies to manage the challenges posed by DoH.

PAN-OS Feature: DNS Sinkholing

DNS Sinkholing is a powerful technique used to identify hosts within your network that may be infected with malware attempting to contact Command and Control (C2) servers via *standard DNS* queries.

How it Works:

1. Detection: The firewall, typically using signatures within an Anti-Spyware profile or verdicts from the DNS Security service, identifies a standard DNS query (UDP/TCP 53) destined for a known malicious domain (often used for C2).
2. Interception & Modification: Instead of allowing the query to proceed to the internet or blocking it outright, the firewall intercepts the query. It then crafts a *false* DNS response, replacing the actual malicious IP address with an IP address you configure – the "Sinkhole IP".
3. Redirection: This Sinkhole IP usually points to an internal server you control or, commonly, the firewall's own management interface or a dedicated loopback interface (configured specifically for this purpose).
4. Identification: When the infected client receives the fake response, it attempts to connect to the Sinkhole IP address (often over HTTP/HTTPS) instead of the actual C2 server.
5. Logging & Alerting: The firewall logs these connection attempts to the Sinkhole IP. By reviewing these logs (specifically, Traffic logs filtering by destination IP = Sinkhole IP), administrators can identify the source IP address of the potentially infected host(s).

Configuration:

• Anti-Spyware Profile / DNS Security Profile: Enable DNS Signatures/relevant categories and configure the Sinkhole action (IPv4 and/or IPv6). Select the threat severity levels/categories for which sinkholing should apply.
• Sinkhole IP: Define the IPv4 and/or IPv6 address to use for the sinkhole response within the profile. This IP should be routable within your network but ideally not lead anywhere sensitive or externally accessible. Using a loopback interface on the firewall is a common practice.
• Security Policy Rule: Apply the configured Anti-Spyware/DNS Security profile to relevant Security Policy rules that allow *standard DNS traffic* (App-ID `dns`).
• (Optional) Sinkhole Server/Firewall Policy: If using a dedicated server or firewall interface, ensure there's a mechanism to log or observe traffic hitting the Sinkhole IP. A simple web server on the sinkhole can provide visual confirmation for testing. You might also create a specific Security Policy rule denying traffic *to* the sinkhole IP to prevent actual connections while still logging the attempts.

PAN-OS Feature: DNS Proxy

The DNS Proxy feature allows the Palo Alto Networks firewall to act as an intermediary for *standard DNS* requests (UDP/TCP 53) originating from clients behind the firewall. Instead of clients querying external DNS servers directly, they query the firewall, which then forwards the requests on their behalf.

Benefits of using DNS Proxy:

• Visibility: The firewall gains direct visibility into which internal clients are making which standard DNS requests, even if they were originally configured to use different external DNS servers. DNS logs will show the client-to-firewall query.
• Control: You can enforce the use of specific upstream DNS servers for standard DNS queries, regardless of client configuration.
• Security Policy Enforcement: DNS Proxy allows Security Profiles (like Anti-Spyware with Sinkholing or the DNS Security subscription) to be applied consistently to the standard DNS traffic handled by the proxy as it's forwarded upstream.
• Conditional Forwarding: You can configure the DNS Proxy to forward queries for specific internal domains to internal DNS servers, while sending external domain queries to public resolvers.
• Caching: The DNS Proxy can cache responses, potentially speeding up DNS resolution for frequently requested domains.

How it Works:

1. Client Configuration: Clients are configured (manually or via DHCP) to use an IP address on a firewall interface as their DNS server for standard DNS.
2. DNS Proxy Object: You configure a DNS Proxy object on the firewall ( Network > DNS Proxy ). This defines:
   • Which firewall interfaces/IPs will listen for client DNS queries.
   • Primary and Secondary upstream DNS servers to which the firewall will forward queries.
   • DNS Proxy Rules for conditional forwarding (optional).
   • Caching options.
3. Security Policy Rule (Client -> Proxy): A Security Policy rule is needed to allow clients to send DNS queries (App-ID `dns`) *to* the firewall interface IP configured in the DNS Proxy object.
4. Security Policy Rule (Proxy -> Upstream): A separate Security Policy rule is needed to allow the DNS traffic (App-ID `dns`) *from* the firewall (acting as the proxy) *to* the upstream external/internal DNS servers. Security Profiles are typically applied to this rule.
5. Processing: The firewall receives the client query, checks its rules/cache, applies security checks on the forwarded query (via the second rule), forwards to the appropriate upstream server, receives the response, caches it (if configured), and sends it back to the client.

Applying DNS Security through Profiles and Policies

The effectiveness of DNS security features hinges on their correct application within Security Profiles and Security Policy Rules, considering both standard DNS and encrypted DNS like DoH.

Security Profiles: The Control Knobs

Security Profiles define *how* the firewall inspects traffic that matches a Security Policy rule.

• Anti-Spyware Profiles:
  • DNS Signatures: Detect known malicious domains (C2, malware) in *standard DNS* traffic. Actions include alert, block, sinkhole.
  • DNS Sinkholing Configuration: Define sinkhole IPs and enable sinkholing for specific threat severities for standard DNS queries.
• DNS Security Profiles (Requires License):
  • Leverages cloud service for advanced detection (DGA, Tunneling, etc.) primarily on *standard DNS* traffic.
  • Policy Actions: Define actions (allow, alert, block, sinkhole) for various categories identified in standard DNS queries.
  • Sinkhole Configuration: Specify sinkhole IPs for verdicts applied to standard DNS.
  • Note: Inspection of DoH requires SSL Decryption first. If decrypted, these profiles *can* inspect the underlying DNS query.
• URL Filtering Profiles:
  • Categorizes domains using PAN-DB based on FQDN.
  • Can block access based on categories (malware, phishing, questionable). Works on standard HTTP/HTTPS traffic and can block access *after* DNS resolution. Can also be used to block connections to known DoH provider URLs.
• Application Control (via Security Policy):
  • Not a profile, but achieved by setting the Application in the Security Policy Rule.
  • Used to explicitly allow `dns` or block `dns-over-https`.
• File Blocking Profiles: Relevant if malware attempts to download files after successful C2 communication established via DNS methods.
• Vulnerability Protection Profiles: May contain signatures against attacks targeting DNS server software vulnerabilities.

Security Policy Rules: The Gatekeepers

Security Policy rules determine *which* traffic gets inspected by *which* Security Profiles or which action is taken.

• Controlling Standard DNS:
  • Create rules allowing `dns` App-ID on `application-default` service (UDP/TCP 53).
  • Apply Anti-Spyware and/or DNS Security profiles to these rules.
  • Use DNS Proxy? Apply profiles to the proxy-to-upstream rule.
• Controlling DoH:
  • Identify DoH traffic using App-ID `dns-over-https`.
  • Decide on policy:
    • Block: Create a rule matching `dns-over-https` and set Action to `Deny`. This is a common enterprise approach.
    • Allow (with Decryption): Create a rule allowing `dns-over-https`, attach an SSL Decryption profile (Forward Proxy), AND attach DNS Security/Anti-Spyware profiles to inspect the decrypted content.
    • Allow (No Inspection): Not recommended for security, but technically possible.
  • Use URL Filtering to block categories associated with known public DoH providers as an additional layer.
• Rule Order Matters: Ensure specific DNS and DoH rules are placed above broader allow rules (e.g., general web browsing allow rules). A typical order might be: Block DoH -> Allow Specific DNS (Proxy/Direct) with Profiles -> Block Remaining DNS -> Allow Web Browsing.

Advanced Protection: The DNS Security Subscription Service

While built-in PAN-OS features provide a strong foundation for standard DNS, the Palo Alto Networks DNS Security subscription service offers advanced, real-time protection against modern, evasive threats primarily leveraging *standard DNS (port 53)*.

Key Capabilities (focused on standard DNS):

• Cloud-Based Intelligence: Utilizes a continuously updated, cloud-hosted database of malicious domains combined with machine learning for analyzing standard DNS queries.
• Real-Time Analysis: Standard DNS queries are analyzed in real-time against the cloud service for the latest threat intelligence.
• Predictive Analytics (ML): Goes beyond known bad domains to identify (in standard DNS):
  • Domain Generation Algorithms (DGAs): Detects domains generated algorithmically by malware.
  • DNS Tunneling Detection: Analyzes standard DNS query patterns and payloads.
  • Newly Malicious Domains: Identifies domains recently registered or repurposed for malicious activities.
• Reduced False Positives: Machine learning helps differentiate legitimate but unusual standard DNS activity from genuine threats.
• Integration with Sinkholing: Allows sinkholing actions based on DNS Security service verdicts for standard DNS queries.

How it Works (Simplified for Standard DNS):

1. A standard DNS query matches a Security Policy rule with an attached DNS Security profile.
2. The firewall checks its local cache for a verdict on the domain.
3. If not cached or expired, the firewall forwards metadata about the query to the DNS Security cloud service.
4. The cloud service analyzes the domain using its database, ML models, and reputation analysis.
5. The cloud service returns a verdict (e.g., benign, malware, C2, DGA, tunneling, grayware) to the firewall.
6. The firewall enforces the action defined in the DNS Security profile for that verdict (allow, alert, block, sinkhole) on the standard DNS query/response.
7. The verdict is cached locally on the firewall.

DNS Security and DoH:

It's crucial to understand that the DNS Security subscription's analysis engine primarily works on the DNS protocol data itself. To apply these advanced analytics to DoH traffic:

1. The DoH traffic (HTTPS on port 443) must first match a Security Policy rule.
2. That rule must have an SSL Decryption profile attached (specifically, Forward Proxy decryption).
3. The firewall must successfully decrypt the session (requiring certificate trust, etc.).
4. *Only then* can the firewall extract the underlying DNS query from the decrypted HTTPS data.
5. This extracted DNS query can then be analyzed by the DNS Security service engine (if a DNS Security Profile is also attached to the same rule).

Without SSL decryption, the DNS Security service cannot see or analyze the DNS queries hidden within DoH.

Diagram: DNS Query Flow with Palo Alto Inspection

This sequence diagram illustrates the path of a standard DNS query from a client through a Palo Alto Networks firewall configured with DNS Proxy and DNS Security.

Sequence diagram showing standard DNS query processing, DNS Security cloud lookup, sinkholing for malicious domains, and normal resolution for benign domains via DNS Proxy.

Diagram: Firewall DNS Query Decision Flow (Standard DNS)

This flowchart outlines the logical steps the firewall takes when processing a standard DNS query under a security policy.

Flowchart illustrating the decision process for a standard DNS query hitting a Palo Alto Networks firewall security policy with various security profiles.

Diagram: DNS Security Ecosystem Components

This graph shows the relationships between key components involved in Palo Alto Networks DNS Security, including DoH considerations.

Component graph illustrating interactions, including standard DNS flow, DoH flow, and relevant security components/logs.

Diagram: State of a DNS Query Processed by Firewall

This state diagram shows possible states for a standard DNS query. DoH traffic might follow a different path (e.g., blocked by App-ID, or decrypted then following this flow).

State diagram illustrating the lifecycle including checks for DoH and potential decryption before inspection.

PCNSE Exam Focus Areas for DNS Security

DNS Security concepts and configuration are frequently tested on the PCNSE exam. Here are key areas to focus on:

Core Concepts & Feature Differentiation:

• DNS Fundamentals: Understand the basic DNS resolution process (recursive vs authoritative).
• Threat Landscape: Know the definitions, mechanisms, and targets of DNS Tunneling, DGAs, Cache Poisoning, Amplification/Reflection, NXDomain, Random Subdomain attacks.
• DoH Implications: Understand what DoH is, why it's used, and the security challenges it presents (visibility loss, control bypass). Know that PAN-OS uses App-ID (`dns-over-https`), URL Filtering, and potentially SSL Decryption to manage it.
• PAN-OS Feature Mapping:
  • Where is DNS Sinkholing configured? (Anti-Spyware Profile or DNS Security Profile)
  • What is the primary purpose of DNS Sinkholing? (Infected host identification via Traffic Logs for standard DNS threats)
  • What does DNS Proxy provide? (Visibility, control, caching for standard DNS)
  • Where is DNS Proxy configured? (Network > DNS Proxy; Security Policy rules needed)
  • What requires the DNS Security license? (Advanced DGA detection, Tunneling detection, cloud ML analysis for standard DNS; also needed if inspecting decrypted DoH)
  • Where are DNS Security subscription features configured? (DNS Security Profile)
  • How does URL Filtering contribute? (Category-based blocking, blocking DoH providers)
  • How does App-ID contribute? (Identifying `dns` vs `dns-over-https`)
  • What is needed to inspect DoH content? (SSL Decryption)

Configuration & Implementation:

• Security Profile Application: Understand that profiles (Anti-Spyware, DNS Security, URL Filtering) are applied to Security Policy rules allowing the relevant traffic. For standard DNS, apply to the rule allowing App-ID `dns`. For DoH inspection, apply to the rule allowing `dns-over-https` *and* ensure SSL Decryption is active on that rule.
• Sinkhole Configuration: Know how to specify the Sinkhole IPv4/IPv6 address within the profiles.
• DNS Proxy Setup: Understand the object config and the two associated policy rules for standard DNS.
• DoH Policy: Know how to create rules using App-ID `dns-over-https` to either block it or allow it (potentially with decryption).
• Policy Rule Design & Order: Be able to construct and order rules correctly to handle standard DNS, DoH, and general web traffic according to security goals.
• External Dynamic Lists (EDLs): Understand how Domain EDLs can be used in DNS Security profiles.

Monitoring & Troubleshooting:

• Log Analysis:
  • Threat Log: Shows DNS Security/Anti-Spyware verdicts/signatures.
  • Traffic Log: Crucial for identifying sinkhole connection attempts (destination = sinkhole IP); also shows basic DNS/DoH flow allowed/denied by policy.
  • URL Filtering Log: Shows actions taken based on domain categories or specific DoH provider URLs.
  • Decryption Log: Shows success/failure of SSL Decryption attempts (relevant for DoH inspection).
  • DNS Log: Shows detailed DNS Proxy activity if configured.
• Packet Captures (PCAPs): Understand stages for capturing standard DNS vs encrypted DoH.
• Troubleshooting Commands (CLI): show dns-proxy ... , show url-cloud ... , test dns-security-cloud ... , basic connectivity tests.

DNS Security Quiz (PCNSE Focus)

Test your knowledge of Palo Alto Networks DNS Security concepts.