Staff

Technical Tip: Using a wildcard FQDN

Forum|Forum|6 years ago
April 30, 2020
0 replies
214167 views

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 v6.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

To verify the address is configured:

show firewall address fortinet-fqdn
config firewall address
    edit "fortinet-fqdn"
        set uuid 8a0d18e0-f6b8-51f0-40bd-da92455c0781
        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).

Note:

If the DNS query from an endpoint is made to an internal DNS server and this DNS traffic does not pass through the FortiGate, then the query from the DNS Server to the Forwarder (could be internal or external), to resolve the FQDN ,has to go through the FortiGate, so FortiGate can cache the resolution and update the wildcard FQDN object.

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

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.

In addition, DNS traffic using DNS-over-HTTPS (DoH) protocol is not supported.

The wildcard FQDN is updated if a DNS query is done using either FortiGuard DNS servers, 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 into the FQDN object.

diagnose firewall fqdn list | grep fortinet

*.fortinet.com: ID(48)

For v7.0 and later:

diagnose firewall fqdn list-all | grep fortinet

fqdn_u 0x55dbb4208add *.fortinet.com: type:(1) ID(186) count(0) generation(1) data_len:0 flag: 1

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.

Wildcard FQDN IP addresses are not shared between VDOMs in a multi-VDOM environment.

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

If the resolved IP does not show in the output of the 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, configure the cache-ttl value 86400, and run the above command; the FQDN will be resolved to an 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)

For v7.0 and later:

diagnose firewall fqdn list-all | grep fortinet
fqdn_u 0x9e287f1 *.fortinet.com: type:(1) ID(19) count(1) generation(1) data_len:13 flag: 1

Some of the domains (for example, google.com) have very short TTLs and resolve to different IPs for different requests to implement DNS-based load balancing. 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 an 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 v7.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

To clear DNS cache, use the following command.

diagnose test application dnsproxy 1

Note: Beginning with FortiOS 7.6.4, firewall policies now support IPv6 wildcard addresses, providing improved flexibility, scalability, and simplified management for IPv6 network environments. For additional details, see IPv6 wildcard addresses - FortiGate 7.6.0 new features.

Related documents:

Support for Wildcard FQDN addresses in Firewall policy

Technical Tip: Wildcard FQDN show unresolved IP address issue

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded