PTR PEBKAC

Ok, I know PTR requests have been discussed here in depth, but I still feel like I have a scenario that I cannot figure out and I am hoping that I can get someone's help who understands this better than I do.

Current set up:
Beta 6
No Conditional Forwarding
DHCP is router
Only small number of devices use pi-hole for DNS
Unbound
Wireguard setup using pivpn
wireguard client 10.242.139.1
Linux ubuntu on a old lap that I converted to be my pi-hole setup.
DHCP pool on router: 192.168.0.2 - 192.168.0.253
I also had this same issue on pi-hole 5, so it is not a beta issue. It is most definitely PEBKAC.

I currently get
lb._dns-sd._udp.2.0.0.192.in-addr.arpa
lb._dns-sd._udp.0.0.168.192.in-addr.arpa
lb._dns-sd._udp.0.139.242.10.in-addr.arpa - wireguard

These ptr requests are in a ranges outside my wireguard and outside my dhcp ranges. I don't know what to do about these because they get stuck in a loop. I have tried conditional forwarding before, But I still don't know which set up for conditional forwarding I should do because they are outside my dhcp range. No vlan on router either.

In normal DNS queries, you start with a domain and wants to know the IP.
In reverse DNS queries, you start with an IP and you are requesting the domain/hostname.

PTR are used for Reverse DNS queries.

No.
Actually, you need to read them in reversed order (this is how PTR requests are written).

In this example:

This is requesting the hostname of the IP 192.168.0.2 (this is 2.0.168.192 reversed).

This is the same:

It is a request for the hostname of the IP 10.242.139.0 (this is 0.139.242.10 reversed).

Correct, I do understand that they are in reverse. But they would actually be

192.0.0.2 Which is outside my 192.168.x.x (not 192.168.0.2)
192.168.0.0 I believe this is my modem?
10.242.139.0 Is 1 below my wireguard client at 10.242.139.1, first wireguard peer is 10.242.139.2

Although they look similar, the above are not reverse lookups.

They are RFC6763 DNS service discovery requests (in your case, for the legacy browsing domain) as used by zeroconf clients, often in conjunction with wide area mDNS (like Apple's Bonjour or Linux' avahi), to gather informaton about services in your network, e.g. to allow discovery of AirPrint printers in the same subnet even if they'd reside in another network segment.

Is there anything I can do to stop these? They end up happening a lot and the only fix I have so far is to restart the device it is happening on. This slows it down. But then it ends up happening almost every minute.

These are DNS Discovery Service requests. Not the classic PTR which asks, "what is the name of the client at this IP". DNS-DS is frequently associated with the Apple Bonjour protocol.