[dns-operations] DNS NAT Translation Timeouts

Brian Dickson briand at ca.afilias.info
Thu Jul 31 01:07:50 UTC 2008


Jason Fesler wrote:
>
> On Jul 30, 2008, at 5:01 PM, Brian Dickson wrote:
>
>> Yes, it will give security guys conniptions,  but that is what DMZs 
>> are *for*. If the firewall
>> can't do blind forwarding of UDP with no state, it deserves to be 
>> bypassed...
>
> ... after a careful audit of anything else on the host that is also 
> using UDP, and also making sure that the host won't run future 
> applications that use UDP, or can withstand being on the open 
> internet.  Checking with lsof/netstat and rpcinfo -p would be prudent.
>

"...anything else on the host..." - is often just a bad idea.

If anyone has such a set-up, i.e. DMZ, host acting as caching recursive 
resolver, *and* has anything else on it, the easiest way to avoid such 
an audit task is:
- install a new box, to be *only* used as caching recursive resolver
- dedicate a new IP address for it (or them, if there is more than one) 
- on the "inside" portion of the DMZ address space
- if necessary, have the firewall do the port-53+OLD_IP mapping to 
port-53+NEW_IP, on the Private->DMZ boundary - again, can be statelessly 
done
- follow the rest of the bits previously described to bypass state-full 
UDP issues on the Outside->DMZ (or direct Outside->resolver) boundary

Seriously, in this day and age, provisioning a physically separate box 
(or virtual, now that various virtualization things are available), is 
not a big deal.
Heck, even dedicating a new virtual interface (IP alias) can accomplish 
99% of this.
Hardware for handling even stupid levels of query traffic is commodity 
stuff.

Brian



More information about the dns-operations mailing list