3.3 DNS Configuration & Dynamic DNS

3.3 DNS Configuration & Dynamic DNS

Quick Answer: Fireware separates DNS into Network DNS (system-wide resolvers configured under Network > Configuration > WINS/DNS and used by Firebox security daemons) and Interface-Specific DNS (overriding system DNS for clients on individual interface DHCP scopes). DNS Forwarding turns the Firebox into an in-line caching DNS resolver, while Conditional Domain Forwarding routes queries for specific internal domain names (e.g., *.corp.local) to private corporate nameservers (such as Active Directory Domain Controllers across a VPN) and sends public queries upstream. For dynamic public IP interfaces, Dynamic DNS (DDNS) automatically updates FQDN records at providers like DynDNS, No-IP, and WatchGuard DDNS over secure HTTPS sessions, using a Force Update interval (typically 28 days) to prevent provider account expiration during periods of IP stability.

The Mission-Critical Role of DNS in Fireware OS

The Domain Name System (DNS) is foundational to both standard client connectivity and the core security operations of Fireware OS. While client workstations rely on DNS to locate web servers and email hosts, the Firebox itself operates as an intensive DNS consumer. A wide spectrum of built-in security engines and administrative functions depend directly on continuous, low-latency DNS resolution:

• WebBlocker: Queries cloud-based URL classification databases (Forcepoint / Websense) in real time to categorize HTTP/HTTPS destinations.
• Gateway AntiVirus (GAV): Connects to cloud signature servers to download updated signature databases.
• APT Blocker: Queries cloud sandbox infrastructure to transmit file checksums and receive malware behavioral analysis verdicts.
• ThreatSync (XDR): Submits local endpoint and firewall telemetry and receives cloud threat intelligence updates.
• SpamBlocker & Reputation Enabled Defense (RED): Resolves Recurrent Pattern Detection (RPD) queries and reputation scores for sending IP addresses.
• FQDN-Based Policies & Aliases: Periodically resolves Fully Qualified Domain Names (e.g., *.microsoft.com, api.salesforce.com) defined in firewall policies, dynamically updating the underlying IP filter tables.
• NTP Time Synchronization: Resolves public NTP pools (pool.ntp.org) to maintain exact millisecond clock alignment required for certificate validation and log timestamps.

If the Firebox is configured with unreachable or high-latency DNS servers, security subscription lookups fail or time out, resulting in degraded security posture (failing open or failing closed) and severe web browsing latency for all protected users.

---

Network DNS vs. Interface-Specific DNS Configuration

Fireware implements a dual-tier DNS configuration architecture that separates global device-level resolution from client-level subnet distribution.

1. Network DNS (System-Wide Resolvers)

Configured in Policy Manager under Network > Configuration > WINS/DNS or in Fireware Web UI under Network > Interfaces > WINS/DNS tab:

• Domain Name: Specifies the primary domain suffix for the Firebox (e.g., example.com).
• Primary & Secondary DNS Servers: Specifies the upstream IPv4 and IPv6 recursive resolvers that the Firebox OS uses for its own internal operations.
• Domain Search List: An ordered list of domain suffixes automatically appended when the Firebox resolves unqualified hostnames.
• Consumers: Utilized exclusively by Fireware system daemons, subscription security services, license synchronization, and administrative processes.
• DHCP Inheritance: If an interface DHCP scope is configured to Use Network DNS, connected clients receive these identical system resolvers.

2. Interface-Specific DNS (Per-Interface Overrides)

Configured within the individual interface DHCP server settings under Network > Interfaces > Edit > DHCP Server tab:

• Allows an administrator to explicitly configure unique Primary and Secondary DNS servers distributed only to clients receiving DHCP leases on that specific physical or virtual interface.
• Completely overrides the global Network DNS settings for that interface's DHCP clients.

Practical Enterprise Architecture Scenario

Consider an enterprise deploying a Firebox with three distinct network zones:

                    [Upstream Public DNS / DNSWatch]
                                   ^
                                   |
                           [Firebox Appliance]
                     Network DNS: 1.1.1.1, 8.8.8.8
                    /              |              \
       [Eth1 - Trusted]    [Eth2 - Optional]    [Eth3 - Custom]
         Corporate LAN        Guest Wi-Fi         IoT Devices
         DHCP Server:         DHCP Server:        DHCP Server:
       DNS: 10.0.1.10,      DNS: 1.1.1.1,       DNS: Use Network
            10.0.1.11            8.8.8.8             DNS
       (Internal AD DC)     (Public Resolvers)  (Inherits 1.1.1.1)

