DietPi-Config | Changed DNS address not applied/boot persistent

[maartenlangeveld]

Creating a bug report/issue

Required Information

• DietPi version | 6.20.5

Additional Information (if applicable)

• Can this issue be replicated on a fresh installation of DietPi? YES

Steps to reproduce

1. Run 'dietpi-config' --> network options --> adapter options --> change wired network settings
2. Change DNS from 8.8.8.8 to Cloudfare (1.1.1.1 1.0.0.1)
3. Apply settings
4. Reboot
5. Run 'dietpi-config' --> network options --> adapter options --> change wired network settings
6. Ethernet details still mentions DNS = 8.8.8.8 (even after mutiple reboots)
   Ethernet Details: │
   │ Usage : Sent = 0MB | Recieved = 0MB │
   │ Address : IP = 192.168.0.250 | Mask = 255.255.255.0 | Gateway = 192.168.0.254 | DNS = 8.8.8.8 │
   │ │
   │ ●─ DHCP/STATIC IP ──────────────────────● │
   │ Change Mode : [STATIC] │
   │ Copy : Copy current address to "Static" │
   │ Static Ip : [192.168.0.250] │
   │ Static Mask : [255.255.255.0] │
   │ Static Gateway : [192.168.0.254] │
   │ Static DNS : [1.1.1.1 1.0.0.1] │
   │ ●─ Additional Options ──────────────────● │
   │ Disable : Disable Ethernet adapter │
   │ ●─ Apply ───────────────────────────────● │
   │ Apply : Save all changes and restart networking

Expected behaviour

• Ethernet details should show DNS = 1.1.1.1 1.0.0.1

Actual behaviour

• Ethernet details shows DNS = 8.8.8.8

Extra details

• ...

[MichaIng]

@maartenlangeveld
Can you please check the following steps:

• Apply the new DNS via dietpi-config
• Verify it is applied to /etc/network/interfaces: cat /etc/network/interfaces
  
  
  
  • Beneath #Ethernet it should contain: dns-nameservers 1.1.1.1 1.0.0.1
  
  
• Verify this is applied to /etc/resolv.conf as well: cat /etc/resolv.conf
  
  
  
  • Should contain: nameserver 1.1.1.1 1.0.0.1
  
  

[maartenlangeveld]

Hi Micha, see output below. There's a mismatch between interfaces and resolv.conf !

cat /etc/network/interfaces:

/etc/network/interfaces

Please use DietPi-Config to modify network settings.

Local

auto lo
iface lo inet loopback

Ethernet

allow-hotplug eth0
iface eth0 inet static
address 192.168.0.250
netmask 255.255.255.0
gateway 192.168.0.254
dns-nameservers 1.1.1.1 1.0.0.1

Wifi

allow-hotplug wlan0

iface wlan0 inet dhcp
address 0.0.0.0
netmask 0.0.0.0
gateway 0.0.0.0

dns-nameservers 0.0.0.0

wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 114.114.114.114

[MichaIng]

@maartenlangeveld
That is strange, although we had such a case one time already, sadly I can't find the topic anymore.

resolvconf is quite a bid intendant of the interface config, at least it can be. There is a trigger when starting interfaces that usually tells resolvconf (respectively the underneath library) to apply the DNS nameservers from /etc/network/interfaces. But other triggers can apply different nameservers afterwards, e.g. of course a DHCP server and as well in case of static IP the default gateway (your router) seems to have the ability to forward another DNS server to the client when connecting. At least this was obviously the case on the other topic, where "magically" the applied DNS nameserver always matched the one that was configured within the router settings, so where the router itself resolves it's requests, as well even that /etc/network/interfaces had a different entry.

You could check if those entries from /etc/resolv.conf match the ones configured in your router/gateway/AP, just to identify the source.
Of course this is actually not wanted, if you already configure a static DNS entry and I am not sure how to block it. Perhaps something can be done within the router settings, either block DNS forwarding or simply configure the cloudflare DNS there as well.

Otherwise the hammer method would be to remove resolvconf, although this might lead to issues in combination with 3rd party software or even system parts expecting it. But if you want to try:

apt-mark manual ifupdown
apt-mark auto resolvconf
G_AGA # This should purge resolvconf, if it is not required by any other installed APT package
ifdown eth0
ifup eth0
cat /etc/resolv.conf

/etc/resolv.conf will then be a static file, no symlink to what resolvconf dynamically changes. Currently not 100% sure, but the ifdown && ifup should apply the DNS configured in interfaces, otherwise you might need to add it manually: echo 'nameserver 1.1.1.1 1.0.0.1' > /etc/resolv.conf

[maartenlangeveld]

Hi Micha,

I have disabled DHCP on my router (dhcp is handled by Pi-hole running on same device). Moreover, the DNS servers on my router were couldflare's (1.1.1.1 1.0.0.1) so not 8.8.8.8.

Thanks for the work around. I will try.

