I don’t think, that this is the problem, because installation with static IP works fine, the same DNS Server and IPv6 deactivated. It is just an issue with DHCP and deactivated IPv6.
Ok than the DNS server assigned by DHCP is maybe the problem?
But presumptions doesn’t help here 
It is the same… I strictly use my dnsmasq-Server for static and dhcp configuration.
But does the behaviour change when you change the upstream DNS?
After testing different things, i am thinking that AdGuard is to slow for dietpi. I also found an issue on github (https://github.com/hassio-addons/addon-adguard-home/issues/259).
Seems to be working with the hints (https://github.com/hassio-addons/addon-adguard-home/issues/259#issuecomment-943293683).
Maybe PiHole is the better alternative or i have to use filters in dnsmasq.
or for testing, use a global upstream DNS provider. Just to exclude local network components.
Probably PiHole is a good alternative for you as it is based on dnsmasq as well. This might allow to combine 2 software solutions on your network. As well it’s giving way more flexibility if you like to customize dnsmasq/DNS/DHCP functionalities.
I had PiHole before. AdGuard has some nice advantages, but i have another user with the same problem. He uses PiHole. Maybe he will write to this post later…
Just since you said you disabled IPv6 via “dietpi.txt”. Note that on a DietPi with finished first run setup you need to disable it via dietpi-config > Network Options: Adapters instead. The dietpi.txt setting is only a flag for autosetup during first boot.
To verify whether IPv4 and IPv6 are both using the intended local DNS you could use a blocked hostname and run:
ping -4 <blocked.hostname>
ping -6 <blocked.hostname>
which should then both be blocked (unable to resolve).
A shame that GitHub hostnames are so often found on public blocklists. I even found it on one which itself was hosted on GitHub. Complete nonsense. I guess blocklist maintainers use some algorithms to update those, and if e.g. some ad or tracker is pulling anything from GitHub, it is added to the blocklist automatically. I cannot think of any other explanation 
.
Hi,
as one of the testers for the mupibox project I phase similar issues, but different context.
Environment is Router with pihole and Fritz Mesh repeaters (but on LAN connection as AP) with Raspberry 2b and 4B.
4B with internal Wifi or Trust WLAN stick
Installation is a jeopardy with DHCP lease / DNS resolving. Did several runs with pihole activated/deactivated, static ip and 9.9.9.9 as DNS server in dietpi.txt, DNS Server in Fritzbox, IPv6 enabled/disabled in dietpi.txt.
Most times during installation after a reboot it cannot resolve the hostname anymore, in some (rarer cases) it even did not get a DHCP lease.
THere is only one DHCP Server in the Router, no others, no subnets.
Only thing i could imagine is that the Fritz repeaters have an influence, but other setups work.
You are failing to ping Cloudflare global DNS servers 1.1.1.1 (network connectivity check). At least it indicates a working WiFi + DHCP IP address assignment. We had some challenges with Cloudflare way back and changed somewhere around 2020/21 to Quad9 DNS 9.9.9.9. But this was an issue in some specific parts of the world only and should be working from Germany without issues. Anyway you could try to change network connectivity check to some other IP/DNS name based on your preferences.
1.1.1.1 also causes issues with some older router models which used that IP internally for their APIs, while it was never officially part of private/LAN IP ranges.