Pi-hole 4.3 Now Available

Originally published at: Pi-hole 4.3 Now Available – Pi-hole

Today, we’re pleased to announce the release of Pi-hole 4.3! Thank you to to our patrons and everyone else who continue to support us.


Network Information Table

We have added a new page to the web interface which displays some enhanced information about the devices on your network.


Fixes And Tweaks

  • Improved support for HTTPS on the block page
  • We have removed jQuery Input mask, which prevented correct entry of IP addresses on mobile
  • Fixed a vulnerability in the web interface that could have triggered remote code execution when adding or removing white/blacklist entries.
  • Support for more granular debugging configurations for FTL

More information can be found at https://changes.pi-hole.net


A post was split to a new topic: V4.3 FTL download and dns-servers.conf issue

On my odroid xu4 running Debian and last pihole the network information table is empty. How can I fix this?

Here debug token


On my raspberry pi running pihole it works.

Fixed it by deleting /etc/pihole/pihole-FTL.db followed by pihole -r

Seems that database was malformed.

Works perfectly fine on 2 RPi3B+. I completed apt update with 6 new updates and everything is running smooth.

Here is a guide to installing Pi Hole :slight_smile: https://valhallagroup.ltd/network-wide-ad-blocker/

So far so good with this update. The new network page provides a good summary of devices that have been seen and if they use the pi-hole.

4 posts were split to a new topic: Flushing the ARP cache to remove stale entries - Network Overview

A post was split to a new topic: Debian Sid - Network Overview

A post was merged into an existing topic: Flushing the ARP cache to remove stale entries - Network Overview

Will pi-hole be adding the options to use encrypted dns like cloudflare offers?

A post was split to a new topic: DNS cache after 4.3 update

Personally I use:
OpenVPN -> pihole -> unbound -> root dns.

and traffic between unbound and root dns is encrypted (if I'm not mistaken.)
so my VPN encrypts all traffic and unbound does the same with dns requests.

This traffic is not encrypted. Is is authenticated, but the data is in clear text.

:cold_face: ... oookaay ... #ActingLikeALostGuy When will the official support of the DNS-over-TLS be available? :blush:

We are not involved in the development of unbound. However, looking at man unbound, I see an option called forward-tls-upstream: yes which seems to suggest using TLS.

Note that using DoT has several disadvantages, the most severe one being that you cannot use TLS encryption to the root servers, instead, you have to specify upstream providers that support DoT (e.g. Quad9 or CF). In my eyes, this causes additional problems because you allow them to collect your DNS queries which is exactly what you prevent by querying the root servers directly with unbound. Also, this just encrypts the traffic between you and the upstream provider. It does not protect their requests to the root servers so you should only consider this when you are in a situation where you can ultimately trust these providers (offering an expensive service for free... :thinking: ) and cannot trust your own ISP (whom you pay money for their service).

1 Like

I read your answer carefully. And I thank you for that. you have noticed, I suppose, that I have no confidence in the Internet service providers as to their discretion on DNS requests. This is also the reason why I chose to directly query the root servers. So I will stay on my current configuration, even if the flow goes unencrypted between unbound and root DNS servers.

I already have the latest version of Pi-hole because I am a new user, but in the future how do we update? or does the update automatically get pushed?

pihole -up from CLI

1 Like

Also keep in mind that DoH / DoT is not the holy grail for privacy. Your ISP (and others) will still be able to see where you connect to.

Think of it like this:

DNS is like asking someone for directions. After you got them, you go there. So even if you trust the person whom you got the directions from more than your ISP, your ISP can still just follow you walking over there and see who you visit.

Example: when your laptop gets a DNS reply from somewhere (e.g.: ISP, root server, anything upstream really) for website.com, and receives IP address as a reply... then your browser connects to which is visible to your ISP (and others upstream). Even when the DNS query was done over DoT or DoH.

It does not matter even if the IP you connect to hosts multiple websites. While TLS (HTTPS) may encrypt the HTTP-protocol host-header which is needed for virtual hosts, its SNI outside of the encrypted stream that is easily readable for anyone along the way.

Folks are working on ESNI, which could encrypt this. But this is far from being the standard yet. It also is far from being perfect, as the ESNI proposal still has a flaw in the design itself.

Even with ESNI or an improved successor, your ISP and others "along the way" will still be able to see which IP you connect to. So its not hard to figure out what site you visit if "they" wanted to.

Since its a rather complex topic, with lots of stuff involved, let me try somewhat to give an overview:

Browser ad-blocker

  • Versatile in blocking individual ads and objects in content.
  • Not protecting all of your network or device, just 1 browser.


  • Protecting all of your network and devices, if configured right.
  • Can only block on a DNS (domain) level, not individual ads and objects in content.


  • Prevents parties from viewing/altering the content you receive and send.
  • Does not hide what sites you connect to.
  • Could be circumvented by ISP's using MitM (for DPI/content-injection).


  • Prevents parties from altering DNS responses along the way back to you.
  • Handy to prevent DNS-based ad-injections by ISP's and other foul play.
  • Does not protect against ISP content-injected ads.


  • Prevents parties from viewing DNS queries & responses to some extend.
  • Root servers do not offer encryption, so you will need a third-party (can you trust them?).
  • The "last mile" to the root servers is always unencrypted (thus far).
  • You can host your own DoH script on an external server, as an alternative to Google/CF/Quad9.
  • No true privacy benefits against ISP's, since you connect through them after you received your DNS response anyways.


  • More privacy (your ISP can't see what you visit, unlike just DoH/DoT). But your VPN provider can.
  • Costs money (faster/decent ones do at least).
  • Only as good as you trust them to be (do they really not keep logs or mess with your connection?).
  • Harder to do your own DNS (e.g.: use pi-hole as an (ad-)blocker) out-of-the-box.

As you can see filtering out ads and other bad stuff, and also keeping a high level of privacy, is a major undertaking that requires a combination of techniques and a lot of technical know-how. And even then its never perfect I'm sure.