1. Trusted Interface (Corporate LAN): Connected workstations must resolve Active Directory domain resources (corp.example.local), Kerberos authentication targets, internal file servers, and intranet sites. The DHCP server on Eth1 is configured with Interface-Specific DNS pointing to the internal domain controllers (10.0.1.10 and 10.0.1.11).
2. Optional Interface (Guest Wi-Fi): Guests should never query or discover internal Active Directory nameservers. The DHCP server on Eth2 is configured with Interface-Specific DNS pointing to public recursive resolvers (1.1.1.1 and 8.8.8.8) or WatchGuard DNSWatch resolvers. This isolates corporate DNS infrastructure from untrusted guest devices.
3. Firebox System Daemons: The Firebox itself continues to query the fast, public Network DNS servers (1.1.1.1 and 8.8.8.8) for WebBlocker, GAV, and ThreatSync, ensuring security service traffic does not depend on internal server availability.

---

DNS Forwarding & Conditional Domain Forwarding

When a network includes distributed branch offices, remote sites, or hybrid cloud environments, simple static DNS assignment introduces architectural challenges. To resolve these, Fireware provides DNS Forwarding and Conditional Domain Forwarding (configured under Network > Configuration > DNS Forwarding).

DNS Forwarding Mechanics

When DNS Forwarding is enabled globally:

• The Firebox begins listening for incoming DNS queries on UDP and TCP port 53 across all Trusted, Optional, and Custom interfaces.
• DHCP scopes are configured to hand out the Firebox interface IP address (e.g., 192.168.1.1) as the client's primary DNS server.
• In-Memory Caching: The Firebox maintains a local in-memory DNS cache. When a client requests www.example.com, the Firebox queries its upstream forwarder, stores the resulting A record in memory along with its Time-to-Live (TTL), and returns the answer. When subsequent clients query the same domain, the Firebox answers immediately from cache, drastically reducing WAN bandwidth usage and eliminating resolution latency.

Conditional Domain Forwarding (Domain Name Rules)

In split-horizon enterprise networks, branch office users must resolve both internal private corporate domains and external public Internet domains:

• If branch clients point directly to public DNS (8.8.8.8), they cannot resolve internal corporate servers (e.g., crm.corp.local).
• If branch clients point all DNS queries to the headquarters domain controller across a Branch Office VPN (BOVPN), every public web search and streaming request must traverse the VPN tunnel, creating a severe performance bottleneck and adding latency.

Conditional Domain Forwarding eliminates this dilemma by allowing the administrator to define domain-specific forwarding rules:

Client Query: 'intranet.corp.local'
       ↓
Firebox checks DNS Forwarding Rules:
  - Rule: '*.corp.local' → Forward across BOVPN to 10.0.1.10 (Corporate AD DC)
  - All Other Domains (*.com, *.org) → Forward to Upstream Network DNS (8.8.8.8)

Configuration of Domain Name Rules:

1. The administrator enables DNS Forwarding.
2. In the Conditional Forwarding section, the administrator adds a rule:
   • Domain Name: corp.local (or *.corp.local).
   • Forwarder IP Addresses: 10.0.1.10 and 10.0.1.11 (the headquarters Active Directory DNS servers reached via BOVPN).
3. When a branch user visits fileserver.corp.local, the Firebox inspects the domain suffix, recognizes the match for corp.local, and forwards the query across the VPN to 10.0.1.10.
4. When the same user visits www.watchguard.com, the Firebox finds no rule match and forwards the query directly to the public Network DNS servers over the local Internet connection.

Integration with WatchGuard DNSWatch

When WatchGuard DNSWatch is licensed and enabled:

• The Firebox automatically intercepts outbound client DNS queries on port 53 and redirects them to DNSWatch secure recursive resolvers.
• If a user inadvertently clicks a phishing link or malware attempts to establish command-and-control (C2) communication, DNSWatch blocks the resolution and redirects the user to a secure educational landing page.
• Conditional domain forwarding rules take precedence over DNSWatch redirection, ensuring internal corporate domain lookups remain directed to private domain controllers.

