DietPi dig and resolv.conf strange issue

Troubleshooting
1

Greetings,

I have setup Pi Hole and Unbound DNS server, but have a strange issue with it - If I open dietpi-config and set DNS for its Ethernet device to 127.0.0.1:5335 (local unbound server) it doesn’t work. If i set it to, for example 1.1.1.1 - it works.


Now, if I use dig to resolve an domain to IP, it throws an error “dig: parse of /etc/resolv.conf failed”

If I remove/delete resolv.conf, dig command works again and server which gives response is the local unbound server…


I have another device with exact setup (Pi Hole + Unbound) and it works flawlessly. I tried to copy exact config from working device to the problematic one - no luck. It just won’t work as intended.

Definitely need help from an dietpi guru :frowning:

2

Please try to use a hash sign instead of a colon. For IPv6 support (where the IPs themselves contain colons) this is often used:

127.0.0.1#5335

EDIT: I’m shocked, it seems to be simply not supported by /etc/resolv.conf glibc. On other OSes (non-Linux) 127.0.0.1.5335 is a valid syntax to define a custom port but on Linux 53 is used forcefully. Interesting and disappointing, I didn’t know that as I always use an upstream DNS on servers.

3

Personally I don’t recommend to use this setup at all. It is not a good idea to use localhost as DNS server. Because what will happen if unbound, Pihole or AdGuard are failing? You will not be able to resolve DNS request locally anymore and would need to change DNS settings first, before you are able to probably reinstall thinks. Better to use a global upstream DNS.

4

Hey everybody!

First of all, I would like to thank you all for helpful advices and insights. Means a lot for a someone who’s trying to find his way through linux hell :smiley:

What I have done in meantime - in DietPi-Config utility I set DNS to 127.0.0.1 without port designation and… it worked. For some reason, it wasn’t working before but for some reason unbeknownst to me it decided to work this time.

I wasn’t very descriptive in my first post, but let me ammend it:

I have two SBC devices, NanoPi Neo Plus2 (Allwinner H5 CPU, 512MB RAM) and RPi 4 - 2GB RAM model.

NanoPi was set up more than a year ago and I used and abused it… and learned a lot. It serves me as DNS, SMB, qBitTorrent, WWW server… etc. and works flawlessly for a device with just 512MB of RAM. Its CPU, even it is capable of 1200 MHz, is locked to max 1000 MHz in DietPi (cannot find a way to enable higher speed). Current DietPi version 8.0.0 beta. I wasn’t able to update it to Bullseye successfully - even if I follow official guide - its somehow not to clear and descriptive to me as I haven’t be able to follow it. Thanks God for dietpi-backup :smiley:

Few days ago, I bought my first RPi 4 device to serve as DNS and UNIFI controller and, of course, installed DietPi, latest stable version, SSHd to both SBC devices and tried to replicate the setup. I thought I was successful as it seemed to be working - didn’t check local DNS resolution :smiley:

Anyway, its working now but it left me curious as I haven’t encountered such issue.
I’m planning to buy another RPi to replace my trustworthy NanoPi workhorse - its RAM size is way to small for anything serious, but will probably keep it running as a secondary DNS server.


Again, thank you all - looking forward to learn more from you.
I wish you a Happy New Year and the all very best.


EDIT: I was wrong - it’s still broken… Maybe I should downgrade DietPi to 10 buster and try to replicate the setup to see if the issue would be the same.

5

Just to post an update to the topic… Still broken. If I set 127.0.0.1 as a DNS server in dietpi-config it works but I lose dig and nslookup tools functionality so, I have to choose - to have these two functional or to use local DNS resolver.

If only there was no that other device where it works flawlessly I would accept that it’s just not possible, but…

I ordered another two RPi 4 - would try to tinker with setup variations and shed some light to this issue.

6

Still I don’t understand why you like to use 127.0.0.1 as DNS resolver on your DietPi device. There is literally no benefit.

The important setting is not in dietpi-config, it’s more the value inside /etc/resolv.conf

can you share following

cat /etc/resolv.conf
ping -c 1 -W 10 dietpi.com
ping -c 1 -W 10 -4 dietpi.com
dig @127.0.0.1 dietpi.com
dig dietpi.com
7

