Alright, after a few weeks there´s only one thing freaking me out: from time to time the router mixes up the MAC-to-IP-binding for the system running pi-hole and other web services. I need to edit the static IP in the router (FritzBox) config and need to restart the pi (only restarting networking service or anything like that doesn´t work). I think it´s a FritzBox bug, unable to manage two IPs for one MAC address. It´s like a "race condition", and sometimes the wrong IP address wins... 
Try the "arp" command.
My router allows telnet so I can check ARP on Pi as well as router.
Ohw Ps, I managed to have the relevant Pi-Hole daemons running on the aliased interface instead of the physical:
My router doesn´t, so ARP is a one-side tool
I installed pi-hole exactly like in the link described, only on eth0:0 instead of wifi interface.
Thats bummer.
But is it this simple to enable the Fritzbox telnet daemon ?
https://www.fritzmod.net/modification/telnet/
It says you have to connect phone and dial the numbers 
#96*7* Telnet einschalten
#96*8* Telnet ausschalten
Was thinking, if get in, and things go wrong again, below one will clear ARP so router and/or Pi need to rediscover MAC (try instead of reboot etc):
ip -s -s neigh flush all
Might need sudo.
UPDATE: Don´t read until the "UPDATE" section at the end, just ignore it...
It´s really strange. This time, the problem is slightly different:
After adding "sunmaker.com" and "www.sunmaker.com" to the blocking list (at least that´s the only trigger imaginable for me, because there´s no router involved this time), on a Windows machine a "nslookup piholeandwebservername" gave me:
Server: sunmaker.com
Address: 192.168.0.9"
*** piholeandwebservername hasn´t been found by sunmaker.com: Non-existent domain.
So i did a "ipconfig /flushdns" and again nslookuped to the piholeandwebservername while tailing the pihole.log. That log told me:
dnsmasq[10323]: /etc/pihole/local.list 192.168.0.9 is piholeandwebservername
local.list content:
192.168.0.9 piholeandwebservername
192.168.0.9 pi.hole
So, QUIZ QUESTIONS:
1) Why the hell is local.list using 192.168.0.9 (and not 192.168.0.15 as it should) for the piholeandwebservername?!?
2) What triggers the creation of local.list content?
Instant workaround (editing local.list manually) didn´t help.
UPDATE:
Forget everything above. A closer look to tail pihole.log pointed out that pi.hole forwarded the DNS request to the router... which - again - told pi.hole that piholeandwebservername is 192.168.0.9 instead of 192.168.0.15...
So once again: no telnet or ssh or ANY other baseline access to the router. AVM killed the enabling/disabling using phone code in it´s firmware around 2015.
Update:
More debugging pointed out:
- Using FQDN is very important. "nslookup piholeandwebservername" is NOT the same like "nslookup piholeandwebservername.fritz.box"
- Specifing the DNS server helped a bit:
nslookup piholeandwebservername pi.hole
gave 192.168.0.9 --> WRONG (because pi.hole forwards the request to fritz.box)
nslookup piholeandwebservername fritz.box
gave 192.168.0.9 --> WRONG
nslookup piholeandwebservername.fritz.box pi.hole
gave 192.168.0.9 --> WRONG, BUT there´s a workaround:
a) Pi: nano /etc/pihole/local.list
b) Pi: Adding line "192.168.0.15 piholeandwebservername.fritz.box"
c) Pi: pihole restartdns
d) Windows endpoint: "ipconfig /flushdns" and now...
nslookup piholeandwebservername fritz.box fritz.box
still gives 192.168.0.9 --> WRONG, but:
nslookup piholeandwebservername.fritz.box pi.hole
now gives 192.168.0.15 --> RIGHT, because pi.hole uses the new line of local.list.
So finally: Not a nice workaround (especially because i still don´t know the root cause (what´s going on in the router/fritz.box?!?)), but at least it avoids rebooting the pi.
pihole -r
As described in the concept howto:
Basically that´s what I did (weeks ago already). The wrong IP for the webserver name comes from FritzBox als already mentioned.
Meanwhile I made my workaround (editing /etc/pihole/local.list) permanent with a "sudo chattr +i /etc/pihole/local.list" so it can´t be updated with wrong values, not even by root.
Will be excited to see what happens on the next pihole (core) update - just in case the setup/update routine tries to write the local.list.
But at the moment I´m quite happy with this "solution" and it seems I need to live with that because the router doesn´t properly handle the two IPs for my webserver/pihole machine.
The local.list file is written every time you run gravity, so it probably will work fine with the update.
A post was split to a new topic: Conflict with other port 80 services