On Feb 3, 2013, at 9:12 AM, GangChen <phdg...@gmail.com> wrote: > I would like to learn more about the problems.
There are quite a few separate issues. We generally treat DNS results as if they are essentially stateless—regardless of who asks the question, they should get the same answer. However, there are a lot of situations where this simply isn't true. Some of them are covered by RFC6731, but most are not. The most obvious cases are situations where there is in fact a split dns architecture, but RFC6731 isn't applicable. This is probably most split dns situations. The second set of cases are cases where DNS is used to operate a captive portal. In these cases, the DNS server on the captive portal will give different answers than a DNS server on a working 3G link, for instance. So if HE treats DNS responses as if they were generally equivalent, either we will be unable to ever see the captive portal web page, or we will be unable to use the 3G network without logging in to the captive portal. Neither situation is desirable. A third, less obvious, set of cases are where DNS is used to optimize CDN delivery. In this case, suppose I have a 3G interface that doesn't have CDN-optimized DNS, and a connection through my ISP on the wireless LAN that does have CDN-optimized DNS. In this situation, if I treat the two DNS servers as equivalent, then I may use the 3G DNS server to look up information I will then use to connect to the CDN over the wireless LAN interface. This will likely result in suboptimal routing, and unacceptable performance. This is why when I've discussed this issue in the past, I've always argued that each provisioning domain needs to be treated separately. We should not look up names in one provisioning domain and use them in another; if we want to try connecting across multiple provisioning domains, we should do DNS lookups on each such provisioning domain, and use the results we get only for connecting within that provisioning domain. _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
