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

[Radouch, Zdenek]

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