Subject: [mif] Scope of DNS router selection draft

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Mar 2011 12:51:23 +0000

I think the maximal scenario this draft needs to solve is the case where a MI host is connected to a 3G network with some private domains, and a corporate network with some private domains.   In this scenario, it is possible for each provisioning domain to specify a minimal list of domains for which queries should be sent to that provisioning domain's DNS servers, and not the others.   And I think it's exceedingly unlikely that that list of domains will ever overlap.   I would go so far as to say that there is no legitimate scenario where such a thing could occur.   Hence we do not need to solve that problem.

Further, in any legitimate scenario, all the domains that do not appear on the DNS server selection list must resolve to the same information, unless the information is location-dependent.   This document doesn't claim to solve the location-dependency problem, so we don't need to think about that here, although it's actually an important problem that we might *want* to think about in a separate context.   I don't think the solution for this problem overlaps with the solution that this document offers, so we can address them separately.

Margaret proposed a scenario where a multi-homed network might receive different router selection options from different service providers.   In this scenario, the question arises: how do we combine this information and provide it to the client.   This presupposes a solution: that we do information aggregation in the router, and provide that aggregate information to the client, which then uses it to resolve these domains.

I would like to point out two things about this.   First, this isn't a MIF problem.   This is a multihoming problem.   I don't mean that it shouldn't be solve, or even that we shouldn't solve it, but I think it's important to keep the problem in perspective.   From my perspective, this is an ops problem, not a standards problem.   The problem is that you have information from two different services providers, and you need to combine that information. 

There are two ways I can think of to combine the information.   The first is the one Margaret proposed: to take the two DHCP options and produce the union of the two options, including IP addresses.   This would work, but it has the potential not to scale--we were already worried that this option might get a bit too big; this potentially doubles or triples the potential size of the option.   So as a DHCP wonk, I don't like that.

The second solution, which is the one I prefer, is to use the DHCP options received on both interfaces to configure a caching name server, and to provide the IP address of that caching name server to internal DHCP clients.   I think this solution is administratively easier, easier to debug, and generally operationally simpler.   Better still, it lets us consider the problem this draft attempts to solve *strictly* as a MIF problem, and *not* as a multihoming problem.

The point I'm getting to is that I think we can solve all reasonable scenarios with a DHCP option that isn't version-specific--it'll work whether you get it via DHCPv4 or DHCPv6, and will contain no IP addresses of either type.   I think this is a lot easier and gets us to the finish line a lot faster than trying to address the edge cases we talked about in the meeting by sending IP addresses in the option.