I searched the forum to see if anyone else had experienced the same issue, but without success (I might have used the wrong search terms). Anyway, having finally found the answer to my problem, I figured I'd put it here for reference in case anyone else has the same issue.
My local DNS suffix for my LAN is, imaginatively, "lan".
Today I installed Pi-hole on a brand new Raspberry Pi, with a fresh installation of the 2018-06-27 Raspbian Stretch Lite image. The only customisations I made were:
- enabled SSH so I could run the Pi headless
- changed the "pi" account password
- added an SSH key for the "pi" account
- set eth0 to static IP and static DNS
- changed the hostname, the locale, the timezone, and the Wi-Fi country
- updated the kernel (rpi-update)
- upgraded all existing packages with apt
- installed tcpdump
- changed the upstream DNS provider from Google to Cloudflare during the Pi-hole installation
- changed the Pi-hole admin web page password
Everything else, for both Raspbian and Pi-hole, was left at the default settings, including the blocklists.
So then I set about testing the blocking, and looking at the Query Log. I used "zedo.com" as a test.
I fired up a command prompt under Windows and issued nslookup zedo.com. As expected, the response came back:
Name: zedo.com
Addresses: ::
0.0.0.0
But, which wasn't expected, the Query Log showed DNS lookups for both "zedo.com" and "zedo.com.lan". The "zedo.com" lookup was blocked by Pi-hole, but the "zedo.com.lan" lookup was passed to the upstream resolver which, quite understandably, returned an "NXDOMAIN" response.
tcpdump showed that the "zedo.com.lan" query was coming from the Windows client, and not being magically created by Pi-hole. So I spent some time this afternoon researching Windows DNS client behaviour, and finally found the answer.
Windows' default behaviour is to append the local DNS suffix to any lookup which is not fully-qualified. And what makes a name fully-qualified? A dot at the end. This was the magic that I did not know until now. So, zedo.com is not fully-qualified, but zedo.com. is.
When I typed nslookup zedo.com Windows treated it as non-fully-qualified, so appended ".lan" to the lookup and sent that query first. When that failed - as of course it would - then Windows tried again without the suffix. Pi-hole passed the first query to the upstream resolver, but blocked the second query.
When I tried again with nslookup zedo.com. then it was blocked as expected, and without a supplementary lookup ending with ".lan".
So, if anyone is testing Pi-hole from Windows, using nslookup, remember to stick a dot at the end of the FQDN, otherwise it won't be FQ.
Hope this helps.