Leif / Iljitsch, >>> 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. >> Leif Johansson wrote: >> Of course (I am beeing intentionally obtuse) but isn't it >> quite unlikely that any recommendation the we make at this >> point will have any impact Keith will not like it, but NAT vendors will take suggestions that will make NAT better. In this case, having in the NAT box a DNS proxy that forwards reverse lookups for public addresses to the ISP's DNS servers and replies a blanket reply for RFC1918 addresses does not look to much work. That box could also accept dynamic address registration that is default in the latest MS products. Even if _we_ have a DNS server at home Joe-Six-Pack does not, therefore the place for that animal is in the NAT box indeed. You want to convince NAT box vendors to implement it? Tell them that if they do, Keith will stop beating the crap out of them :-) > Iljitsch van Beijnum wrote: > RFC 2827 provides exactly these recommendations. Does it? We are not talking about blocking RFC1918 traffic here; what we are talking is blocking traffic where both SA(after NAT) and DA are public that contains a DNS request for a PRT like 8191CFR.in-addr.arpa, which requires to decapsulate the packet to inspect its content. It's not that simple. Michel.