Das ist für (modernes) DNS heutzutage eigentlich zu wenig (und stand in #3 auch noch anders und damit "richtiger"). Denn da kann ganz schnell auch mal TCP verwendet werden - spätestens dann, wenn eine Antwort nicht mehr in das 512-Byte-Paket bei UDP paßt (EDNS (
RFC 6891) ist ein optionales Feature).
Zwar werden die ersten Einträge dann meist trotzdem übertragen und der Rest nur "abgeschnitten", aber gerade bei DNSSEC kann auch schon mal ein einzelner Eintrag dank größerer Signaturen nicht mehr in diese 512 Byte passen - gerne auch mal wg. IPv6-Adressen, die halt doppelt soviel Platz brauchen und auch die "Texte" für irgendwelche Namen sind da gerne mal deutlich länger (auch beim Reverse DNS) als bei IPv4.
Daher sollte man heutzutage immer UDP
und TCP für DNS-Server freigeben, wenn man nicht von Beginn an schon weiß, daß der Server (und/oder alle Clients) gar kein DNS over TCP unterstützt (was
RFC 7766 seit drei Jahren aber fordert - siehe "Introduction" dort).
Auch die Dokumentation zum "Pi-hole(R)" bezieht sich auf die Verfügbarkeit der Portnummer für die beiden (gebräuchlichsten) IP-Protokolle TCP und UDP:
https://docs.pi-hole.net/main/prerequesites/
Da hier ja jeder Client selbst seine Abfragen macht und viele bei abgeschnittenen UDP-Antworten danach auf TCP-Basis eine Wiederholung einer Abfrage starten (wenn sie nicht über EDNS-Support dann doch noch größere UDP-Pakete verkraften), kann das zu schwer zu findenden Problemen führen oder auch zu unerklärlichen Verzögerungen in der Auflösung von DNS-Namen. Das mag dann mit dem einen Client problemlos funktionieren (weil der mit EDNS umgehen kann), aber ein Client ohne EDNS-Support wartet sich dann einen Wolf (bis zum Timeout des Verbindungsversuchs), wenn die TCP-Umschaltung nicht möglich ist.
----------------------------------------------------------------------------------------------------------
BTW ... warum hast Du denn eigentlich nach #2 (erster Satz) und #3 (dritter Satz) noch so lange weiter diskutiert, anstatt das erst einmal zu machen? Dadurch entstand halt beim Leser der Eindruck, diese simple Portfreigabe wäre genau das, was Du nicht willst bzw. was Dir aus irgendeinem Grunde nicht reicht, weil da auch noch andere Zugriffe möglich sein sollen. Hättest Du das gleich vor oder direkt nach #3 einfach mal so eingestellt, wäre das hier vermutlich deutlich kürzer geworden.
----------------------------------------------------------------------------------------------------------
Generell mal zu diesen Blackhole-Servern beim DNS ... und deren (vermutlicher) Zukunft:
Spätestens dann, wenn sich DNS over HTTPS durchsetzen sollte bei den Browser-Herstellern und zur Standardeinstellung wird (Google und Mozilla arbeiten ja daran), muß man bei so einer Konstellation dann aber auch noch die einzelnen Browser so konfigurieren (können), daß diese ebenfalls den "Pi-hole(R)" als (DoH-)Server verwenden ... bisher gibt es dieses Feature aber m.W. im "Pi-hole(R)" noch nicht. Der unterstützte Proxy dient bisher nur dazu, die per DNS-Paket entgegengenommenen Anfragen beim Upstream über DoH aufzulösen, anstelle des "normalen" DNS-Protokolls.
Da aber so ein Blocker gerade für Browser ja i.d.R. verwendet werden soll, muß man am Ende die eingesetzten Programme auf den Clients dann noch genauer beobachten ... wenn diese auf DoH anstelle vom üblichen DNS setzen und dabei direkt einen Server im Internet/beim Provider befragen (z.B. die von Cloudflare), greift der schöne Ansatz in diesem Fall ins Leere ... das gilt natürlich auch für irgendwelche Apps, die ihre eigenen Abfragen über DoH abwickeln.
Es gibt ja bereits genug öffentliche DoH-Server (
https://github.com/curl/curl/wiki/DNS-over-HTTPS) und auf diesem Weg kann eine App oder ein IoT-Gerät eben auch leicht verhindern, daß irgendwelche Kommunikation (z.B. mit dem Hersteller) über simple "DNS-Sperren" blockiert wird (IP-Adressen werden da ja ohnehin schon nicht mehr verwendet, weil die noch einfacher zu blockieren sind, sofern sie irgendwo fest verdrahtet sind).
Man darf sich also auch mit einem solchen Blackhole-Server für DNS-Abfragen nicht zu sicher fühlen ... seit DoH (und der Standardisierung) und der Verfügbarkeit der entsprechenden Server für öffentliche Abfragen, werden dabei eigentlich nur noch "die Dummen" blockiert (auch wenn das natürlich besser ist als nichts und gegen unerwünschte Werbung ggf. helfen mag) - Malware oder auch "geschwätzige" Geräte wird man auf diesem Weg vermutlich nicht mehr lange am Reden hindern können ... da braucht's dann doch wieder die Paket-Filterung.
Hier haben dann die Werbeblocker im Browser (z.B. uBlock Origin) doch wieder die besseren Karten, weil sie die betreffenden Links bzw. Requests schon sehen, bevor die DNS-Abfrage gestartet wird und damit davon unabhängig sind, auf welchem Wege die Auflösung erfolgt.
Am Ende wird man also vermutlich in der Zukunft bei einer Kombination aus beidem landen (Adblocker + DNS-Blackhole) ... quasi bei einer zweistufigen "Verteidigung".
