[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