You should have answered just:
"Thank you for your answer", instead of complaining.
1 Like
Hi Butter,
I also had a little struggle with old unused DHCP entries in my Fritzbox which I could delete but 5 minutes later they were back again.
In the end I did
- saved the settings & phone books
- factory reset of the router
- restore the settings
Now all's fine. The box went through so many updates and betas that I'm not surprised to see some crab in there.
Try it. It only takes you 20 minutes.
I found that behaviour to not be consistent over time.
I've seen different order responses sporadically on dis- and reconnects of devices, change of DHCP settings or router reboots.
My decision to name the clients that I want to see in Pi-hole with a specific label was made after a FritzOS update that prompted different sorted DNS replies over all my devices.
That's something you should peeve your router's manufacturer about.
It doesn't, as explained:
You could pester MS why their nslookup only displays one name.
And you could knock about that Photosync software's 's dodgy use of mDNS, and approach Shelly about those funny internationalised names their devices pick for themselves.
Well, if it's just a minority - I have created my local DNS records some seven years ago and never thought about them since, with only occasional additions for new devices.
Strange example: there's a new PhotoSync version out there fixing the .photosync thing, developers are awesome and ultra quick.
Right after updating on the endpoint, the client hostname was shown correctly as HostName.fritz.box in Pi-Hole`s Web UI.
Interestingly, right on the Pi-Hole machine, still:
nslookup xxx.xxx.xxx.xxx pi.hole
xx.x.xxx.xxx.in-addr.arpa name = HOSTNAME.photosync.
xx.x.xxx.xxx.in-addr.arpa name = HostName.fritz.box.
xx.x.xxx.xxx.in-addr.arpa name = HOSTNAME.fritz.box.
Authoritative answers can be found from:
nslookup xxx.xxx.xxx.xxx fritz.box
xx.x.xxx.xxx.in-addr.arpa name = HostName.fritz.box.
xx.x.xxx.xxx.in-addr.arpa name = HOSTNAME.fritz.box.
xx.x.xxx.xxx.in-addr.arpa name = HOSTNAME.photosync.
I mean the final result seems fine, but I still don't understand how Pi-Hole is picking one of those responses. My guess would still be the first line provided by the upstream DNS (for local hostnames it is the router) is used.
1 Like
mDNS. It's always mDNS. Having two different name resolution systems in parallel and mixing the results (as the fritz box apparently does) can never lead to anything good.
You are absolutely right. After another client usage (Windows suspend to disk earlier, later restored from hibernate), now in Pi-holes web interface I only see HOSTNAME.photosync entries again. So it seems like even the endpoint (PhotoSync application) seems to fix the mDNS part, Pi-hole still gets from the router either the wrong (undesired) or the right (desired) hostname - purely based on a thing called luck or randomness. Oh dear, I think this route only has one direction 
straight at manual maintenance city named https://pi.hole/admin/settings/dnsrecords.
Interestingly this is what I get now directly on the Pi-hole machine:
nslookup xxx.xxx.x.xx
xx.x.xxx.xxx.in-addr.arpa name = HOSTNAME.photosync.
xx.x.xxx.xxx.in-addr.arpa name = HostName.fritz.box.
xx.x.xxx.xxx.in-addr.arpa name = HOSTNAME.fritz.box.
Authoritative answers can be found from:
nslookup xxx.xxx.x.xx pi.hole
xx.x.xxx.xxx.in-addr.arpa name = HostName.fritz.box.
xx.x.xxx.xxx.in-addr.arpa name = HOSTNAME.fritz.box.
Authoritative answers can be found from:
nslookup xxx.xxx.x.xx fritz.box
xx.x.xxx.xxx.in-addr.arpa name = HostName.fritz.box.
xx.x.xxx.xxx.in-addr.arpa name = HOSTNAME.fritz.box.
What is used by Pi-hole itself (as the output is different when not specifying a dns server)? Maybe it's a caching thing...? Last straw 
And 5 minutes later nslookup xxx.xxx.x.xx also only gives 2 lines, without any .photosync in it. But https://pi.hole/admin/queries?client_ip=xxx.xxx.xxx.xxx still shows HOSTNAME.photosync in the client column. Weird.