--On Wednesday, 15 October, 2003 22:10 +0200 Leif Johansson
<leifj(_at_)it(_dot_)su(_dot_)se> wrote:
| (2) But the typical plug-and-play NAT, at least the ones I
| have run across, is preconfigured with the addresses to be
| used on the "inside" and contains (or is intimately paired
| with) a DHCP server that gives out those addresses.
| Installing a DNS filter in the thing that would intercept PTR
| queries for that address range, or any 1918 address range,
| and respond to them in some "canned" way while passing other
| DNS queries out to the network as intended is not rocket
| science and certainly doesn't violate any plug-and-play
| arguments.
So where is the the leak coming from? If what people claim is
true and
if not all, but most NAT-boxes are configured with inside DNS,
filtering
and extra cheese, where, I ask you do all of those root-zone
requests
and other rfc1918 leaks come from?
Leif,
I was speaking to the architectural issue, not the deployment
one. None of the three plug and play boxes I have here with NAT
capability has any inside DNS capability (either enabled by
default or available to be turned on).
It does sound like a recommendation to the effect of "if you are
going to use NAT, or construct a NAT box, then an 'inside DNS'
mechanism" would be a reasonable idea. And I would assume it
would be an even better one if it made clear what the preferred
way was to do an "inside DNS" -- I think there might be a couple
of different ways to do it, and some might be less reprehensible
than the others.
john