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.
| Field | Description |
|---|---|
| Domain Name Server | The 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.
| Field | Description |
|---|---|
| DNS Record | The domain name to override (e.g., printer.local, dashboard.internal). |
| IP Address | The 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.
| Field | Description |
|---|---|
| Enable Split DNS | Activates domain-based DNS routing. |
| Search Domains | The internal domain or subdomain to route to a separate resolver. |
| DNS Server | The IP address of the DNS server that should handle queries for the specified domain. |
| Port | The 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.
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)
- WireGuard subnet (e.g.,
- Remote Subnet:
- Internal network (e.g.,
192.168.10.0/24)
- Internal network (e.g.,
Remote Peer Configuration (e.g., FortiGate)
- Local Subnet:
192.168.10.0/24 - Remote Subnet:
- WireGuard subnet
- Primary WAN IP (/32)
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
Updated
Comments
0 comments
Please sign in to leave a comment.