AdGuard – Internetfilter einrichten, aber gründlich!

Allgemein Linux Windows

Auf die Frage, was jetzt besser ist – AdGuard, PiHole oder doch Filter XYZ – möchte ich hier gar nicht näher eingehen, denn das ist eine Glaubensfrage. Das Grundprinzip ist bei allen DNS-Filtern ähnlich.

Beschäftigen wir uns erst einmal grundlegend mit DNS, um zu verstehen, was wir im folgenden alles machen werden bzw. zu verhindern wissen wollen. DNS ist (fast) so alt wie das Internet und wandelt Domainamen in IP-Adressen um und umgekehrt, dies geschieht auf Port 53 UDP. Der Client stellt eine Anfrage an Port 53 UDP beim DNS-Server, der ermittelt eine passende Antwort (Details siehe https://de.wikipedia.org/wiki/Domain_Name_System) und liefert das Ergebnis an den Absender zurück. Dabei können die Antworten unterschiedlich sein, man spricht oft von A- oder auch AAAA-Records, CNAME, SOA u.s.w.
Lass mich das knapp zusammenfassen, sonst wird dieser Beitrag schlichtweg zu groß.

  • A – die Antwort enthält eine oder mehrere IPv4-Adressen
  • AAAA- die Antwort enthält eine oder mehrere IPv6-Adressen
  • CNAME – die Antwort enthält mögliche Alias-Namen für die Domain/Rechner
  • SOA – die Antwort enthält den Server, der die Antworten letztendlich geliefert hat

Es gibt natürlich noch weitere Records und Verfahrensweisen (z.B. Port 53 TCP für Zonentransfers), aber das soll hier nicht das Thema sein. Viel mehr möchte ich die Installation und Konfiguration innerhalb einer Docker-Instanz beschreiben, die auf einem virtuellen Server im Internet läuft. Natürlich kannst du AdGuard auch nativ auf einem kleinen Server wie einen Raspberry Pi oder vergleichbaren installieren. Du kannst AdGuard auch auf einem Server in deinem LAN laufen lassen. Extern hast du aber so einige Vorteile, gerade in Verbindung mit der Fritzbox und Gastnetzen. Und einen vServer bekommst du auch schon für weniger als 5€ im Monat.

Am Ende dieser Anleitung hast du ein Setup, bei dem Nutzer im LAN/WLAN (inkl. Gäste-Netz) den Internet-DNS-Filter nicht einfach durch Ändern in eigene DNS-Einstellungen auf dem Endgerät umgehen können, wie es in so vielen Anleitungen beschrieben wird. Auf lange Sicht wird das Generieren von DNS-Filtern auf der einen und das Umgehen auf der anderen Seite immer ein Katz-und-Maus-Spiel bleiben. Ich werde versuchen, diesen Blogbeitrag dahingehend immer aktuell zu halten, damit du als Admin Herr deiner DNS-Filter bleibst und die auch definitiv in deinem Netzwerk Anwendung finden.

DNS auf Port 53 hat das Problem, das sämtliche Anfragen und Antworten im Klartext erfolgen, sprich wer auf der Leitung die Bits mitliest (Wireshark, etc.) kann auch sehen, welche Adressen jemand ansurft. Inzwischen gibt es verbesserte Varianten für Namensauflösungen, die verschlüsselt arbeiten können, z.B.:

  • DNS over TLS (DoT), welcher den Transport Security Layer als Transportverschlüsselung nutzen,
  • DNS ober HTTPS (DoH), welcher eine HTTPS-TCP-Session während der kompletten Sitzungsdauer als Verschlüsselung nutzen
  • DNS over QUIC (DoQ), DNS auf Basis von Googles Quick UDP Internet Connections (QUIC)

Spätestens der DNS-Server muss die Anfragen interpretieren können und deshalb ist genau das auch der Ort, wo Filterlisten installiert werden. Sobald eine dieser Anfrage für eine Adresse kommt, die in der Filterliste steht, dann antwortet der DNS-Server einfach mit einem falschen A- oder AAAA-Record, zum Beispiel IPv4 0.0.0.0. Im Egebnis bekommt der Client zwar eine Antwort zu einer Domainanfrage, aber den Inhalt (Werbung z.B.) dort z.B. kann er nicht abrufen, da unter der IPv4 0.0.0.0 dieser gar nicht liegt.

Schauen wir uns zunächst die Konfiguration von DHCP und DNS auf der Fritzbox näher an. Dazu nutze ich ein Lab, anhand ich die Konfiguration erläutern werde.

                                                                 +----------------------+
                                                                 |vServer           DNS |
                                                                 |Docker                |
                                                                 |AdGuard               |
                                                                 |203.0.113.1           |
                                                                 |Domain MyAdGuard.dns  |
                                                                 +-------------------+--+
+-------------------+                                                                |
| LAN/WAN        PC |                                                                |
| DHCP              |                                                                |
| 192.168.178.0/24  |        +---------------------------+       +----------+      +-+------+
| GW 192.168.178.1  |        | Router                    |       | Internet |      |        |
| DNS 192.168.178.1 +--------+ FritzBox                  +-------+ Service  +------+ GROBI  |
+-------------------+        | DHCP-Server               |       | Provider |      |        |
                             | 192.168.178.1             |       +----------+      +--------+
+-------------------+        | 192.168.179.1             |
| Gäste LAN/WAN  PC +--------+ DNS 203.0.113.1           |
| DHCP              |        |     (Domain MyAdGuard.dns)|
| 192.168.179.0/24  |        +---------------------------+
| GW 192.168.179.1  |
| DNS 192.168.179.1 |
+-------------------+

Die oben dargestellte Fritzbox hat ein Standard LAN/WLAN und das Gast-WLAN aktiviert und stellt für beide Netze den DHCP-Server und das Default Gateway. Im LAN/WLAN im Subnetz 192.168.178.0/24, im Gäste-Netz 192.168.179.0/24. Das Gateway und der Standard-DNS-Server ist jeweils die erste IP in dem jeweiligen Subnetz. Soweit alles Standardwerte der Fritzbox. Du kannst zwar in den DHCP-Einstellungenunter Heimnetz/Netzwerk/Netzwerkeinstellungen/weitere Einstellungen/IP-Adressen/IPv4-Einstellungen bereits einen anderen DNS-Server angeben, allerdings greifen diese Einstellungen nicht im Gäste-Netz, da ist der DNS immer 192.168.179.1. Wenn eine DNS-Anfrage auf der Fritzbox ankommt, dann wird diese, sofern kein Eintrag im Cache vorliegt, an einen der voreingestellten DNS-Server unter Internet/Zugangsdaten/DNS-Server (hier DNS 203.0.113.1) weitergeleitet. Allein deshalb ist es ungünstig, AdGuard home im lokalen Netz laufen zu lassen. Beachte bitte die Unterscheidung der DNS-Einstellungen in der Fritzbox im Bereich DHCP und Zugangsdaten – das ist nicht dasselbe!
Die IP-Adresse des DNS-Server 203.0.113.1 und dessen Domain-Name MyAdGuard.dns sind fiktive Werte, diese musst du mit deinen realen Werten ersetzen. IPv6 blenden wir erst einmal aus.

Aber zunächst setzen wir den DNS-Server, hier AdGuard home, auf. Ich gehe davon aus, das du Docker bereits lauffähig hast (wie das geht, habe ich in diesem Blogbeitrag beschrieben). Im Gegensatz zu vielen anderen Dockerinstanzen benötigst du hier noch ein wenig Vorarbeit. Du musst dir auf deinem Host-System (also da wo Docker läuft) zwei Ordner erstellen, die später für AdGuard zum einen als Arbeitsverzeichnis und zum anderen als Konfigurationsverzeichnis dienen. Wo du die erstellst, ist grundsätzlich deine Entscheidung. Ich empfehle dir, um die Dateistruktur von Linux zu erhalten, entweder ein Unterverzeichnis von /var oder /opt – ich habe mich hier für /var entschieden:

# mkdir /var/adguardhome
# mkdir /var/adguardhome/work
# mkdir /var/adguardhome/conf

Welches Verzeichnis hier für was vorgesehen ist, muss ich sicherlich nicht weiter erläutern. Dann starten wir mal gleich unsere Docker-Instanz von AdGuard:

# docker run --name adguardhome \
    -v /var/adguardhome/work:/opt/adguardhome/work \
    -v /var/adguardhome/conf:/opt/adguardhome/conf \
    -p 53:53/tcp -p 53:53/udp \
    -p 3000:3000/tcp \
    -p 853:853/tcp \
    -d adguard/adguardhome

Wie du vielleicht bemerkst, unterscheidet sich der Aufruf hier von der offiziellen Dokumentation, ich erläutere im folgenden, für was die einzelnen Optionen zuständig sind:

–name verhindert, das als Name irgendetwas zufälliges generiert wird (hier speziell adguardhome)
-v definiert Volumes nach dem System Quelle:Ziel (hier Arbeits- und Konfigurationsverzeichnisse)
-p 53… bestimmt, das der Port 53 (DNS) auch von außen erreichbar ist, ohne Nutzung von Zonen und DNS-Zonentransfers reicht UDP im Grunde schon aus
-p 3000… defineirt, das die Administrationsoberfläche unter Port 3000 von außen erreichbar ist
-p 853… definiert, das DNS over TLS (DoT) von außen erreichbar ist und du auch verschlüsselte Anfragen an deinen DNS-Server stellen kannst

Folgende Optionen habe ich nicht aktiviert:

-p 80:80/tcp ermöglicht den Zugriff per HTTP auf den DNS-Server – das ist aus meiner Sicht unnötig (außer ggf. für Zertifikatserstellung)
-p 67:67/udp -p 68:68/tcp -p 68:68/udp wird nur für DHCP benötigt und da mein DNS-Server nicht im lokalen Netzwerk betrieben wird, kann ich mir die Freigabe der Ports auch sparen (DHCP macht die Fritzbox)
-p 443:443/tcp habe ich ausgelassen, da ich kein DNS über HTTPS (DoH) möchte. DoH bringt für den Nutzer viele Vorteile, für dich als Admin mehr Probleme, da der Nutezr mit DoH grundsätzlich sämtliche Filterregeln umgehen kann. Aber auch dagegen ist ein Kraut gewachsen, das erläutere ich dir später in diesem Beitrag
-p 784:784/udp ist DNS over QUIC, eine DNS-Technik, eine noch recht junge DNS-Technik, die ich in meinem Setup nicht unterstützen möchte
-p 5443:5443/tcp -p 5443:5443/udp wird für DNScrypt benötigt, auch eine Technik, die ich in meinem Setup nicht unterstütze

Im Anschluss kannst du über http://Docker-Host-IP:3000 bzw. direkt auf dem Docker-Host mit http://127.0.0.1:3000/ die Konfigurationsseite öffnen, einige notwendige Einstellungen treffen bzw. Filterliste importieren. Eine wichtige Einstellung, gerade wenn der DNS-Server im Internet steht und Anfragen nicht vom Endclient, sondern von Routern bekommt, wie in unserem Szenario), solltest du unter Einstellungen/DNS-Einstellungen/DNS-Serverkonfiguration den Begrenzungswert auf 0 stellen, da ansonsten ziemlich schnell dein Router wegen zu vielen Anfragen in zu kurzer Zeit geblockt wird.

Solltest du auf deinem vServer den NGINX Proxy Manager einsetzen, musst du selbstverständlich noch eine Weiterleitung auf Port 3000 einrichten.

Fröhliches filtern…

Du kannst deine AdGuard-Installation testen, in dem du deinem Client manuell die IP deines AdGuard-Home als DNS einträgst (hier fiktiv 203.0.113.1). Anschließend sollte dein Internet noch immer funktionieren und auf im AdGuard-Webinterface siehst du unter Anfragenprotokoll die von dir soeben aufgerufenen Seiten im Browser (und etliche weitere Anfragen, die dein PC so im Hintergrund macht).

Du kannst vordefinierte Filterlisten in AdGuard unter Filter/DNS-Sperrliste/Sperrliste hinzufügen oder im selben Unterpunkt auch eigene Listen hinzufügen. Eine aus meiner Sicht sehr gute Quelle für regelmäßig aktualisierte Filterlisten ist das Blocklist Project, schön aufgeteilt in verschiedene Kategorien.

Wenn das wie gewünscht funktioniert, gehen wir einen Schritt weiter. Stelle deine DNS-Testeinstellungen im PC wieder auf „…automatisch beziehen“ zurück und ändere stattdessen die DNS-Einstellungen im Router. Ändere dazu den 1. DNS-Eintrag unter Internet/Zugangsaten/DNS-Server auf die IP-Adresse deines neuen DNS-Server ab und lass die 2. Zeile einfach leer. Du kannst auch für den 2. DNS-IPv4-Eintrag und die beiden IPv6-Einträge meine im Bild dargestellten Adressen nutzen, dabei handelt es sich um die Cloudflare-DNS-Server mit Malware- und Familien-Filter, die gem. den Einstellungen später dein DNS-Backup sein sollen, wenn dein Server mal down ist. Dann hast du noch immer einen guten Grundschutz vor malware, Phishing und nicht ganz jugendfreien Inhalten.

Jetzt nutzen grundsätzlich alle Clients in deinem Heimnetzwerk deinen eigenen DNS-Server AdGuard home. Grundsätzlich? Ja grundsätzlich, denn es gibt etliche Geräte, die so wie du eben bei deinem Test ihre eigenen DNS-Einstellungen mitbringen und somit immer deinen DNS-Server links liegen lassen. Geräte von Google sind da so ein Beispiel, die nutzen per default 8.8.8.8 oder 8.8.4.4 unabhängig von deinen DHCP-Vorgaben, aber auch dafür habe ich eine Lösung, die ich dir später in diesem Beitrag erläutere. Eins nach dem anderen.

DNS over TLS (DoT) – verschlüsselte DNS-Abfragen mittels TLS

Bislang ist unser Setup recht einfach – wir kümmern uns nur um Anfragen auf Port 53 UDP. Im nächsten Schritt sorgen wir dafür, das zwischen Fritzbox und AdGuard Home verschlüsselt kommuniziert wird -dein provider muss nicht mitlesen, welche Domains aus deinem Netzwerk erreicht werden sollen. Die Fritzbox unterstützt von Haus aus DoT. Dafür benötigen wir zunächst ein Zertifikat. Dein Server (mit Docker, AdGuard home u.s.w) braucht also neben einer IP-Adresse auch eine Domain (oder Subdomain), die kannst du bei deinem Server-Betreiber beantragen. Im meinem Lab habe ich MyAdGuard.dns als Domain registrieren lassen (rein fiktiv) und du kannst deine AdGuard-Oberfläche jetzt unter http://MyAdGuard.dns:3000 erreichen. Jetzt holen wir uns ein passendes Zertifikat für unseren DNS-Server bei Let’s Encrypt.

Wie immer gibt es mehrere Wege, an ein Zertifikat zu kommen, ich erläutere die hier einen recht einfachen mittels CertBot. Logge dich dazu in deine AdGuard-Docker-Instanz mit Root-Rechten und installiere zunächst snapd.

$ sudo apt update
$ sudo apt install snapd
$ sudo snap install core; sudo snap refresh core

Als nächstes wird Certbot installiert.

$ sudo snap install --classic certbot

Im kommenden Schritt stoppst du deine AdGuard-Instanz und holst dir die Zertifikate (ein paar Fragen (zu registrierende eMail-Adresse, Domain, EULA, etc. musst du schon beantworten) und startest AdGuard wieder.

$ sudo docker stop adguardhome
$ sudo certbot certonly --manual --preferred-challenges=dns
$ sudo docker start adguardhome

Bei Erfolg bekommst du 2 Dateien, welche du in deiner AdGuard-Oberfläche unter Einstellungen/Verschlüsselungseinstellungen speicherst (copy&paste):

  • fullchain.pem – dein PEM-codiertes SSL-Zertifikat
  • privkey.pem – dein PEM-codierter privater Schlüssel

Diese liegen in deinem aktuellen verzeichnis und kannst du mit cat anzeigen lassen:

$ cat fullchain.pem
$ cat privkey.pem

Sollte dir die DNS-Challenge nicht gelingen, kannst du ggf. auch komplett manuell ein Let’s-Encrypt-Zertifikat erstellen, ggf. musst auch du die Anwendung, die auf Port 80 auf deinem Server zugreift (bei mir NGINX Proxy Manager), beenden (das Zertifikat ist 3 Monate gültig und der Vorgang muss dann wiederholt werden):

root@adguarddns:~# certbot certonly --standalone
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Please enter the domain name(s) you would like on your certificate (comma and/or
space separated) (Enter 'c' to cancel): myadguard.dns
Renewing an existing certificate for myadguard.dns

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Could not bind TCP port 80 because it is already in use by another process on
this system (such as a web server). Please stop the program in question and then
try again.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<-- an der Stelle habe ich den NGINX Proxy Manager (TCP port 80) beenden müssen
(R)etry/(C)ancel: R

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/myadguard.dns/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/myadguard.dns/privkey.pem
This certificate expires on 2021-09-07.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
root@adguard.dns:~# cat /etc/letsencrypt/live/myadguard.dns/fullchain.pem
-----BEGIN CERTIFICATE-----
MIIFHTCCBAWgAwIBAgISBDOObfp8LJ2ZtwVkuY+0yv+wMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTA5MDUwNDE3MDdaFw0yMTEyMDQwNDE3MDZaMBYxFDASBgNVBAMT
...
Der Status sollte in beiden Fällen grün werden.

Wenn du später die Zertifikate erneuern möchtest, wiederholst du einfach diese Schritte.

Als nächstes gehst du wieder in die Admin-Oberfläche deiner Fritzbox und gibst im Textfeld unter Internet/Zugangsdaten/DNS-Server bei DoH (ganz unten) myadguard.dns an und aktivierst die Haken wie im Bild zu sehen. Nach einem Klick auf Übernehmen solltest du in den Online-Verbindungsdaten erkennen, das ab jetzt myadguard.dns als Standard-DNS genutzt wird, natürlich DoH-verschlüsselt.

Das kannst du auf der Übersichtsseite der Fritzbox verifizieren, entscheidend ist die Zeile 203.0.113.1 (aktuell genutzt für Standardanfragen – DoT verschlüsselt):

Das war es im großen und ganzen – jetzt kommen noch die Feinheiten. Was hast du bislang erreicht – fassen wir kurz zusammen?

  1. du hast einen eigenen DNS-Server aufgesetzt und konfiguriert
  2. du hast Standard-Filterlisten und möglicherweise eigene Filterlisten hinzugefügt
  3. du hast deinen neuen eigenen DNS-Server als Standard-DNS in deiner Fritzbox angegeben, so dass alle Clients standardmäßig per DHCP auf deine Fritzbox verwiesen werden, diese wiederum auf deinen AdGuard home
  4. du hast sichergestellt, das DNS-Kommunikation zwischen deiner Fritzbox und Adguard home verschlüsselt stattfindet

Kümmern wir uns jetzt um diejenigen Clients, welche der Meinung sind, sie müssten deinen vorgebebenen DNS-Server umgehen. Bekanntermaßen existieren dafür etliche Anleitungen im Internet, hier deine und meine Antwort darauf.

individuelle DNS-Einstellungen blockieren

Zuerst verhindern wir, das Clients eigene DNS-Server in ihren Netzwerkeinstellungen hinterlegen und nutzen (so wie du oben bei deinem ersten DNS-Test). Zugegebenermaßen kannst du ersteres nur schwer verhindern und schon mal gar nicht, wenn du keinen Admin-Zugriff auf das Gerät hast. Aber du kannst verhindern, das der Client auf Port 53 UDP in deinem Netzwerk DNS-Anfragen zu externen Servern verschickt, indem du dir unter Internet/Filter/Listen/Netzwerkanwendungen einen neuen Eintrag erstellst (DNS) und Port 53 UDP (am besten gleich auch 853 TCP für DoT) als Ziel angibst.

Netzwerkanwendung DNS erstellen/bearbeiten

Anschließend bindest du die Netzwerkanwendung an das entsprechende Zugangsprofil. Dazu musst du wissen, das die Fritzbox Zugangsprofile und Filterliste nur für das Forwarding (Weiterleiten) der IP-Pakete heranzieht, sprich wenn Pakete aus dem LAN ins WAN geroutet werden sollen. Wenn der Client die DNS-Anfrage an den DNS-Server der Fritzbox (192.168.178/179.1) stellt, geht das Paket zur Fritzbox, diese verarbeitet es und schickt es mit ihrer Absenderadresse zu deinem DNS-Server AdGuard home (deshalb greifen die Forwarding-Regeln der Firewall nicht und nur diese Pakete mit Ziel UDP 53 können diese ungehindert passieren).

DNS Pot 53 UDP und DoT Port 853 TCP anlegen
Netzwerkanwendung DNS und Blacklist an gewünschte Zugangsprofile binden (hier nur Gast und Test)

Mit ntopng und Wireshark kannst du gut erkennen, das der Router die DNS-Anfrage blockt und freundlicherweise ein ICMP-Paket zum Absender schickt:

blockierte DNS-Anfrage in Wireshark
versuchter DNS over HTTPS-Aufbau in ntopng, auffällig sind die vielen offenen Sessions

Also für das Ändern der DNS-Einstellungen im Betriebssystem hast du jetzt eine Gegenwehr. In dem Zusammenhang kannst du gleich ein paar DNS-Server in die Blacklist (gesperrte Internetseiten) legen, denn das hat 2 Vorteile. Zum einen lassen sich die IP-Adressen dieser Server nicht mehr von lokalen Clients auflösen und zum anderen werden nur noch Domains und URLs im Browser der Clients zugelassen. Die Fritzbox sperrt bei aktivierter Blacklist automatisch die direkte Eingabe von IP-Adressen im Browser (HTTP/HTTPS). Die Blacklist ist im Screenshot oben bereits an die Profile Gast und Test gebunden.

DNS over HTTPS (DoH) blockieren

Mit DNS über HTTPS (DoH) ist seit einiger Zeit eine weitere Methode für verschlüsselte DNS-Lookups unterwegs. Aus Sicht des Endnutzers eine tolle Sache, als Admin willst du das nicht in deinem Netzwerk haben. Der Client, z.B. der Browser Firefox, baut eine HTTPS-Verbindung zu einem unterstützenden DNS-Server auf und hält diese über die komplette Sitzungsdauer. DNS-Anfragen werden dann praktisch in dieser HTTPS-Verbindung „getunnelt“. Mmh, als Admin kannst du jetzt nicht HTTPS blockieren, denn dann wäre überhaupt kein Surfen für den Nutzer mehr möglich. Im Grunde bräuchtest du an dieser Stelle eine Layer7-Firewall, eine sogenannte Application Layer Firewall (ALF), welches die bestehende SSL-Verbindung aufspaltet, in die IP-Pakete hineinschaut, um zu prüfen, ob der HTTPS-Stream jetzt Webseite-Daten oder DNS transportiert. Dies setzt wiederum voraus, das du auf dem Client ein SSL-Server-Zertifikat deiner ALF installieren musst – ganz schön viel Aufwand also (aber nicht unmöglich). Das hat man aus Sicht der IT-Sicherheit schnell verstanden und Firefox hat auch gleich eine Lösung parat, die wiederum etwas Konfigurationsaufwand auf deinem DNS-Server bedarf, aber alles nicht so kompliziert. Lass mich zunächst erläutern, wie die DoH funktioniert und wo die Abwehr ansetzt: die Canary domain use-application-dns.net.

Beim Start vom Firefox mit aktivierten DoH sendet der Broswer eine DNS-Anfrage (Port 53 UDP) an den voreingestellten DNS-Server vom Betriebssystem. Dieses Lookup erfolgt auf die sogenannte „Canary Domain“ use-application-dns.net. Jetzt kommt es auf die Antwort des DNS-Server an, was im Anschluss passiert:

  • Die Antwort enthält keinen NOERROR (NXDOMAIN, SERVFAIL) -> DoH bleibt deaktiviert
  • Die Antwort enthält einen NOERROR, aber A- und AAAA-Record sind leer -> DoH bleibt deaktiviert
  • Die Antwort enthält einen NOERROR und es wird ein A- oder AAAA-Record geliefert -> DoH wird aktiviert

Also abhängig vom Ergebnis wird DoH im Anschluss aktiviert oder nicht. Wenn der DNS-Server zu use-application-dns.net eine IP-Adresse liefert (diese Domain gibt es wirklich und erläutert die Wirkungsweise in englisch), dann aktiviert Firefox DoH und nutzt nachfolgend eine HTTPS-Verbindung zu einem vom Nutzer eingestellten DNS-Server (vermutlich nicht deiner mit den Filterlisten). In den beiden anderen Fällen bleibt DoH deaktiviert. Du musst also sicherstellen, das dein DNS-Server unter keinen Umständen einen A- oder AAAA-Record zu dieser Canary Domain zurückliefert. Außerdem ist es wichtig, dass die Domain bereits blockiert ist, während dieser einmalige Test läuft. Wird die Domain erst später blockiert, hat das auf ein bereits aktiviertes DoH keine Auswirkung (bis der Client oder Firefox neu gestartet wird). Hier mal ein Beispiel der DNS-Anfrage/Antwort zuerst an AdGuard (203.0.113.1 liefert Status NXDOMAIN) und anschließend an Cloudflare:

$ dig use-application-dns.net @203.0.113.1

; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> use-application-dns.net @lowcarbo.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29490
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;use-application-dns.net.	IN	A

;; AUTHORITY SECTION:
use-application-dns.net. 10	IN	SOA	fake-for-negative-caching.adguard.com. hostmaster.use-application-dns.net. 100500 1800 900 604800 86400

;; Query time: 10 msec
;; SERVER: 203.0.113.1#53(203.0.113.1)
;; WHEN: Do Jul 15 11:41:28 CEST 2021
;; MSG SIZE  rcvd: 171

Beachte den Unterschied in der ANSWER-Section – Status jetzt NOERROR und mehrere IPs:

$ dig use-application-dns.net @1.1.1.1

; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> use-application-dns.net @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63655
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;use-application-dns.net.	IN	A

;; ANSWER SECTION:
use-application-dns.net. 372	IN	A	44.235.246.155
use-application-dns.net. 372	IN	A	44.236.72.93
use-application-dns.net. 372	IN	A	44.236.48.31

;; Query time: 15 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Do Jul 15 11:41:47 CEST 2021
;; MSG SIZE  rcvd: 100

Doch wie setzt du das jetzt auf deinem Server um? Ganz einfach mit den DNS-Umschreibungen unter Filter/DNS-Umschreibungen:

Filter / DNS-Umschreibungen

Jetzt musst du nur noch warten. Spätestens nach dem Neustart des Clients mit aktiverten DoH versucht der Firefox ein DNS-Lookup auf use-application-dns.net und da dein Server keine IP-Adresse zurückliefert, lässt Firefox DoH deaktiviert. Mal sehen wie das zukünftig andere Browser-Hersteller umsetzen, das bleibt spannend.

Wenn du wissen willst, welche Daten oder IP-Pakete in deinem Netzwerk unterwegs sind und wer welche Verbindungen wohin unterhält, dann möchte ich dich an meinen Blogbeitrag bezüglich ntopng verweisen. Ohne regelmäßige Analyse deines Netzwerkes wirst du nicht feststellen können, ob nicht doch jemand ein neues Schlupfloch gefunden hat.

Update von AdGuard Home

Ein Update auf eine neue Version ist recht einfach, stoppen und löschen des laufenden Container (Konfiguration und Arbeitsverzeichnis liegt ja lokal auf dem Host und werden dabei nicht gelöscht), anschließend Container wie bereits bei Erstinstallation erneut starten.

# docker stop adguardhome
# docker rm adguardhome
# # docker run --name adguardhome -v /var/adguardhome/work:/opt/adguardhome/work -v /var/adguardhome/conf:/opt/adguardhome/conf -p 53:53/tcp -p 53:53/udp -p 3000:3000/tcp -p 853:853/tcp -d adguard/adguardhome

So – und nun viel Erfolg mit deinem DNS-Server und deiner lokalen Netzwerkkonfiguration.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.