dnswall 0.1.3 issues query IDs which are consecutive. As a defence against reply spoofing, query IDs should not be predictable. For background information, search Google for "dns predictable query id".

This is compounded by dnswall sending its queries from the same source port. By observing one query from dnswall on the network I can predict with 100% certainty the source port and query ID of the next query and thereby send a spoofed reply to it.

In light of this I consider dnswall to only be safe to use when its path to the "real" upstream DNS server is certain to be private (e.g. over a loopback interface on the same machine).

The suggestion in the README file to forward to a remote DNS server, such as an ISP's resolver, is wholly inappropriate and should be removed in favour of a strong recommendation for a loopback-only scenario.

Comment deleted

Thanks James for the heads up, and sorry to everyone that this fix is so delayed.

There was one specific check that should have been in the first release that didn't make it, which is to check the source address of responses to make sure they came from the designated forwarder. This has been corrected in the current release.

However, since dnswall does not do recursive lookups itself, and instead only sends queries to a single, trusted resolver, the standard DNS poisoning attacks are different. The reason query IDs should be unpredictable in a recursive resolver is that an attacker can see them when a query is made for a domain under his control. Since dnswall only sends queries to a single trusted server, the only way an attacker can get access to the very predictable query IDs is to either sniff the network or control the forwarder. In both cases, the attacker has succeeded no matter what we do.

The main way in which dnswall could be made more secure is to use randomized ports to make the search space larger. While I would welcome any simple patch to do this, I don't think it is critically important for several reasons: 1) It only matters if the attacker can forge packets with the forwarder's source IP, yet somehow not actually control the forwarder or be able to sniff his traffic. Due to the widespread use of ingress filtering on networks to prevent IP spoofing in the first place, this is not an easy attack at all. 2) Given that dnswall's query ID is actually unpredictable to an attacker, the search space of 16 bits is actually reasonably secure.

However, as I've said, I'd welcome any small patches to add randomized query IDs or randomized source ports, but the goal is still a simple, secure DNS proxy that can handle the kind of traffic that major networks can shove at DNS.

• Andrew

The importance of using port randomization along with other proposals for increasing the search space against a poisoning attacker is being reconsidered due to evidence that ingress filtering is not sufficient to protect many typical deployment scenarios for dnswall.

Patch for review at http://codereview.appspot.com/2522. This patch turned out to be a lot more complicated than I was expecting. This is just using rand() at the moment. We can figure out how to get a better PRNG in another patch.

This code is untested because I don't have a way to test dnswall. We need a better testing solution.

I checked in that patch in r12, but I did not change dnswall.c to use the new heap. I've started testing the new heap implementation, but I haven't yet satisfied myself that it works.

Fixed in r15.