Daniel / Iljitsch, > Daniel Senie wrote: > [NAT box acting as a DNS server] > It also may be ill-advised, unless a switch is present for disabling it.
Of course. > 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). Indeed. However, one should consider the trade-off between having blanket reverse resolution for RFC1918 hops vs. flooding the roots with bogus requests. Besides, for what I have seen these ISPs that use RFC1918 space for links do not provide reverse lookup for them anyway :-( >> Michel Py wrote: >> That box could also accept dynamic address registration that is >> default in the latest MS products. > Daniel Senie wrote: > 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. Both accept and intercept are needed. For accept, what we are looking at is as follows: The NAT box is also the DHCP server and gives its own address for the DNS server. Then MS hosts register with it, making it possible not only to return something for an RFC1918 reverse lookup and not flood the roots, but also to return the actual host name instead of a blanket name. If using DHCP, the MS host on the inside could try to register with a DNS server outside: it does not know its address and registration to a broadcast address would not be forwarded. Intercept would be nice in the following situations: - When Joe Blow has configured a static IP and static DNS servers that point to the ISP's DNS servers instead of the NAT box. - When the NAT box is not the DNS server and there is no other DNS server. I both cases, intercept would discard the packets of clients trying to register with the ISP's DNS servers. This would require a comprehensive implementation: the box should intercept dynamic DNS registration packets and reverse lookups with an RFC1918 target, but allow other requests. >>> Iljitsch van Beijnum wrote: >>> RFC 2827 provides exactly these recommendations. >> Michel Py wrote: >> 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. > Daniel Senie wrote: > 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. Rare indeed, because if the source address is private it is unlikely that the reply would ever get back to the requester, and NAT implementations that break DNS do not make it to the market. Michel.
