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

[S G]

Having read that, I'm not sure lwip is the right stack to do that. Its simply 
not meant for such a setup. And like Z wrote, even if you get it running, 
there's no guarantee future changes to lwip will leave your setup intact.

I'd suggest to either get an OS with support for separated processes or use 
ReactOS's multi-stack adaptions to add multiple instances of lwip to your 
firmware. You can then cleanly separate the interfaces by connecting the two 
stacks and your application via non-lwip things like OS messages boxes etc.

Simon

Mark Lvov wrote:
>
> 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