Technical Tip: Using a wildcard FQDN

vpereira · ‎04-30-2020

Description

This article describes the usage of wildcard FQDN.

Scope

Any supported version of FortiGate.

Solution

Support for wildcard FQDN addresses in firewall policy has been included in FortiOS 6.2.2.

A wildcard FQDN can be configured from either the GUI or CLI.

From the GUI:

Go to Policy & Objects -> Addresses -> New Address.
In the screenshot below, *.fortinet.com is used as a wildcard FQDN.

From the CLI:

config firewall address
    edit "fortinet-fqdn"
        set uuid 96c22534-8a3b-51ea-ad68-98a463172306
        set type fqdn
        set fqdn "*.fortinet.com"
    next
end

A firewall policy needs to be defined to use a wildcard FQDN.

config firewall policy
    edit 8
        set name "fqdn-policy"
        set srcintf "port9"
        set dstintf "port1"
        set srcaddr "all"
        set dstaddr "fortinet-fqdn"
        set action accept
        set schedule "always"
        set service "ALL"
        set nat enable
    next
end

When the wildcard FQDN has been configured, it will show as an unresolved FQDN in the firewall address list.

As compared to the standard FQDNs, the wildcard FQDN does not use system DNS settings (Network -> DNS).
The wildcard FQDN is updated when a DNS query is made from a host connected to FortiGate (DNS traffic passing through a FortiGate).

If the query matches the wildcard FQDN, the IP address is added to the cache for that object on the FortiGate.

Note that FortiGate will not be able to read encrypted DNS queries unless 'Deep Packet Inspection' is enabled. Most browsers such as (Chrome, Firefox, Edge, etc) can encrypt DNS traffic. Below is an example of 'Use secure DNS' being enabled on Chrome.

The wildcard FQDN is updated if a DNS query is done using either FortiGuard DNS servers or internal DNS servers or any public DNS server.

If internal DNS servers are used, the DNS traffic passes through the FortiGate.

The response from the query is then populated to the FQDN object.

diagnose firewall fqdn list | grep fortinet

*.fortinet.com: ID(48)

For v7.0 and later:

diagnose firewall fqdn list-ip

For updating the FQDN with IP addresses, running 'nslookup' from a host connected to a FortiGate will manually resolve each wildcard entry and the list will be populated with new IP addresses as shown below.

Note that all IP addresses are assigned to that wildcard FQDN object for an unlimited time by default.

If FortiGate is rebooted, all IP addresses have to be learned again.

If the FQDN is configured something like this as shown in image:

And if the resolved IP does not show in the output of diagnose firewall fqdn list-ip command as below:

diagnose firewall fqdn list-ip
List all IP FQDN:
fqdn_u 0xfff3724 tdscpc.gov.*: type:(1) ID(63) count(0) generation(0) data_len:0 flag: 0
Total ip fqdn range blocks: 0.
Total ip fqdn addresses: 0.

Try using the FQDN in the policy and configure the cache-ttl value 86400 and run the above command, the FQDN will be resolved to IP.

diagnose test application dnsproxy 6
worker idx: 0
vfid=0 name=tdscpc.gov.in ver=IPv4 wait_list=0 timer=3591 min_ttl=3600 cache_ttl=86400 slot=-1 num=1 wildcard=0
61.246.185.70 (ttl=86400:86397:86397)

If it is necessary to limit TTL, this is possible from the CLI and configurable per object:

diagnose firewall fqdn list | grep fortinet

*.fortinet.com: ID(48) ADDR(208.91.113.75) ADDR(208.91.113.80) ADDR(208.91.113.85) ADDR(34.228.249.126) ADDR(34.226.137.150) ADDR(96.45.36.159)

Some of the domains (for example, google.com) have very short TTL and resolve to different IPs for different requests to implement DNS-based load balance. This will result in a discrepancy between the IP resolved by FortiGate and the other IP resolved by the host. A workaround for this issue is to set a large cache-ttl so that IP addresses will be saved longer even when their TTLs expire.

config firewall address
    edit "wildcard.google.com"
        set type fqdn
        set fqdn "*.google.com"
        set cache-ttl 86400
    next
end

Sometimes a new DNS query replaces the existing entries learned from FortiGate.

Consider the example below:

diagnose test application dnsproxy 6
vfid=0 name=*.google.com ver=IPv4 min_ttl=37:0, cache_ttl=0 , slot=-1, num=4, wildcard=1
172.217.1.164 (ttl=94:0:0) 172.217.164.205 (ttl=114:0:0) 172.217.1.14 (ttl=106:0:0) 172.217.164.238 (ttl=37:0:0)

Performing a nslookup for mail.google.com replaced all 4 entries above.

nslookup mail.google.com

> mail.google.com
Server: dns.google
Address: 8.8.8.8

Non-authoritative answer:
Name: googlemail.l.google.com
Addresses: 2607:f8b0:400b:809::2005
172.217.165.5
Aliases: mail.google.com

diagnose test application dnsproxy 6
vfid=0 name=*.google.com ver=IPv4 min_ttl=41:0, cache_ttl=0 , slot=-1, num=2, wildcard=1
172.217.1.174 (ttl=255:0:0) 172.217.165.5 (ttl=263:221:221) Then, nslookup drive.google.com- IP 172.217.1.174 is replaced.
> drive.google.com
Server: dns.google
Address: 8.8.8.8

Non-authoritative answer:
Name: drive.google.com
Addresses: 2607:f8b0:400b:800::200e
172.217.164.206

diagnose test application dnsproxy 6
vfid=0 name=*.google.com ver=IPv4 min_ttl=110:0, cache_ttl=0 , slot=-1, num=2, wildcard=1
172.217.165.5 (ttl=263:85:85) 172.217.164.206 (ttl=299:275:275)

The IP addresses are replaced because they have already expired.

ttl = 106:0:0 is the original TTL:time to expire in TTL:time to expire in cache.

The latter two are the same if the cache-ttl is not set in the address.

In FortiOS 7.4.0 and above, the 'fqdn-max-refresh' timer can be modified.

The 'fqdn-max-refresh' setting is utilized to set the global upper limit for the FQDN refresh timer. If any FQDN entries have a TTL interval longer than the 'fqdn-max-refresh' value, their refresh timer will be reduced to this predefined upper limit. By using this setting, FortiGate can control the maximum interval for querying DNS updates for its FQDN addresses, allowing more control over DNS caching behavior.

CLI Syntax:

config system dns

set fqdn-max-refresh <integer> -> FQDN cache maximum refresh time, in seconds (3600 - 86400, default = 3600).

end

Note that the dns-udp session helper is configured by default. If an administrator removes the dns-udp session helper, wildcard FQDNs will not be resolved when devices behind FortiGate attempt DNS queries.

config system session-helper

...

edit 14

set name dns-udp
set protocol 17
set port 53

Related articles:

Support for Wildcard FQDN addresses in Firewall policy

Technical Tip: Wildcard FQDN show unresolved IP address issue