Recently updated to the FTLDNS beta and had issues when updating the block lists using Cloudflare DNS. If i change to Google it updates with no problems.
It seems to be the zeustracker.abuse.ch list that is gets stuck on, and Pi Hole then seems to fail updating any more lists and DNS stops working. Restarting the pihole-FTL service gets DNS running again until the next attempted list update.
Log from the update gui below:
[i] Neutrino emissions detected...
[β] Pulling blocklist source list into range
[i] Target: raw.githubusercontent.com (hosts)
[β] Status: Retrieval successful
[i] Target: mirror1.malwaredomains.com (justdomains)
[β] Status: No changes detected
[i] Target: sysctl.org (hosts)
[β] Status: No changes detected
[i] Target: zeustracker.abuse.ch (blocklist.php?download=domainblocklist)
[β] Status: Connection Refused
[β] List download failed: using previously cached list
[i] Target: s3.amazonaws.com (simple_tracking.txt)
[β] Status: Connection Refused
[β] List download failed: using previously cached list
[i] Target: s3.amazonaws.com (simple_ad.txt)
[β] Status: Connection Refused
[β] List download failed: using previously cached list
[i] Target: hosts-file.net (ad_servers.txt)
[β] Status: Connection Refused
[β] List download failed: using previously cached list
[β] Consolidating blocklists
[β] Extracting domains from blocklists
[i] Number of domains being pulled in by gravity: 144628
[β] Removing duplicate domains
[i] Number of unique domains trapped in the Event Horizon: 121618
[i] Nothing to whitelist!
[β] Parsing domains into hosts format
[β] Cleaning up stray matter
[β] DNS service is NOT running
Nope, just loads forever, Iβm guessing that maybe cloudflare do some sort of blocking? Perhaps they think the list is malware.
[Update] I now seem to be getting the same issue under other DNS providers too. Not sure if itβs my config? Was a fresh Raspbian install, PiHole installed and then upgraded to FTL. Static ip set via dhcpcd.conf
Whenever the request to too large to fit into a single UDP packet, applications retry with a TCP request. This commonly happens when you enable DNSSEC as the key info can be quite extensive. However, they are rarely used without DNSSEC, still, they could, in principle, be used for very large replies, e.g., when a huge number of IP addresses corresponds to a given domain.
TL;DR: Yes, DNS over TCP is part of the standard and disabling may have a negative effect, but it is unlikely that you experience it without DNSSEC.