Just to follow up: I have switched DNS provider from Pi-Hole (on my old server) to the DietPi AdGuard Home (put into production yesterday as a replacement for my old server).
Issue is now gone, so in my case it was the pihole service on the other server that had gotten way to slow over time.
@Ruud but this should not have any influence in the issue of @cc13 because he use global upstream DNS provider inside DietPi local network settings. While using PiHole would resolve the issue for @cc13 
This morning I took a RPi Zero W and installed DietPi (ARMv6-Bullseye) on it. In the beginning it looked good. Installation run and when I switched between dietpi and root user no issue with curl popped up.
Next I installed my needed software on this Zero W:
Docker, Docker-Compose, Git, PHP (all with dietpi-software). When I tried to setup portainer with my docker-compose.yml file (I used an existing/working backup file) I run in:
root@ZeroW:/mnt/dietpi_userdata/docker-data/containers/portainer# docker-compose up -d
[+] Running 0/1
⠇ portainerservice Pulling 5.2s
no matching manifest for linux/arm/v6 in the manifest list entries
When I now switch between dietpi and root user I see the curl error message again. No other software/container is installed on this Zero W. And here a few commands to test on this Zero W:
root@ZeroW:/mnt/dietpi_userdata/docker-data/containers/portainer# time wget --spider dietpi.com
Spider-Modus eingeschaltet. Es wird geprüft, ob die Datei auf dem Server existiert.
--2023-02-05 13:14:35-- http://dietpi.com/
Auflösen des Hostnamens dietpi.com (dietpi.com)… 2606:4700:3032::ac43:aadb, 2606:4700:3030::6815:1c8d, 104.21.28.141, ...
Verbindungsaufbau zu dietpi.com (dietpi.com)|2606:4700:3032::ac43:aadb|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 301 Moved Permanently
Platz: https://dietpi.com/ [folgend]
Spider-Modus eingeschaltet. Es wird geprüft, ob die Datei auf dem Server existiert.
--2023-02-05 13:14:40-- https://dietpi.com/
Verbindungsaufbau zu dietpi.com (dietpi.com)|2606:4700:3032::ac43:aadb|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: nicht spezifiziert [text/html]
Datei auf dem Server existiert und könnte weitere Verweise enthalten,
aber Rekursion ist abgeschaltet -- kein Download.
real 0m5,627s
user 0m0,275s
sys 0m0,061s
root@ZeroW:/mnt/dietpi_userdata/docker-data/containers/portainer# time wget --spider -T 3 dietpi.com
URL transformed to HTTPS due to an HSTS policy
Spider-Modus eingeschaltet. Es wird geprüft, ob die Datei auf dem Server existiert.
--2023-02-05 13:14:51-- https://dietpi.com/
Auflösen des Hostnamens dietpi.com (dietpi.com)… fehlgeschlagen: Die Wartezeit für die Verbindung ist abgelaufen.
wget: Host-Adresse »dietpi.com« kann nicht aufgelöst werden
real 0m3,307s
user 0m0,233s
sys 0m0,052s
root@ZeroW:/mnt/dietpi_userdata/docker-data/containers/portainer# time curl -I -m 3 dietpi.com
curl: (28) Resolving timed out after 3000 milliseconds
real 0m5,190s
user 0m0,083s
sys 0m0,067s
Could there be an issue with my internet provider/connection? But I cannot imagine that because if I try the same 3 commands on my linux laptop in the same network all responses are faster (less then 1 second).
Edit: And I get the same error message when I try to get Portainer installed via dietpi-software.
I guess you Linux laptop is PiHole as local DNS server? You would need to test with same settings on all systems.
Theoretically you could create a local hotspot on your mobile device, connect one of your RPi using WiFi and check how it behave.
Your are right, the laptop is using pi-hole as DNS server.
I connected the ZeroW via Hotspot with my smartphone. The curl error message is not showing but docker can’t load the portainer image (that could be a different issue…). Next step is to replace pihole with adguard.
What should change on this? If you are using a global upstream DNS, PiHole as well as AGH should not have any influence. Isn’t it?
Anyway, what you could try as well is to use our DietPi implementation of PiHole and not to use Docker container.
Good question… I try to do all what comes to my mind to find the reason for this issue.
Ok, then I will go with DietPi implementation of PiHole on a fresh installed system.
One more question. What upstream DNS server has been set in your FritzBox internet connection settings?
In “Internet / Zugangsdaten” is set:
Vom Internetanbieter zugewiesene DNSv4-Server verwenden (empfohlen)
And in Homenetwork - Networksettings - IPV4 Settings - below DHCP Settings - local DNS Server: IP-Address of RPi Pihole.
Short Update: New setup of RPi with fresh DietPi and with the first login I see the curl error message again.
Which DNS server is this test device using? Can you switch for this test device to STATIC IP and use your Fritzbox as upstream DNS server?
root@RPi3:/home/dietpi# cat /etc/resolv.conf
nameserver 9.9.9.9
nameserver 149.112.112.112
The device is using STATIC IP in all my tests and in my “prod” environment to. I use DHCP only for “normal” clients like laptops. Now I will setup the Fritzbox IP as DNS server on this device. In resolve.conf you mean?
With Fritz IP (192.168.0.1) in resolv.conv the curl error message is gone.
And error was gone if you connect to your mobile phone hotspot right?
Yes, no curl Error Message with using the Hotspot.
hope you are not getting me wrong, but somehow the issue seems to be related to your ISP or some other local network configuration. 
No,all good.
I had DietPi running for a while with this Hardware and ISP. End of this week I can test the Hardware with another ISP. Hopefully with new Insights.
Interesting/mysterious indeed. Since dig works fine, using the very same upstream DNS providers, I’m not sure whether an ISP issue can be the explanation.
I’m more thinking about an issue with some depth of Raspbian system files/libraries used by curl and wget for their DNS resolution. And since my Raspberry Pi Zero W does not have this issue (and a few thousand others neither), it would then only occur with some very specific network behaviour/setup.
Could some tcpdump be helpful to which packets are going where/coming from where when doing the curl/wget commands?
but why is it working while using a mobile phone hotspot? Maybe interface related? Ethernet vs. WiFI?
At least it is also a different network, not only a different ISP. Sadly the RPi Zero has no Ethernet, so a USB Ethernet adapter is the only option to test this.