Re: [lwip-users] Split DNS for multihomed setup

[Radouch, Zdenek]

Hi Mark,

I understand the picture now, including your examples. You have
two completely uncoordinated networks, and you need to connect
them together. Not only can you have name conflicts, you can also
have address conflicts.
My advice -- don't do it. Not just because the configuration is "wrong"
and should be fixed, but because even if you get it working today, it
will crumble under you tomorrow, because it violates so many assumptions
built into the TCP stack designs. All stacks I am familiar with, including
those used inside routers were designed to handle a single coordinated
name space and a single coordinated address space. Conceptually you would
have to augment the name and address spaces with an extra dimension to
make them unique. That sounds like a significant undertaking.

> ... should be
> possible, since the application has enough information to make decision
> with regards to what connection goes where ...

You may have all the information you need to distinguish the two networks,
but the problem is that the stack does not support what you want without
a major surgery. It's kind of like arguing that your brain could handle
two pairs of hands. Well, maybe it could, but you have only one pair.

> I said "private" network in terms of RFC1918

RFC1918 is a more elaborate version of another 20+ years old RFC (can't
remember the number) which was equally inadequate in describing
the state of modern networking. The problem with them is that they trivialize
the networks as a set of interconnected enterprises. That may be an OK mental
model for certain specific discussions, but it is far from adequate in handling
the today's situation where IP became the connection tool of choice for 
everything
around us, including common appliances and devices.
Today you can have a "private" network connecting subsystems within your 
refrigerator,
you can attach multiple of these refrigerators to the "private" network
of organization A you describe, you can do the same in organization B, then join
the A and B networks (as you are doing) and called that a "private" network,
and finally throw in your corporate network and end up with what your IT folks
call enterprise "private" network. 
The only way the above will work correctly is if the entire system is carefully
coordinated, something only possible if you eliminate the word "private" from
your networking vocabulary.

Cheers,
-Z


