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

[Mark Lvov]

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