Hide/Block HTTPS Requests

Would it be possible to hide or block HTTPS requests from the query log?

Below is an example.

2021-10-29
20:46:24 A https://app-measurement.com/sdk-exp iPad-Pro.lan OK
(cache) NXDOMAIN (2.9ms)

It does respond with NXDOMAIN however it shows as allowed and not blocked or in red.

https://docs.pi-hole.net/regex/pi-hole/

Edit:

These are not DNS requests of type HTTPS (which is what the linked URL would address). They are malformed DNS queries of type A, and the malformed query starts with the https protocol.

You aren't going to be able to do much with these, since they are type A. The best approach is to find and fix or delete the offending software.

This is unusual. A URL should not appear in the query log. Only domains.

URL: https://app-measurement.com/sdk-exp

Domain: app-measurement.com

We've seen such queries before, they are bugs in the client software that does them. Usually, they get fixed pretty soon as they can never result in a valid response. If this happens from an IoT device that never receives updates, your are out of luck.

Surprising that we see it from an iPad Pro in this case. But, it is clearly the originator of the malformed queries.

In this case, it’s out there for at least a year.

Why is this surprising? I guess apps can be broken on apple devices just the same way they can be broken somewhere else.

It could be isolated by disabling (if possible, if not removing) apps selectively and observing when it stops. I'd start with disabling all apps because multiple can be affected when this is a (user-tracking?) SDK.

Edit: See also here https://stackoverflow.com/questions/54461349/how-to-decrypt-firebase-requests-to-app-measurement-com/54463682#54463682

Is there a second query somewhere requesting the domain without https:// ? If so, they may just never have realized their mistake as the SDK would still work.

no, it's one case

regex working for that is:

(^|.+.|.+)app-measurement.com(.+|$)

For me, it's the case for every https request

This confirms my hypothesis

at least for @yubiuser

Is this misbehavior isolated to Apple devices? I don't see this domain myself but I don't have any Apple devices on my household. By any chance, did you ever try to narrow down which app(s) are causing these lookups?

This is happening on all of my iOS devices. Just not the iPAD-Pro. It happens on several apps, just not one in particular.

An example of an application where this happens is "CheapCharts".

Also, this has been happening since I've been using Pi-Hole, which is about 4 years now.

Interesting, so it was likely even be happening before.

According to

over 1.5 million apps are actively using Firebase every month.

Another interesting point is that this bug seems to be present only on Apple devices but not on Android.

Anyway, there is nothing we can do about this but, fortunately, this misbehavior is completely harmless.

I'm not sure if a shortcut to hide them is meaningful, thoughts @moderators ?

My comment regarding the iPad Pro was not well thought out. Disregard.

I run a number of Pi-holes on my network, serving different subsets of clients. My wife's stuff is on some of them, and my stuff is on others. Reasons.

Here is what I found when I checked the most recent six days of dnsmasq logs - I see these from each of our IOS devices, hers more than mine.

zgrep "https://" /var/log/pihole.log* | grep query