> -----Original Message-----
> From: address@hidden [mailto:lwip-
> address@hidden On Behalf Of Mark Lvov
> Sent: Wednesday, August 20, 2014 2:24 PM
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] Split DNS for multihomed setup
> 
> Thanks for the input!
> 
> I'll try to provide a concrete example. The device has two network
> interfaces. One of them (X) is physically connected to a network of
> organization A, another (Y) - to a network of organization B. Since
> those networks are completely out of our control, we can not discount
> the possibility, that we are configured to connect to "foo.local" via X
> and to "foo.local" via Y. I said "might", because it is impossible to
> make an assumption, that the networks we are connected to, have no
> "overlapping" domain names.
> 
> >> ... the interfaces of the device happen to be connected to the same
> >> (numerically, but not logically!) "private" network.
> 
> > I have no idea what that may mean. Can you provide a concrete
> example?
> 
> I said "private" network in terms of RFC1918 (10/8, 172.16/12,
> 192.168/16). It is certainly not impossible, that interface X ends up
> in a 192.168.1/24 network of organization A and Y - in 192.168.1/24 of
> organization B. The networks are numerically similar (they both are
> 192.168.1/24 after all), but logically distinct (they are definitely
> different networks belonging to different organizations).
> 
> > A duplicate name is a clear problem that must be eliminated; don't
> try inventing some magic to "fix" it through routing or any other
> hacks.
> 
> I acknowledge, that it *is* a problem and ideally it should be
> eliminated, but all I can do is work around it, which should be
> possible, since the application has enough information to make decision
> with regards to what connection goes where. It is just a matter of
> "convincing" the stack to cooperate.
> 
> Mark
> 
> On Tue, Aug 19, 2014 at 1:35 AM, Radouch, Zdenek <address@hidden>
> wrote:
> > Hi Mark,
> >
> > I think I understand your situation. Here are a few additional
> comments.
> >
> >> Those networks might both have "foo.local" and a nameserver, capable
> >> of resolving it.
> >
> > That very detail is *the* most important detail, as it clearly
> violates the DNS rules.
> > You cannot realistically expect the resolver to help you if you
> ignore
> > the rules of the game (OK, so perhaps it's not you, but that's
> irrelevant :-)).
> >
> >> ... the interfaces of the device happen to be connected to the same
> >> (numerically, but not logically!) "private" network.
> >
> > I have no idea what that may mean. Can you provide a concrete
> example?
> >
> > Two more things:
> >
> > 1. A duplicate name is a clear problem that must be eliminated; don't
> try inventing some
> >     magic to "fix" it through routing or any other hacks.
> >
> > 2. Be very careful when you say "private" network. This term is
> abused almost every single time
> >     it is used. I have spent years trying to teach people why they
> should not use it.
> >     My suggestion -- forget the "private" attribute when considering
> whether or not your network
> >     architecture will work.
> >     Take this very case -- you have duplicate names in your name
> space, and you (or someone else)
> >     thinks it is OK, as long as you label the networks "private".
> They are not very private if the nodes
> >     on them share their name space with other networks, are they?
> >
> > Hope this helps.
> >
> > Cheers
> > -Z
> >
> >
> > ________________________________________
> > From: address@hidden
> > address@hidden on behalf of Mark
> > Lvov address@hidden
> > Sent: Monday, August 18, 2014 3:22 PM
> > To: Mailing list for lwIP users
> > Subject: Re: [lwip-users] Split DNS for multihomed setup
> >
> > Thanks for the food for thought!
> >
> > I'll try to explain the setup in more detail. Perhaps I've been too
> vague.
> > The device in question is physically connected to two different
> > networks. We have no control over those networks whatsoever. On the
> > application level you might imagine a following configuration
> > statement: "connect to foo.local:2000 via interface X". Why is it
> > specified like that? Because those networks are controlled by
> separate
> > organizations and it is important to make a distinction with regards
> > to what goes where. Those networks might both have "foo.local" and a
> > nameserver, capable of resolving it. So the query to resolve the
> > domain name of that particular destination must be made (at least,
> > that's how I see it..) through a particular interface.
> >
> > As you say, some of such cases can surely be solved by routing, but
> as
> > I see it, in some instances it might not be possible, for example, if
> > the interfaces of the device happen to be connected to the same
> > (numerically, but not logically!) "private" network.
> >
> > Hope that makes sense,
> > Mark
> >
> > On Sat, Aug 16, 2014 at 11:37 PM, Radouch, Zdenek
> <address@hidden> wrote:
> >> Hi Mark,
> >> I am completely missing what this has to do with DNS.
> >>
> >>> We obviously must make sure, that the DNS query is made through the
> >>> ethernet interface.
> >>
> >> No. A DNS query is not made through an interface. A query is made to
> >> a configured name server, wherever the name server is, on whatever
> >> interface this name server can be reached.
> >> If the primary configured name server cannot resolve the name the
> >> resolver iterates to the next configured name server.
> >>
> >> This should have nothing to do with a multi-homed configuration, as
> >> long as the routing to the name servers is defined. If not, then the
> >> routing is where the problem is.
> >>
> >>>  the "resolver cache" (dns_table) obviously does not consider which
> >>> interface the entry belongs to
> >>
> >> Because an entry does not belong to an interface at all, the entry
> >> belongs perhaps to some global query name space.
> >>
> >> As I said, I am really missing what the problem is. Do you have a
> >> name server that can translate your example "foo.local"? If you do,
> >> then that is the server that will successfully return the answer to
> >> the query, and you should not care where it is, other than making
> sure the resolver will contact it.
> >> Once the records come back, they can be cached, there is no
> interface
> >> involved in this, all you need is the foo.local => a.b.c.d mapping.
> >> That is what DNS is, nothing more.
> >>
> >> You need to ask yourself (and perhaps explain) why you believe that
> >> an address record, mapping a name to an address is insufficient in
> >> your application. You said:
> >>
> >>> the destinations, that we must connect to might be specified as
> >>> domain names...
> >>
> >> If you successfully translate the name then the destination will no
> >> longer be a domain name, it will be an IP address.
> >> Do you still need to know which interface? If you do, then that's a
> >> routing issue, if you don't then that should clarify why it is not
> needed in the DNS query.
> >>
> >> Cheers,
> >> -Z
> >>
> >>
> >> ________________________________________
> >> From: address@hidden
> >> address@hidden on behalf of
> Mark
> >> Lvov address@hidden
> >> Sent: Friday, August 15, 2014 5:26 PM
> >> To: Mailing list for lwIP users
> >> Subject: [lwip-users] Split DNS for multihomed setup
> >>
> >> Hello,
> >>
> >> I am using raw API, my system has two distinct network interfaces
> and
> >> there is a requirement, that (TCP) connections to certain remote
> >> addresses are made through certain network interfaces.
> >>
> >> Furtermore, the destinations, that we must connect to might be
> >> specified as domain names, that obviously need resolving. The
> problem
> >> is, certain destinations must only be resolved via DNS queries, that
> >> are made through a particular network interface. For example,
> >> consider a situation, when we have a PPP netif and an ethernet netif
> >> (that is on a "local" network) and we need to connect to "foo.local"
> >> via ethernet netif. We obviously must make sure, that the DNS query
> >> is made through the ethernet interface. Hope, that makes sense.
> >>
> >> Now, I've looked through the DNS implementation and I see that there
> >> are basically two obstacles:
> >> * there is no way to specify, which interface the queries should go
> >> through (the pcb is bound to IP_ADDR_ANY without any way to override
> >> it)
> >> * the "resolver cache" (dns_table) obviously does not consider which
> >> interface the entry belongs to
> >>
> >> I am intentionally mentioning "interface" all throughout, but it can
> >> be substituted for "source address", since those are equivalent in
> >> this context.
> >>
> >> What is the best way to tackle this problem? Perhaps I should
> attempt
> >> to patch the dns implementation to add the "source address" argument
> >> to the relevant functions and make the entries dns_table aware of
> the
> >> source address of the query (falling back to IP_ADDR_ANY if source
> >> address is not specified)? Is there any other way to do this?
> >>
> >> Thanks,
> >> Mark
> >>
> >> _______________________________________________
> >> lwip-users mailing list
> >> address@hidden
> >> https://lists.nongnu.org/mailman/listinfo/lwip-users
> >>
> >> _______________________________________________
> >> lwip-users mailing list
> >> address@hidden
> >> https://lists.nongnu.org/mailman/listinfo/lwip-users
> >
> > _______________________________________________
> > lwip-users mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/lwip-users
> >
> > _______________________________________________
> > lwip-users mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users