Can someone please tell me how to change DNS servers in Ubuntu?

[Fritz]

The more I search the more confused I become. It's real simple, I want to use Google's DNS servers rather than my ISP and Ubuntu seems to not want me to do this as I cannot find clear instructions on how to do this.

Thanks

PS: I did edit the /etc/resolvconf/resolvconf.d/base file to add 2 lines "nameserver 8.8.8.8" and "nameserver 8.8.4.4" but this did nothing. I can't understand why is info is so damned hard to find.

 

[Fritz]

Well hell, figured out how to do it PfSense.

 

[Gary Gapinski]

I think the answer might be "carefully".

systemd has borged local name resolution. On recent (≥16.10) versions of Ubuntu, you will have a cacheing resolver listening on 127.0.0.53. And you will not have DNSSEC by default.

The configuration can be found in /etc/systemd/resolved.conf. Defaults are compiled in, and are for Google name servers. Specific resolvers can be configured, but I have no clue not rigorously tested to see what happens if/when resolvers are statically configured and resolver info arrives via DHCP(v4/v6) as well as IPv6 RA.

gapinski@ubuntu-1704-server:~$ cat /etc/systemd/resolved.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details

[Resolve]
#DNS=
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
#Domains=
#LLMNR=yes
#DNSSEC=no
#Cache=yes
#DNSStubListener=udp
gapinski@ubuntu-1704-server:~$

The command systemd-resolve --status can be used to find out what the system has decided to use.

systemd-resolved is supposed to use whatever it sees from DHCP(v4|v6) (or IPv6 RA, or static network configuration), but YMMV. There can be different DNS information on different interfaces, and I have no idea what gets used in such situations.

The man page has some information, but one might consider it and its relatives demotivational.

I created two VMs to check both Ubuntu 17.04 Server and Desktop. I got slightly different results. The Server instance did not have IPv6 enabled, and systemd-resolved wasn't listening on IPv6 on the Desktop instance. I also see completely different (and puzzling) results (namely, the Google DNS servers in use) on other systems in mixed IPv4/IPv6 DHCPv4/DHCPv6/SLAAC networks. Even more puzzlement was gained when I installed BIND (collided with systemd-resolved interface use and default /etc/default/bind9 has RESOLVCONF=no, which causes bind9-resolvconf.service (yet another systemd-related "service") to not change /etc/resolv.conf (I suspect manual editing of /etc/resolv.conf is best avoided).

gapinski@ubuntu-1704-server:~$ systemd-resolve --status
Global
DNS Servers: 192.168.137.2
DNS Domain: localdomain
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 2 (ens33)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
gapinski@ubuntu-1704-server:~$

gapinski@ubuntu-1704-desktop:~$ systemd-resolve --status
Global
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 2 (ens33)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 192.168.137.2
DNS Domain: localdomain
gapinski@ubuntu-1704-desktop:~$

 

[Fritz]

Wow, thanks for this.

The way I tested was - DNS leak test

It now shows the DNS Servers set in PfSense rather than my ISP's.

 

[rubylaser]

I typically just add the the DNS nameservers to my /etc/network/interfaces file (this is on 16.04 LTS)

sudo nano /etc/network/interfaces

and, add a line like this to the bottom

dns-nameservers 8.8.8.8 8.8.4.4

So, it ends up looking like this.

auto eth0
iface eth0 inet static
        address 10.1.1.71
        netmask 255.255.255.0
        gateway 10.1.1.1
        dns-nameservers 8.8.8.8 8.8.4.4

and take the interface down and bring it back up

sudo ifdown eth0
sudo ifup eth0

 

[Fritz]

Is there any advantage to setting them in Ubuntu as opposed to a redirect in PfSense as I currently have it?

 

[PigLover]

There is advantage in having your DNS point to your pfSense box and letting it do redirects for you.

First advantage is that, by default, pfSense runs a cacheing DNS resolver with DNSSEC enabled. This means that any DNS answers will be cached in the pfSense resolver and the next request for that same DNS name will respond much faster. Don't underestimate how important this is for responsiveness - a typical web page can have dozens to hundreds of "objects' on it, and many times the top-level URL is exactly the same - so any DNS latency can be amplified 10x to 100x or more in painting a whole web page. Also, the DNSSEC support decreases the likelihood that DNS spoofing attacks will succeed.
Note that you can enable cacheing and DNSSEC on your ubuntu box too - but using the pfSense resolver makes the cache global for everything that is using it so if you have multiple machines behind it there can be some further gain.

