Edward, > Not necessarily. What I mean is that it is up to the multi-homed > device to decide what interfaces are candidates (for the pending data > transmission) and consult the DNS on each interface. However, what
Yes, but how to decide that? Some information is required, and this draft proposes a way to cover DNS server selection component of the bigger problem. > however I know you are in the v6 mode) for a SMTP server is 127.1.2.3 > on wireless and 127.3.2.1 on wired, you can't then use 127.3.2.1 on > the wireless. No mixing and matching of the results. Right, host should use a learned address only on the interface it was learned on. That is part of source/destination address selection problematic covered by other drafts. Here the problem is, which DNS server to talk to resolve "private.corporation.com". > Yes, those are issues - for the multi-homed device. That's the case we're looking at:) > problem then? No. Both split DNS and multi-homing are fine. > However, there is a need for multi-homed devices to know how to deal > with split DNS. (And not vice versa.) Right, but how can they behave well in split DNS case if they are not told how to deal with the situation? E.g. told who knows what. > haven't spend enough time thinking it over. Generally, multi-homing > is a special case and the DNS serves a wide population that is mostly > signal-homed. Yes, today my laptop qualifies as multihomed (the RJ-45 > port and the wireless card are active and at times I have a cable > plugged in). Still, the host behaves as single-homed (maybe the > wireless hasn't found a SSID it can use). Yes, that behavior is very common current practice. However, at MIF WG we are looking to improve that in such a way host uses both WLAN, RJ-45, cellular, VPN tunnel, DSMIP tunnel, Teredo tunnel, and so on all at the same time. A related scenario is multi-site, where a host has a single physical uplink network interface, but multiple routers on it. In such a case, DNS servers behind some routers may have information the DNS servers behind other routers do not have. > In the future, as a device is multi-homed, it needs to deal with that > fact locally. It might decide not to use the 802.11 radio but use > the GSM radio, or neither and use the Bluetooth. But that choice > will be made before worrying about what DNS server. By the time it > chooses what DNS server to use, the interface is picked. This is the current practice, but it is changing. In the future, these devices use 802.11 and GSM at the same time. Use cases include MPTCP, offloading (e.g. browsing traffic over 802.11 and VoIP over GSM) and so on. > An enlightened host might be very agile on the interface choice - as > the 802.11 fades out the GSM is used with sessions flipping over to > the new transport (that results from the new data link). Again in > this case, the flipping is done and then the DNS server is changed. That is current practice. In the future the enlightened host keeps GSM open all the time and uses that for some traffic (e.g. for those that might benefit of address stability, or those that use cellular operator's services), while WLAN is used for "bulk" traffic when available. For faster download and browsing, the host may load content over both radios at the same time. In addition, the host may have corporate VPN active, which should be used only for corporate traffic, not for bulk Internet access. (But this is of course policy dependent issue, split tunnel may not be allowed). > I guess I am saying, to a multi-homed device, what DNS server to use > is the tail of the "what i/f to use" dog. > [http://www.urbandictionary.com/define.php?term=the%20tail%20wagging%20the%20dog&defid=3285170] I bet standards are being created for much smaller corners than this?-) Anyhow, in Appendix A, if you checked, I describe also some behaviors hosts could apply even when (and if) network is not explicitly supporting provisioning of this information. E.g. host can use search list options and prefixes as hints. Teemu _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
