I am also interested in this question and I tried the solution proposed @sim.
To test it, I put
Then I restarted the network with
sudo service network-manager restart
The result is that
/etc/resolv.conf looks like
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nm-tool states that the dnsserver are
which are the ones provided by my router.
On the other hand digging an address tells that
;; Query time: 28 msec
;; SERVER: 126.96.36.199#53(188.8.131.52)
If I am right, I conclude from all this that
- only the "head" part is read by resolvonf: the "base" part is
somehow controlled by dnsmasq
- the dnsserver is actually forced to
184.108.40.206 regardless of the server provided by dhcp, BUT you loose the caching provided by dnsmasq, since the request is always sent to 220.127.116.11
- dnsmasq is still using ONLY the dnsserver provided by dhcp.
All in all, it works but I don't think it is the intended result asked for.
A more close solution I think is the following. Edit
sudo vim /etc/dhcp/dhclient.conf
supersede domain-name-servers 18.104.22.168;
The result is the following: resolv.conf contains only 127.0.0.1, which means that dnsmasq cache is invoked and nm-tool says
which means that if the name searched for is not in the cache, then it is asked for at 22.214.171.124 and not at the server provided by dhcp.
Another (perhaps better) option is to use "prepend" instead of "supersede": in this way, if the name is not resolved by 126.96.36.199, then the request falls back on the other server. In fact, nm-tool says