GURI SoftHouse
System Development,
Auditing and Consulting
DNSPROXY APPLICABILITY

Consider an internal network with multiple zones and public IPs, isolated through a packet filter. Each zone has its own DNS. By allowing entry of any request to NS CACHE then it may result at data contamination.

When you enter a DNS redirector commonly found, one can ensure they do not check if that request is, or not, about an inner zone.

The existence of such condition is possible only if there is an input filter, operating as a redirector, and checking the contents of the request belongs to the interior zones. This is the purpose of this dnsproxy.

An example:

Suppose a domain exemplo.com with internal zones i1.exemplo.com, i2.exemplo.com and i3.exemplo.com. Some questions about the external system perigo.sem is sent to the NS zone i1.exemplo.com. In doing so, the internal NS cache, if not properly configured (recursion off), may query the root-servers and send the response. However, if the malicious requester also send fake responses directing to that NS then can have the internal cache contamination.

The dnsproxy uses the source code of the dnscache DJBDNS, Daniel Bernstein, with some modifications. The resource was developed by Lucio Henrique Franco under the orientation of Ulisses Guedes.

The application was in operation from 2004 to 2011, at network of Brazilian Space Research Institute (INPE/SJC) which proves its efficiency. At middle of 2011, the application was disabled due to a BUG of BIND, when ISC was implementing and testing the EDNS, that allows packets of DNS PROTOCOL with more than 512 bytes, that is not accepted by dnscache.

The original code djbdns, djbdns-1.0.5, the complete source code of dnsproxy ( djbdns-1.0.5-Ulisses) and a patch file (diff) (djbdns-1.0.5-ulisses.diff.gz) are available for download.

Modified versions include updating the root-servers in 2004, once the original djbdns-1.0.5 was conceived in 2001.