Gateway DNS Configuration

The DNS (Gateway v14+) tab defines how the gateway resolves domain names for all traffic passing through it. From here, you can assign the resolvers the gateway uses for standard queries, pin specific domains to fixed IP addresses, and route internal domain traffic to a dedicated DNS server using Split DNS.

Getting this configuration right ensures that devices behind the gateway can reach both public internet resources and internal services without interruption.


Domain Name Servers

This section defines the upstream DNS resolvers the gateway uses for all standard domain queries. Any domain that isn't covered by a static record or a Split DNS rule will be resolved through these servers.

FieldDescription
Domain Name ServerThe IP address of the resolver you want to add. Both public resolvers (e.g., 1.1.1.1) and internal DNS servers are supported.

You can add up to three DNS servers. Adding at least two is recommended β€” if the first becomes unreachable, the gateway falls back to the next in the list, preventing resolution failures from affecting connectivity.


DNS Records

Static DNS records let you manually map a domain name to a specific IP address. These mappings take precedence over both global resolvers and Split DNS rules, making them a reliable way to guarantee that certain resources are always reachable at a known address.

FieldDescription
DNS RecordThe domain name to override (e.g., printer.local, dashboard.internal).
IP AddressThe IP address the domain should resolve to.

Each DNS record maps to exactly one IP address. However, multiple domain names can point to the same IP address. For example, both example.com and sample.com can resolve to 192.168.249.100, but example.com cannot be assigned two different IP addresses at the same time.

Static records are most useful for internal resources that either don't appear in any DNS server or whose IP address needs to remain fixed β€” such as network printers, internal dashboards, monitoring tools, or legacy systems. They also serve as a practical fallback when a resource must remain resolvable even if your internal DNS server goes down.


Split DNS

By default, all domain queries go through the global resolvers defined above. Split DNS lets you carve out exceptions: queries for specific domains are sent to a designated internal DNS server, while everything else continues using the global resolver list.

FieldDescription
Enable Split DNSActivates domain-based DNS routing.
Search DomainsThe internal domain or subdomain to route to a separate resolver.
DNS ServerThe IP address of the DNS server that should handle queries for the specified domain.
PortThe port the DNS server listens on.

When to use Split DNS

Split DNS is the right choice when your organization runs internal services under a private domain that isn't publicly resolvable. A common example: your company hosts resources under corp.local, which only your internal DNS server knows how to resolve. Without Split DNS, the gateway would send those queries to a public resolver, which would fail to find them.

With Split DNS enabled, queries for corp.local go straight to your internal server, while everything else continues through the global resolvers. This separation is especially important in hybrid environments where internal and external traffic must be handled differently without exposing private infrastructure to the public internet.

Split DNS only affects query routing. It does not encrypt DNS traffic or prevent internal domain names from being visible to other parties on the network. If DNS privacy is a concern, consider pairing this with additional security controls.


Split DNS with DNS Servers Behind IPsec (Advanced Configuration)

In environments where the internal DNS server is located behind an IPsec tunnel, additional configuration is required for Split DNS to function correctly.

Important: Without this configuration, DNS queries may not traverse the IPsec tunnel correctly, and Split DNS may not function as expected.

Required Configuration

The gateway’s Primary WAN IP (port0) must be included in the subnet configuration on both sides of the IPsec tunnel.

Timus Configuration

  • Local Subnet:
    • WireGuard subnet (e.g., 192.168.249.0/24)
    • Primary WAN IP as /32 (e.g., 10.1.10.150/32)
  • Remote Subnet:
    • Internal network (e.g., 192.168.10.0/24)

Remote Peer Configuration (e.g., FortiGate)

  • Local Subnet: 192.168.10.0/24
  • Remote Subnet:
    • WireGuard subnet
    • Primary WAN IP (/32)
Warning: If the Primary WAN IP is not included, DNS queries may not traverse the tunnel, causing Split DNS to fail.

Why This Is Required

  • DNS queries may originate from the gateway WAN IP
  • If not included in IPsec policies, traffic is dropped
  • This results in failed or fallback DNS behavior
Result: Including the WAN IP ensures DNS queries are properly routed through the tunnel, and internal domains resolve correctly.

Updated

Was this article helpful?

1 out of 1 found this helpful

Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.