Sure, here you go:

root@KAR02SRV01:~# cat /etc/resolv.conf
nameserver 127.0.0.1:5335

root@KAR02SRV01:~# ping -c 1 -W 10 dietpi.com
PING dietpi.com (104.21.44.30) 56(84) bytes of data.
64 bytes from 104.21.44.30 (104.21.44.30): icmp_seq=1 ttl=57 time=21.9 ms

— dietpi.com ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 21.923/21.923/21.923/0.000 ms

root@KAR02SRV01:~# ping -c 1 -W 10 -4 dietpi.com
PING dietpi.com (172.67.194.85) 56(84) bytes of data.
64 bytes from 172.67.194.85 (172.67.194.85): icmp_seq=1 ttl=57 time=27.3 ms

root@KAR02SRV01:~# dig @127.0.0.1 dietpi.com
dig: parse of /etc/resolv.conf failed

root@KAR02SRV01:~# dig dietpi.com
dig: parse of /etc/resolv.conf failed
root@KAR02SRV01:~#


Now, here are the output of another SBC where it all works OK (I suppose):

root@karpidns:~# cat /etc/resolv.conf
nameserver 127.0.0.1:5335
nameserver 127.0.0.1

root@karpidns:~# ping -c 1 -W 10 dietpi.com
PING dietpi.com (172.67.194.85) 56(84) bytes of data.
64 bytes from 172.67.194.85 (172.67.194.85): icmp_seq=1 ttl=57 time=15.6 ms

— dietpi.com ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 15.556/15.556/15.556/0.000 ms

root@karpidns:~# ping -c 1 -W 10 -4 dietpi.com
PING dietpi.com (104.21.44.30) 56(84) bytes of data.
64 bytes from 104.21.44.30 (104.21.44.30): icmp_seq=1 ttl=57 time=15.0 ms

— dietpi.com ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 15.020/15.020/15.020/0.000 ms

root@karpidns:~# dig @127.0.0.1 dietpi.com

; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> @127.0.0.1 dietpi.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8183
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dietpi.com. IN A

;; ANSWER SECTION:
dietpi.com. 165 IN A 172.67.194.85
dietpi.com. 165 IN A 104.21.44.30

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 11 17:08:28 CET 2022
;; MSG SIZE rcvd: 71

root@karpidns:~# dig dietpi.com

; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> dietpi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62479
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dietpi.com. IN A

;; ANSWER SECTION:
dietpi.com. 127 IN A 104.21.44.30
dietpi.com. 127 IN A 172.67.194.85

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 11 17:09:06 CET 2022
;; MSG SIZE rcvd: 71

8

as you can see there is a difference on both /etc/resolv.conf files.

KAR02SRV01

nameserver 127.0.0.1:5335

karpidns

nameserver 127.0.0.1:5335
nameserver 127.0.0.1

on the first device remove entry nameserver 127.0.0.1:5335 and replace it by nameserver 127.0.0.1

This is exactly what MichaIng explained above https://dietpi.com/forum/t/dietpi-dig-and-resolv-conf-strange-issue/6144/2
Using :5335 will not work on /etc/resolv.conf

9

And I did that too (prior making my first post here) :thinking:
I presumed that something could be messed up if port was defined in dietpi-config (thus resolv.conf) but that produced the very same error/issue with resolv.conf and dig/nslookup tools.

Simply put, if I put 127.0.0.1 (in any form, with or without port designation) in dietpi-config or manually in resolv.conf - it doesn’t work and dig/nslookup goes haywire…

Looks like system (KAR02SRV01) won’t accept 127.0.0.1 as DNS server.

…but another one (KARPIDNS) has no such issues - 127.0.0.1 works just fine.

10

Remove /etc/resolv.conf and create a new one with a single entry nameserver 127.0.0.1. Reboot your system. What does dig return once system has been booted.

11

This is tangential to your problem but are you aware that all of the 127.0.0.0/24 subnet is loopback? There is a pattern to have local DNS resolvers listen only on 127.0.0.53:53 and any required public addresses, which can help avoid conflicts with other resolving services (docker etc). Take a look at Ubuntu 20+.

This would mean you won’t have to use a higher port for local DNS resolution.

12

Going to close this topic as it is 2 years old.