https://sweeps.gg/giveaways/1000-giveaway-e6qcn/
this link produced this:
and this I know for a fact came from my browser. I use Opera as my main browser.
This depends on your chose remote control. It is unlikely, though.
I just tried the link myself and about 60 queries were made. sweeps.gg was queried (as expected) when navigating to this page, however, sweeps.gift was never requested.
The response for sweeps.gg is A = IP, AAAA = IP. All green.
When manually enter sweeps.gift, this seems to give a different page. The response is A = IP, AAAA = NODATA
This depends on your chose remote control. It is unlikely, though.
I'm using normal windows RDP. so if that's not the case, it does not make sense that it comes from my computer. could the pi be confusing traffic? seems unlikely.
I just tried the link myself and about 60 queries were made.
sweeps.ggwas queried (as expected) when navigating to this page, however,sweeps.giftwas never requested.
it might be because I'm logged in. I'll try to find another example that does not require anything like that.
EDIT:
this very site showed up on my search.
ran into the same problem i had where pages don't load with this picture.
I'm not going to clear the logs, this is what I got.
/var/log/pihole.log:19086:Oct 7 08:52:04 dnsmasq[22636]: 534 192.168.55.132/61982 query[A] www.linkedin.com from 192.168.55.132
/var/log/pihole.log:19087:Oct 7 08:52:04 dnsmasq[22636]: 534 192.168.55.132/61982 forwarded www.linkedin.com to 1.1.1.3
/var/log/pihole.log:19092:Oct 7 08:52:04 dnsmasq[22636]: 536 192.168.55.132/61982 query[A] www.linkedin.com from 192.168.55.132
/var/log/pihole.log:19117:Oct 7 08:52:04 dnsmasq[22636]: 534 192.168.55.132/61982 reply www.linkedin.com is <CNAME>
/var/log/pihole.log:19118:Oct 7 08:52:04 dnsmasq[22636]: 534 192.168.55.132/61982 reply www-linkedin-com.l-0005.l-msedge.net is <CNAME>
also I'm starting to notice a trend that everything that's not from the cache shows up as insecure. don't know if it's related but it is strange since the test for dnssec passed.
EDIT:
these are all unknown.
Even with the further examples you provided, I am unable to reproduce this locally. Are all unknown queries coming from the same client? To rule out that this may be a side-effect of some anti-virus/firewall/etc. application: Do you maybe have another device ideally with a different operating system (like phone, tablet, etc.) from which you could try to reproduce this?
This is unlikely. The queries are returned to the IP address shown there. If it would be the wrong device, the reply would never get received.
I'm not familiar with this, but I guess it does not forward such things. Can you use the machine without remote access? Does it still happen in this case?
This is not necessarily an issue, INSECURE just means it doesn't get any extra security through DNSSEC. It is less a hint to something problematic but more showing that DNSSEC cannot determine if this is secure or not. Not the best choice of wording if you ask me.
The vast majority of the web is actually not using any proper signature. At least that's my experience. Try browsing to the German site https://www.denic.de You should get a green SECURE report for this domain.
We could try recording your DNS traffic so I can inspect the data using Wireshark. Try
sudo tcpdump -w /tmp/dns.pcap port 53
on your Pi-hole to start the recording. It can be terminated with Ctrl + C once we have recorded such an unknown query. Send me the file in a private message (in a ZIP-archive) if you are concerned about privacy. You can inspect the content of the file using
tcpdump -n -t -r /tmp/dns.pcap port 53
before sending it.
sudo tcpdump -w /tmp/dns.pcap port 53
is this available on pihole from the box or should I apt-get some package? because I tried running it and it did not find the command.
Are all
unknownqueries coming from the same client?
no, I have 2 windows machines where this happens. I could not reproduce this on my mobile device.
also, could this be related to my other topic regarding DHCP entries not populating correctly?
https://discourse.pi-hole.net/t/dhcp-leases-show-up-as-i-unknown-i/38876/16
Oh, sorry, I figured it would be available. Run
sudo apt install tcpdump
to get it.
Not, this unknown is just inserted automatically by the web interface when the name is empty. This is done client-side and is not related here. Just using the same word, by chance, for the different and unrelated things.
Not, this
unknownis just inserted automatically by the web interface when the name is empty. This is done client-side and is not related here. Just using the same word, by chance, for the different and unrelated things.
yeah I know it's just the same word, what I meant was, could the root cause be the same?
sending you the pm now.
No, they are separate.
Thanks for providing the PCAP via PM. I checked what was going on in your network and found that the second query was in fact a resubmission because Windows was impatient.
Windows resubmitted after waiting only 0.1 seconds! That's pretty odd and a bit low for a timeout, but okay, this is probably among the things that cannot be fixed on Windows.
Now we know what is going on and I can look into reproducing this locally so we can work on a fix.
that's great! i would point out that I do use tcp optimizer on my windows machines with these settings:
I didn't see anything that's immediately relevant, but maybe you will.
Undo the optimizer and see if things work right without it. If so, add back tweaks one at a time until you find the one that is causing it.
I'm very sure it's one of the tweaks.
that's a lot of restarts for something that won't fix this for sure. I'll read later into each tweak to see in-depth if something is more relevant to this case. however if it's a time out thing, those entries were in the 600ms range for some of the sites, it could be a normal timeout.
It's just a single restart. The one that disables the entire list of changes. That will tell you with certainty if the issue is with pihole-FTL of if it's self-inflicted.
Just a quick update: Reproducing this locally turns out to be a lot trickier than I figured initially because Linux (which is the only operating system I have at hand) is trying really hard to prevent me from doing DNS lookups with such a ridiculously low retry timeout 
Still work in progress...
ah Linux, allowing you to do stupid things if you want to, but you'll have to work hard for that. yeah, windows is a bit more flexible with user errors. anyway, I might have the time today to restore the settings of the TCP optimizer to defaults and check if that's the cause.
I honestly disagree. From what I know, the registry is a beast you don't want to edit manually. And you can only tweak such things in Windows using third-party software.
Anyway, even when I was able to reproduce retried queries by sending queries with the same query ID in short succession, I was not able to reproduce exactly what you saw. However, I'm currently on my somewhat limited mobile setup and will try to reproduce this at home next week.
So far, the proposed change is documented here:
windows is a bit more flexible
I mentioned it's flexible to user errors, I worked as a pc tech for most of my careers, the ease with which normal users can destroy windows with a few clicks be it with 3rd party software or just randomly, is astounding.
as for the change, that's great! I hope this also helps other people, maybe ones with lower-end hardware or low memory or something.
haven't gotten around to testing the TCP optimizer, maybe tomorrow. will update with the results.
yep, reverted to windows defaults and the issue disappeared. will test further to see if it's just temporary.
EDIT: was wrong, it did not change, and I saw this happen on a computer in the network I'm pretty sure I did not use the optimizer on.