>
    DNS Proxy Rule and FQDN Matching
    Focus
    Download PDF
    Focus
    1. Home
    2. Next-Generation Firewall
    3. Set Up Firewalls
    4. DNS Proxy
    5. DNS Proxy Rule and FQDN Matching
    Download PDF
    Next-Generation Firewall

    DNS Proxy Rule and FQDN Matching

    Table of Contents

    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?
    • NGFW (Managed by Strata Cloud Manager)
    • VM-Series, funded with Software NGFW Credits
    • AIOps for NGFW Premium license (use the Strata Cloud Manager app)
    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

    Recommended For You

    © 2024 Palo Alto Networks, Inc. All rights reserved.