I have noticed so domains in the top list coming from my iphone and only my iphone
they seem to be doing some form of lookup of the subnet by the look of the address
192.168.0.0/16 is the subnet
Does anyone have any information on what is going on here please
its only started a few days ago, and never seen these domains before
These are reverse DNS lookups.
I believe it to be Bonjour service discovery:
Pointer Records
PTR records enable service discovery by mapping the type of the service to a list of names of specific instances of that type of service. This record adds yet another layer of indirection so services can be found just by looking up PTR records labeled with the service type.The record contains just one piece of information, the name of the service instance (which is the same as the name of the SRV record). PTR records are accordingly named just like SRV records but without the instance name:
.
Here is an example of a PTR record for a print spooler named PrintsAlot:
_printer._tcp.local. 28800 PTR PrintsAlot._printer._tcp.local.
Again, the 28800 is the time-to-live (TTL) value, measured in seconds.
Below is a classical PTR lookup example with regular DNS (not via Bonjour mDNS):
$ dig +noall +answer -x 10.0.0.3
3.0.0.10.in-addr.arpa. 2 IN PTR nas.home.dehakkelaar.nl.
Out of curiosity, do you have a .local search/suffix domain configured via the DHCP service?
Can check with below one on the Pi-hole host:
$ sudo pihole-FTL dhcp-discover
Scanning all your interfaces for DHCP servers
[..]
domain-name: "home.dehakkelaar.nl"
I though that, but why?
by pi-hole, yes i do
domain-name: "CN"
CN isnt the same as local is it?
Or did you make a typo 
I misread it, I though you meant like .local
Na I really meant the name "local" bc that one is exclusively reserved for mDNS and not meant for classical regular Do53 (unicast DNS over port 53):
Using ".local" as a private top-level domain conflicts with Multicast DNS and may cause problems for users.
https://www.rfc-editor.org/rfc/rfc6762.html
(Appendix G)
Oh ps, that CN TLD is conflicting with Internet DNS:
$ whois cn.
[..]
domain: CN
organisation: China Internet Network Information Center (CNNIC)
address: No. 4, South 4th Street
address: Zhong Guan Cun
address: Beijing 100190
address: China
EDIT: If you can configure that CN name in the router, you could change it into one of the recomendations at the bottom of that Multicast DNS RFC:
Appendix G. Private DNS Namespaces
The special treatment of names ending in ".local." has been
implemented in Macintosh computers since the days of Mac OS 9, and
continues today in Mac OS X and iOS. There are also implementations
for Microsoft Windows [B4W], Linux, and other platforms.Some network operators setting up private internal networks
("intranets") have used unregistered top-level domains, and some may
have used the ".local" top-level domain. Using ".local" as a private
top-level domain conflicts with Multicast DNS and may cause problems
for users. Clients can be configured to send both Multicast and
Unicast DNS queries in parallel for these names, and this does allow
names to be looked up both ways, but this results in additional
network traffic and additional delays in name resolution, as well as
potentially creating user confusion when it is not clear whether any
given result was received via link-local multicast from a peer on the
same link, or from the configured unicast name server. Because of
this, we recommend against using ".local" as a private Unicast DNS
top-level domain. We do not recommend use of unregistered top-level
domains at all, but should network operators decide to do this, the
following top-level domains have been used on private internal
networks without the problems caused by trying to reuse ".local." for
this purpose:.intranet. .internal. .private. .corp. .home. .lan.
https://www.rfc-editor.org/rfc/rfc6762.html#appendix-G
Or home.arpa which is a more recent RFC and has added protection when local queries unintentinaly leak to the Internet DNS servers upstream:
$ xargs -n 1 whois <<< 'intranet. internal. private. corp. home. lan. home.arpa.'
No whois server is known for this kind of object.
No whois server is known for this kind of object.
No whois server is known for this kind of object.
No whois server is known for this kind of object.
No whois server is known for this kind of object.
No whois server is known for this kind of object.
[..]
domain: HOME.ARPA
[..]
contact: technical
name: Internet Assigned Numbers Authority (IANA)
organisation: Internet Corporation for Assigned Names and Numbers (ICANN)
[..]
remarks: This domain is administered as part of the .ARPA zone
remarks: management, described at https://iana.org/domains/arpa
$ dig dummy.name.home.arpa.
[..]
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27385
[..]
;; AUTHORITY SECTION:
home.arpa. 900 IN SOA prisoner.iana.org.
hostmaster.root-servers.org. 1 604800 60 604800 604800
About above prisoner.iana.org.:
Indeed a weird domain
none is this is telling me why, I knew it was PTR, and a reverse lookup, but what is sending it on my iphone
Have a read on below link:
I believe it comes default enabled with MacOS & iOS.
Not sure though so maybe someone else can confirm???
I also noticed the dig
I ran it and its going to an old subnet with the old pi-hole IP
dig lb._dns-sd._udp.0.0.168.192.in-addr.arpa
;; communications error to 10.42.0.252#53: timed out
or is that my system messed up, because then it complete the request and forwards it to upstream servers
I think I changed something with dig, a few years again to always try a DNS server, I clearly never changed it
a PTR shouldn't be going upstream should it
wait not, that wasn't using pi-hole
forget to mention pi-hole is ran in docker here
so the host does not use pi-hole
That should be with ptr at the end:
dig lb._dns-sd._udp.0.0.168.192.in-addr.arpa ptr
But I suspect you get an NXDOMAIN reply via regular DNS.
Then it should be:
dig @<PIHOLE_IP_HERE> lb._dns-sd._udp.0.0.168.192.in-addr.arpa ptr
yes I just realized
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;lb._dns-sd._udp.0.0.168.192.in-addr.arpa. IN A
It could:
$ dig +short -x 9.9.9.9
dns9.quad9.net.
Depends if its a private or public IP thats beeing queried for.
The private ones should be prevented from being forwarded upstream by Pi-hole, router or maybe even Unbound.
EDIT: Check the Pi-hole "Advanced DNS settings".
I was reading the data wrong anyway
the server should have been the pi-hole address not Cloudflare
anyway that was my mistake
anything 192.168.X.X is private as far as I know
there getting NXDOMAIN
NXDOAMIN is not found, right?
or am I getting confused
I just want to reduce the frequency or stop them altogether, which needs to be done on my iphone, but I have no idea what it is, if it is bonjour, how do I find what is using it
I can't remeber changing anything on my iphone or installing any new apps
Yes.
Non eXisting.
If Pi-hole or my router wont stop them (which they do OOTB if either is configured to do DHCP), my upstream Unbound will:
$ cat /etc/unbound/unbound.conf.d/pi-hole.conf
[..]
# Ensure privacy of local IP ranges
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: 172.16.0.0/12
private-address: 10.0.0.0/8
private-address: fd00::/8
private-address: fe80::/10