Ubuntu ignoring DNS from DHCP

[courtney2]

I've recently kicked Ubuntu to the curb because it was the ONLY Linux distro that was ignoring my DHCP settings that tell local computers which DNS servers to use. I do this because I have internal DNS records for my server. I have returned to Ubuntu, and therefore, am facing this issue yet again. I saw in the past this is a systemd thing, and it is "a feature" to be doing this. How can I get Ubuntu to start paying attention to my DNS settings that are set by my DHCP server? Currently I cannot access my local servers with my computer unless I edit my /etc/hosts file, which is not a viable solution

[TheFu]

I've recently kicked Ubuntu to the curb because it was the ONLY Linux distro that was ignoring my DHCP settings that tell local computers which DNS servers to use. I do this because I have internal DNS records for my server. I have returned to Ubuntu, and therefore, am facing this issue yet again. I saw in the past this is a systemd thing, and it is "a feature" to be doing this. How can I get Ubuntu to start paying attention to my DNS settings that are set by my DHCP server? Currently I cannot access my local servers with my computer unless I edit my /etc/hosts file, which is not a viable solution

I'm not having this issue on 16.04.

I do have this issue with Android 7+, however. Google thinks they know best, I suppose. NOT!!! It is frustrating to have to use a VPN to access my nextcloud server from my own home LAN!

[Doug S]

I'm not having any troubles with 16.04 either. Nor did I with previous LTS versions

Perhaps post your /etc/dhcp/dhcpd.conf file. The relevant portion of mine is:

# option definitions common to all supported networks...

default-lease-time 86400;
max-lease-time 93000;
option domain-name "smythies.com";
# option domain-name-servers 192.168.111.1, 75.154.133.68, 75.154.133.100;
option domain-name-servers 192.168.111.1;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.111.255;
option routers 192.168.111.1;

And do you observe DNS in your resulting client lease file (in one example client case on my LAN /var/lib/dhcp/dhclient.br0.leases):

lease {
  interface "br0";
  fixed-address 192.168.111.112;
  option subnet-mask 255.255.255.0;
  option routers 192.168.111.1;
  option dhcp-lease-time 86400;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.111.1;
  option dhcp-server-identifier 192.168.111.1;
  option broadcast-address 192.168.111.255;
  option domain-name "smythies.com";
  renew 0 2018/01/28 02:22:02;
  rebind 0 2018/01/28 11:30:32;
  expire 0 2018/01/28 14:30:32;
}

[courtney2]

I've had this issue with 16.04 to 17.10 I'm afraid.

First, my dhclient file:

option rfc3442-classless-routes code 121 = array of unsigned integer 8;

send host-name = gethostname();
request subnet-mask, broadcast address, time-offset, routers, domain-name, domain-name-servers, domain-search, host-name, dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers, netbios-name-servers, netbios-scope, interface-mtu, rfc3442-classless-static-routes, ntp-servers;

timeout 300;

I have never touched this file before, this is what I get on this network.

And for my /etc/resolv.conf file:

nameserver 127.0.0.53

So, my thoughts are systemd is being stupid as usual and messing with my DNS server settings. Perhaps there's a way to disable systemd from handling DNS and just letting the OS do its thing with resolvconf?

[Doug S]

And for my /etc/resolv.conf file:

nameserver 127.0.0.53

So, my thoughts are systemd is being stupid as usual and messing with my DNS server settings. Perhaps there's a way to disable systemd from handling DNS and just letting the OS do its thing with resolvconf?

From which I assume your client computer is a desktop. On such a client on my LAN I get:

$ cat /etc/resolv.conf
# 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
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53
search smythies.com

For a server client I get something different. And for the recommended command I get:

~$ systemd-resolve --status
Global
          DNS Domain: smythies.com
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 3 (wlp8s0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 2 (enp9s0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.111.1
          DNS Domain: smythies.com

[courtney2]

Hmmmm. Your above config for your client desktop (which I am using here) has the same output, except there is no search option. But what this tells me, though, is that systemd's resolver is probably the culprit and causing it to ignore my internal DNS server, as I rely on order of DNS servers so that internal computers can see my local DNS entries. And, from what I hear, ignoring order of DNS server entries is a "feature" in systemd

[Doug S]

I wonder if bug 164230 applies to your issue.

[courtney2]

Hey Doug! I bet you that is it. I ended up solving my issue with this. I ultimately had to disable systemd-resolvd, add "dns=default" to /etc/NetworkManager/NetworkManager.conf and remove the /etc/resolv.conf symlink to get things working right. This whole systemd takeover is a load of crap

[maretodoric]

Ok, gotta tune in on this old thread so sorry for reviving it. But I've found a way to make this work without uninstalling systemd-resolve in couple of steps.

1. Remove symlink for /etc/resolv.conf
   

   rm -rf /etc/resolv.conf

2. Create empty file for /etc/resolv.conf
   

   touch /etc/resolv.conf

3. Edit NetworkManager configuration file that forces use of dnsmasq so that it actually use default DNS entries, or remove that file all-together if you have "dns=default" set in default NetworkManager.conf
   

   sed -i 's/^dns.*/dns=default/g' /usr/lib/NetworkManager/conf.d/10-dns-resolved.conf

4. Stop and disable systemd-resolved
   

   systemctl stop systemd-resolved && systemctl disable systemd-resolved

5. Restart NetworkManager
   

   systemctl restart NetworkManager

I've gotten to this solution since i was using fedora for long time and haven't had any issues like this. I as well have home DNS server with some custom DNS entries which are now overridden on Mint 19. Tried to look for differences between two distros (other than obvious lol) and figured this.
So for everyone that doesn't feel comfortable removing system services, feel free to try this to resolve your problem.

[oldos2er]

Hi maretodoricm, could you clarify which version of Ubuntu you ran these commands on?