Dynamic DNS Overview
Focus
Focus

Dynamic DNS Overview

Table of Contents
End-of-Life (EoL)

Dynamic DNS Overview

What is Dynamic DNS?
When you have services hosted behind the firewall and use destination NAT policies on the firewall to access those services or when you need to provide remote access to the firewall, you can register IPv4 address changes (whether the interface is a DHCP client receiving a dynamic address or has a static address) or IPv6 address changes (static address only) for the interface with a dynamic DNS (DDNS) service provider. The DDNS service automatically updates the domain name-to-IP address mappings to provide accurate IP addresses to DNS clients, which, in turn, can access the firewall and services behind the firewall. DDNS is often used in branch deployments that are hosting services. Without DDNS support for firewall interfaces, you would need external components to provide accurate IP addresses to clients.
The firewall supports the following DDNS service providers: DuckDNS, DynDNS, FreeDNS Afraid.org Dynamic API, FreeDNS Afraid.org, and No-IP. The individual DDNS service provider determines the services it provides, such as how many IP addresses it supports for a hostname and whether it supports IPv6 addresses. Palo Alto Networks® uses content updates to add new DDNS service providers and to provide updates to their services.
For high availability (HA) configurations, make sure that content versions on the HA firewall peers (active/passive or active/active) are in sync because the firewall maintains the DDNS configuration based on the current Palo Alto Networks content release version. Palo Alto Networks can change or deprecate existing DDNS services through a content release. Additionally, a DDNS service provider can change the services it provides. A mismatch in content release versions between the HA peers can cause issues with their ability to use the DDNS service.
The firewall does not support DDNS over an interface that is a Point-to-Point Protocol over Ethernet (PPPoE) termination point.
In the following example, the firewall is a DDNS client of a DDNS service provider. Initially, the DHCP server assigns IP address 10.1.1.1 to the Ethernet 1/2 interface. A destination NAT policy translates the public-facing 10.1.1.1 to the real address of Server A (192.168.10.1) behind the firewall.
  1. When a user attempts to contact www.serverA.companyx.com, the user queries its local DNS server for the IP address. The www.serverA.companyx.com (set, for example, as a CNAME to your duckdns.org record: serverA.companyx.duckdns.org) is a domain belonging to the DDNS provider (DuckDNS in this example). The DNS server checks for the record with the DDNS provider to resolve the query.
  2. The DNS server responds to the user with 10.1.1.1, which is the IP address for www.serverA.companyx.com.
  3. The user packet with destination 10.1.1.1 goes to firewall interface Ethernet 1/2.
  4. In this example, the firewall performs destination NAT and translates 10.1.1.1 to 192.168.11.0 before sending the packet to the destination.
After some time passes, DHCP assigns a new IP address to the firewall interface, which triggers a DDNS update, as follows:
  1. The DHCP Server assigns a new IP address (10.1.2.2) to Ethernet 1/2.
  2. When the firewall receives the new address, it sends an update to the DDNS service with the new address for www.serverA.companyx.com, which the DDNS service registers. (The firewall also sends regular updates based on the update interval you configure. The firewall sends DDNS updates over HTTPS port 443.)
Consequently, the next time the client queries the DNS server for the IP address of www.serverA.companyx.com and the DNS server checks the DDNS service, the DDNS service sends the updated address (10.1.2.2). Thus, the user successfully accesses a service or application through the firewall interface using the updated interface address.
If your firewall is configured for HA active/passive mode, be aware that the firewall sends DDNS updates to the DDNS service while the two HA firewall states are converging. After the HA states converge, DDNS is disabled on the passive firewall. For example, when two HA firewalls first boot up, they both send DDNS updates until they establish whether they are in HA active or passive mode. During this interval, you still see DDNS updates in system logs. After the HA states converge and each firewall notifies its clients that it is active or passive, the passive firewall no longer sends DDNS updates. (In HA active/active mode, each firewall has an independent DDNS configuration and doesn’t synchronize the DDNS configuration.)