“reply from unexpected source” when using link-local IPv6 resolver address

I've recently been trying to properly configure IPv6 for everything in my network, however I've run into an issue with using my Pihole resolver from macOS Monterey.

Since the public IPv6 prefix may change, I'm distributing its link-local IPv6 address on my local network, which is causing an issue on my Mac. The following demonstrates it clearly:

➜  ~ dig @fe80::fea5:8099:fe4f:8ac6%en0 google.com     
;; reply from unexpected source: fe80:e::fea5:8099:fe4f:8ac6%14#53, expected fe80::fea5:8099:fe4f:8ac6%14#53
^C%    
➜  ~ nslookup google.com fe80::fea5:8099:fe4f:8ac6%en0
;; reply from unexpected source: fe80:e::fea5:8099:fe4f:8ac6%14#53, expected fe80::fea5:8099:fe4f:8ac6%14#53
^C  
➜  ~ nslookup google.com fe80:e::fea5:8099:fe4f:8ac6%en0
Server:     fe80:e::fea5:8099:fe4f:8ac6%en0
Address:    fe80:e::fea5:8099:fe4f:8ac6%14#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.81.238

➜  ~ ping6  fe80::fea5:8099:fe4f:8ac6%en0 
PING6(56=40+8+8 bytes) fe80::1c4c:232:1096:128a%en0 --> fe80::fea5:8099:fe4f:8ac6%en0
16 bytes from fe80::fea5:8099:fe4f:8ac6%en0, icmp_seq=0 hlim=64 time=5.584 ms
16 bytes from fe80::fea5:8099:fe4f:8ac6%en0, icmp_seq=1 hlim=64 time=2.664 ms

➜  ~ ping6  fe80:e::fea5:8099:fe4f:8ac6%en0
PING6(56=40+8+8 bytes) fe80::1c4c:232:1096:128a%en0 --> fe80::fea5:8099:fe4f:8ac6%en0
16 bytes from fe80::fea5:8099:fe4f:8ac6%en0, icmp_seq=0 hlim=64 time=6.354 ms
16 bytes from fe80::fea5:8099:fe4f:8ac6%en0, icmp_seq=1 hlim=64 time=2.965 ms

➜  ~ ifconfig
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=6463<RXCSUM,TXCSUM,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
    ether bc:d0:74:43:e1:d6 
    inet6 fe80::1c4c:232:1096:128a%en0 prefixlen 64 secured scopeid 0xe 
    [...]

It seems like something inserts an improper subnet id (which always matches the scope id from ifconfig, but changes across reboots) into the address, but can also strip it out – just doesn't do it properly on DNS queries. Running Wireshark on those DNS queries confirms that on the actual network adapter the packets have the proper IPv6 addresses (no subnet id). Therefore I believe this is somewhere within the OS.

I read here that macOS inserts the subnet id for network adapter identification in the kernel so it'd seem it's not stripped out. That'd lead me to believe it's a bug in the kernel, but it's been unnoticed for many years (IPv6 isn't that new)?

Non-macOS machines don't have this issue and resolve these names properly and macOS is also totally fine with resolving with the publicly-routable address as well.

Any idea what this could be/how to fix it?