[MichaIng]

@maartenlangeveld
Ah you mean DNS is handled by Pi-hole, don't you?

In case of Pi-hole DONT remove resolvconf, I will quickly check but it requires it, if I remember correctly.

Pi-hole works as a DNS server to resolve advertising related DNS requests to the loopback IP. It alone should not work as DHCP server, although this can be installed/configured in parallel.

But Pi-hole requires the underlying system be resolve it's requests on an external DNS server, to incoming requests are resolved by Pi-hole, but Pi-hole again forwards non-ad requests to the DNS server configured in /etc/resolv.conf. And it might be possible, but I am not 100% sure, that Pi-hole itself uses resolvconf to set this machine internal DNS entry. Perhaps you can configure it in its web UI.

[maartenlangeveld]

Yes, have disabled DHCP on my router and now have pi-hole running as DHCP. On nanopi i use a static address as you have seen. In pi-hole I also have cloudfare's DNS (1.1.1.1 1.0.0.1) selected. Other issue after reboot lighttpd and php7.0-fpm are not always automatically started.

[MichaIng]

@maartenlangeveld
~Hmm not sure then what sets 8.8.8.8 currently.~

Pi-hole indeed requires resolvconf: https://github.com/pi-hole/pi-hole/blob/master/automated%20install/basic-install.sh#L210

Ah yeah during Pi-hole install/setup you can choose the upstream DNS provider, which will be then configured: https://github.com/pi-hole/pi-hole/wiki/Upstream-DNS-Providers

Just found where to change this on existing Pi-hole, if there is no related option in the web UI (at least "pihole" command does not offer one):
Edit: /etc/dnsmasq.d/01-pihole.conf DNS1= and DNS2=
And edit as well: /etc/pihole/setupVars.conf PIHOLE_DNS_1= and PIHOLE_DNS_2=

The first should apply the desired DNS after restarting Pi-hole, the second assures that on Pi-hole update this will not be reverted.

---

About Lighttpd and PHP-FPM:

• Does on boot, directly before login prompt is shown, dietpi-services throw any error?
• It should start webserver and PHP after all other boot steps are finished and directly before login prompt appears.

[maartenlangeveld]

Hi Micha,
As a test I hhave configured completely different 'upstream' DNS servers in Pi-hole admin Web ui. Has no impact on resolv.conf (has not changed).

cat /etc/dnsmasq.d/01-pihole.conf
...
...
server=208.67.222.222
server=208.67.220.220
interface=eth0

Maybe you have to look at how dietpi-config in v6.19.7 handled change of DNS? I installed pi-hole firstly on 6.19.7 and everything worked fine. After update to v6.20.5 gave problems i did a fresh and new install of v6.20.5 hoping that would solve the problems.

About Lighttpd and PHP-FPM:
Does on boot, directly before login prompt is shown, dietpi-services throw any error? No.
Problem occurs sometimes. Not reproducable everytime.

[MichaIng]

@maartenlangeveld
Okay about the DNS thing I am a bid lost them, since we sorted out all sources I can think of (router, interfaces, Pi-hole).
Not 100% sure, but maybe Pi-hole even uses it's own internal resolver based on it's own settings and not /etc/resolv.conf anymore. They made lots of progress since/with FTLDNS implementation.
If that is the case you can still try the workaround above, removing resolvonf. Simply reinstall G_AGI resolvconf if any issues occur with Pi-hole or others.
Just note that on pihole -up most likely resolvconf will be reinstalled automatically.

About Lighttpd/PHP, okay, perhaps service internal and their logs in /var/log or systemctl -t php7.0-fpm/systemctl -t lighttpd might give a hint.
If you face the issue again, try to catch some logs and feel free to report here.

[maartenlangeveld]

Thanks!!

[maartenlangeveld]

Deleted resolvconf. Re-installing using G_AGI resolvconf does not bring back resolv.conf.

[MichaIng]

@maartenlangeveld
? Purging the resolvconf package should not even remove the /etc/resolv.conf file, only turn it from symlink to real file.

[maartenlangeveld]

Sorry, i got you wrong, my fault : I deleted resolv.conf. I have manually restored meanwhile.
Thanks a lot for your support!

[MichaIng]

@maartenlangeveld
Ah okay jep this file needs to stay in every case, resolvconf is just one packages that adjusts it dynamically, systemd-resolved e.g. can do this as well (systemd internet modern resolver).

[MichaIng]

@maartenlangeveld
Is this still an issue?

I just recognized that this was on v6.20. In some cases the v6.20 update failed, leading to DietPi settings not being boot persistent and in cases on boot the first run setup steps are done, which in combination with the above would lead to a reset of the network interfaces to pre-update state.

So generally please update to v6.21 in case before further investigating.
Another issue, possibly related to Lighttpd/PHP services not starting on boot. On v6.21 please try:

