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 443:443/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 Nutzer 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 (noch) 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 (noch) 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.
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. Eine weitere Quelle nach z.B. nur deutschen IP-Adressen, um z.B. nur DNS-Anfragen von diesen zu erlauben, ist hier zu finden. Denn es kann durchaus sein, das dein DNS-Server für unerwünschte Dinge missbraucht wird, wie z.B. manipulierte RRSIG-UDP-Pakete, die dann einen fremden Server mit UDP-Antworten „bombardieren“ soll – aber das erkennst du dann schnell an den sprungartig ansteigenden DNS-Anfragen an deinen Server.
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 --preferred-chain="ISRG Root X1" -d myadguard.dns -d *.myadguard.dns
$ sudo docker start adguardhome
Die Angaben -d myadguard.dns -d *.myadguard.dns sind optional. Wenn du kein Wildcard-Zertifikat benötigst, kannst du die letztere Option auf jeden Fall weglassen.
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
...
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?
- du hast einen eigenen DNS-Server aufgesetzt und konfiguriert
- du hast Standard-Filterlisten und möglicherweise eigene Filterlisten hinzugefügt
- 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
- 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.
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).
Mit ntopng und Wireshark kannst du gut erkennen, das der Router die DNS-Anfrage blockt und freundlicherweise ein ICMP-Paket zum Absender schickt:
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:
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.
Vielen Dank! Ich bin aufgrund der Empfehlung in dieser Anleitung von meinem Pi auf einen Hetzner-Cloudserver umgezogen, so dass mein Adguard nun extern liegt. Docker habe ich allerdings nicht verwendet, damit habe ich keine Erfahrung.
Nachteil dieser Variante ist, dass man die Clients hinter der FRITZ!Box nicht mehr differenziert sieht.
Gerne.
Das ist richtig, die Fritzbox selbst (nicht mehr die Geräte dahinter) ist nur noch als Client sichtbar. Aber dafür kannst du jetzt auch deine mobilen Geräte (Handy, Tablets, etc.) auf deinen eigenen DNS-Server inkl. Werbefilter verweisen lassen, selbst wenn sie über das Mobilnetz (LTE, 5G, etc) oder fremde WLAN-Hotspots mit dem Internet verbunden sind. Und das alles verschlüsselt und nicht mehr für jeden offen wie ein „Scheunentor“.
Mir ist das mehr wert als zu wissen, welches Endgerät daheim welche DNS-Anfragen stellt.
Und ich kann dir nur empfehlen , dich mit Containern (docker) zu beschäftigen. Gerade, wenn du nur einen vServer hast, wirst du die Virtualisierung schnell zu schätzen wissen.
DNS ist bei iOS Geräten nicht einstellbar, wenn sie über Mobilnetz online sind. Das kann/muss man ggf. über VPN on Demand regeln und z.B. den heimischen Router dazwischenklemmen (mit Fritzbox ja recht einfach zu machen).
Aber bei fremden W-LANs oder Hotspots ist das schon eine Erleichterung (wenn sie nicht o.g. Gegenmaßnahmen einsetzen 😉 ).
Docker werde ich mir gelegentlich mal ansehen.
Hallo Thomas, doch das geht. Habe es erst vor 2 Wochen auf all meinen Apple Geräten und der Kinder zu Hause eingerichtet. Und zwar geht das ganze über Konfigurationsprofile, welche auch von AdGuard im Einrichtungsassistenten -> DNS-Datenschutz erstellt werden können. Es klappt ganz gut damit.
Danke, das werde ich dann mal testen!
Hallo Lars,
danke für deinen qualitativen(!) Blog-Eintrag. Ich nutze AdGuard Home um in 1. Linie für meine Kids gewisse Dienste zu sperren und stehe nur vor einem Problem:
Wenn ich AdGuard Home ebenso einrichte, wie du es beschrieben hast, dann gelten die Regeln für alle Geräte, sprich wenn ich Facebook, Instagram, TikTok & Co. sperre, dann gilt es auch für meine Frau und mich.
Gibt es dafür eine Lösung, das ich trotzdem zwischen den Eltern und Kindern im AdGuard (nicht im LAN) unterscheiden kann?
Danke und Grüße,
Lukas
Danke für das Feedback.
Wenn du AdGuard Home auf einem Server im Internet betreibst, dann kommen die DNS-Anfragen aus Sicht von AdGuard Home von der öffentlichen IP deines Heimrouters, da dieser die internen privaten IP-Adressen in die öffentliche, von deinem Provider zugewiesene IP ändert (Network Address Translation (NAT)). In dem Fall kann AdGuard Home nicht unterscheiden, von welchem Gerät im internen Netzwerk zu Hause die DNS-Anfrage kommt.
Du kannst aber den Eltern-Geräten im WLAN manuell eine andere DNS-Adresse, als die vom DHCP-Server zugewiesene, mitgeben.
Unter Android:
Öffne die Einstellungen auf dem Gerät.
Wähle WLAN.
Drücke lange auf dein aktuelles Netzwerk und wähle dann Netzwerk ändern.
Aktiviere das Kontrollkästchen Erweiterte Optionen anzeigen.
Ändere IP-Einstellungen zu Statisch.
Füge die IP-Adresse(n) eines anderen DNS-Server zu den Feldern DNS 1 und DNS 2 hinzu.
Unter iOS:
Öffne die Einstellungen-App.
Tippe auf WLAN. Wenn es ausgeschaltet ist, schalte es ein.
Wähle ein Wi-Fi-Netzwerk und tippe auf das blaue „i“-Symbol.
Tippe auf DNS konfigurieren und wähle Manuell.
Tippe auf Server hinzufügen und füge eine andere DNS-Adressen hinzu
Ich hoffe, das hilft dir weiter. Eine komfortable Lösung gibt es leider nicht.
Hallo Lars,
danke ebenfalls für dein Feedback. Ich denke, dass ich da auf AdGuard DNS umstellen werde, gestern wurde die Version 2.0 veröffentlicht: https://adguard-dns.io/de
Evtl. interessiert es hier jemanden.
Grüße,
Lukas
Hallo,
ich möchte Adguard wieder deinstallieren (mit allen Unterordnern). Kannst Du mir sagen mit welchem Befehl ich das sauber hinbekomme?
Danke, Lutz
Wenn du meiner Anleitung gefolgt bist, kannst du mit „docker stop adguardhome“ und „docker rm adguardhome“ die Instanz beenden und löschen. Anschließend kannst du den Arbeitsordner löschen („rm -R /var/adguardhome“). Mehr ist bei Docker-Instanzen nicht notwendig.
Hallo,
ich habe adguard home auf einem mini-pc unter debian am laufen.
der mini-pc hat eine zweite netzwerk-schnittstelle. unter linux ist es ja grundsätzlich möglich, ein zweites subnetz einzurichten. koennte man adguard dann dazu nutzen, auch das gastnetzwerk zu filtern?
Grundsätzlich schon. Du musst nur sicherstellen, das dein Adguard Home aus dem Gastnetz erreichbar ist. Entweder du änderst im Gastnetz die Einstellungen des zuständigen DNS-Server oder du musst den dort eingestellten Server so konfigurieren, das er Anfragen an Adguard Home weiterleitet.
Aber mit deiner Beschreibung alleine ist mir leider nicht ganz klar, wie dein Netzwerk aufgebaut ist.
Hallo,
ich habe Adguard Home auf einem Raspi.
Ist es möglich bestimmte Geräte auszuschließen.
Meine Frau kann mit ihren Handy nicht auf sponsored links klicken, obwohl ich sie im benutzerdefinierten Filter freigegeben habe
Wird die Anfrage denn auch tatsächlich gefiltert oder hat es ggf. einen anderen Grund?