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.