Hi, I downloaded the most recent image of Dietpi for Raspberry Pi and was getting a DNS Resolver Check error. It turns out the script was trying to reach one.one.one.one. I’m not sure if this is intentional, but it prevents the first run of a new install to fail. I changed this to 1.1.1.1 in dietpi.txt and now it works fine. Just thought I’d post this to save others time trying to debug.
Hi pls can you specify which image you used? Because I did a fresh installation of my RPi4B yesterday evening without any issues. 
Hammer
The https://one.one.one.one domain should be accessible world-wide. It is a relatively new top-level domain indeed, from 2015: https://en.wikipedia.org/wiki/.one_(domain)
But since it is used by/for Cloudflare itself (DNS provider with most servers world-wide), it should be resolved by any DNS server. If it is not resolved, then it makes sense to change/check the own DNS server to assure it does not use some very outdated cache or such.
Btw changing the DNS test domain to an IP breaks the purpose to test DNS resolving of course. If indeed one.one.one.one does not work for any strange reason, e.g. ISP blocks that top-level domain or such, then it’s better to change it to e.g. google.com or some other well-known domain, but not an IP.
Thanks. Your explanation is very helpful in helping me understand the issue. On another PC on the same network and same DNS server: 192.168.1.1, I can ping one.one.one.one. However, on the Dietpi Pi, I cannot. In fact, I can’t seem to ping anything including www.google.com from the Dietpi machine, having said that, everything else seems to work. Eg, when I select Dietpi-Update, it works can tells me my version is 6.28 and the most recent version is 6.28. In fact, I was able to update the image version to 6.28. So internet works.
When I do a cat /etc/resolv.conf on the Pi, it says:
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 192.168.1.1
search localdomain
So, I think it is using the same DNS server as the other PC? Again, this is a fresh install of Dietpi on the Pi.
Any idea what can be wrong? Thanks!
Hi,
pls can you try running the 2 following commands
ping -c 1 one.one.one.one
ping -4 -c 1 one.one.one.one
probably as well an option and to avoid any corruption on the image, can you pls download a new one and flash it to your SD card
https://dietpi.com/downloads/images/
This should deliver v6.25 and on first boot you should be updated to v6.28
Thank you…I tried re-imaging the SD and reinstalling, but still the same issue. However, from the two ping commands you suggested:
ping -c 1 one.one.one.one results in an error: Destination unreachable: No route
However, ping -4 -c 1 one.one.one.one works fine.
What is the difference between the two?
It’s very strange since the pi definitely has internet access given it’s able to upgrade itself from 6.25 to 6.28. It’s just the ping (as far as I can tell) that does not work. Additionally, if I change dietpi.txt from one.one.one.one to 1.1.1.1 so that it passes the resolve test and the setup completes, when I go to dietpi-software, I’m able to install software from the menu system. I’m using pfsense as my router. Is there a known compatibility issue? As I mentioned, I can ping from the other pc’s on my network.
Thank you!
Hi
basically the 2 commands are doing the same. They are going to ping Cloudflares DNS Server. It is the globally available hostname for Cloudflares 1.1.1.1 DNS resolver:
The only difference is, that on the 2nd command you will force IPv4 connection.
In meantime we have seen some messages about having issues to ping one.one.one.one. It seems that in some cases ping is trying to connect to the IPv6 address even if there is no IPv6 connection available. In such cases the connection test fails.
ping -c 1 one.one.one.one > simple connection test
ping -4 -c 1 one.one.one.one > force connection via IPv4
So I guess you don’t have IPv6 configured in your local Network. You could go to “dietpi-config” network settings and disable IPv6 competently (set to OFF) if this is the case. Usually this should fix the issue as well.
if I change dietpi.txt from one.one.one.one to 1.1.1.1 so that it passes the resolve test and the setup completes
Yep that’s working because you are going to bypass the DNS test completely as you don’t go to resolve something 
It would be better to change to something like google.com or some other global domain.
Thank you. Yes, i think that is the issue, I don’t have ipv6 on my LAN. Unfortunately, since this is the first run / install of dietpi, there is no way to reach the config menu to disable ipv6.
not fully true 
It can be disabled before initial boot. Once you have flashed your SD card, just put it back to your desktop computer. You should have mounted an additional drive called boot. There your have the config files and you could adjust settings that will be applied initially. Locate the file called dietpi.txt and open it with a text editor and search for the following line:
# IPv6
CONFIG_ENABLE_IPV6=0
putting it to 0 will disable IPv6. Hope it will fix your issue. If not you could adjust DNS domain check on your needs.
# - Domain to ping when checking DNS resolver. Default: one.one.one.one (Cloudflare DNS domain, see above)
CONFIG_CHECK_DNS_DOMAIN=one.one.one.one
Joulinar already debugged it greatly. Hammer Indeed what is missing in such cases is a button to disable IPv6 right from the error prompt, if DNS resolving fails.
I added some generic information about how to achieve this until then to our “Getting started” thread:
Due to current reports: If “Checking DNS resolver” fails, this is most likely due to your system or local network setup does not support IPv6 and you did not disable it via > dietpi.txt> . Please try the following steps:
- Hit > Exit> , in case of a second prompt, hit > Cancel> .
- Run the following command: > /DietPi/dietpi/func/dietpi-set_hardware enableipv6 0
- Run the following command: > /DietPi/dietpi/dietpi-login
The DNS resolving should now succeed.
Actually the local network does not need to have IPv6 enabled, e.g. no DHCPv6 or even ULAs (Unique Local Addresses) need to be assigned. As long as the device is able to assign itself an IPv6 address via SLAAC. This is e.g. true for my RPi production server, while I have IPv6 completely disabled router/network-wise. However I observe the same IPv6 connection issue you faced on my (testing) VMs, running on the notebook. They are connected via bridged network through the WiFi connection of the notebook to the router, and even if they auto-configure their virtual network adapters with an IPv6 address, they hang on any IPv6 name resolving. I am not sure in which circumstances, but there are obviously rare cases, where IPv6 needs to be disabled system-wide to not run into those issues. It is actually a good thing that this is recognised directly on first run setup DNS resolver test, otherwise it would lead to follow-up errors, then hard to debug. Error handler rework, to allow disabling IPv6 on-the-fly for DNS resolver test, will come with DietPi v6.29, until then the “Getting started” addition hopefully enables others to solve this rare issue.
Thank you. This might belong to different thread, but I have tried to google it extensively…when I flash the image using etcher on a Windows 10 PC, I don’t see the “boot” drive in order for me to edit dietpi.txt. It’s not mounted and I can’t see to get it mounted. Is there some trick to it? Thanks again for everyone’s help.
Once etcher finished, remove the SD card, wait a second and put it back to your computer. Windows should now mount the SD card again. At least it’s doing it for me.
Thank you again…I was able to mount the SD in Windows. My issue was a drive letter was not assigned to the SD. Works great now!
My issue was a drive letter was not assigned to the SD
Yes that was my assumption as well but good that it is working now.
I had the same issue with a fresh install today of v6.31.2 on a RPi 2B
I solved it by disabling IPv6 from the network config.
yep indeed, disabling IPv6 is best practice if you encounter connection issues during initial setup
A pain that IPv6 is still so weakly implemented even on ISP/route basis.
dietpi.com hangs on outgoing IPv6 connections often, sometimes outgoing mails time out because of this (if I interpret the logs correctly) . Not sure if its related, but do you guys receive longer hang when posting something here after a longer time, then quick response on next posts within minutes? For outgoing connections it’s like that, hang first, quick for a minutes time frame after route had established once. Probably we have to disable IPv6 (like it was a year ago) but somehow I hate it for a modern server. This would only affect Cloudflare <> dietpi.com not you <> Cloudflare, so even IPv6-only clients can still connect.
It’s a little bit off-topic but yes, I have same experience on dietpi forum. Quite often it’s hanging on posting something while editing same post a minute later is working fine. As well I’m missing quite some emails about new forum post or replies.
Okay I removed the AAAA (IPv6) record and IP address, lets see if this solves the issue. Especially missing mails is a real problem!
ok will keep you posted.