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.
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.
The DNS server responds to the user with 10.1.1.1, which is
the IP address for www.serverA.companyx.com.
The user packet with destination 10.1.1.1 goes to firewall interface
Ethernet 1/2.
In this example, the firewall performs destination NAT and translates
10.1.1.1 to 192.168.10.1 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:
The DHCP Server assigns a new IP address (10.1.2.2) to Ethernet
1/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.)