====== DNS Sinkhole ======

===== DNS Testing =====
More details [[paloaltonetworks:api:url_testing#check_dns_from_file_list|here]]

===== DNS Sinkhole IP =====

For DNS Sinkholing, Palo have an offering on their system which was ''72.5.65.111'' but is now (as of 2025), ''198.135.184.22''.

Bogon IP addresses are reserved address spaces that are filtered out on the Internet but are not typically filtered in enterprise WAN environments and will therefore get routed to the Internet perimeter.

https://www.team-cymru.com/bogon-reference.html

The addresses I typically use are ''192.0.0.1/32'' and ''2600:5200::1/128''.


This data gathered from [[https://live.paloaltonetworks.com/t5/Community-Blog/If-you-are-using-1-1-1-1-anywhere-in-your-firewall-configuration/ba-p/208746|here]].

=====DNS Sinkhole FQDN Quirk =====
When configuring a sinkhole ‘address’, PAN-OS now supports FQDN entries in addition to IP address entries.

The whole purpose of DNS Sinkhole is to intercept DNS queries between the internal DNS Server and the Internet (not the endpoint and the internal DNS server). 

If you are able to intercept DNS queries between the endpoint and the Internal DNS server, you can just block and DNS Sinkhole serves no purpose.

The default is sinkhole.paloaltonetworks.com but can be set to any other FQDN.

If a FQDN is set (including the default), then the sinkhole action does not return an IP (an A record) but instead returns a CNAME record.

If the sinkhole action is set between the client and the internal DNS server, the CNAME record is returned to the endpoint. The Linux ping command (or Linux OS) knows what to do with a CNAME response but Windows ping command (or Windows OS) does not.

Thus, if you apply a FQDN sinkhole between the clients and the internal DNS server, you will never see the “Block access to Sinkhole address” security policy rule hit because Windows can’t do anything with this CNAME (at least, the Windows ping command can’t).

However, since sinkholing is supposed to happen between the internal DNS server and the Internet, and since an internal DNS server should actually resolve the DNS CNAME record on behalf of the end point client, there isn’t actually an issue here (just a lack of documentation).

What will happen is that the Sinkhole action will return a CNAME to the internal DNS server. The internal DNS server will resolve the CNAME to an IP address and then provide the IP address to the internal client regardless of whether it is Linux or Windows.