Okay, static domain_name_server=1.1.1.1 sieht gut aus. Dann sollte auch /etc/resolv.conf nun bei 1.1.1.1 bleiben.
Oh, das ist also bereits ein v6 Skript. Dann ist das Update bei dir einmal bereits weiter fortgeschritten als ich dachte. Wichtig ist, dass /etc/.pihole und /opt/pihole auf dem gleichen Stand sind, und da /opt/pihole bereits v6 ist (ich dachte es wäre noch v5), muss /etc/.pihole ebenfalls auf v6 gebracht werden.
Das ist dann tatsächlich eine gute Lösung um alle Repositories auf den v6 Stand zu bringen. Der Befehl holt übrigens keine Abhängigkeiten, sondern synchronisiert die Dateien in /etc/.pihole (und ggf. /var/www/html/admin) mit denen auf dem Server. Entscheidend für pihole -up und pihole -r sind der Installer /etc/.pihole/automated\ install/basic-install.sh, welcher von beiden Befehlen aufgerufen wird, und vorweg einige seiner Funktionen. Oben hat pihole -up versucht build_dependency_package aus dem v6 Installer auszuführen, welches im v5 Installer noch nicht existiert.
Ein pihole -r danach macht ja genau dasselbe wie pihole -up, auch wenn die Repositories bereits auf dem aktuellsten Stand sind. Also noch mal die Kombination für @Eggi:
sudo pihole checkout master
sudo pihole -r
Da ist tatsächlich einiges durcheinander geraten, aber es war auch ein großes Update, mit nicht trivialen Migrationsschritten. Und da der Prozess/die Skripte insgesamt komplex sind, führen kleine Änderungen in A manchmal zu unerwarteten Nebenwirkungen in B. Beispielsweise habe ich beim Testen von frischen v6 Installationen nach dem Release festgestellt, dass das web UI ohne Passwortschutz dasteht, obwohl es dafür extra einen Check gibt, welcher im Falle eines nicht vorhandenen Passworts, ein zufälliges erstellen soll. Der Check hatte jedoch einen Fehler. Also habe ich den Fehler korrigiert, und in Open Source Manier einen Pull Request geöffnet, welcher zusammen mit einer anderen Fehlerkorrektur dann als v6.0.3 veröffentlich wurde. Was ich jedoch beim Testen von frischen Installationen nicht bemerkt habe: diese Korrektur führte zum Auslassen der Migration der alten Konfigurationsdateien bei Updates. Das Erstellen das Passworts, erstellt die neue Konfigurationsdatei, was vor den Migrationsschritten passierte. Die Migration wurde jedoch ausgelassen, sofern die neue Konfigurationsdatei bereits existierte. Inzwischen ist das das mit v6.0.4 behoben.
Dass die Skripte in /etc/.pihole teils nach /opt/pihole kopiert werden, /etc/.pihole bei beim Updateprozess sehr früh auf den aktuellen Stand gebracht wird, /opt/pihole jedoch sehr spät, birgt das Risiko dass beide Seiten verschiedene/inkompatible Versionen beinhalten können, wenn das Update in der Mitte abbricht. Es wäre sicherlich stabiler, wenn die Skripte aus /opt/pihole nicht auf Funktionen aus /etc/.pihole zurückgreifen, also so viel wie möglich vom Installer-Skript selbst erledigt wird, inklusive seines eigenen Updates. Aber das erfordert eine Umstrukturierung die wiederum Fehler mit sich bringen kann und ausgiebig getestet werden muss. Dass mit v6 alle Konfigurationsdateien ein /etc/pihole/pihole.toml zusammengefasst wurden, war eine ähnliche sehr sinnvolle Umstrukturierung, um Fehlerquellen durch Configs in diversen unterschiedlichen Ordnern zu vermeiden. Aber genau diese Migration selbst ist eben auch Fehleranfällig. Selbiges für das Einbetten des Webservers und PHP-Interpreters in pihole-FTL. Schaltet Fehler im Zusammenhang mit separaten Lighttpd und PHP Setups und unterschiedlichen Versionen (je nach Betriebssystem) aus, aber dann muss Pi-hole halt auf andere Ports umsteigen und/oder eine Logik für den Umgang des obsoleten Lighttpd einbauen, die offensichtlich ebenfalls bei einigen nicht ganz wie gewünscht gekappt hat.
Will sagen: Es wurde mit v6 sehr vieles in eine sehr sinnvolle Richtung zusammengefasst, was Pi-hole und seine Updates in Zukunft deutlich einfacher und fehlerfreier machen sollte. Genau solche größeren strukturellen Änderungen sind jedoch immer Fehleranfällig, bei der Vielzahl an Systemen und Setups, welche berücksichtigt werden müssen. Und Pi-hole ist kein kommerzielles Projekt, sondern rein Spendenfinanziert, wo Entwickler üblicherweise nicht ansatzweise für die Entwicklungszeit bezahlt werden können, sondern dies neben einem anderen Job tun. Da ist das Einführen von festen Testläufen aller Aspekte nicht einfach zu organisieren. Bei einem Großen Pi-hole Update (v5 => v6, v6 => v7) macht es also Sinn, ein Backup zu erstellen, und/oder das Update vorher auf einer geklonten Testinstanz zu testen, und Fehler ggf. zu melden. Wenn man dafür keine Zeit hat, ein paar Tage warten, dann sollten die gröbsten Probleme gelöst sein 
.
Übrigens @Steff du betreibst bei dir den Webserver noch aus einem anderen Grund, sodass die Ports 80/443 nicht von Pi-hole genutzt werden können? Der Lighttpd Webserver kann ja ansonsten deinstalliert werden, sodass Pi-hole 80/443 nutzen kann.
Da habe ich ja was zusammengeschrieben ... sorry für den Roman. Einen schönen Wahltag wünsche ich 
.