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.