sed -i '/^After=/s/[[:blank:]]multi-user.target//' /etc/systemd/system/dietpi-postboot.service
systemctl daemon-reload

[MichaIng]

I mark this as closed. However feel free to reopen if the issue persists.

[alpha-tango-kilo]

Hi there,

I am also having this issue. I'm running DietPi v6.25.3 on my Raspberry Pi 3 Model B (armv7l), with Pi-hole installed, similar to maartenlangeveld.

I use Unbound as my DNS resolver for Pi-Hole, running on 127.0.0.1:5353, set up as per the official guide here. I know this to be working as it can be tested with dig pi-hole.net @127.0.0.1 -p 5353

However if I try and ping pi-hole.net I get ping: pi-hole.net: Temporary failure in name resolution The Pi's DNS is set to 127.0.0.1 in dietpi-config, and I was trying to change it to Cloudflare's as a debugging step and I experienced OP's issue. Not entirely sure how to move forward.

Edit: It's also worth nothing that I have the same disparity as OP between interfaces and resolv.conf. interfaces has the DNS I'm trying to switch to, resolv.conf has the DNS I'm trying to switch from and is showing in dietpi-config

Thanks for any help :)

[MichaIng]

@AtkLordOverAll
Made some test installs (two VMs, one Stretch, one Buster) and so far everything works:

root@VM-Buster:/var/log# dig pi-hole.net @127.0.0.1 -p 5353

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> pi-hole.net @127.0.0.1 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51013
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;pi-hole.net.                   IN      A

;; ANSWER SECTION:
pi-hole.net.            300     IN      A       206.189.252.21

;; Query time: 256 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Thu Jul 11 21:23:38 CEST 2019
;; MSG SIZE  rcvd: 56

Then after setting up Pi-hole to use unbound 127.0.0.1#5353 as upstream DNS, also Pi-hole resolves fine:

root@VM-Stretch:/var/log# dig pi-hole.net

; <<>> DiG 9.10.3-P4-Debian <<>> pi-hole.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18672
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;pi-hole.net.                   IN      A

;; ANSWER SECTION:
pi-hole.net.            300     IN      A       206.189.252.21

;; Query time: 10 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 11 19:29:33 UTC 2019
;; MSG SIZE  rcvd: 56

Unable to replicate issue. I followed the linked instructions precisely as well.

---

Ah just tested ping pi-hole.net and it seems that pi-hole.net blocks ICMP requests, so ping does not work. But this has nothing to do with the DNS resolving, which works fine as well:

root@VM-Stretch:/var/log# ping pi-hole.net
PING pi-hole.net (206.189.252.21) 56(84) bytes of data.
... # it just hangs here, but domain has been resolved as above

[alpha-tango-kilo]

You're an absolute saint for testing all of this, thank you! If I wanted to use Unbound as the Pi's (not Pi-hole's) DNS, that's okay if I put 127.0.0.1:5353 as the DNS IP, or should I use Cloudflare / something else? (On a working install this is, not my borked one)

Given it's not replicable I'll nuke the install and start fresh. Given all of the software I use comes from dietpi-software, it'll only take a few minutes. Thanks for making such a great OS and supporting everyone, you've got my donation :)

[MichaIng]

@AtkLordOverAll
Why would you want to use Unbound as the Pi's but not Pi-hole's DNS? This would mean that the Pi does not use Pi-hole, which is most probably not what you want? Also I am not sure if the pihole-FTL service somehow forces 127.0.0.1 (Pi-hole) as DNS nameserver entry, so if you even have any chance to bypass Pi-hole without being reverted on reboot/service restart and such.

So basically I would do the following to restart:

systemctl stop pihole-FTL
systemctl stop unbound
echo 'nameserver 8.8.8.8' > /etc/resolv.conf
curl -IL dietpi.com

• Check if name resolution works well with Google DNS.

systemctl start pihole-FTL
echo 'nameserver 127.0.0.1' > /etc/resolv.conf
# Configure Pi-hole to use e.g. Google DNS as upstream nameserver
curl -IL dietpi.com

• Check if Pi-hole works as nameserver with Google DNS.

systemctl start unbound
dig dietpi.com @127.0.0.1 -p 5353

• Okay can be skipped since you already did this.

And finally configure Pi-hole to use unbound by adding 127.0.0.1#5353 as the one and only upstream DNS. Note the hash char instead of usual colon to separate IP and port 😉.

If the last test fails, you might want to check the Pi-hole logs, although I would first disable pihole.log query log entries (obsolete, never required, just had discussion with Pi-hole dev about this):

pihole -l off
dig dietpi.com
tail /var/log/pihole-FTL.log
tail /var/log/pihole.log

[alpha-tango-kilo]

You make a fair point about me wanting to use Pi-hole's blocking on the Pi itself, my bad. Everything now works, thank you so much!

[MichaIng]

@AtkLordOverAll
Okay great. Whatever was the reason it did not work before, perhaps some typo or cache issue.