---

Dynamic DNS (DDNS) Implementation on Dynamic External WANs

In many small-to-medium enterprise (SMB) and branch office deployments, procuring static public IPv4 addresses from Internet Service Providers is cost-prohibitive or unavailable (e.g., dynamic cable, DSL, or 4G/5G cellular backup links). When an ISP dynamically rotates the Firebox External IP address:

• Inbound Branch Office VPN (BOVPN) tunnels initiated by remote peers collapse.
• Mobile VPN users (IKEv2, SSL, L2TP) cannot resolve the gateway to connect.
• Remote administrative access via Fireware Web UI or WSM is severed.

Dynamic DNS (DDNS) solves this by running an embedded client on the Firebox that monitors the External interface IP address and automatically updates a public Fully Qualified Domain Name (FQDN) whenever the address changes.

Supported Dynamic DNS Providers

Fireware natively supports four dynamic DNS provider mechanisms under Network > Dynamic DNS:

1. DynDNS (dyn.com): Industry standard commercial dynamic DNS service.
2. No-IP (noip.com): Widely used dynamic DNS provider.
3. WatchGuard DDNS: A complimentary DDNS service provided by WatchGuard for all registered Fireboxes with active Standard Support. The Firebox registers an FQDN under the *.dyn.watchguard.com domain (e.g., seattle-branch.dyn.watchguard.com).
4. Custom Provider: Allows integration with custom HTTP/HTTPS dynamic DNS APIs compliant with the standard DynDNS v2 protocol.

Key Configuration Parameters

• Interface: The specific External interface monitored for IP changes.
• Provider: The selected dynamic DNS service.
• Domain Name / FQDN: The registered hostname to maintain (e.g., vpn.company.no-ip.org).
• Username & Password / Key: The authentication credentials or API update token provided by the DDNS service.
• Force Update Interval (Critical Setting):
  • Third-party dynamic DNS providers (such as No-IP and DynDNS) enforce strict account activity policies. If an account sends no update for 30 consecutive days, the provider assumes the domain is abandoned and automatically releases or deactivates the hostname.
  • On stable broadband connections, an ISP might leave the public IP address unchanged for multiple months. Without scheduled updates, the provider would cancel the domain registration despite the site being fully operational.
  • To prevent this, Fireware includes a configurable Force Update interval (default is typically 28 days). The Firebox periodically transmits a forced update to the provider, confirming that the hostname is active and renewing the registration.
• IP Detection Mode:
  • Interface IP: The Firebox reads the IP assigned directly to its External interface. Used when the Firebox holds a routable public IP.
  • Detected IP Address: Used when the Firebox sits behind an upstream ISP modem/router performing double-NAT. The Firebox contacts a public STUN/web utility to discover its true public NAT address and reports that external IP to the DDNS provider.

Security Best Practice

Fireware transmits all DDNS update requests over TLS-encrypted HTTPS connections. This protects the administrator's account credentials and API keys from interception on transit ISP networks.

---

Operational Verification, Diagnostics & FSM

Fireware provides dedicated tools for verifying and troubleshooting DNS and DDNS operations:

1. Firebox System Manager (FSM)

• Status Report > Dynamic DNS: Displays the current operational status of the DDNS client, the registered domain name, the last reported IP address, and the timestamp of the last successful update.
• Traffic Monitor: Filter by ddns to observe real-time update transactions and server return codes:
  • good: The update was successful and the IP was modified.
  • nochg: The update succeeded and the IP was identical.
  • badauth: Authentication failure (incorrect username or update token).
  • nohost: The specified FQDN does not exist under the provider account.

2. Web UI Diagnostic Tools

Under Diagnostics > Network, select the DNS Lookup tool. This allows the administrator to perform an interactive DNS query directly from the Firebox OS, testing resolution against configured Network DNS servers and validating conditional forwarding rules.

3. Fireware CLI Verification

• show dns-forwarding — Displays DNS forwarding operational status, listening interfaces, cache statistics, and active conditional domain rules.
• show dynamic-dns — Displays configured DDNS profiles, monitored interfaces, registered hostnames, and last update results.
• diag dns — Runs real-time diagnostic checks against system nameservers.