Announcement

**rsylte** · May 19, 2015, 01:12 AM

Finally fixed the issue by disabling dnsmasq in /etc/NetworkManager/NetworkManager.conf. Everything seems to be working fine now.

Anybody know why dnsmasq doesn't honor the DNS-servers received from DHCP?

Best regards
Roger Sylte

**SteveRiley** · May 20, 2015, 10:41 PM

Would you please --

1. Re-enable dnsmasq
2. Open two console windows side-by-side
3. Run your previous watch in one of them
4. Run tail -f /var/log/syslog in the other

Now wait for the switch. What do you see appear in syslog?

**kubicle** · May 20, 2015, 11:31 PM

If you have multiple nameservers configured, dnsmasq will alternate between them (sharing the load) when making requests. If you wish to make dnsmasq always use the primary nameserver (if available), you need to enable the "strict-order" option for dnsmasq (can be done through dnsmasq conffiles)

**rsylte** · May 21, 2015, 06:24 AM

Thank you for your suggestions!

There is nothing logged in syslog when this happens. DHCP is configured with our gateway as a backup DNS server. As per kubicle's reply, dnsmasq is load-balancing between all DNS servers, so the behaviour where it switches between internal and external DNS server is to be expected.

I re-enabled dnsmasq and added a configuration-file "/etc/NetworkManager/dnsmasq.d/my.conf" containing just one line = "strict-order", and restarted network-manager. So far everything seems to be working fine.

Thank you!

Best regards
Roger Sylte

**SteveRiley** · May 21, 2015, 11:08 AM

Originally posted by rsylte View Post

There is nothing logged in syslog when this happens. DHCP is configured with our gateway as a backup DNS server. As per kubicle's reply, dnsmasq is load-balancing between all DNS servers, so the behaviour where it switches between internal and external DNS server is to be expected.

