Hi Simon,

On Sat, 8 Apr 2017 at 00:21, Simon Kelley <si...@thekelleys.org.uk> wrote:

> I understand the desire to be able to specify resolvers dynamically with
> the full set of source-address and routing options; that's actually
> already available, and has been for a long time, using the DBus
> interface to dnsmasq, which includes the "SetDomainServers" method,
> which takes strings identical to argument to --server. I've not looked
> at the code, but your previous patch to allow binding both IP and
> interface should have automatically added that feature to
> SetDomainServers. (if it didn't then I'd certainly take a patch to
> correct that.)


Thanks for pointing me to the DBus-interface, that does indeed sound like
the correct approach. I will test if SetDomaimServers automatically support
the server/interface/adress syntax, and provide a patch if not.

Have a nice weekend,
Kristian


>
>
> Cheers,
>
> Simon.
>
>
>
> On 23/03/17 18:16, Kristian Evensen wrote:
> > Automatically specifying which source address and interface to be used
> for
> > communicating with a given DNS server is very convenient on multihomed
> hosts.
> > Two use-cases I have had for this feature are:
> >
> > * Several mobile broadband providers hand out private IP-addresses, but
> the DNS
> > servers are global. Unless special routing rules are added, then the
> default
> > route will be used for resolving domains. This is not ideal, as it might
> lead to
> > higher latencies for replies, or an additional cost to the user if DNS
> requests
> > to the "local" servers are free.
> >
> > * Several mobile broadband devices act as small routers, and some of the
> most
> > popular types only hand out the same IP, DNS server, etc. To make
> matters worse,
> > if these devices loose connectivity, they will highjack any DNS request
> and
> > reply with its own IP. If you have multiple of these devices, you risk
> being
> > stuck without working DNS as all requests might be forwarded to the
> disconnected
> > device. Adding support for binding to interface and IP will make sure
> that
> > requests are sent to the correct device. Some external tool will still be
> > required to check that DNS is working fine and updating the resolv-file
> > accordingly.
> >
> > Dnsmasq already supports reading and binding to an ip-adress/interface
> through
> > the --server option. This patch adds support for specifying which source
> address
> > and/or interface to use for a server in the resolv-file, using the same
> syntax
> > as for --server. For example, in order to specify that source ip
> 100.76.125.47
> > and interface wwan1 should be used to communicate with server
> 213.158.199.1, the
> > following line would have to be added to the resolv-file:
> >
> > nameserver 213.158.199.1@100.76.125.47@wwan1
> >
> > Since the syntax is not standard, the --multihomed-resolver command line
> option
> > must be enabled. Please note that lines with and without source
> > address/interface can be mixed.
> >
> > Since we now have two places where the interface-part of --server is
> parsed, I
> > have factored out this parsing into a separate function. parse_server()
> is
> > converted to use this function.
> >
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to