When combining Pi-Hole with pixelserv-tls , the encrypted blocked connections can be answered by an HTTPS server instead of being completely dropped ( BLOCKINGMODE=IP ).
The way this works is that pixelsrv-tls generates a certificate dynamically that will match the Server Name sent in the SNI extension, which should end up passing verification by the client (if the CA used to generate such certificates is trusted).
While the connection will ultimately be blocked, the browser will attempt to establish such connections until it ultimately fails.
What would be great is if for blocked domains, there could be an option to also block the corresponding ESNI record. Right now this could mean answering with NXDOMAIN to _esni.blocked.domain.
It might be safe enough to enable by default when responding with an IP (BLOCKINGMODE=IP or IP-NODATA-AAAA)
Dropping all ESNI records with a regex is not an option as that would impact non-blocked domains.
While this is obviously the very beginning of this spec, I anticipate browser support to pick up soon. Both Firefox and Safari have preliminary implementations. And since CloudFlare supports basically 10% of internet traffic, I'm sure there are some commonly blocked domains already supporting this.
For now, this can still be disabled in the browser, however this may change in the future.
What worries me more is the usage of ESNI in devices you cannot control, such as built in telemetry, chromecast, …
I think that it would be very wise to anticipate this new spec will be implemented sooner or later and already have a defense against it.
@mathieuh
Unfortunately, I'm NOT smart enough to make a case for this to be implemented in dnsmasq. I would suggest to propose this enhancement to Simon Kelley.
@DL6ER to avoid a possible conflict with the changes made to dnsmasq in pihole-FTL, your input for this request may (will?) be required...
It's unlikely to impossible that dnsmasq makes a change that pihole-FTL could not incorporate.
I agree, but I also see that this should be done inside dnsmasq instead of having to add another hack in pihole-FTL. Implementing regex blocking was one thing, but adding this would have to be done in an even deeper region of the dnamsq cache code which is something I really don't like to do.
This thread is ageing a bit now, but I wanted to bump it now that both Firefox and Chrome's DoH trials are well underway and the protocol is becoming more normal.
I support this request from the original post entirely:
Use case
Like most people here, I run Pi-Hole locally on my LAN using Port 53.
When I take my laptop out of the network then the filtering stops working, because the local Pi-Hole instance is no longer available.
To fix this, I host my Pi-Hole instance in the cloud so I can access it from anywhere.
To avoid sending unencrypted DNS queries, my cloud-based Pi-Hole listens on DNS-over-HTTPS and this is where I point my browser.
Problem with Pi-Hole's current approach to ESNI
When ESNI is enabled in the browser, the browser makes TXT queries through Pi-Hole in the format: _esni.blocked.domain
Pi-Hole does not filter these queries, even for blocked domains, which can end up allowing the browser to access ESNI-enabled domains which should be blocked.
This is a significant proportion of filtered domains, as in theory it is any which are using Cloudflare.
This is useful for manually-added domains but I guess the reason for the feature request is that it would also be useful for Pi-Hole or dnsmasq automatically filter queries to _esni.* for any domains which are on the Gravity lists.
I don't think you would want these queries to be answered at all, regardless of the blocking mode.
It is necessary to implement an exception in FTL to achieve this as dnsmasq provided feature could serve this purpose. Fortunately, compared to when this feature request was raised initially (2018), the rewrite done for FTL v5.0 allows us to implement this efficiently and even fairly straightforward.
So I went along and implemented it. We now reply to all _esni.X requests with NXDOMAIN given X is blocked for any reason (exact or regex blacklist or due to a gravity list match). The reply type will always be NXDOMAIN regardless of the configured blocking mode.
Please test it carefully! Run
pihole checkout ftl new/block_esni
to get the version of FTL containing this new feature. Note that, while the new _esni blocking defaults to being enabled, however, it may be disabled by setting
BLOCK_ESNI=false
in /etc/pihole/pihole-FTL.conf. I don't think there is any reason for why it would need to be disabled, however, it certainly won't hurt.
And just to confirm, I've been running this since you pushed the test branch 8 days ago and it's worked perfectly and given me no problems in that time.
Looking forward to the v5.0 stable release.
thanks.