Subject: [mif] DNS server selection and whether to support DHCPv4 or not

From: <[email-masked]>
Date: Mon, 11 Apr 2011 11:44:25 +0000

Hi,

We discussed in Prague whether the DNS server selection options should be distributed also via DHCPv4.

The use case would be e.g. access where DHCPv4+SLAAC combo is used without support for Stateless DHCPv6. With DHCPv4 host could learn about suffixes and then use IPv4 to talk to DNS servers  for related queries.

My main comment against that was the IPv4 host multihoming in presence of increasingly common RFC1918 addressed network has some serious issues.

If I recall correctly, the plan was to discuss on mailing list whether DHCPv4 should be supported. Opinions?

Best regards,

                Teemu

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Apr 2011 08:47:13 -0400

> My main comment against that was the IPv4 host multihoming in presence of increasingly common RFC1918 addressed network has some serious issues.

It seems to me that this is minimally different than the problem where you have been given a default route on both interfaces, and have to decide on which interface to send a DNS request without any help from the routing table.   It's entirely possible in this case that a host reachable on one interface is not reachable on the other, despite having valid default routes on both.

The solution to this problem is that if I am asked to query a DNS server based on configuration information received on interface A, I *must* send my DNS requests to the next-hop router on interface A.   If that is not possible, the configuration is invalid.   If it is possible to send the query on interface B, I nevertheless must not attempt to do so.

I think this approach completely eliminates the problem you're talking about, Teemu, even if the two DNS servers have the exact same RFC1918 IP address.   Of course, that assumes that the stack is smart enough to make it possible to implement the technique I just described... :)

---

From: <[email-masked]>
Date: Mon, 11 Apr 2011 13:20:22 +0000

I tried to refer to a bigger problem: a host connected to two different networks from where it gets same numerical address for itself (192.168.1.2), or both have same subnet (192.168.0.0 with 255.255.255.0 mask), same default gateway address (192.168.0.1) etc etc... and how to have reasonable way to sort that mess out..  or from both interfaces DNS server address is same as default gateway's, but both try to point to different boxes.. i.e. IPv4 multi-interface implementation would have to have some kind of solution for worst-case RFC1918 address conflicts.. and that's why I'm personally more interested in defining stuff for environments that are not filled with address conflicts:)

When the IPv4 addresses of multiple interfaces are not in so such serious conflict that approach would work.

The draft already btw says:
--
   The node SHOULD create a host specific route for the DNS server
   address.  The route must point to the interface DNS server address
   was learned on.  This is required to ensure DNS queries are sent out
   via the right interface.
--
I wrote that IPv6 in mind, but probably would apply then for IPv4 as well:)

Teemu

From: ext Ted Lemon [mailto:[email-masked]]
Sent: 11. huhtikuuta 2011 15:47
To: Savolainen Teemu (Nokia-CTO/Tampere)
Cc: [email-masked]
Subject: Re: [mif] DNS server selection and whether to support DHCPv4 or not

On Apr 11, 2011, at 7:44 AM, <[email-masked]<mailto:[email-masked]>>
 <[email-masked]<mailto:[email-masked]>> wrote:
My main comment against that was the IPv4 host multihoming in presence of increasingly common RFC1918 addressed network has some serious issues.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 Apr 2011 09:34:42 -0400

On Mon, Apr 11, 2011 at 01:20:22PM +0000, [email-masked] wrote:

> I tried to refer to a bigger problem: a host connected to two
> different networks from where it gets same numerical address for
> itself (192.168.1.2), or both have same subnet (192.168.0.0 with
> 255.255.255.0 mask), same default gateway address (192.168.0.1) etc
> etc... and how to have reasonable way to sort that mess out..  or
> from both interfaces DNS server address is same as default
> gateway's, but both try to point to different boxes.

I would be fascinated to learn that there is a way to prefer one of
those networks over another.  As far as any routing can tell, surely,
they're the same network.  The usual advice is "don't do that", and I
can't see any reason that we could suggest anything better.

Trying to fix that sort of problem is in effect trying to do
subclassing on identical address blocks.  I think that way lies
madness.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Apr 2011 10:16:13 -0400

> can't see any reason that we could suggest anything better.

You can certainly do it on a Linux machine.

> subclassing on identical address blocks.  I think that way lies

And yet, IPv6 link-local, which is exactly analogous, seems to work just fine!   :)

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 Apr 2011 11:00:04 -0400

> You can certainly do it on a Linux machine.

I should have been more precise: I'd be fascintated to learn that
there is a way to prefer one of these networks over another on a
case-by-case basis.  I've never had an experience where I have two
interfaces in the same RFC 1918 address space, where both networks
think they're the same net block, where each network is offering a
different service, and where I am able to reach each service reliably.
If you're telling me that there is a way to make this work reliably,
then I'm pleasantly surprised but I'd like a pointer to the fine
manual.  This is especially true where both networks are offering a
different service of the same service type on the same address (such
as, for instance, two DNS servers on 192.168.0.1, from two different
interfaces -- a not completely unusual default in my experience).

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Apr 2011 11:16:39 -0400

> interfaces -- a not completely unusual default in my experience).

I'm not sure I get what you're saying here.   This is the problem we are trying to solve, not a problem that's solved.   Right now the state of the art is that if you have two interfaces, both of which are active and configured at the same time, it's pretty easy for bad things to happen.   The MIF working group is supposed to be identifying the problems that come up, and proposing ways to solve them.

