sorry, but how can the router solve mydomain.ddns.net if I don’t tell him someway how to translate it? At the moment I tell to pi-hole how to do it and in the no-ip account there is no way to indicate where it should point to.
The DDNS service, which is running on your router (or your Raspberry Pi or wherever you run it), detects your public IP and detects when your public IP is changing and transmits it to the no-ip servers, which transmits it to the worldwide DNS root servers. Or maybe it goes straight to the DNS root servers, IDK, but the point is, it’s deposited there somehow.
When you now try to reach yourDDNS.com, your machine from where you call this domain asks the DNS servers, which you had configured on your machine (in your case it makes a request to your PiHole).
And in your piHole config you have set some DNS upstreams servers like google or cloudflare or quad9 or maybe you even run your own DNS server like unbound.
But no matter which way you go, they all get the IP for your requested domain call from a database which has the same data as the DNS root servers.
So every internet user which tries to reach your DDNS domain is forwarded to your public IP. It works like for every other domain on the internet, the only difference is, that you run a webservice on a non-static IP.
If you had a static IP, you could just register a domain, point it to your IP and you don’t have to care about it anymore. No need for DDNS.
This is how DNS works, kinda 
I have some more addition, because you talked about that you have to “tell” PiHole about your DDNS.
When you make a custom DNS entry in PiHole, for example from yourDDNS.net to the local IP of your webservice device, your DNS call get’s “intercepted” from your PiHole.
like: jappevpn.ddns.net → 192.168.111.66
Normaly the route would be (without extra entry in Pihole, when you call from inside your LAN):
Your machine → Pihole → DNS upstream server you configured in Pihole
This DNS server now returns own your public IP back to you and you make a route from your machine to the internet back to your own network.
If you make an entry for this in PiHole like mentioned above, the route is just:
Your machine → Pihole
because PiHole has now an entry for this domain in its database: the local IP of your webservice device.
So you “save” some unnecessary route trough the internet.
Some routers (I know it from FritzBox) prevent to point a Domain to a local IP (keyword DNS-rebinding) and you have to “whitelist” your DDNS-domain in your router.
Thanks Jappe for the detailed informations.
Let me recap with my words to see if I understood well how it works.
In a normal use of a raspberry with dietpi intalled, if I would reach the pi from outside my network, I should have a ddns domain. This is true if I have a router which is able to configure a ddns domain (which has to be declared somehow from me in advance in it). Is this true?
what if in my router there is no such function? In this case I should tell dietpi: “ ehi there! Keep in mind if someone call my domain.ddns.net you should open this page that is stored in the pi”. Am I wrong?
If your router can’t handle DDNS, you just can use dietpi-ddns. My router could do it but I don’t use it, I use the ddns-service of DietPi and it works just fine.
No, that’s not how it works.
TLDR:
When you use a DDNS service, your public IP and your domain is stored on the DNS root name servers, which you contact automatically with every request you make.
Long answer:
Your domain is just a “better name” for your public IP. It would be a pain in the ass to remember all of these IPs of the websites you want to visit. Domain names are easy to remember, (like google.com) but a (in worst case) 12-digit-number is not (like 172.217.1.206).
In the end you don’t need a domain, if you are the only one who is using your services and your IP doesn’t change (often).
You could just type in your public IP into your browser.
When I request your domain, I have no idea what your public IP is. So my device needs to look up your public IP somewhere. Just the domain is not enough. The average user don’t fiddle with their network settings, so they use automatically the DNS servers set by their ISP (often pre-configured in the router, which you got by your ISP).
But other people use Quad9 (default of DietPi, I guess) or Cloudflare or some other DNS service or people like me even run their own DNS resolver.
But what they all have in common is, that they grab their data (which IP belongs to which domain) from a central DNS server network, where every domain from the internet and their associated IPs are stored. When you use a DDNS service, your public IP and your domain is stored there too.
So when you use a DDNS service, this service checks periodically your public IP and transmits it to this central DNS network. You don’t have to configure anything in PiHole, the only thing you have to do for this is to config you DDNS-service.
When I now request your domain, my machine first contacts my own DNS server. When I have no IP for your domain in there, it requests the central DNS network. My machine gets now your public IP from there and then my browser uses this IP to make contact to your machine.
So you see, in “real” you make two requests: the first one to find out the IP for the domain and then the “actual” call to contact this IP.
And now the special case:
When you now call your own domain from your own network, where your device is running in, it would be a unnecessary rundabout way to contact the central DNS servers, which will send you your own public IP and then you make a connection from your LAN into the internet back to your public IP.
Then it comes in handy to make a DNS entry in Pihole: You link your domain with the LOCAL IP of your device, so you don’t have to leave your LAN. Your browser then makes a request to PiHole, and PiHole has an entry for your domain and gives back the LAN IP of the device and not your public IP, like the central DNS name servers would do.
IRL it’s a bit more complicated, see the image below 
The most DNS resolvers have huge databases withall this info stored in, so you don’t have to contact all these servers (Step 3 to 6), which saves some time and your request is faster. This is called DNS-caching or cached DNS. The disadvantage of this is, that it needs some time (in exceptional cases up to 48 hours) until these caches know “new” domains and IPs (for example when you setup your DDNS service). But most of the time it’s just a matter of minutes.
Imagine between step 2 and 3 sits your Pihole. When your pihole has an entry for the requested domain, it goes straight to step 7. if not, it goes to step 3. (This is only valid when you call your domain from inside your network)
When I call your domain, or every other person, we all have to contact the DNS root name servers, to get your IP.
So when you call for example http://jappevpn.ddns.net, in the background your browser contacts the DNS root name servers, grabs the associated public IP and then calls this public IP on port 80 (2.203.96.132:80, because http means to request on port 80, for example https would be port 443, ftp would be port 21 etc.).
My router receives then a request on port 80. I configured some port forwading in my router, requests on port 80 are forwarded to my RaspberryPi 4 (192.168.XXX.XXX) also to port 80. On my RapsberryPi runs a webserver (Lighttpd), which is also listening on port 80 and serves you then the website, which your browser shows you.
Offtopic:
The next logical question is: How the heck know the machines the route, when they got the public IP to a server? 
I guess this is all done by big routing tables and some algorithms?
But back to topic now 
again thank you for the really well done networking guide
OK looking at my dietpi-ddns, looks like I’ve already done this:
Provider : [No-IP] │
│ Domains : [mydomain.ddns.net] │
│ Username : [myemail@gmail.com] │
│ Password : [************] │
│ Timespan : [10 minutes]
And reading what you wrote this is fine, but my question is: what happens if the dietpi is down and I’m using just this setting? I guess I can’t reach just mydomain.ddns.net, but all the other devices (such as a security camera) can be reached. Isn’t it?
I understand this, in my case the DNS root name server is No-ip. Is this correct?
Now, back to my pi-hole situation.
I don’t remember why (I’m quite sure there is a why ) When I was trying to reach the domain from my own network (with the old router), with the community we workaround in this way:
see this post [Solved]How to connect outside of dietpi network - #50 by Joulinar and this one [Solved]How to connect outside of dietpi network - #57 by Joulinar
This situation sounds good because, I think, this speeds up the internal connection. But, what if dietpi is down? does this mean all the devices connected to the router are unreachable?
So the final question now is: How can I check if going back to the easiest situation (i.e. just dietpi-ddns) without using pi-hole as a “DNS Resolver”, will work?
Siome last informations about my actual router that can, maybe, help:
In the configuration, I can see and change if every single device has DHCP or dedicated IP; I have a remote control panel where I can activate “HTTP: 8080 and HTTPS: 8181” to a single device, or range of IP’s addresses or to all the devices; I have a “port triggering” for which I ignore the function; I have a DMZ which is actually active and settled on the Dietpi address; I also have set (as suggested) the DHCP interval with a single IP address, the Dietpi ones.
It should be only a problem when your IP changes while your DietPi is offline, because then the new IP can’t be announced to no-ip.com
Your old public IP is still stored there and your Domain still points to it, no matter if your Dietpi is reachable or not.
And yes, your IP gets transmitted to the name servers of no-ip.com and is requested from there.
If your DietPi acts as your DHPC server then your devices shouldn be reachable, if you establish your network connection when Dietpi is not running. When you establish the connection and then turn off your DietPi you should be fine, because then your devices already got an IP adress assigned.
A walkaround for this would be to assign your devices static IPs, so they don’t need to get one assigned from your DHCP server.
And you could deactive Pihole and let your router do the DNS resolving and everything should be fine.
And for your last question:
I don’t think a DMZ is necessary and could also make problems, but I don’t know much about using DMZ.
I don’t understand the thing with the DHCP interval, because I thought DietPi now handles your DHCP? So DHCP should be deactivated in your router.
If you shut down your DietPi regularly, the easiest solution would be to let your router handle DNS and DHCP, because it’s always online and reachable.
I guess the whole confusion is coming from the fact that the original Vodafone router was not able to handle traffic inside the network correctly. Means ghezzia was not able to reach Owncloud from inside the network using DDNS name. Therefore we created the ugly workaround to use PiHole to exclude the Vodafone router from DNS resolution and traffic routing. This way, PiHole was returning a local IP (custom DNS entry) instead of the global WAN IP. Means no routing on the Vodafone router needed as the access would be local only. Furthermore it was needed to setup DHCP on PiHole to allow all LAN clients to get correct DNS server assignment. Unfortunately again a missing feature on the Vodafone router to allow custom DNS settings. Even more worse, it was not possible to disable DHCP server functionality completely on the Vodafone router. The workaround we found (on internet) was to reduce DHCP range on the Vodafone router down to a singel IP address. The one PiHole server is using.
Now, with the new router, you could try the original setup again. Usually having the router acting as DNS/DHCP server is quite a common scenario and the router should be able to handle the request correctly.
How to deal with your NoIP address update is a different topic and should be excluded for now. Usually modern router support setting DDNS.
I told there was a why
Ok looking at this post [Solved]How to connect outside of dietpi network - #50 by Joulinar to test it, is it enough I disable the DHCP in pi-hole and re-open the range from .2 to .254 in my router?
I asked just because I’m wondering if this can disable something in the network
It depends on the IP of your router, it shouldn’t be in the DHCP range. So your routers IP has to be .1, when your DHCP range is .2 to .254.
And all of the IPs of your devices may change, so don’t wonder if you can’t connect via the “old” IPs, e.g. when you use SSH or similiar stuff.
If you assigned some static IPs to some devices, they also shouldn’t be in the DHCP range.
I confirm my router is 192.168.1.1 so the range .2 to .254 is the right one
This is not clear to me. My dietpi is 192.168.1.15. should I move it out of the .2 . 254 range?
Of course it makes sense to apply the previous reserved or static IPs on the router again for the same devices (if it can set reserved IPs via DHCP).
It btw depends on the router whether it has issues with static IPs in the DHCP range. In my case, I use mostly static IPs, but additionally apply them as reserved IPs in the router. This works very well so that the router does not assign those IPs to any other device but would assign it to the intended device, if I switch it from static IP back to DHCP, also e.g. when setting up a fresh OS on it or so.
easiest would be
- give STATIC IP .15 to PiHole device
- disable DHCP within PiHole interface
- set DHCP range on router .20-.200
- ensure port forwarding 80/443 is still pointing to your DietPi device
- restart a compute inside your network that you like to use for testing to assign new DHCP/DNS settings
- check if your can access your private cloud from inside the network using DDNS name
I followed the steps indicated but a strange thing (do you remember I’m the strange things man ) happens.
From inside my network, I can reach the Dietpi through SSH (using mydomain.ddns.net) but, through the browser, I can’t reach either owncloud or pi-hole because it says it’s taking too long to connect to the site… If I’m outside my network looks like it works.
can you try to reach owncloud by using your external IP like
https://<external.ip>/owncloud
So it’s reachable on port 22 (SSH) but not on 80/443 for HTTP/HTTPS… which sounds like a problem with your webserver.
Is lighttpd running?
What happens if you try to reach owncloud from inside your network via the local IP of DietPi?
if he could reach it from external, Webserver seems to be running fine.
Oh yes, I didn’t read right, again 
I’m sorry but I don’t understand how to try this. If you mean to reach the owncloud using mydomain.ddns.net/owncloud, it works if I’m outside my network but it doesn’t if I’m in.
What is the external IP?
It’s your public IP, where your domain points to.
You can look it up in your router, normally, or use some service like https://ifconfig.me/ to see it.