At 05:24 PM 10/15/2003, Michel Py wrote:
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.
It also may be ill-advised, unless a switch is present for disabling it.
While we can argue ISPs should not use RFC 1918 space, there are many using
it, including some who use it because their equipment vendors force them to
do so (Cisco in the CMTS routing space comes to mind. Do a traceroute out
from behind a cable modem, and the head-end router responds with a 10/8
address. Nice job folks).
That box could also accept dynamic address registration that is
default in the latest MS products.
accept, or INTERCEPT? Intercepting the traffic would be nice. After all,
NAT boxes usually (not always, so a disabling switch would be a good idea)
are at an administrative border (i.e. gateway to home or office). Those DNS
updates should not be travelling beyond administrative boundaries in most
cases.
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 :-)
Heh. Router vendors would likely be interested because it's a good thing to
do. As for the part about Keith...
> 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.
Agree. RFC 2827 only discusses filtering packets whose source address is
inappropriate for crossing a border. When NAT is used, it's rare (if the
implementation is any good) to have a problem with bogus source addressed
packets leaving the private network.