Description
This article describes how to identify and prevent unwanted DNS queries from FortiGate’s FQDN Address ObjectYES.
Customer may notice frequent DNS queries sent by the FortiGate which match some of the FQDN addresses defined in their Address Objects.
When sniffing the DNS traffic originally coming from the FortiGate using the following filter, customer may notice frequent queries for certain FQDN address objects defined on the FortiGate.
# diag sniff packet any ‘host <ip of FortiGate> and udp port 53’ 6
This may be more noticeable for certain built-in FQDN objects in older builds which has been carried over during upgrade, however could also apply to any FQDN objects:
- softwareupdate.vmware.com
- autoupdate.opera.com
- swscan.apple.com
- auth.gfx.ms
FortiGate will re-query the FQDN address 5 seconds before its TTL expires. The TTL is the value returned by the DNS server, and can be identified using a nslookup query from Windows:
>nslookup -debug softwareupdate.vmware.com
------------
….
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 3, authority records = 8, additional = 9
QUESTIONS:
softwareupdate.vmware.com, type = A, class = IN
ANSWERS:
-> softwareupdate.vmware.com
canonical name = esd751.vmware.com.ds.edgekey.net
ttl = 1931 (32 mins 11 secs)
-> esd751.vmware.com.ds.edgekey.net
canonical name = e751.dscd.akamaiedge.net
ttl = 3 (3 secs)
-> e751.dscd.akamaiedge.net
internet address = 23.59.156.48
ttl = 9 (9 secs)
As highlighted above, the server replied in 9 seconds to the query to this A Record. Hence, the FortiGate will store this response in its cache for 9 seconds, but will perform a re-query 5 seconds before it expires.
The “cache-ttl” option should not be confused for a way to override how frequently the FortiGate re-queries the FQDN address. This option only defines for how long to keep an address, but does not define how fast the TTL expires. “cache-ttl” is used in instances where a DNS server rotates many different IP addresses for a particular FQDN in a short time frame, but the FortiGate would like to keep the IP address in cache even if the next query does not contain that IP address.
Solution
In 6.0.5+ and 6.2.0+, most built-in addresses used in SSL inspection and SSL Exemption has been moved to custom wildcard-fqdn under:
# config firewall wildcard-fqdn custom
However, since the upgrade will carry over older configurations, customers may still see legacy definitions for FQDN addresses such as:
# config firewall address
edit "autoupdate.opera.com"
set type fqdn
set fqdn "autoupdate.opera.com"
next
edit "google-play"
set uuid 724b1998-0070-51e7-9203-7ba60d18f6c0
set type fqdn
set fqdn "play.google.com"
next
edit "swscan.apple.com"
set type fqdn
set fqdn "swscan.apple.com"
next
edit "update.microsoft.com"
set type fqdn
set fqdn "update.microsoft.com"
next
end
To prevent these addresses from initiating unwanted DNS queries, users can either:
1) Identify whether these objects are used anywhere using the command below. If not, delete them entirely.
# show full | grep “swscan.apple.com” -f
2) Change the addresses into type wildcard-fqdn wherever applicable to avoid DNS queries.
# config firewall address
edit "swscan.apple.com"
set type wildcard-fqdn
set wildcard-fqdn "*swscan.apple.com"
next
end
Generally, if an FQDN address was used for SSL Exemption, it should be defined as a wildcard FQDN.
