--On Wednesday, 15 October, 2003 22:10 +0200 Leif Johansson <leifj@it.su.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