I am using the DNS Proxy on a Palo Alto Networks firewall for some user subnets. Besides the default/primary DNS server, it can be configured with proxy rules (also called conditional forwarding) which I am using for reverse DNS lookups, i.e., PTR records, that are answered by a BIND DNS server. While it is easy and well-known to configure the legacy IP (IPv4) reverse records, the IPv6 ones are slightly more difficult. Fortunately, there are some good tools on the Internet to help reversing IPv6 addresses.
I am using a PA-200 with PAN-OS 7.1.2. The BIND server runs on a Ubuntu 12.04.5 LTS with BIND version 9.8.1-P1. For some general information about DNS reverse lookups, use this Wikipedia article. Similar to the notation of IPv6 address in the DNS.
DNS Proxy Rule
This is the configuration of my DNS Proxy with one proxy rule for the reverse lookups. Note that the connections from the Palo Alto to the DNS servers are established via IPv6 though the bulk of DNS lookups is still IPv4 (A records).
These are the “domain names” I configured. The first lines are the well-known legacy IP reverse zones (RFC1918, thanks to Israel in the comments for telling me that I was missing many zones for the 172.16.0.0/12 range!) while the last one is my /48 global unicast IPv6 subnet.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
*.168.192.in-addr.arpa *.16.172.in-addr.arpa *.17.172.in-addr.arpa *.18.172.in-addr.arpa *.19.172.in-addr.arpa *.20.172.in-addr.arpa *.21.172.in-addr.arpa *.22.172.in-addr.arpa *.23.172.in-addr.arpa *.24.172.in-addr.arpa *.25.172.in-addr.arpa *.26.172.in-addr.arpa *.27.172.in-addr.arpa *.28.172.in-addr.arpa *.29.172.in-addr.arpa *.30.172.in-addr.arpa *.31.172.in-addr.arpa *.10.in-addr.arpa *.2.1.0.6.1.5.0.0.3.0.0.2.ip6.arpa |
Now all DNS queries are primarily sent to the DNS server at 2003:51:6012:120::a08:53, while the reverse DNS (rDNS) lookups are sent to 2003:51:6012:120::11.
BIND Zone
I am using a BIND server for my reverse zones. Here are two of the many zones configured within the “named.conf.local” configuration file:
|
1 2 3 4 5 6 7 8 9 |
zone "168.192.in-addr.arpa" { type master; file "/etc/bind/db.168.192"; }; zone "2.1.0.6.1.5.0.0.3.0.0.2.ip6.arpa" { type master; file "/etc/bind/db.2.1.0.6.1.5.0.0.3.0.0.2"; }; |
And this is part of my /48 zone for IPv6 PTR records:
|
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 |
weberjoh@jw-vm10:/etc/bind$ cat db.2.1.0.6.1.5.0.0.3.0.0.2 ; ; 2003:51:6012::/48 ; ; Zone file built with the IPv6 Reverse DNS zone builder ; http://rdns6.com/ ; $TTL 1h ; Default TTL @ IN SOA jw-vm10.webernetz.net. webmaster.webernetz.net. ( 2016061401 ; serial 1h ; slave refresh interval 15m ; slave retry interval 1w ; slave copy expire time 1h ; NXDOMAIN cache time ) ; ; domain name servers ; @ IN NS jw-vm10.webernetz.net. ; IPv6 PTR entries ; 110 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.1.0.2.1.0.6.1.5.0.0.3.0.0.2.ip6.arpa. IN PTR fd-wv-fw01-dmz.webernetz.net. 9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.1.0.2.1.0.6.1.5.0.0.3.0.0.2.ip6.arpa. IN PTR jw-nb12-lx.webernetz.net. 2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.1.0.2.1.0.6.1.5.0.0.3.0.0.2.ip6.arpa. IN PTR jw-vm06-planes.webernetz.net. 5.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.1.0.2.1.0.6.1.5.0.0.3.0.0.2.ip6.arpa. IN PTR jw-esa.webernetz.net. 7.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.1.0.2.1.0.6.1.5.0.0.3.0.0.2.ip6.arpa. IN PTR f5-external.webernetz.net. 0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.1.0.2.1.0.6.1.5.0.0.3.0.0.2.ip6.arpa. IN PTR jw-ts01-perle.webernetz.net. 2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.1.0.2.1.0.6.1.5.0.0.3.0.0.2.ip6.arpa. IN PTR jw-vm16-ns1.weberdns.de. 2.d.3.5.3.0.e.f.f.f.7.7.3.1.2.0.0.1.1.0.2.1.0.6.1.5.0.0.3.0.0.2.ip6.arpa. IN PTR jw-nb04-ftp-adsb.webernetz.net. |
Test ‘n Wireshark
This is a basic test from a Windows 7 client behind one of the user subnets on the Palo Alto. It uses the IPv4 address of the Palo Alto layer 3 interface (192.168.125.1) for DNS queries. I tested a normal DNS name weberblog.net as well as a private/RFC1918 IPv4 address 192.168.100.0 . (Yes, in this case, the *.0 IPv4 address is not the network address but a real address.)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
C:\Users\weberjoh>nslookup Standardserver: pa-user.webernetz.net Address: 192.168.125.1 > weberblog.net Server: pa-user.webernetz.net Address: 192.168.125.1 Nicht autorisierende Antwort: Name: weberblog.net Addresses: 2a01:488:42:1000:50ed:8588:8a:c570 80.237.133.136 > > > 192.168.100.0 Server: pa-user.webernetz.net Address: 192.168.125.1 Name: nc-client-0.webernetz.net Address: 192.168.100.0 > > |
Captured on the Palo Alto (Monitor -> Packet Capture), these are two screenshots from Wireshark that show the connections to the different DNS servers for the different use cases. In any case, the queries from the Palo Alto are made from the appropriate layer 3 interfaces with the corresponding IPv6 addresses, in my case 2003:51:6012:125::1, etc.:
Some Notes
For more information about the DNS proxy use this Palo Alto Networks article: How to Configure DNS Proxy on a Palo Alto Networks Firewall.
Also note that during some configuration changes (commits) on the Palo Alto, the DNS proxy was not working anymore at all! The only way to bring it back to life was to restart the process from the CLI on the Palo:
|
1 |
debug software restart process dnsproxy |
Cheers.
Featured image “Unklar” by 5auge is licensed under CC BY-NC-ND 2.0.
Nice post, helped me figure out my reverse DNS issue.
I didn’t notice one thing when I attempted to implement this. Your current entries will only allow IP addresses in the 172.16.0.0/24 subnet. It doesn’t match the entire RFC1918 scope. Not sure if there’s a single entry way to resolve this, but I just added entries for each.
*.10.in-addr.arpa
*.16.172.in-addr.arpa
*.17.172.in-addr.arpa
*.18.172.in-addr.arpa
*.19.172.in-addr.arpa
*.20.172.in-addr.arpa
*.21.172.in-addr.arpa
*.22.172.in-addr.arpa
*.23.172.in-addr.arpa
*.24.172.in-addr.arpa
*.25.172.in-addr.arpa
*.26.172.in-addr.arpa
*.27.172.in-addr.arpa
*.28.172.in-addr.arpa
*.29.172.in-addr.arpa
*.30.172.in-addr.arpa
*.31.172.in-addr.arpa
*.168.192.in-addr.arpa
Thanks again for the post.
Uh, shit, you are fully correct. Haha. I didn’t see it. ;) Thanks for that. I will update the listing in the post above.