I was trying to use dnsspoof but it did not work as expected. These are the steps I followed:

  1. Set IP forward in kernel to 1
  2. arpspoof -i eth0 -t -r and arpspoof -i eth0 -t -r Checked with arp -a and it works
  3. Create a file.txt with: *.hello.com
  4. dnsspoof -i eth0 -f file.txt

From victim computer I browse to www.hello.com and it is redirected to the real site. Output from dnsspoof is:

dnsspoof: listening on eth0 [udp dst port 53 and not src] >  3864+ A? www.hello.com >  3864+ A? www.hello.com

I have checked on Wireshark and it seems that the victim is receiving responses from the same IP with the router MAC (first) and with the attacker MAC (second). I have flushed the DNS and tried fresh requests, even though this should not be necessary in theory. My questions are:

1) Why is this not working? Someone has suggested using iptables to block packets from the router, but it seems strange that dnsspoof does not do it by itself, and none of the tutorials I have checked (1, 2, 3, 4) requires this step. Also, I cannot get the right iptables rule to make this work correctly.

2) Many tutorials seem to use dnsspoof without arpspoof. Is the latter really necessary? I mention because once (by chance) the DNS spoof seemed to work in another computer which was not "arpspoofed".

3) How does dnsspoof work? Just by listening for DNS requests in the whole LAN and then sending the resolution back?


With the iptables command iptables -D FORWARD --match string --algo kmp --hex-string '|68 65 6c 6c 6f|' --jump DROP the router is not queried, and only the spoofed DNS is sent. However, the victim browser stays loading forever and finally it says it cannot access the site(?). Without the iptables command I am able to see how the request goes like this:

victim --> attacker --> router and answer: router --> attacker --> victim

And just after this the attacker sends twice the spoofed DNS to the victim. Again, I am still confused about this behaviour and have not answered yet any of my three questions. I kind of believe the answer for (2) is that dnsspoof spoofed the whole network, but only if you did arpspoof before you can guarantee that the spoofed packet will get to the victim before the legitimate one. However, in my case, this is not working because the petition is forwarded.


This is a network capture with the same example over another network ( The legitimate DNS is forwarded first and, later on, the spoofed DNS. In this example, there were other petitions in the middle of both responses but quite often I get the packets one after the other.

network capture

  • Have you well changed the hex ? Try this command for hello.com # iptables --append FORWARD --match string --algo kmp --hex-string '|68 c5 a4 c5|' --jump DROP
    – Xavier59
    Commented Nov 27, 2016 at 11:35
  • I supposed the hex string should be 68 65 6c 6c 6f instead, shouldn't it? I am going to try it, but I am also questioning this method. Why is this necessary? None of the tutorials talks about it. No place mention this so there should be something else Commented Nov 27, 2016 at 15:46

2 Answers 2


Try installing libpcap0.8 and libpcap-dev. There was a bug and this should fix it, although it didn't work for me. I use kali on my tablet with a Linux deployment and there are many issues.


I'm not intimately familiar but:

arpspoof would make your victim's traffic to the router ( which is either the DNS resolver, or used to route to the DNS resolver ) go via attacker's PC.

dnsspoof would then intercept that traffic and doctor responses as appropriate.

If victim is still receiving responses from router it suggests that your arpspoof isn't working fully.

  • Well, that is the issue... Arpspoof seems to work well. However, the attacker also forwards the legitimate DNS request and sends the answer back, even before dnsspoof sends the spoofed one, as seen in the picture Commented Nov 27, 2017 at 11:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .