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 <[email protected]> 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: [email protected] > [[email protected]] on behalf of Mark Lvov > [[email protected]] > 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 <[email protected]> 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: [email protected] >> [[email protected]] on behalf of Mark Lvov >> [[email protected]] >> 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 >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/lwip-users >> >> _______________________________________________ >> lwip-users mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/lwip-users > > _______________________________________________ > lwip-users mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/lwip-users > > _______________________________________________ > lwip-users mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
