Next-Generation Firewall
DNS Proxy Rule and FQDN Matching
Table of Contents
Expand All
|
Collapse All
Next-Generation Firewall Docs
-
Cloud Management of NGFWs
- Cloud Management of NGFWs
- PAN-OS 10.0 (EoL)
- PAN-OS 10.1
- PAN-OS 10.2
- PAN-OS 11.0
- PAN-OS 11.1 & Later
- PAN-OS 9.1 (EoL)
-
-
-
- Configure a Filter Access List
- Configure a Filter Prefix List
- Configure a Filter Community List
- Configure a BGP Filter Route Map
- Configure a Filter Route Maps Redistribution List
- Configure a Filter AS Path Access List
- Configure an Address Family Profile
- Configure a BGP Authentication Profile
- Configure a BGP Redistribution Profile
- Configure a BGP Filtering Profile
- Configure an OSPF Authentication Profile
- Configure a Logical Router
- Configure a Static Route
- Configure OSPF
- Configure BGP
- Configure an IPSec Tunnel
- Web Proxy
- Cheat Sheet: GlobalProtect for Cloud Management of NGFWs
-
PAN-OS 10.1
- PAN-OS 10.1
- PAN-OS 10.2
- PAN-OS 11.0
- PAN-OS 11.1 & Later
-
- Tap Interfaces
-
- Layer 2 and Layer 3 Packets over a Virtual Wire
- Port Speeds of Virtual Wire Interfaces
- LLDP over a Virtual Wire
- Aggregated Interfaces for a Virtual Wire
- Virtual Wire Support of High Availability
- Zone Protection for a Virtual Wire Interface
- VLAN-Tagged Traffic
- Virtual Wire Subinterfaces
- Configure Virtual Wires
- Configure an Aggregate Interface Group
- Configure Bonjour Reflector for Network Segmentation
- Use Interface Management Profiles to Restrict Access
-
- DNS Overview
- DNS Proxy Object
- DNS Server Profile
- Multi-Tenant DNS Deployments
- Configure a DNS Proxy Object
- Configure a DNS Server Profile
- Use Case 1: Firewall Requires DNS Resolution
- Use Case 2: ISP Tenant Uses DNS Proxy to Handle DNS Resolution for Security Policies, Reporting, and Services within its Virtual System
- Use Case 3: Firewall Acts as DNS Proxy Between Client and Server
- DNS Proxy Rule and FQDN Matching
-
- NAT Rule Capacities
- Dynamic IP and Port NAT Oversubscription
- Dataplane NAT Memory Statistics
-
- Translate Internal Client IP Addresses to Your Public IP Address (Source DIPP NAT)
- Enable Clients on the Internal Network to Access your Public Servers (Destination U-Turn NAT)
- Enable Bi-Directional Address Translation for Your Public-Facing Servers (Static Source NAT)
- Configure Destination NAT with DNS Rewrite
- Configure Destination NAT Using Dynamic IP Addresses
- Modify the Oversubscription Rate for DIPP NAT
- Reserve Dynamic IP NAT Addresses
- Disable NAT for a Specific Host or Interface
-
- Network Packet Broker Overview
- How Network Packet Broker Works
- Prepare to Deploy Network Packet Broker
- Configure Transparent Bridge Security Chains
- Configure Routed Layer 3 Security Chains
- Network Packet Broker HA Support
- User Interface Changes for Network Packet Broker
- Limitations of Network Packet Broker
- Troubleshoot Network Packet Broker
-
-
Cloud Management and AIOps for NGFW
- Cloud Management and AIOps for NGFW
- PAN-OS 10.0 (EoL)
- PAN-OS 10.1
- PAN-OS 10.2
- PAN-OS 11.0
- PAN-OS 11.1
- PAN-OS 11.2
- PAN-OS 8.1 (EoL)
- PAN-OS 9.0 (EoL)
- PAN-OS 9.1 (EoL)
DNS Proxy Rule and FQDN Matching
How the firewall compares an FQDN to DNS proxy rules.
Contact your account team to enable Cloud Management for NGFWs using Strata
Cloud Manager.
Where Can I Use This? | What Do I Need? |
---|---|
|
One of these:
|
When you configure the firewall with
a DNS proxy object that
uses DNS proxy rules, the firewall compares an FQDN from a DNS query
to the domain name of a DNS proxy rule. The firewall comparison
works as follows.
FQDN Comparison to
DNS Proxy Rule | For Example |
---|---|
The firewall first tokenizes the FQDNs and
the domain names in the DNS proxy rules. In a domain name, a string delimited
by a period (.) is a token. | *.boat.fish.com consists
of four tokens: [*][boat][fish][com] |
The matching process is an exact token match between the FQDN and the domain name in the rule;
partial strings aren’t matched. | Rule: fishing FQDN: fish — Not
a Match |
An exception to the exact
match requirement is the use of the wildcard—an asterisk (*). The
* matches one or more tokens. This means a rule consisting
of only a wildcard (*) matches any FQDN with one or more tokens. | Rule: *.boat.com FQDN: www.boat.com — Match FQDN: www.blue.boat.com — Match FQDN: boat.com — Not
a Match |
Rule: * FQDN: boat — Match FQDN: boat.com — Match FQDN: www.boat.com — Match | |
You can use an * in any position: preceding
tokens, between tokens, or trailing tokens (but not with other characters
within a single token). | Rule: www.*.com FQDN: www.boat.com — Match FQDN: www.blue.boat.com — Match |
Rule: www.boat.* FQDN: www.boat.com — Match FQDN: www.boat.fish.com — Match | |
Rule: www.boat*.com — Invalid | |
Multiple wildcards (*) can appear in any position of the domain name: preceding tokens, between
tokens, or trailing tokens. Each nonconsecutive * matches one or
more tokens. | Rule: a.*.d.*.com FQDN: a.b.d.e.com —
Match FQDN: a.b.c.d.e.f.com — Match FQDN: a.d.d.e.f.com —
Match (First * matches d;
second * matches e and f) FQDN: a.d.e.f.com — Not a Match (First *
matches d; subsequent
d in the rule isn’t matched) |
When wildcards are used in consecutive tokens,
the first * matches one or more tokens; the second * matches one
token. This means a rule consisting of only *.* matches any
FQDN with two or more tokens. | Consecutive wildcards preceding tokens: Rule: *.*.boat.com FQDN: www.blue.boat.com — Match FQDN: www.blue.sail.boat.com —
Match |
Consecutive wildcards between tokens: Rule: www.*.*.boat.com FQDN: www.blue.sail.boat.com —
Match FQDN: www.big.blue.sail.boat.com —
Match | |
Consecutive wildcards trailing tokens: Rule: www.boat.*.* FQDN: www.boat.fish.com — Match FQDN: www.boat.fish.ocean.com —
Match | |
Consecutive wildcards only: Rule: *.* FQDN: boat — Not
a Match FQDN: boat.com — Match FQDN: www.boat.com — Match | |
Consecutive and nonconsecutive wildcards can appear in the same rule. | Rule: a.*.d.*.*.com FQDN: a.b.c.d.e.f.com —
Match (First * matches b and c;
second * matches e;
third * matches f) FQDN: a.b.c.d.e.com — Not
a Match (First * matches b and c;
second * matches e;
third * not matched) |
The Implicit-tail-match behavior provides
an additional shorthand: As long as the last token of the rule isn’t an *, a comparison will match if all tokens in the
rule match the FQDN, even when the FQDN has additional trailing
tokens that the rule doesn’t have. | Rule: www.boat.fish FQDN: www.boat.fish.com — Match FQDN: www.boat.fish.ocean.com —
Match FQDN: www.boat.fish — Match |
This rule ends with *, so the Implicit-tail-match
rule doesn’t apply. The * behaves as stated; it matches one or more
tokens. | Rule: www.boat.fish.* FQDN: www.boat.fish.com — Match FQDN: www.boat.fish.ocean.com —
Match FQDN: www.boat.fish — Not a Match (This FQDN doesn’t have a token
to match the * in the rule.) |
In the case where an FQDN matches more than
one rule, a tie-breaking algorithm selects the most specific (longest)
rule; that is, the algorithm favors the rule with more tokens and
fewer wildcards (*). | Rule 1: *.fish.com —
Match Rule 2: *.com — Match Rule 3: boat.fish.com — Match
and Tie-Breaker FQDN: boat.fish.com FQDN matches all three rules; the firewall uses Rule 3 because it’s the most specific. |
Rule 1: *.fish.com — Not
a Match Rule 2: *.com — Match Rule 3: boat.fish.com — Not
a Match FQDN: fish.com FQDN doesn’t match Rule 1 because the * doesn’t have a token to match. | |
Rule 1: *.fish.com —
Match and Tie-Breaker Rule 2: *.com — Match Rule 3: boat.fish.com — Not
a Match FQDN: blue.boat.fish.com FQDN matches Rule 1 and Rule 2 (because the * matches one or more tokens). The firewall uses Rule
1 because it’s the most specific. | |
When working with wildcards (*) and Implicit-tail-match
rules, there can be cases when the FQDN matches more than one rule
and the tie-breaking algorithm weighs the rules equally. To
avoid ambiguity, if rules with an Implicit-tail-match or a wildcard
(*) can overlap, replace an Implicit-tail-match rule by specifying
the tail token. | Replace this: Rule: www.boat with
this: Rule: www.boat.com |
Best Practices for Creating
DNS Proxy Rules to Avoid Ambiguity and Unexpected Results | |
Include a top-level domain in the domain name to avoid invoking an Implicit-tail-match that might
match the FQDN to more than one rule. | boat.com |
If you use a wildcard (*), use it only as
the leftmost token. This practice follows the common understanding
of wildcard DNS records and the hierarchical nature of DNS. | *.boat.com |
Use no more than one * in a rule. | |
Use the * to establish a base rule associated
with a DNS server, and use rules with more tokens to build exceptions
to the rule, which you associate with different servers. The
tie-breaking algorithm will select the most specific match, based
on the number of matched tokens. | Rule: *.corporation.com — DNS
server A Rule: www.corporation.com — DNS
server B Rule: *.internal.corporation.com —
DNS server C Rule: www.internal.corporation.com —
DNS server D FQDN: mail.internal.corporation.com —
matches DNS server C FQDN: mail.corporation.com — matches
DNS server A |