Your work PC is making those queries, asking Pihole to resolve the xxx.sophosxl.net domain; not the other way around. I guess Sophos Antivirus is installed on your work PC, and this is OK. Sophos checks the URLs you visit by asking to its servers, in order to block or warn about harmful URLs. Probably your work admin has set filters, warnings or blocks regarding some types of web sites/URLs. I have Sophos installed on my iMac and here is a sample of Pihole query, it makes many similar queries. Sophos creates a lot of queries, this is normal.
Hello! Thank you for helping.
I also have Sophos on my personal computers and have similarly seen sophosxl.net queries for my personal computers. I'm not concerned about those.
I apologize if you saw this, but want to reiterate/clarify that every single query from the work PC in my pi-hole query log shows that it comes from Sophos. The screenshot sample comes from 5 seconds of navigating Google News. No domain other than sophosxl.net is ever listed.
Looking for a way to give the pi-hole "first look" at these queries before Sophos gets its hands on them.
As any DNS server, Pi-hole is only aware of the source IP address of a DNS request.
It cannot know which process or software running on that IP has issued the request.
Your Query log shows a client IP associated with the name DAVEMATTHEWS has sent TXT record resolution requests for a couple of *.sophosxl.net domains.
(EDIT: Just to be clear: korhant is right - those are requests for *.sophosxl.net, they are not "coming from sophosxl.net".)
From what you describe, it would seem that your browser already knew IP addresses for Google News (by retrieving previous DNS lookup results from a cache).
If you can rule out cache usage, that could suggest that Sophos software running on that DAVEMATTHEWS machine would be redirecting DNS requests to its own DNS routines, potentially by-passing Pi-hole.
If that would be the case, you can only address this by changing the configuration of Sophos on that machine.
I like that suggestion, I will try clearing the cache and maybe use a different browser as well to test that theory.
As a side note, Pi-hole did briefly work on the PC (only with the VPN off) when I first set it up. After a day or so it stopped working regardless of whether the VPN was on. So that gives me some hope this cache idea will work.
Sorry to report that doesn't seem to have worked. I (1) ran ipconfig /flushdns on the command prompt, (2) cleared the DNS cache on the browser, (3) tried a different browser, and (4) tried visiting websites I know I've never visited before.
All ads continued to load. I checked the pi-hole log and 100% of queries were for sophosxl.net and the pi-hole gave all of them the green-light.
I asked our IT people if they'd help me troubleshoot the Sophos settings. Unless anyone else has suggestions, I'll report back with what they say. I suspect they will not modify security settings on my account. They said it could be a company wide setting and not specific to my machine.
Another update - IT people confirmed that Sophos is acting as its own DNS server bypassing my pi-hole. They concluded the Sophos DNS functionality was more secure and therefore should be preferred over the pi-hole.
My last question is: Is this a local setting on my PC or a global setting? They seem to think it can not be fixed on my PC without affecting everyone else. I decided to see if I could test for this:
Theory: If the DNS functionality of the Sophos software on the PC is based on internal settings, if I interrupt the connection I assume that the PC would continue trying to ping sophosxl.net when I enter a URL in my browser. I have no idea if that's true, it was just a theory.
Test: Disconnected ethernet cable from PC, cleared DNS cache, rebooted pi-hole, rebooted modem, reconnected ethernet. Then refresh 10 tabs in my browser at once while the PC was re-establishing a connection. Then check the query log to see if the PC was still trying to ping Sophos.
Results: For the first ~4 minutes of the connection being re-established, the pi-hole functioned correctly. Requests from my browser to the DNS server were going to the correct domain. Domains were being blocked as expected. After 4 minutes, all queries again started being routed to sophosxl.net.
Conclusions: ??? ... To me this seems to say that my computer Sophos settings are being directed by a remote setting. Meaning the problem can't be fixed without affecting others I work with?
I suspect the (work instigated?) VPN may also play a role here.
When connected to your VPN, can you still access resources from your local network, e.g. a NAS, your router's web UI or Pi-hole's dashboard?
I don't think that those sophosxl.net requests are somehow camouflaging the actual DNS requests. According to Sophos SXL documentation, those domains are used for checking up-to-date information regarding websites, specifically on IP reputation (*.ip.0x.s.sophosxl.net) and malicious web content (*.m.0x.s.sophosxl.net).
This would make me expect to observe such sophosxl.net requests in addition to any regular DNS requests, just as korhant reported for their network.
But you seem to observe nothing but those requests (would that be correct)?
Now, VPN clients would commonly try to route DNS traffic to their VPN-specific DNS servers, in order to prevent DNS requests from leaking outside of the VPN connection.
And that could mean that your VPN maybe leaking DNS requests for *.sophosxl.net domains. And even if Sophos software on your client would indeed force the use a different DNS server (potentially in addition to your VPN client's DNS redirection), this would raise the question why it would still send those *.sophosxl.net requests to Pi-hole, and not to its own DNS servers.
But all in all, your observation seems well out-of scope for Pi-hole - it would seem that you are at the whim of your company's security policies.
The VPN is there so we can access files stored on a local server within our main office building. I only have it connected when I need to access that server, it mostly remains inactive. With the VPN active I can still access the pi-hole and my router UI (no NAS).
Yes that's correct. The only exception is I'll briefly see non-sophos domains when the PC is first beginning to use the ethernet connection. But the steady-state behavior is for 100% of DNS requests to be directed at sophosxl.net. I tested it again just now by going to a website I know for a fact I've never visited before. Here is another sample from visiting that site.
I assume that this won't be resolved. What irks me most about this is I was introduced to pi-hole by a work friend who should have the exact same security settings I do. His work PC works fine with the pi-hole.
Every single one of those queries were for a TXT record. Web sites use A or AAAA records for returning an IP address. To me it looks like Sophos security is trying to find if any of those obfuscated domains show up on their naughty list.
The domains are converted to something that would hide the true domain name and only Sophos would know how to convert those strings back to the actual domain name.
If you can access http://pi.hole/admin, then DNS requests are still handled by pi.hole.
When running ipconfig /all on your Win10 PC, what's the output of the DNS server section when your VPN is active and inactive, respectively?
And also, run from your Win10 PC, what's the output of
nslookup DAVEMATTHEWS
Would this maybe also explain why most of the replies are either "NXDOMAIN" or "BLOB" (with an occasional "N/A")?
I have never accessed pi-hole this way. I tried just now and it did not work. It does work if I log in with 192.168.1.241/admin (pi-hole IP).
VPN off:
DNS Servers . . . . . . . . . . . :
2001:558:feed::1
2001:558:feed::2
192.168.1.241 (pi-hole IP)
Note I did not set a preferred DNS server for IPv6.. Not really sure what the correct IPv6 DNS address is.
............
I:\>nslookup DAVEMATTHEWS
Server: cdns01.comcast.net
Address: 2001:558:feed::1
*** cdns01.comcast.net can't find DAVEMATTHEWS: Non-existent domain
VPN on:
DNS Servers . . . . . . . . . . . :
2001:558:feed::1
2001:558:feed::2
192.168.1.241 (pi-hole IP)
............
I:\>nslookup DAVEMATTHEWS
Server: [server name].[work name].local (censored names for privacy)
Address: 192.168.0.44
Name: DAVEMATTHEWS.[work name].local
Address: 10.100.100.22
When the VPN is on, the ipconfig command shows that 192.168.0.44 DNS server that does not appear to be on my network.
Your recent findings would suggest that Pi-hole is by-passed two-fold:
Via Comcast's IPv6 DNS servers when your work VPN is off, and via some DNS server of yet unknown origin when your VPN is active.
If that latter DNS server is indeed forced by your VPN and run by your company, you wouldn't be able to use Pi-hole when your work VPN is active.
To address the former (edit: and you should, as this wouldn't affect your Win10 PC only, but all clients capable of IPv6), you'd have to find a way to configure your router to advertise your Pi-hole host machine's IPv6 as DNS server instead.
When picking an IPv6 address (from ip -6 address), avoid public GUAs (range 2000::/3), and prefer your Pi-hole host's ULA address (range fd00::/8) over its link-local (fe80::/10).
You'd have to consult your router's documentation sources on further details for its IPv6 configuration options. Note however that some few router models show a misbehaviour of distributing their own IP address along with any custom address regardless.
If your router doesn't support configuring IPv6 DNS, you could consider disabling IPv6 altogether.
If your router doesn't support that either, your IPv6 capable clients will bypass Pi-hole via IPv6.
2 Likes
Okay I see what you mean, disabling IPv6 fixed the issue. I didn't realize that Windows 10 goes through IPv6 even when you set a preferred IPv4 server. This wasn't an issue on any other machines I have.
So I guess that means I have to figure out how to set it up IPv6 on the router. When I run ip -6 address show eth0 I get this:
inet6 2601:98b:8000:23f4::2a/128 scope global dynamic noprefixroute
valid_lft 148842sec preferred_lft 148842sec
inet6 fe80::2110:abf6:bba8:6b0b/64 scope link
valid_lft forever preferred_lft forever
You're saying I plug one of the above addresses into the settings below (or into the PC host settings)? And you're also advising against using the one starting with "fe"? Sorry this is not something I'm very familiar with.
This may be a misled impression from partial observation:
As mentioned, all IPv6-capable clients are able to use your ISP's (Comcast?) DNS servers, and as they tend to prefer IPv6 over IPv4, I consider it very likely that a portion of your network's DNS traffic has been by-passing Pi-hole via IPv6.
A *Yes* to your first and a *No* to your second question (click for details)
When picking one of your Pi-hole host's IPv6 addresses for your router's DNS server configuration, go for a stable address, so
- avoid GUAs (range
2000::/3)
Your ISP controls your GUA IPv6 prefix it, so it may change, either regularly or on router restarts.
(Your IPv6 address starting with2601:is such a public global unicast address(GUA).) - avoid Privacy Extension addresses (marked with
temporary)
The interface identifier portion of an IPv6 PE address is designed to change regularly, on some systems as often as every hour.
(Your output shows youreth0to carry none of those.)
As link-local addresses (LLAs) are non-routable and only reachable on the same link, you should usually prefer ULA addresses (range fd00::/8 ) over LLAs (range fe80::/10 ).
(Your output doesn't include any unique local address (ULAs), presumably because your router does not or cannot advertise a ULA prefix.)
Click for a sample output all mentioned IPv6 address types
~ $ ip -6 address show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:1a57:b007:fa11:a730:2552:35e7:c6e2/64 scope global temporary dynamic
valid_lft 7176sec preferred_lft 3576sec
inet6 2001:1a57:b007:fa11:abba:ba1d:face:bf39/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 7176sec preferred_lft 3576sec
inet6 fd02:1ce:c01d:bee2:5886:3be8:1032:f39d/64 scope global temporary dynamic
valid_lft 7176sec preferred_lft 3576sec
inet6 fd02:1ce:c01d:bee2:face:b055:f1ee:f1ea/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 7176sec preferred_lft 3576sec
inet6 fe80::dead:c0de:500d:f00d/64 scope link
valid_lft forever preferred_lft forever
(For readability, I've added blank lines to separate GUAs, ULAs and LLA)
As your output doesn't list a ULA, you should consider using your LLA.
For most home networks, configuring a link-local IPv6 of Pi-hole's host machine as DNS server in your FritzBox would probably be fine, but note that additional network equipment like access points or L3 switches may split your network into multiple links, as may VLANs. Your Pi-hole's LLA won't be accessible by any IPv6 clients not residing on the same link as your Pi-hole machine.
Once you've configured your router, reboot your Win10 PC and reverify the IPv6 DNS servers that your Win10 PC is using: Your Pi-hole's IPv6 should now be the only IPv6 DNS server address.
If your ISP's DNS servers would still show up, then your clients would still be able to by-pass your Pi-hole.
Appreciate the help as always.
Have not had time to troubleshoot this too much. I tried reading about IPv6 in general and it seems fairly complicated.
I tried a plug and chug of the LLA into the router settings (chose "use these DNS servers", entered the LLA under "Primary DNS", and blanked out the second row). I expanded it like this before entering into router settings:
fe80::2110:abf6:bba8:6b0b/64. ---> fe80:0000:0000:0000:2110:abf6:bba8:6b06
The router gave me a an error "The Primary DNS Server is not valid; it has to be a global unicast address", which led me to this post encouraging what appears to be a 3rd party firmware update to the router/modem.
I tried plugging the RPi LLA address into the preferred DNS server under the PC IPv6 settings and received no error, however the PC's behavior was back to the way it was before I disabled IPv6.
Still working on it.
You've correctly expanded that address, but the last hex digit may have fallen victim to a typo. 
Your router should advertise your Pi-hole's IPv6 as local DNS server.
I am not sure whether your router screenshot would show that respective option, or whether it would be related to your router's upstream DNS configuration.
You'd have to consult your router's documentation for details.
Yes that was a typo 
Based on the error I receive showing that only a global unicast address may be used, does this indicate to you that my router is not capable of advertising my pi-hole's LLA IPv6 as a local DNS server (at least in its current firmware)? The screen shot I gave earlier shows the only options for configuring IPv6 addresses.
Some other things that might be relevant (not sure):
I have a modem/router combo (CAX80), from researching other threads it seems that my ISP may have some influence on modem behavior and IPv6 restrictions via firmware settings. Might that explain why the router won't accept an LLA over a global unicast address (because that is my ISP's preference via firmware)?
I have a recursive DNS server set up locally on the RPi using unbound and these instructions from pi-hole.net. The only thing I changed in the unbound code was to change do-ip6: no to do-ip6: yes
Screen shots ...
A strong 'Perhaps'.
Your guess is as good as mine here - chances are, it is even better, since you have better access to your router and its documentation.
To a degree, limiting configuration to only GUAs could be somewhat sensible for upstream configuration, so it may or may not hint at the possibility that the respective configuration option is for your router's upstream servers, but that is just me wildly speculating.
Your router's documentation and support channels should be your prime source of knowlegde here.
I realise they may not be as approachable as us Pi-hole folks, but I really can't help you much here as I do not know your router at all.
You got that right!
I started a new thread on Netgear's forum asking about using a non global unicast address and the first response was essentially "just use a global unicast address". 
From reading other posts in this community, I gather the main reason not to use a GUA is because it's not reliably static. The other reason I'm seeing is that it can cause privacy concerns. In this post, I think it's said that using the RPi's GUA makes pi-hole publicly available. I think I understand that second part a little less?
In the meantime, setting the link local address as the preferred IPv6 DNS server address on my PC's does seem to be working. It will be nice to find a fix for the router so it's working correctly for everything on the network.
Thanks again for all your help. I'll add an edit to the first post with the solution to the original Sophos question.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.