The Palo Alto firewall has a feature called DNS Proxy. Normally it is used for data plane interfaces so that clients can use the interfaces of the Palo for its recursive DNS server. Furthermore, this DNS Proxy Object can be used for the DNS services of the management plane, specified under Device -> Setup -> Services. However, there was a bug in PAN-OS that did not process the proxy rules and static entries when a DNS proxy object was used in the management plane. This bug was fixed in PAN-OS 6.0.0. I tested it in my lab with PAN-OS 6.1.0 running. Here are the successful results.
The fixed bug in version 6.0.0 was bug ID 41472: “When a DNS Proxy object was configured with static entries, hostnames assigned to the DNS Proxy were resolved as expected to the IP addresses listed on the Static Entries tab (Network > DNS Proxy). However, when setting the DNS Proxy Object as the DNS Service on the Device > Setup > Services dialog, all DNS queries from the management interface ignored the defined static entries.”
DNS Proxy
I added a DNS proxy called “Google” with their two public DNS servers, as well as a few proxy rules to other DNS servers and static entries. This proxy object was then referenced for the management services as a “DNS Proxy Object”:
Tests
After a commit, I pinged a few hosts from the management plane. The first one should use the default DNS server, while the three following requests should use the proxy rules. The last object was the static entry in the DNS proxy.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
weberjoh@fd-wv-fw02> ping host heise.de PING heise.de (193.99.144.80) 56(84) bytes of data. 64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=1 ttl=245 time=44.0 ms 64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=2 ttl=245 time=12.5 ms ^C --- heise.de ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1008ms rtt min/avg/max/mdev = 12.514/28.279/44.044/15.765 ms weberjoh@fd-wv-fw02> ping host webernetz.net PING webernetz.net (80.237.133.136) 56(84) bytes of data. 64 bytes from wp367.webpack.hosteurope.de (80.237.133.136): icmp_seq=1 ttl=55 time=86.9 ms 64 bytes from wp367.webpack.hosteurope.de (80.237.133.136): icmp_seq=2 ttl=55 time=66.9 ms ^C --- webernetz.net ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1004ms rtt min/avg/max/mdev = 66.965/76.949/86.933/9.984 ms weberjoh@fd-wv-fw02> ping host ra.webernetz.net PING ra.webernetz.net (192.168.112.4) 56(84) bytes of data. 64 bytes from 192.168.112.4: icmp_seq=1 ttl=62 time=1.13 ms 64 bytes from 192.168.112.4: icmp_seq=2 ttl=62 time=1.20 ms ^C --- ra.webernetz.net ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1008ms rtt min/avg/max/mdev = 1.139/1.170/1.201/0.031 ms weberjoh@fd-wv-fw02> ping host www.formel1.de PING www.formel1.de (78.138.119.82) 56(84) bytes of data. 64 bytes from f1-lb01.formel1.de (78.138.119.82): icmp_seq=1 ttl=53 time=11.9 ms 64 bytes from f1-lb01.formel1.de (78.138.119.82): icmp_seq=2 ttl=53 time=52.4 ms ^C --- www.formel1.de ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1009ms rtt min/avg/max/mdev = 11.925/32.206/52.487/20.281 ms weberjoh@fd-wv-fw02> ping host asdf.foobar.com PING asdf.foobar.com (1.2.3.4) 56(84) bytes of data. ^C --- asdf.foobar.com ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 999ms |
Since the default route of the management interface points through one of the data interfaces of the Palo Alto, I could easily do a packet capture on the Palo itself. It correctly revealed the three different DNS servers for the requests. Of course, the request to the static entry is not shown since it did not trigger a DNS request to a server.
Works as Expected
The tests showed that the function of a DNS proxy for the management services works as expected. Not only the default DNS servers, but also the proxy rules and static entries are used through the management plane.
Note that the following scenarios do NOT work:
- Pre PAN-OS 6.x, the DNS Proxy object used in the management services sent all requests to the primary and secondary DNS servers but NOT to the proxy rules. The static entries were not used, too.
- It is not possible to set a “DNS Server” in the management services to the IP address of a data interface of the Palo Alto itself. This won’t work since the Palo uses some kind of internal path when sending packets to an own data interface. This means, if a DNS Proxy object should be used, it must be selected as a “DNS Proxy Object” and not as an entry of “DNS Servers”.
I’m using the same setup as suggested in your blog post. I created a dns proxy object to serve my local lan. It has a few static entries and it is pointing to two public dns servers. (91.239.100.100 and 37.235.1.174) I’ve installed minemeld on a local vm and this server has a local dns name which is in the list of static entries. When I configure [device>setup>services>dns] with the listed dns servers I’m not able to resolve my local minmeld vm. This is expected. When I configure [device>setup>services>dns] with the dns proxy object, the minemeld vm is resolved correctly but fails to resolve updates.paloaltonetworks.com. Does this ring a bell and could this be related to the (old) bug you mentioned in your post? I’m running panos 8.1.0-b41.
Hey sansmouse.
No, it does not directly ring a bell. Sorry. Is the DNS proxy object for the management working for other domain names? If yes, then it’s really strange, since then *only* “updates.paloaltonetworks.com” is not working.
I had some more issues with the DNS proxy on the Palo Alto during the last years. So, to be honest, I do NOT recommend the usage of the DNS proxy at all to my customers! We simply had TOO MANY issues with it. ;(
Another example: The DNS proxy rules are NOT correctly matched when using customized “service routes” under Device -> Setup -> Services -> Services Features. Concrete: If a proxy rule is matched AND you have a service route for DNS, this service route is NOT used but the hardware management interface again. Buggy at all…