/var/log/pihole.log.5.gz:Oct 25 14:55:25 dnsmasq[11039]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.125
/var/log/pihole.log.5.gz:Oct 25 12:50:22 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log.5.gz:Oct 25 06:10:46 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log.4.gz:Oct 26 16:08:17 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log.4.gz:Oct 26 15:25:51 dnsmasq[14596]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.134
/var/log/pihole.log.4.gz:Oct 26 12:43:05 dnsmasq[14596]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.134
/var/log/pihole.log.4.gz:Oct 26 09:08:43 dnsmasq[11039]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.125
/var/log/pihole.log.4.gz:Oct 26 08:22:08 dnsmasq[14596]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.134
/var/log/pihole.log.3.gz:Oct 27 19:32:23 dnsmasq[11039]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.125
/var/log/pihole.log.3.gz:Oct 27 18:06:06 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log.3.gz:Oct 27 16:01:55 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log.3.gz:Oct 27 12:51:51 dnsmasq[11039]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.125
/var/log/pihole.log.3.gz:Oct 27 12:16:12 dnsmasq[14596]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.134
/var/log/pihole.log.3.gz:Oct 27 10:28:53 dnsmasq[14596]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.134
/var/log/pihole.log.3.gz:Oct 27 10:15:05 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log.3.gz:Oct 27 05:39:00 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log.2.gz:Oct 28 21:15:29 dnsmasq[11039]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.125
/var/log/pihole.log.2.gz:Oct 28 16:07:46 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log.2.gz:Oct 28 14:53:57 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log.2.gz:Oct 28 12:40:09 dnsmasq[11136]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.134
/var/log/pihole.log.2.gz:Oct 28 08:31:42 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log.1:Oct 29 21:19:14 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log.1:Oct 29 19:38:22 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log.1:Oct 29 12:54:50 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log.1:Oct 29 11:10:58 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log.1:Oct 29 10:47:38 dnsmasq[11136]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.134
/var/log/pihole.log.1:Oct 29 08:09:55 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log:Oct 30 11:27:37 dnsmasq[8589]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.132
/var/log/pihole.log:Oct 30 11:26:03 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log:Oct 30 07:13:04 dnsmasq[11039]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.125

IP's as follows:
125 - her iPad Pro IOS 15
126 - her iPhone 12 IOS 15
132 - my iPad IOS 15
134 - my iPhone 7 Plus IOS 15

In my case, yes:

/var/log/pihole.log.1:Oct 29 08:09:55 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log.1:Oct 29 08:09:56 dnsmasq[23030]: query[A] app-measurement.com from 192.168.0.126
/var/log/pihole.log.1:Oct 29 08:09:56 dnsmasq[23030]: query[type=65] app-measurement.com from 192.168.0.126
...
/var/log/pihole.log.1:Oct 29 11:10:58 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log.1:Oct 29 11:10:59 dnsmasq[23030]: query[A] app-measurement.com from 192.168.0.126
/var/log/pihole.log.1:Oct 29 11:10:59 dnsmasq[23030]: query[type=65] app-measurement.com from 192.168.0.126
...
/var/log/pihole.log.1:Oct 29 12:54:50 dnsmasq[23030]: query[A] https://app-measurement.com/sdk-exp from 192.168.0.126
/var/log/pihole.log.1:Oct 29 12:54:50 dnsmasq[23030]: query[A] app-measurement.com from 192.168.0.126

Since this is not really a feature request at this point (we have an option to handle HTTPS queries via regex), I moved this to Community Help.

The reason I made it a feature request was if something could be implemented as below.

This is from the Pi-Hole Remote app. It does hide these from the query log when viewing through it.

I'll move it back to a Feature Request. It will accumulate votes like other open feature requests.

This is interesting and also somewhat misleading. As it says "hide HTTPS queries" under the title "TYPE", I'd have expected it to do exactly this: Hide queries with type HTTPS.

However, what you describe is that it hides all queries (also A type ones) when then domain starts in `https://... This is obviously something different. Or does it hide both kinds of queries?

I think that is a misunderstanding:
Pi-hole cannot hide any HTTPS requests, as it never even receives them.

Pi-hole is only receiving DNS requests - in your case, a request for an improper domain name of https://app-measurement.com/sdk-exp. Like any domain, that can be blocked (via they ways already discussed) and/or excluded via Pi-hole's API / Web interface UI.

The true fix for this would be for the app and kit developers to adjust their incorrect DNS requests.

I would not add an specific option to hide the mal-configured https://app-measurement.com/sdk-exp nor HTTPS (TYPE 65) requests. If at all, this feature would need to be way broader:

Since this query type is unique to Apple IOS, my preference would be to not implement this feature request. We don't selectively hide other requests that are unique to other platforms - root server queries from routers, etc.