Technical Tip: Using wildcard FQDN

[vpereira]

Description
This article describes the usage of wildcard FQDN.

Related Link:
https://docs.fortinet.com/document/fortigate/6.2.0/new-features/329154/support-for-wildcard-fqdn-add...

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 GUI or CLI.

From GUI.

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

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

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 updating the FQDN with IP addresses, '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 has to be learned again.

If it is needed to limit TTL, it is possible from the CLI, 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 resolves to different IPs for different request to implement DNS based load balance. That will result in discrepancy of the IP resolved between FortiGate and by the other host. A workaround to the problem is to set a large cache-ttl so that IP address will be saved longer even its TTL expires.

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

Sometimes it happens that a new DNS query will replace 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)

Doing 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 are original TTL:time to expire in TTL:time to expire in cache

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