Second advantage is that the pfSense resolver will resolve local-scope names. If you don't do anything special this means the names handed out locally by your DHCP on pfSense will be resolvable. So if you have a box named "kodi" on your lan you can refer to it using its DNS name instead of having to look up the address assigned by DHCP and using the address. There are more creative things you can do with this too by using the "host overrides" and "domain overrides" in the pfSense resolver to create more DNS names that are valid only in the local scope of your LAN.

Lastly, if you set things up to point to your pfSense resolver rather than directly to an outside DNS service its easier to change things. If, for example, you want to change your DNS service from Google to Amazon then you only have to change it once (in the pfSense box) rather than going out to all of the systems you've set up on the LAN and changing it on each of them (and you don't have to remember the 10 different ways DNS gets set up between Centos, Rhel, Ubuntu before 16.10, ubuntu after 16.10, Windows, etc., etc.).

 

[Fritz]

Awesome, thanks.

 

[nitrobass24]

@PigLover is on point with his comments.

It also can provide you with an extra layer of security as well. Lots of malware leverage 53/UDP to communicate but if all of your boxes are configured to use a DNS server you control that helps. You can even go a bit further and include a firewall rule to drop all 53/UDP traffic that is destined for DNS servers except those you approve. For example, my FW drops all DNS packets except those for my DNS server and OpenDNS.

If you wanted to go a step further you could use one of the professional or open source threat intel feeds and pump it into your DNS server as a Response Policy Zone (RPZ). ThreatStop has a decent write-up on how this works, so I won't explain it here. DNS Firewall Service

 

[BLinux]

I wish you never mentioned any of the below... I was happy believing in Santa Claus and editing /etc/resolv.conf. on CentOS/RH/Fedora systems, I just configure stuff using nmcli and it seems to edit /etc/resolv.conf correctly.

I think the answer might be "carefully".

systemd has borged local name resolution. On recent (≥16.10) versions of Ubuntu, you will have a cacheing resolver listening on 127.0.0.53. And you will not have DNSSEC by default.

The configuration can be found in /etc/systemd/resolved.conf. Defaults are compiled in, and are for Google name servers. Specific resolvers can be configured, but I have no clue not rigorously tested to see what happens if/when resolvers are statically configured and resolver info arrives via DHCP(v4/v6) as well as IPv6 RA.

gapinski@ubuntu-1704-server:~$ cat /etc/systemd/resolved.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details

[Resolve]
#DNS=
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
#Domains=
#LLMNR=yes
#DNSSEC=no
#Cache=yes
#DNSStubListener=udp
gapinski@ubuntu-1704-server:~$

The command systemd-resolve --status can be used to find out what the system has decided to use.

systemd-resolved is supposed to use whatever it sees from DHCP(v4|v6) (or IPv6 RA, or static network configuration), but YMMV. There can be different DNS information on different interfaces, and I have no idea what gets used in such situations.

The man page has some information, but one might consider it and its relatives demotivational.

I created two VMs to check both Ubuntu 17.04 Server and Desktop. I got slightly different results. The Server instance did not have IPv6 enabled, and systemd-resolved wasn't listening on IPv6 on the Desktop instance. I also see completely different (and puzzling) results (namely, the Google DNS servers in use) on other systems in mixed IPv4/IPv6 DHCPv4/DHCPv6/SLAAC networks. Even more puzzlement was gained when I installed BIND (collided with systemd-resolved interface use and default /etc/default/bind9 has RESOLVCONF=no, which causes bind9-resolvconf.service (yet another systemd-related "service") to not change /etc/resolv.conf (I suspect manual editing of /etc/resolv.conf is best avoided).

gapinski@ubuntu-1704-server:~$ systemd-resolve --status
Global
DNS Servers: 192.168.137.2
DNS Domain: localdomain
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 2 (ens33)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
gapinski@ubuntu-1704-server:~$

gapinski@ubuntu-1704-desktop:~$ systemd-resolve --status
Global
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 2 (ens33)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 192.168.137.2
DNS Domain: localdomain
gapinski@ubuntu-1704-desktop:~$

 

[Fritz]

systemd-resolve --status returns "Unrecognized Option "--status"

I run into this all the time. Seems like half the commands on the Internet don't work. This alone keeps a lot of people away from Linux. Not finding an answer is one thing but finding a sea of bogus or half answers is far worst. I understand that a lot of info out there is obsolete so I always look for a date/version but there are still tons of info out there that is totally worthless without a hint as to why. My recent attempt to install and config Nextcloud is a prime example. Far too many DIFFERENT tutorials out there and none of them work 100%.