Expected Behaviour:
.local is not within any block list, so requests should be allowed.
Actual Behaviour:
Requests to random_string.local are being blocked.
Debug Token:
https://tricorder.pi-hole.net/354wd57apd
I posted this on reddit here: https://www.reddit.com/r/pihole/comments/k7atiy/suddenly_all_requests_for_randomstringlocal_are/
My top blocked domains are all of the form random_string.local, which is very new since updating to 5.2.1. I've hidden them from the top blocked domains by adding *.local to the api settings, but they're still counted in all the other stats.
Has something changed in the latest update that effects local domains?
Can you post a new token? The one provided doesn't seem to be on the server.
And a dig <domainname> @PIHOLE_IP output would be helpful.
Edit:
Using local is not a great idea, Bonjour / mDNS use that as their default domain and that will cause a lot of confusion when you're trying to find out if the domain is for your LAN or if it's from an Apple device that is trying to use multicast DNS.
I've tried doing another debug log, but it's failing to upload. I'll try again in the morning and attempt to upload manually if it keeps failing.
As for the dig, the output from one of my devices is here:
; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> b60b65090b17.local @192.168.0.25
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54417
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;b60b65090b17.local. IN A
;; Query time: 0 msec
;; SERVER: 192.168.0.25#53(192.168.0.25)
;; WHEN: Mon Dec 14 00:09:32 GMT 2020
;; MSG SIZE rcvd: 47
This is what I was referring to.
I appreciate that, I haven't explicitly asked anything to use the local domain, but I guess it's something in my docker stack. It wasn't being blocked before the latest update, so any ideas what changed? There are other reports on reddit about this changing in the last update too.
They're not being blocked, per-se. They are NXDOMAIN since they don't exist.
What blocking mode are you using?
I don't have one specified in the pihole conf file, so I assume the default of NULL?
Why have they only just started showing up after the latest update? They won't have existed before either, but they weren't being reported as blocked domains.
Default would be null, or 0.0.0.0.
There was a security update with Security enhancement for the "never forward non-FQDNs" feature by DL6ER · Pull Request #3794 · pi-hole/pi-hole · GitHub that prevents .local queries from being passed to the upstream. The behavior was detected in Pi-Hole forwards it's hostname upstream when queried with local domain suffix · Issue #3303 · pi-hole/pi-hole · GitHub.
Now you see that the queries are prevented from being passed upstream, which could leak information about your hostnames. .local will never be resolved upstream so they shouldn't ever be passed upstream.
OK, I get that they're not exactly being blocked and shouldn't go upstream. The issue for me is that overnight I've gone from 5% blocked to 50% blocked. The stats have become meaningless. Will this happen to anyone with docker or apple devices?
Obviously I didnt understand the above when creating this thread. Just curious how I can fix the stats?
I don't think docker picks .local as a domain, so without seeing your compose or your runtime I can't say one way or the other.
The solution is to not use the .local domain at all. These queries were happening all along, you now are seeing them. The proper solution is to fix that and not hide the fact that it's happening.
1 Like
For clarification, this feature is enabled when "Never forward non-FQDNs" is enabled.
I've changed the domain setting to lan in the pihole dhcp settings. Now my top domains and query log are full of random_string.lan being blocked.
Does the security update also apply here? A new dig is provided below:
; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> 7afe172d610b.lan @192.168.0.25
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5755
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;7afe172d610b.lan. IN A
;; Query time: 0 msec
;; SERVER: 192.168.0.25#53(192.168.0.25)
;; WHEN: Mon Dec 14 07:28:13 GMT 2020
;; MSG SIZE rcvd: 45
Are you using HomeAssistant?
Edit: And if you are, are you on version 5.8 that changed DNS
Here's a debug token now that I've been running with *.lan for while. https://tricorder.pi-hole.net/t5jbh8p1zn
Yes I'm using home assistant.I'm not sure about version 5.8. I'm on 0.118.4 within a docker container.
I don't know what kind of resolution we can give you.
The queries are valid queries and coming from some device or service on your network. Pi-hole doesn't generate random hostnames or queries.
Is there a specific host that seems to be generating these queries when you examine the Query Log on the admin interface?
Here is the actual code for the local check:
if [[ "${PIHOLE_DOMAIN}" != "none" ]]; then
echo "domain=${PIHOLE_DOMAIN}" >> "${dhcpconfig}"
if [[ "${DNS_FQDN_REQUIRED}" == true ]]; then
echo "local=/${PIHOLE_DOMAIN}/" >> "${dhcpconfig}"
fi
fi
What that says is: If you have set a domain for Pi-hole to use, which in this updated case is .lan, then tell pihole-FTL that .lan is a local only domain and do not forward it.
Do you see any indications on your query log that .lan domains are being forwarded to your upstream? Or are they coming up as blocked (probably listed as regex for the cause of the block).
Edit:
Looking at your debug, the .lan block should be working:
-rw-r--r-- 1 root root 629 Dec 14 07:04 /etc/dnsmasq.d/02-pihole-dhcp.conf
dhcp-authoritative
dhcp-range=192.168.0.64,192.168.0.251,24h
dhcp-option=option:router,192.168.0.1
dhcp-leasefile=/etc/pihole/dhcp.leases
domain=lan
local=/lan/
dhcp-option=option6:dns-server,[::]
dhcp-range=::100,::1ff,constructor:eth0,ra-names,slaac,24h
ra-param=*,0,0
They are coming from a single host. It's an Ubuntu server running docker. One of the docker containers is Home Assistant. I'll get all the latest updates, and return Sith my results.
One of the best autocorrect fails I've seen in a long time.
1 Like