no-resolv is doing more harm than good.<div><br></div><div>dnsmasq is smart enough to ignore 127.0.0.1 in /etc/resolv.conf  And it will automatically pick up DHCP-assigned DNS servers which are written there.  Some DHCP clients have an option to update a different file with the DNS servers, in that case use dnsmasq's resolv-file option.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Nov 10, 2012 at 9:54 AM, /dev/rob0 <span dir="ltr"><<a href="mailto:rob0@gmx.co.uk" target="_blank">rob0@gmx.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Seems to me that dnsmasq is a better nscd replacement, and it has a<br>
place in mobile computing.<br>
<br>
# we use this dnsmasq as this system's own resolver<br>
no-resolv<br>
# I'm not sure if both of these are needed; we only want DNS and<br>
# only on loopback; we serve only this machine.<br>
no-dhcp-interface=lo<br>
listen-address=127.0.0.1<br>
user=dnsmasq<br>
group=dnsmasq<br>
# When connected to VPN, these names/addresses resolve. When not<br>
# connected, they don't, but that's okay, because we can't get to<br>
# them anyway.<br>
server=/rob0.vpn/<a href="http://192.168.6.1" target="_blank">192.168.6.1</a><br>
server=/6.168.192.in-addr.arpa/<a href="http://192.168.6.1" target="_blank">192.168.6.1</a><br>
# upstream: Google Public DNS<br>
server=8.8.4.4<br>
<br>
The problem here is when you might not want to use 8.8.4.4, such as<br>
when you're at a dnsmasq site where internal DNS is working. The<br>
solution, I guess, would be a hook in the DHCP client to write the<br>
DHCP-obtained nameserver[s] to a dnsmasq.d/file to include, and<br>
signal or restart dnsmasq.<br>
<br>
Problem with that solution: will dnsmasq.d get crufty, or do we just<br>
reuse the same file? Also, what if one of the mobile connections is<br>
not handled by DHCP, such as some cellular data connections?<br>
<br>
Speaking of cruft, maybe that's not a bad thing? What will dnsmasq do<br>
with multiple upstream servers?<br>
<br>
server=192.168.40.1<br>
server=192.168.0.1<br>
server=192.168.1.1<br>
server=8.8.4.4<br>
<br>
When we're at a site where one of those is our router, that should<br>
respond much faster than 8.8.4.4 can. OTOH, it could cause<br>
intermittent errors with local names; 8.8.4.4 is not going to know<br>
"minipax.rob0.lan".<br>
<br>
Can we priortise upstream servers? --all-servers implies that this<br>
can be done somehow, but I don't know how ... is it merely the order<br>
in which they are listed in the config (or on the command line)? When<br>
not using --all-servers, how does dnsmasq decide when to try a<br>
different one, and which one will be tried in that case? Random<br>
selection, rotating sequential, fixed top-down priority?<br>
<br>
Ideally we'd want something which you set up one time and is mostly<br>
done; something that should work at regular sites you frequent, as<br>
well as most public hotspots.<br>
--<br>
  <a href="http://rob0.nodns4.us/" target="_blank">http://rob0.nodns4.us/</a> -- system administration and consulting<br>
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:<br>
<br>
_______________________________________________<br>
Dnsmasq-discuss mailing list<br>
<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
<a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
</blockquote></div><br></div>