Pi-hole FTL v5.9, Web v5.6 and Core v5.4 released

Your Raspberry Pi can block advertisements before they reach your devices with Pi-hole.

While internet advertising is a significant source of revenue for your favourite websites, including this one, some individuals want to prevent it for a variety of reasons, including performance or privacy concerns. You could install blocking software on each of your devices, but the most efficient method is to use Pi-hole to construct a server that filters all of your web traffic at the local network level.

Pi-hole is a network-wide ad-blocker that protects your network from advertisements and trackers without requiring any configuration on individual devices. Pi-hole can block advertising on any network device (such as smart appliances), and unlike browser add-ons, it can block adverts on any programme.

Update Highligts

  • Update embedded dnsmasq DNS server to version 2.86
    • Handle DHCPREBIND requests in the DHCPv6 server code
    • Fix bug which caused dnsmasq to lose track of processes forked to handle TCP DNS connections under heavy load
      The code checked that at least one free process table slot was available before listening on TCP sockets, but didn’t take into account that more than one TCP connection could arrive, so that check was not sufficient to ensure that there would be slots for all new processes. It compounded this error by silently failing to store the process when it did run out of slots. Even when this bug is triggered, all the right things happen, and answers are still returned. Only under very exceptional circumstances, does the bug manifest itself: see https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q2/014976.html 
    • Major rewrite of the DNS server and domain handling code
      This should be largely transparent, but it drastically improves performance and reduces memory foot-print when configuring large numbers domains of the form local=/adserver.com/ or local=/adserver.com/# Lookup times now grow as log-to-base-2 of the number of domains, rather than greater than linearly, as before. The change makes multiple addresses associated with a domain work address=/example.com/1.2.3.4 address=/example.com/5.6.7.8
      It also handles multiple upstream servers for a domain better; using the same try/retry algorithms as non domain-specific servers. This also applies to DNSSEC-generated queries. Finally, some of the oldest and gnarliest code in dnsmasq has had a significant clean-up. It’s far from perfect, but it is better.
    • Revise resource handling for number of concurrent DNS queries
      This used to have a global limit, but that has a problem when using different servers for different upstream domains. Queries which are routed by domain to an upstream server which is not responding will build up and trigger the limit, which breaks DNS service for all other domains which could be handled by other servers. The change is to make the limit per server-group, where a server group is the set of servers configured for a particular domain. In the common case, where only default servers are declared, there is no effective change.
    • Improve efficiency of DNSSEC
      The sharing point for DNSSEC RR data used to be when it entered the cache, having been validated. After that queries requiring the KEY or DS records would share the cached values. There is a common case in dual-stack hosts that queries for A and AAAA records for the same domain are made simultaneously. If required keys were not in the cache, this would result in two requests being sent upstream for the same key data (and all the subsequent chain-of-trust queries.) Now we combine these requests and elide the duplicates, resulting in fewer queries upstream and better performance. To keep a better handle on what’s going on, the extra logging mode has been modified to associate queries and answers for DNSSEC queries in the same way as ordinary queries. The requesting address and port have been removed from DNSSEC logging lines, since this is no longer strictly defined.
    • Allow wildcards in dnsmasq config domain patterns
      Domain patterns in --address, --server and --local have, for many years, matched complete labels only, so --server=/google.com/1.2.3.4 will apply to google.com and www.google.com but NOT supergoogle.com. dnsmasq now introduces an optional * at the LHS of the domain string which changes this behaviour so as to include substring matches within labels. So, --server=/*google.com/1.2.3.4 applies togoogle.com and www.google.com AND supergoogle.com
    • FTL also imported the requested feature to Support Cisco Umbrella/OpenDNS Device ID Remote IP FTL#1096 
    • Connection track mark based DNS query filtering
    • Allow smaller than 64 prefix lengths in synth-domain, with caveats. --synth-domain=1234:4567::/56,example.com is now valid.
    • Make domains generated by --synth-domain appear in replies when in authoritative mode.
    • Ensure CAP_NET_ADMIN capability is available when conntrack is configured.
    • When --dhcp-hostsfile --dhcp-optsfile and --addn-hosts are
      given a directory as argument, define the order in which files within that directory are read (alphabetical order of filename).

Read Full update: Pi-hole FTL v5.9, Web v5.6 and Core v5.4

Leave a comment

All comments are moderated before being published