PDA

View Full Version : [SOLVED] No DNS after static IP change on Ubuntu Server 16.04



LVCNSOL
September 21st, 2020, 12:31 PM
I recently signed up with a new ISP who gave me a new router and without changing too much on their router I thought I'd rather update my servers IP address instead. It was a static IP address before and was working 100% but after the new static IP address domains don't want to resolve for some reason.
I am running a pi-hole server but not as a DHCP client, the router is still handling that. The routers DNS just points to the pi-hole.

The setup was working before the server IP change so I am not sure what I am missing now. Perhaps someone could shed some light?

/etc/network/interfaces file:



# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eno1
iface eno1 inet static
address 192.168.101.110
broadcast 192.168.101.255
netmask 255.255.255.0
network 192.168.101.0
gateway 192.168.101.1
dns-nameservers 192.168.101.1



Not sure if this is relevant?
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
nameserver 127.0.0.1



SOLUTION EDIT:

The routes table and /etc/dhcpcd.conf needed to be updated.

If there are any IP's relating to the router or network in /etc/dhcpcd.conf they will need to be updated.

Then check the routes using sudo ip route if there are any IP's that shouldn't be there delete them by executing:



sudo ip route del default via 192.168.1.254 dev eno1
sudo ip route del 192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.100 metric 202


Then add the default gateway:


sudo ip route add default via 192.168.101.1

webaake
September 21st, 2020, 03:21 PM
For 16.04 I don't think the useless systemd-resolved has taken over yet, but check if it has. (did 16.04 even have systemd? don't remember)

Otherwise the old trusty resolvconf manages your DNS and it's best configured manually in the file /etc/resolvconf/resolv.conf.d/tail
which will not be overwritten automatically.

LVCNSOL
September 21st, 2020, 09:29 PM
Thank you for the feedback. Unfortunately adding the DNS to the resolv.conf doesn't seem to have helped either.

Interestingly when I run route -n I get ip addresses from the old network not the current network. I am not sure if this is an issue - I would assume so but I am not that much of an expert to know what needs to be changed.

Just an edit. When I remove the old routes and then add the correct ones in, the first two always end up coming back after a restart. They must be populating from somewhere but I am not sure where.



Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 202 0 0 eno1
192.168.1.0 0.0.0.0 255.255.255.0 U 202 0 0 eno1
192.168.101.0 0.0.0.0 255.255.255.0 U 0 0 0 eno1

SeijiSensei
September 22nd, 2020, 05:11 PM
The machine is in the 192.168.101.0/24 subnet and designates its gateway as 192.168.101.1, but the routing table doesn't show the same configuration. If you use the configuration in post #1, can you ping 192.168.101.1?

You should be able to configure everything using the graphical NetworkManager.

16.04 used dnsmasq and resolvconf as I recall. systemd didn't really get going until 18.04.

LVCNSOL
September 22nd, 2020, 05:33 PM
This is my issue. When I remove the irrelevant IP addresses from the routing they return after the network is restarted. This I am unsure about as to where it would be defaulting from.
What would add the old IP addresses back to the routing table?

I can ping the gateway on 192.168.101.1

TheFu
September 22nd, 2020, 09:37 PM
dns-nameservers 192.168.101.1

That points at the router, not the pi-hole. That is the problem. Point it at the pi-hole IP.

Also, I'd remove the "networks" line. It isn't needed and if it is wrong, can confuse things.

16.04 has systemd, but not systemd.resolved - thank DOG!

BTW, if you have a pi-hole, you don't need resolvconf or systemd.resolved at all. Those can be purged for systems that don't leave the LAN (desktops and servers), but leave them on any portable devices like laptops. Also, remove the symbolic link for /etc/resolv.conf and create a file there with a standard nameserver and any DNS search options you may desire.

$ more /etc/resolv.conf
nameserver 172.22.22.80
nameserver 172.22.22.81

Best to have 2 DNS servers, running on different systems. You can point the 2nd to a backup DNS, perhaps 1.1.1.1.

LVCNSOL
September 23rd, 2020, 02:47 PM
Thank for the replies all.

Just to eliminate any issues, I have removed the pi-hole and I am just using Cloudflare's DNS on the router level.

This is what /etc/network/interfaces looks like:




# The primary network interface
auto eno1
iface eno1 inet static
address 192.168.101.110
broadcast 192.168.101.255
netmask 255.255.255.0
gateway 192.168.101.1
dns-nameserver 192.168.101.1


Surely pointing the dns-nameserver to the router is okay as it will just use whatever DNS the router is using?

The routing table:



Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 202 0 0 eno1
192.168.1.0 0.0.0.0 255.255.255.0 U 202 0 0 eno1
192.168.101.0 0.0.0.0 255.255.255.0 U 0 0 0 eno1


For some reason I cannot get rid of the 192.168.1.xxx IP addresses. I remove them and they keep returning. Not sure how to rectify that?

Interestingly when I ping 1.1.1.1 it is trying to use the servers old IP address. Once again I am not sure how to sort that out?



PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
From 192.168.1.100 icmp_seq=1 Destination Host Unreachable
From 192.168.1.100 icmp_seq=2 Destination Host Unreachable
From 192.168.1.100 icmp_seq=3 Destination Host Unreachable


As I mentioned before, everything use to work on my previous network. It's only after the router was changed and new IP addresses were used that the issues started.

Thanks for the assistance so far.

TheFu
September 23rd, 2020, 03:46 PM
Whoa!

You can't just change from the network and router from
192.168.1.254 ---> 192.168.101.1
and expect things to work. The router needs to be configured with the changes first. Depending on the router, that may not be possible.

Ping the router by IP. I don't care if that is 192.168.1.254 or 192.168.101.1. If you can't ping the router, you won't get anywhere.

There are rules to how networks work. We can't just make up numbers as we go without ensuring all the parts along the way agree with those new made-up numbers.

"entryway" isn't a valid element in the interfaces file. There's no reference to it in the manpage.

The interfaces file probably should appear like this for now:

# The loopback network interface
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet static
address 192.168.101.110
netmask 255.255.255.0
gateway 192.168.101.1 # assuming this is really the router
dns-nameserver 1.1.1.1
If the router IP is wrong, you won't get anywhere. Anything else is useless. The dns-nameserver pointing at the router may or may not work. It depends whether DNS is running on that device or not. It doesn't always.

You know, if you could show the original file that worked, we'd 100% know what the router IP was.

LVCNSOL
September 23rd, 2020, 04:06 PM
The original router IP was 192.168.1.254 and I can definitely ping the new the router on 192.168.101.1. I have access to the new router and all my other devices on DHCP are working on the router. It's just the server which isn't

I have tried the interfaces file as you mentioned but that doesn't seem to have worked either.

Why though, when I ping 1.1.1.1 it shows as if it's coming from the servers old IP address (192.168.1.100)?

TheFu
September 23rd, 2020, 04:16 PM
If you don't show the exact command and the exact output, we cannot help.

LVCNSOL
September 23rd, 2020, 05:23 PM
Is this what you're reffering to?



~$ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
From 192.168.1.100 icmp_seq=1 Destination Host Unreachable
From 192.168.1.100 icmp_seq=2 Destination Host Unreachable
From 192.168.1.100 icmp_seq=3 Destination Host Unreachable




$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 202 0 0 eno1
192.168.1.0 0.0.0.0 255.255.255.0 U 202 0 0 eno1
192.168.101.0 0.0.0.0 255.255.255.0 U 0 0 0 eno1





$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eno1
iface eno1 inet static
address 192.168.101.110
netmask 255.255.255.0
gateway 192.168.101.1
dns-nameserver 1.1.1.1

TheFu
September 23rd, 2020, 05:38 PM
Are you restarting networking between changes?

LVCNSOL
September 23rd, 2020, 05:48 PM
I am yes. Using sudo ifdown -a && sudo ifup -a

If that's the correct way?

TheFu
September 23rd, 2020, 08:48 PM
systemd broke much of how networking works. Sometimes ifup/ifdown don't work anymore and we have to use the systemctl commands. Sometimes those don't work and for expediency, I just reboot.

Here's an interfaces file:
$ more /etc/network/interfaces

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto ens3
iface ens3 inet static
address 172.22.22.34
netmask 255.255.255.0
gateway 172.22.22.1
dns-nameservers 172.22.22.80 172.22.22.81

My router for that LAN segment is 172.22.22.1. It doesn't run any DNS or caching DNS or forwarding DNS.
If you can't ping the router/gateway, nothing is going to work. If that isn't working, we need to step back and look at the cable, ports, and drivers.

LVCNSOL
September 24th, 2020, 11:38 AM
Okay I have made some headway. It is definitely routing related.

So when I execute route -n I get this:



$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 202 0 0 eno1
192.168.1.0 0.0.0.0 255.255.255.0 U 202 0 0 eno1
192.168.101.0 0.0.0.0 255.255.255.0 U 0 0 0 eno1


The 192.168.1.254 gateway and 192.168.1.0 IP should not be there so I execute both


sudo ip route del default via 192.168.1.254 dev eno1
sudo ip route del 192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.100 metric 202

which removes them, all good.

The I add my default gateway:


sudo ip route add default via 192.168.101.1


So the routes now look like this:


$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.101.1 0.0.0.0 UG 0 0 0 eno1
192.168.101.0 0.0.0.0 255.255.255.0 U 0 0 0 eno1


Now everything works as it should - I can ping google.com with no issues.

However, once the server is rebooted the 192.168.1.254 gateway and 192.168.1.0 IP are back in the routing table again. Where would they be populating from? I don't know what would be holding on to that info?

TheFu
September 24th, 2020, 09:36 PM
Have you ever used any GUI to control the network settings?
Is there a DHCP server on the LAN that might be providing the gateway?

Are you really running 16.04? Netplan took over network configuration after that release.

LVCNSOL
September 25th, 2020, 11:51 AM
I've found where it was sitting.

/etc/dhcpcd.conf had the old router listed. I have no idea why it would have been listed in there but I corrected the IP address and it all seems good now.

Thank you for the assistance TheFu. Will update as solved and add solution to my first post as well.