Comment 3 for bug 1003842

Revision history for this message
Scott Moser (smoser) wrote : Re: Upgrading to Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers

I think the most common case for this is a VPN as likely after you've vpn'd in somewhere, those dns servers have additional (local) results, that even possibly differ from external results. The other case is described in bug 993794. Although, to be honest, I'm not really sure what the benefit of dhcp servers on the same network giving 2 dns servers with different information available. I'm not exactly sure what expected behavior would be there.

There is upstream discussion on this at http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2009q3/003295.html .

One potential solution for this is to use:
 --server=/example.com/1.2.3.4
which would send all dns lookups for 'example.com' to 1.2.3.4.

Note also per /usr/share/doc/dnsmasq-base/examples/dnsmasq.conf.example:
  # Example of routing PTR queries to nameservers: this will send all
  # address->name queries for 192.168.3/24 to nameserver 10.1.2.3
  #server=/3.168.192.in-addr.arpa/10.1.2.3

At one point in the past I had a solution for using resolvconf to manage dnsmasq on connection to a vpn using vpnc. I've described that at [2]. I'm not sure whether the code there still works or not. Perhaps a similar approach could be used by network manager.

--
[1] http://seife.kernalert.de/blog/2010/06/22/nifty-dnsmasq-trick-reverse-lookup-using-a-specific-server/
[2] http://smoser.brickies.net/git/?p=att-resolvconf.git;a=blob;f=README;h=f2eff389131f46d8bf7b6b805f4395d89187cd1d;hb=HEAD