| Description | This article describes an issue that may arise when FQDN addresses are used in conjunction with a local DNS Database. |
| Scope | FortiGate |
| Solution |
On a FortiGate that uses an FQDN address object in firewall policies, issues will arise if the FortiGate is unable to resolve the FQDN to an IP Address.
A FortiGate uses IP Addresses (amongst other things) to match firewall policies, so if it cannot resolve an FQDN then traffic may not match a policy and the traffic flow will not work as expected.
One such problem is if the FortiGate is configured for a local DNS database, which could be used for a locally-hosted captive portal, for example. Let's use this as an example.
If the local DNS Database for our zone 'bah.com' is configured to be 'Authoritative', then this can affect DNS resolution for other FQDNs that happen to use the same root domain but are hosted on an upstream DNS server.
For example, the FQDN captive.bah.com may be working for the captive portal, but an FQDN object for foo.bah.com may not.
In this scenario, it may not be obvious why the DNS resolution is failing, since DNS resolution for devices passing through the Firewall (to the upstream DNS server) will still resolve, but FQDN objects hosted on the firewall itself, may not.
As FQDN records are also cached, the DNS resolution issue may also be intermittent, which can further hamper the troubleshooting.
The solution here is to disable the 'authoritative' flag in the DNS Database, as shown below:
If a DNS server is configured to be Authoritative for the domain, it is saying that 'I am the only DNS server for this zone', and that a given host entry does not exist in this zone - then it does not exist at all. Which is not true in this scenario.
It is also important to note that this flag is enabled by default when creating a new DNS Zone, so use this option with care.
Related documents: Technical Tip: Explanation of the FQDN default cache-ttl |