It is in fact true that as far as I know, if you get configuration information on interface 1, and different configuration on interface 2, current implements will attempt to use configuration information from interface 1 on interface 2, and vice versa, depending on, essentially, happenstance.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 Apr 2011 11:24:16 -0400

On Mon, Apr 11, 2011 at 11:16:39AM -0400, Ted Lemon wrote:

> I'm not sure I get what you're saying here.  This is the problem we
> are trying to solve, not a problem that's solved.

That's what I thought, too, but you seemed to be suggesting it was a
solved problem.

What I was arguing is that this is impossible to fix.  If you happen
to connect to two networks both of which are 192.168.0.0/24, and they
both have DNS servers on 192.168.0.1, there is not just in fact, but I
claim in principle no way for you to make any kind of sensible
decision about which way to send a given DNS query unless you want to
inspect every packet and make a decision on the fly.  (I think that'd
be true of every other application using the network, too, but I'm not
willing to say that with as great certainty.  And what you're going to
do about encrypted packets is a mystery to me.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Apr 2011 11:39:05 -0400

On Apr 11, 2011, at 11:24 AM, Andrew Sullivan wrote:
> inspect every packet and make a decision on the fly.

I don't see what's hard about this.   In order to successfully mif, you must maintain different routing tables for your different interfaces.   You must maintain different configuration information (e.g., DNS server address) for your different interfaces.   Supposing that this proposal gets implemented, you'd have a hunk of config data that said "when looking for names in splith.example.com, go to DNS server X," which would be peculiar to one of your interfaces.   When resolving a name by following that configuration information, you would contact the DNS server using that interface.

What I meant was a solved problem was the problem of contacting IP address X using interface Y.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 Apr 2011 11:57:08 -0400

On Mon, Apr 11, 2011 at 11:39:05AM -0400, Ted Lemon wrote:
> 
> I don't see what's hard about this.  In order to successfully mif,
> you must maintain different routing tables for your different
> interfaces.  You must maintain different configuration information
> (e.g., DNS server address) for your different interfaces.  Supposing
> that this proposal gets implemented, you'd have a hunk of config
> data that said "when looking for names in splith.example.com, go to
> DNS server X," which would be peculiar to one of your interfaces.

Aha!  You've just crystallized for me exactly what it is that's been
bugging me about all of this discussion.

I'm a DNS resolver.  I want to send a DNS query.  How do I do that?
I'm pretty sure, on any existing platform, what I do _not_ do is say,
"Send this query on interface eth3."  The interface is supposed to be
Not My Problem, no?

Similarly, if I'm the layer down in the network stack that is sending
out the DNS query, surely it's supposed to be Not My Problem what the
contents of that query are.

If we're actually supposed to be fixing the case where 192.168.1.1[1]
available on eth1 knows about zone one.example.com and 192.168.1.1[2]
available on eth2 knows about zone two.example.com, I can think of no
way to do that except deep packet inspection on everything.  Quite
apart from the overhead this is going to impose, I have a hard time
understanding how this is going to be standardized in any general way.
It seems like we're planning to standardize a giant ALG for every
possible class of application (because, as we currently see in BEHAVE,
as soon as you've done this for DNS names you'll have the IP address
literal people at the door, demanding that their self-imposed problem
is also solved).

Now, I'm a bear of little brain, so I'm sure there's something I'm
missing.  What is it?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Apr 2011 12:04:47 -0400

> "Send this query on interface eth3."  The interface is supposed to be

No.   This is exactly what you are missing.   The resolver *must* specify the interface that it's sending on in order for MIF to work in the case where two or more interfaces are connected to different provisioning domains.   If it does not, and if we accept (which I am not arguing we should) that different DNS servers may return different results for the same query, then a resolver that does not do this cannot be relied upon.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 Apr 2011 12:25:39 -0400

On Mon, Apr 11, 2011 at 12:04:47PM -0400, Ted Lemon wrote:
> 
> No.  This is exactly what you are missing.  The resolver *must*
> specify the interface that it's sending on in order for MIF to work
> in the case where two or more interfaces are connected to different
> provisioning domains.

Ok, that's what I figured had to be the case, but it seems like a
problem.  How is the resolver going to do that?  I'm not an
implementer, and I therefore don't work on this code, so probably I
don't know what I'm talking about.  But do I understand this to mean
that getaddrinfo() has to change in order to make this work?  

>  If it does not, and if we accept (which I am
> not arguing we should) that different DNS servers may return
> different results for the same query, then a resolver that does not
> do this cannot be relied upon.
 
How does an application know that the resolver does in fact do this?  

I'm sorry to be asking stupid questions, and if this has all be
thrashed out before and I should just work harder in the archives,
please don't hesitate to tell me to go look there.  I just haven't
seen it so far.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Apr 2011 13:08:41 -0400

> that getaddrinfo() has to change in order to make this work?  

Whether the API exposes the configuration database selection or hides it is an interesting question.   I don't see any reason why getaddrinfo() couldn't do the right thing without change, although in fact we're going to propose a different API precisely because getaddrinfo() presumes a synchronous model for name resolution which is probably not desirable.

> How does an application know that the resolver does in fact do this?  

I don't think the application has to know.   I think the hope is that the application won't have to know, because the resolver will just do the right thing.   I think it's worthwhile to *allow* the application to know, but I don't know if any applications will take advantage of that, and I don't think they have to in order to win.

> please don't hesitate to tell me to go look there.  I just haven't

It probably has been hashed out before, but I don't recall a specific conversation on the mailing list, so I certainly don't mind your questions!   :)