How to Configure DNS Sinkhole

Printer Friendly Page


Starting with PAN-OS 6.0, DNS sinkhole is an action that can be enabled in Anti-Spyware profiles. A DNS sinkhole can be used to identify infected hosts on a protected network using DNS traffic in environments where the firewall can see the DNS query to a malicious URL.


The DNS sinkhole enables the Palo Alto Networks device to forge a response to a DNS query for a known malicious domain/URL and causes the malicious domain name to resolve to a definable IP address (fake IP) that is given to the client. If the client attempts to access the fake IP address and there is a security rule in place that blocks traffic to this IP, the information is recorded in the logs.

This information is covered in detail in: How to Verify DNS Sinkhole Function is Working.


Important! When choosing a "fake IP", make sure that the IP address is a fictitious IP address that does not exist anywhere inside of the network. DNS and HTTP traffic must pass through the Palo Alto Networks firewall for the malicious URL to be detected and for the access to the fake IP to be stopped. If the fake IP is routed to a different location, and not through the firewall, this will not work properly.



  1. Make sure the latest Antivirus updates are installed on the Palo Alto Networks device.
    From the WebUI, go to Device > Dynamic Updates on the left. Click "Check Now" in the lower left, and make sure that the Anti-Virus updates are current. If they are now, please do that before proceeding. The Automatic Updates can be configured if they are not setup.
    sinkhole - dynamic updates.png
    Note: A paid Threat Prevention subscription for the DNS sinkhole is required to function properly.

  2. Configure the DNS Sinkhole Protection inside of an Anti-Spyware profile. Click on the Objects > Anti-Spyware under Security Profiles on the left.
    Use either an existing profile or create a new profile. In the example below the "alert-all" is being used:
    sinkhole - anti virus.png

    Click the name of the profile - alert-all, click on the DNS Signatures tab.
    sinkhole - anti spyware profile.png

    Change the "Action on DNS queries" to 'sinkhole' if it is not already set to sinkhole.
    Click in the Sinkhole IPv4 field either select the default Palo Alto Networks Sinkhole IP ( or a different IP of your choosing. If you opt to use your own IP, ensure the IP is not used inside your network and preferably not routable over the internet (RFC1918).
    Click on Sinkhole IPv6 and enter a fake IPv6 IP. Even if IPv6 is not used, something still needs to be entered. The example shows ::1 . Click OK. 

    Note: If nothing is entered for the Sinkhole IPv6 field, OK will remain grayed out.

  3. Apply the Anti-Spyware profile on the security policy that allows DNS traffic from the internal network (or internal DNS server) to the internet.
    Click on Policies > Security on the left side.
    Inside the rules, locate the rule that allows DNS traffic outbound, click on the name, go to the Actions tab, and make sure that the proper Anti-Spyware profile is selected. Click OK.
    sinkhole - policy.png

  4. The last thing needed is to have a security rule that will block all web-browsing and SSL access to the fake IP and also :1 if using IPv6. This will ensure to deny traffic to the fake IP from any infected machines.
    sinkhole - block sinkhole.png
  5. Commit the configuration


See Also

For instructions on testing and verifying the setup reference the following document:

How to Verify DNS Sinkhole Function is Working


For Video tutorials on DNS Sinkhole subject:

Video Tutorial: How to Configure DNS Sinkhole

Video Tutorial: How to Verify DNS Sinkhole


owner: rvanderveken



I have set up DNS sinkholing  configuration as above but there are no sinkhole action in threat detail logs.

DNS sinkholing must use only PAN-DB???

If not, What do I have to check?


I notice from the screenshot that you put the loopback on the untrust side.  Is that important to get this working?  Also, does it matter what IP the sinkhole IP is?

It is not important to put the loopback in the untrust zone. You can configure an separate zone and assign an interface to it.


Aamir Khan

You also have to make sure you have a Security Policy that allows traffic to-and-from the Zone you assign to the Sinkhole interface.

Kind regards,


I have enabled DNS sinkholing but would like to be able to "sinkhole" certain dns calls as well as those matching spyware signatures, for example sinkhole

Is this possible?  If so, how?

Based on the way the Sinkhole action works, it will only sinkhole the DNS queries that are matched with the signatures. It would be a nice feature if the custom spyware or vulnerability signatures would have the Sinkhole action as an option. That way you could create a custom signature that would then sinkhole the request you create in the signature.  Maybe something for the future.

My question is... do we really even need a loopback address defined?

I mean.. why could we not just provide a sinkhole address of (or whatever) and still have the security policy to block going to

Not quite sure I completely understand the need for the loopback address.

What function does it serve.

I also thought that the sinkhole address was originally designed to be a syslog server or some DLP device (based on the ATC training classes), so that the syslog logs all the attempts.

This doc is good in theory and certainly does work, but not in the spirit that was originally attempted.  (or am I wrong...)

Please comment.

After talking with a PAN Engineer and the Engineer to design this feature, I have the following update to this thread and guidance for implementing the feature in a VWire environment:

Loopback is not needed , nor any L3 interface. For some reason many people keep saying that.

Here is how it works:

  • A DNS request flows through Vwire and we detect it as a malware domain
  • We block the request and send a fake answer with an IP that you chose to answer the requester.
  • If the requester is a DNS server then it transmits our fake answer to the original infected requester.
  • The infected client gets your fake answer and trys to reach its Command&Control server

Then in order to know which machine has been infected, all what you have to do is run a report and filter on the fake IP configured. Keep in mind one thing : that IP must be in the path of the firewall and the client so you can see logs from it. IE: if your PAN sits between infected client and data-center but doesn't see internet and you choose to DNS Sinkhole with an internet IP then your firewall will never see the infected client try to reach its command & control server.

Also don't forget to make a deny rule with destination of your DNS Sinkhole IP.

thanks Gun-Slinger , it's all clear now

This works great.  HOWEVER, is there a way to whitelist FQDNs?

We have an SMTP server we are trying to send mail to, but it is being sinkholed.  TIA!

For any URL's that need to be "Whitelisted", you can create a custom URL group, then place individual URL's in that group, then create a rule ABOVE where you would be performing the DNS Sinkhole protection, and place the new Custom URL Group into the Service/ URL Category tab and allow it, that should do it.

IMHO on picture 1 in point 3 rule 1 "block dns sinkhole ip" should have action BLOCK insted of ALLOW.

Please update pictures.

slv, I am sorry those images were not correct.  They are in the process of being updated as we speak.

I configured this feature on version 6.0.4 months ago, but the issue with this is that there is no way to test it. The list of domains that are supposed to trigger the action is to be found in latest AV release notes, but none is triggering the policy.

Also for testing you can use the domains in this list :

Malware Domain List

All the domains in the list are actively malicious.

Thanks for the list. Found why I didn't see any trigger. There was one firewall standing before in the chain, which intercepted requests and dropped all packets. Somehow the outside firewall, where dns-sinkhole feature configured, still shows the session in the traffic log. That is what confused me. Why are the packets that seem to be droped on one firewall still visible in the next.

Tested this in my lab, when I perform nslookup for my lab PC actually sends out 6 DNS queries:







I guess it has to do with dns settings on my PC, adding dns suffix, IPv6 etc.

The firewall forwards the first four,  but drops/sinkholes the last two as expected.

Suspicious DNS Signatures begin in Threat ID 4000001 and end in Threat ID 4999999.

This means that for testing you can consistently use the result you get from the CLI from this command:


> show threat id 4000001

This DNS signature detects a DNS query to the domain  Palo Alto Networks has observed this domain to be associated

with malware and malicious activity.  If multiple threat signatures from a single host are present, this may indicate that the host

is compromised.




In the above example, it results in "", so you can consistently use the output of this command for testing.

My anti spyware profile with the sinkhole configured is used in other outbound security policies in addition to the DNS policy.

Is there a resason why I wouldn't want to do this, like extra overhead or something?

Would it be better to create a separate anti spyware profile  with the sinkhole configured that would be used only for the DNS policy?


Is there a way to access the list of domains that are going to be sinkholed by this procedure?

@craig.brooker, The domains that will be "sinkholed" are the ones that are classified as "suspicioius DNS" in the Apps and Threats DB  or "malware" by PAN-DB URL Classifications.

We do not maintain a "list" of those suspicious URL's , but you can go to either: 


and type in any part of a domain to see the PAN-DB URL Classification if it is deemed Malware or not.


Also, in some of the release notes to the Apps and Threats updates, it lists Suspicious URL's that are added.


One more thing, Earlier in the comments, there is a link to 3rd party maintaineda Malware Domain list.

I configured the DNS sinkhole. Created separate Zone , and assigned the New Loopback interface to that Zone.

Also applied Policy to block that traffic to reach the Sinkhole Zone. And checked the Anti-Spyware is up to date.

And the " Security Profiles " , already cloned one as  " DNS Action > sinkhole " .


Into " Monitor " > " Threat " ,  I still can see the internal DNS server address to reach the public DNS log only.

Can not see the " real client devices " address,  Any configuration missed ?   is it related routing ?  Please help.


Thanks alot.


@RayHo2017 It depends who is making the DNS query. As per your logs, the client PC in your environment must have queried the DNS server, which in-turn went to public DNS server for response. Configure as DNS server on your client PC and then test. Please refer to for the use-case scenarios and implementations.




@ansharma   ,  Thanks.

Finally, it works now. I make a change to the security profile on the default outbound policy to sinkhole rather the separate Sinkhole policy.  So the traffic will be detected by the default outbround policy. Then will do the sinkhole action.

Is step 4 necesary?. Can I let the traffic just flow throug FW to an unreachable IP?






No, it's not necessary to do Step 4. It's basically a way to find out who is making those suspicious DNS queries, so we can find out the possible infected hosts. That's all.




I suppose this is just another method of implementing dynamic block lists?  Another protection in the "kill chain"?  Palo Alto could offer this as an external dynamic list to be used in a security policy (URL category block)?

Hi @ice-quake

No, this is not simply a block list. Sinkhole dns actively intercepts and poisons DNS replies to malicious hostnames and replaces the A record with an IP of your choosing

After this, the I fected host will make outbound C&C connections to your sinkhole IP which will prevent connecting to the actual c&c and will make infected hosts highly visible. This is especially helpful if you have an internal DNS server which, logging wise, would make all infected lookups originate from your DNS rather than the compromised endpoint


Hope this helps

@reaper Is there possible to dns sinkhole a whole other URL category? for example, the whole adult web category? 

Hi @FrankLi


No, DNS sinkhole is part of Threat protection and gets it's information from the malware database.

You could reach out to your sales contact to have them open a Feature Request to make this possible

 Can anyone guide me how we can take the Paloalto firewall configuration backup & restoration process if something goes wrong.

hi @AmitKumar1991


For generic questions you can always go to the discussion area


Please check out these articles in regards to exporting/importing configurtion files:

Back Up Configuration and Device State from the CLI

PAN-OS® 8.0 Web Interface Reference Device Device > Setup > Operations

Save Candidate Configurations

Great post!


two questions:


1. Is PANOS anti-spyware under license?


2. How does PAN firewall know the DNS request is initiated from another internal DNS server but not from an internal host directly?






Yes, a threat prevention license is required.


The firewall doesn't care if the request comes from an internal DNS server or a host.  The firewall will intercept the request and reply with the sinkhole address.  If your hosts do point to internal DNS servers you'll want to create the rule in step 4 to determine the infected host.



The behavior of intercepting DNS requests and modifying DNS responses seems to be shared with the unsupported feature of DNS doctoring/rewriting/translating described here:


Can this functionality be used to accomplish this?  If not, can Palo Alto expand this underlying functionality to support DNS doctoring/rewriting/translating in a future update?

hi @john.berry


DNS sinkhole can only be used to poison malicious DNS queries, there is no option to alter DNS queries in other ways (the article you linked shows how to change one IP to another using traditional NAT, it does not change DNS payload)


You can reach out to your local sales team to have this added as a feature request, so it may get included in a future release