Home

FortiGate DNS Conditional Forwarding: A Technical Investigation into Enterprise Name Resolution Control

.

FortiGate configure DNS forwarding: authoritative guide to conditional DNS forwarding setup, CLI syntax, version compatibility, and operational verification.

The Architecture of Selective DNS Resolution

Conditional DNS forwarding on FortiGate represents a deliberate departure from blanket name resolution. Rather than routing every DNS query through a single upstream resolver, administrators can instruct the firewall to forward requests for specific domains—such as corp.internal or ad.example.com—to designated internal DNS servers, while delegating all other queries to public resolvers or FortiGuard. This capability proves essential in hybrid environments where Active Directory, legacy applications, or segmented networks require isolated name resolution paths.

The feature operates within FortiOS's DNS database subsystem. When enabled, the FortiGate functions as a recursive DNS server on designated interfaces, intercepting client queries and applying domain-matching rules before determining the appropriate upstream forwarder.

Core Configuration: Enabling the DNS Forwarding Engine

Interface-Level Recursive DNS Activation

Before conditional rules take effect, the FortiGate must accept and process DNS queries from client devices. This requires enabling recursive DNS service on the relevant interface:

CLI Implementation

config system dns-server     edit "port4"         set mode recursive     next end

GUI Path: Network → DNS Servers → Create New → Select interface → Mode: Recursive

Without recursive mode enabled, the FortiGate will not forward unresolved queries to upstream servers, breaking resolution for domains not explicitly defined in local databases.

Defining Conditional Forwarding Rules

The heart of the configuration resides in the DNS database. Each entry maps a domain pattern to one or more forwarder IP addresses:

config system dns-database     edit "internal-ad"         set domain "corp.internal"         set authoritative disable         set forwarder "10.10.1.53" "10.10.1.54"     next end

Critical parameters include:

  • domain: The FQDN or subdomain pattern to match. Wildcards are not supported in this field; matching is exact or suffix-based.
  • authoritative: When disabled (recommended for forwarding), the FortiGate queries forwarders for unmatched records. When enabled, it responds only with locally defined entries, returning NXDOMAIN for everything else.
  • forwarder: Space-delimited list of upstream DNS server IPs. Multiple entries provide failover sequencing.

Version-Specific Capabilities

Transparent conditional DNS forwarding, introduced in FortiOS 7.4.1 and refined in 8.0.0, extends functionality by allowing the FortiGate to intercept and forward DNS traffic without requiring clients to explicitly point to the firewall as their resolver. This mode operates at the traffic inspection layer, making it suitable for environments where DHCP-managed DNS settings cannot be centrally controlled.

FortiOS 7.6 and later introduce interface selection for forwarder traffic:

config system dns-database     edit "zone-a"         set interface-select-method specify         set interface "vlan10"     next end

This ensures forwarder-bound queries exit through the correct network segment, a necessity in multi-VRF or SD-WAN deployments.

Operational Behavior and Failover Mechanics

When multiple forwarders are configured, the FortiGate applies a deterministic sequence:

  1. Query the local DNS cache. A valid, unexpired entry satisfies the request immediately.
  2. Forward to the first configured server. A 5-second timeout governs responsiveness.
  3. Upon timeout, mark the first server non-responsive for 5 seconds and retry with the second forwarder.
  4. Continue sequencing through available forwarders. No active health probing occurs; failover is reactive.

This behavior prioritizes low-latency resolution while providing basic redundancy. Administrators should monitor forwarder responsiveness via diagnose test app dnsproxy 2, which exposes query counts, timeouts, and server latency metrics.

Verification and Diagnostic Procedures

Confirming correct operation requires observing query flow at the packet level. The following sniffer filter isolates DNS traffic between a client, the FortiGate, and a forwarder:

diagnose sniffer packet any '(port 53 and host 172.16.191.210) or (port 53 and host 10.10.1.53)' 6 0 l

Expected output shows:

  • Client query arriving at the FortiGate interface
  • FortiGate generating a new query to the designated forwarder
  • Forwarder response returning to the FortiGate
  • FortiGate relaying the answer to the original client

For non-matching domains, the sniffer should reveal queries exiting via the system DNS path (configured under config system dns), confirming the conditional logic is functioning as intended.

Integration with DNS Filtering and Encrypted Protocols

Conditional forwarding operates independently of DNS filtering profiles, but the two can be combined for layered control. When a DNS filter profile is applied to an interface with recursive DNS enabled, filtering occurs before forwarding decisions. This sequence allows administrators to block malicious domains while still permitting legitimate internal resolution.

FortiOS 7.4.1+ supports DNS over TLS (DoT) and DNS over QUIC for transparent and local-in DNS modes. Encrypted upstream queries require specifying port 853 (DoT) or enabling QUIC in the forwarder definition, alongside a compatible SSL inspection profile for deep inspection scenarios.

Common Implementation Pitfalls

  • Client DNS Configuration: Conditional forwarding only affects devices that use the FortiGate as their DNS resolver. DHCP scopes must distribute the FortiGate's interface IP as the primary DNS server.
  • Authoritative Mode Misconfiguration: Enabling authoritative mode without populating local DNS entries causes NXDOMAIN responses for all non-local queries, breaking internet resolution.
  • Forwarder Reachability: The FortiGate must have a valid route to each forwarder IP. In VPN or segmented environments, explicit source-IP binding (set source-ip) may be required to ensure return traffic traverses the correct tunnel.
  • Feature Visibility: The DNS Database feature must be enabled under System → Feature Visibility before GUI configuration options appear.

Frequently Asked Questions

Q: Can conditional DNS forwarding resolve subdomains automatically?
A: Yes. A rule for corp.internal matches queries for server1.corp.internal and app.sub.corp.internal. Matching is suffix-based; more specific entries take precedence if multiple rules overlap.

Q: How does the FortiGate handle IPv6 DNS queries in conditional forwarding?
A: IPv6 queries follow the same conditional logic as IPv4. Forwarder definitions accept both IPv4 and IPv6 addresses. Cache entries are protocol-specific; an IPv4 cache hit does not satisfy an IPv6 query.

Q: Is it possible to apply different forwarders based on source subnet?
A: Not directly within the DNS database. Achieving source-based forwarding requires deploying multiple FortiGate interfaces or VDOMs, each with distinct DNS server configurations and policy-based routing.

Q: What happens if all configured forwarders become unreachable?
A: After exhausting the forwarder list with timeouts, the FortiGate returns a SERVFAIL response to the client. No automatic fallback to system DNS occurs for conditionally matched domains.

Q: Can conditional forwarding coexist with local DNS overrides?
A: Yes. Local DNS entries defined within the same dns-database stanza take precedence over forwarders. This enables hybrid resolution: known internal hosts resolve locally, while unknown names within the domain forward upstream.