While Network Address Translation (NAT) modifies IP addresses in packet headers, its effectiveness often depends on correct Domain Name System (DNS) resolution, especially in scenarios involving internal users accessing internal resources via public names. Palo Alto Networks firewalls provide features like DNS Proxy to manage this interaction effectively, often eliminating the need for complex U-Turn NAT configurations.
Consider a common scenario:
10.1.1.100
(in the DMZ zone).
203.0.113.50
(on the Untrust interface) to
10.1.1.100
for external access.
www.mycompany.com
points to
203.0.113.50
.
192.168.1.20
in the Trust zone) tries to access
www.mycompany.com
.
What happens? The internal user's DNS query resolves
www.mycompany.com
to the
public IP
203.0.113.50
. The user then tries to connect to this public IP. The traffic hits the firewall. To make this work, the firewall typically needs a
U-Turn NAT
configuration (both DNAT and SNAT for internal source/public destination) to hairpin the traffic back to the internal server. This can be complex to set up and potentially inefficient.
A better approach is "Split-DNS" (also called split-horizon DNS), where DNS resolution provides different answers based on the source of the query. Internal users get the internal IP, while external users get the public IP.
Palo Alto firewalls implement this using the DNS Proxy feature.
www.mycompany.com
to the internal IP
10.1.1.100
.
192.168.1.20
) queries for
www.mycompany.com
, the query goes to the firewall.
10.1.1.100
.
10.1.1.100
.
Benefit: Because the client connects directly to the internal IP, traffic flows directly from the Trust zone to the DMZ zone (or wherever the server is). No U-Turn NAT is needed for this specific access, simplifying NAT policy and potentially improving performance.
When DNS Proxy provides the internal IP address, the subsequent connection attempt bypasses the need for U-Turn NAT. The Security Policy evaluation is straightforward:
Trust
(Where internal client is)
192.168.1.20
(or client subnet)
DMZ
(Where internal server is)
10.1.1.100
(The internal server's private IP)
ssl
,
web-browsing
)
Allow
The standard external DNAT rule and its corresponding Security rule (Untrust zone to DMZ zone, Destination IP = Public IP) remain in place for external users.
Palo Alto NAT rules also have a "DNS Rewrite" option (Reverse or Forward). This is typically used to ensure consistency when addresses are being translated by the NAT rule itself, rather than as the primary split-DNS mechanism. For example, if doing Static Source NAT, DNS Rewrite (Reverse) can translate embedded IPs in the DNS response payload back to the original source.
For standard split-DNS use cases (internal clients getting internal IPs), DNS Proxy is the dedicated and generally preferred feature .
Within Palo Alto Networks NAT policy rules, there's a checkbox option for "DNS Rewrite". This feature allows the firewall to inspect the payload of DNS responses passing through it and modify specific IP addresses found within that payload, corresponding to the address translation being performed by the *same NAT rule*. It has two modes: Reverse and Forward.
This feature is not the primary tool for implementing split-DNS (where internal users get internal IPs and external users get public IPs for the same FQDN) – DNS Proxy is generally preferred for that common use case. DNS Rewrite addresses specific situations where the NAT translation itself might cause inconsistencies if IP addresses are embedded directly in DNS response data.
10.1.1.10
10.1.1.10
to
203.0.113.10
for outbound traffic.
10.1.1.10
sends a DNS query outbound (source becomes
203.0.113.10
).
203.0.113.10
. Let's say the payload (e.g., in an A record or TXT record data) contains the IP
203.0.113.10
.
10.1.1.10
), it inspects the payload. It sees
203.0.113.10
and rewrites it to
10.1.1.10
.
10.1.1.10
in the payload.
10.2.2.20
203.0.113.20
(Public IP) to
10.2.2.20
for incoming DNS queries.
service.mycompany.com
via
203.0.113.20
. The query reaches
10.2.2.20
.
10.2.2.20
crafts a response containing the A record IP
10.1.1.100
(another internal server).
10.2.2.20
, it inspects the payload. It sees
10.1.1.100
and (if a corresponding NAT rule exists) rewrites it to
203.0.113.100
.
203.0.113.100
.
Key Reminder: DNS Rewrite within NAT rules is for fixing inconsistencies caused by the NAT translation affecting DNS *payloads*. For the common "split-DNS" requirement (internal clients getting internal IPs for internal servers), configure internal clients to use the firewall's IP as their DNS server and use the firewall's DNS Proxy feature with Static Entries. This avoids complex NAT rules and directs internal clients correctly from the start.