I was thinking that perhaps you were getting new DHCP leases every few minutes (I've seen it before) that had different DNS configuration parameters.

**SeijiSensei** · May 24, 2015, 10:30 PM

Originally posted by kubicle View Post

If you have multiple nameservers configured, dnsmasq will alternate between them (sharing the load) when making requests. If you wish to make dnsmasq always use the primary nameserver (if available), you need to enable the "strict-order" option for dnsmasq (can be done through dnsmasq conffiles)

Is this well-documented? I know I've never heard of this behavior before. It violates the way name servers have been handled in /etc/resolv.conf for as long as I can remember. The standard is to rely on the first server in the list unless it is offline. From "man resolv.conf": "If there are multiple servers, the resolver library queries them in the order listed."

I want my client workstations to prefer the DNS server on my local network which has zone files with local IP addresses rather than the ones on my publicly visible nameservers. I'm surprised I would have to edit a configuration file to get what I expect to be the standard behavior for the resolver.

**SteveRiley** · May 25, 2015, 03:22 PM

Originally posted by SeijiSensei View Post

Is this well-documented? I know I've never heard of this behavior before.

From man dnsmasq:

-o, --strict-order
By default, dnsmasq will send queries to any of the upstream servers it knows about and tries to favour servers that are known to be up.
Setting this flag forces dnsmasq to try each query with each server strictly in the order they appear in /etc/resolv.conf

But remember that *buntu has been using resolvconf for quite a while now. The implementation relies on DBus and some scripts to find DNS servers on connected interfaces and plumb them into dnsmasq. dnsmasq is acting as a caching-only resolver on each *buntu host. Check it out:

Code:

steve@x250:~$ [B]ll /etc/resolv.conf[/B]
lrwxrwxrwx 1 root root 29 May  5 17:20 /etc/resolv.conf -> ../run/resolvconf/resolv.conf

steve@x250:~$ [B]cat /run/resolvconf/resolv.conf[/B]
# 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
nameserver 127.0.1.1

steve@x250:~$ [B]grep -i dns /var/log/syslog | grep -vi mdns[/B]
May 25 13:30:43 x250 kernel: [    0.849312] Key type dns_resolver registered
May 25 13:30:43 x250 NetworkManager[687]: <info> DNS: loaded plugin dnsmasq
May 25 13:30:58 x250 NetworkManager[687]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS.
May 25 13:30:58 x250 NetworkManager[687]: <info> DNS: starting dnsmasq...
May 25 13:30:58 x250 NetworkManager[687]: <warn> dnsmasq not available on the bus, can't update servers.
May 25 13:30:58 x250 NetworkManager[687]: <error> [1432585858.065196] [dns-manager/nm-dns-dnsmasq.c:398] update(): dnsmasq owner not found on bus: Could not get owner of name 'org.freedesktop.NetworkManager.dnsmasq': no such name
May 25 13:30:58 x250 NetworkManager[687]: <warn> DNS: plugin dnsmasq update failed
May 25 13:30:58 x250 NetworkManager[687]: <info> Writing DNS information to /sbin/resolvconf
May 25 13:30:58 x250 dnsmasq[1443]: started, version 2.72 cache disabled
May 25 13:30:58 x250 dnsmasq[1443]: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect
May 25 13:30:58 x250 dnsmasq[1443]: DBus support enabled: connected to system bus
May 25 13:30:58 x250 dnsmasq[1443]: warning: no upstream servers configured
May 25 13:30:58 x250 NetworkManager[687]: <warn> dnsmasq appeared on DBus: :1.49
May 25 13:30:58 x250 NetworkManager[687]: <info> Writing DNS information to /sbin/resolvconf
May 25 13:30:58 x250 dnsmasq[1443]: setting upstream servers from DBus
May 25 13:30:58 x250 dnsmasq[1443]: using nameserver 192.168.0.110#53

**SeijiSensei** · May 25, 2015, 09:19 PM

I knew about the relationship between dnsmasq and resolvconf. As I said I'm just surprised it deviates from what has been the standard for the resolver's behavior for, well probably, decades. I would have thought a change as fundamental as this one would have been more widely advertised when the dnsmasq/resolvconf system was instituted back in, I believe, 12.04.

**kubicle** · May 26, 2015, 12:40 AM

Originally posted by SeijiSensei View Post

I knew about the relationship between dnsmasq and resolvconf. As I said I'm just surprised it deviates from what has been the standard for the resolver's behavior for, well probably, decades. I would have thought a change as fundamental as this one would have been more widely advertised when the dnsmasq/resolvconf system was instituted back in, I believe, 12.04.

The current defaults in (since 2012) dns handling does deviate from libc's resolver (for example) that was used before. And there were some discussions (at least in the form of bug reports) when dns caching via dnsmasq was gradually introduced.

It's a trade-off, where in my opinion, the pros generally outweigh the cons in most use cases. Of course this might not so with every use case, that's why the defaults can be changed. More on the pros and cons you can probably find in these bug reports:
https://bugs.launchpad.net/ubuntu/+s...er/+bug/903854
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842

The latter includes some comments from the dnsmasq lead developer (Simon Kelley), and a few links for more info.

**SteveRiley** · May 26, 2015, 02:16 PM

dnsmasq + resolvconf is great for handling VPNs. All machines in my house are in the rileyz.net domain; I have a Debian 7 box that takes care of DNS and DHCP (and many other things). I can, for instance, connect to the Lexmark X544 printer simply by using the short DNS name "x544."

When I create a VPN connection definition, I select the option to configure routing only for resources on the connection. My default gateway remains the one in my house, not the far side of the VPN -- this is called "split tunneling." resolvconf sees the DNS/DHCP information on the VPN connection and plumbs additional DNS entries into dnsmasq. Now, I can continue issuing short names for stuff at home ("x544," not "x544.rileyz.net") and I can also issue short names for resources over the VPN ("twiki," not "twiki.employer.com"). Very neat, and 100% automatic.

Announcement

DNS lookups switches between internal and external DNS server

DNS lookups switches between internal and external DNS server

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment