Öffentlicher AdGuard Home - Best Practice

[CoMo]

Hallo,

ich würde gerne für Freunde und Familie einen filternden DNS-Server betreiben. Öffentlich via Hostname erreichbar, kein VPN. Das Projekt hat sich die letzten Tage materialisiert, als ich bemerkt habe, dass AdGuard Home bei DoT / DoH / DoQ mit Client-ID's arbeiten kann https://github.com/AdguardTeam/AdGuardHome/wiki/Clients#clientid

Ich kann also für jeden Nutzer eine zufällige Client ID erstellen, mit der er sich quasi am Server authentifiziert. Anfragen ohne Client ID liefern nur ein REFUSED. Das habe ich mit dem Smartphone getestet und es funktioniert.

Die Client-IDs haben das Format username-40bit-random-string

Mein AdGuard Home läuft also nun auf einem Netcup VPS direkt im Internet ohne Reverse Proxy. OS is DietPi und AdGuard und Unbound wurden über dietpi-software installiert.

Plain DNS ist deaktiviert, nur DoH / DoT / DoQ sind aktiv. Also Port 443 TCP und Port 853 TCP/UDP.

DNS-Technisch habe ich folgende Einträge angelegt:

A - <ipv4-adresse>
AAAA - <ipv6-adresse>
HTTPS: 1 . alpn="h2,h3" ipv4hint=<ipv4-adresse> ipv6hint=<ipv6-adresse>
SVCB: 1 . alpn="doq" port=853 ipv4hint=<ipv4-adresse> ipv6hint=<ipv6-adresse>
TLSA: _443._tcp.dns.<meinedomain>.de. IN TLSA 3 1 2 <sha512-hash>
TLSA: _443._tcp.dns.<meinedomain>.de. IN TLSA 3 1 1 <sha256-hash>
TLSA _853._tcp.dns.<meinedomain>.de. IN TLSA 3 1 2 <sha512-hash>
TLSA _853._tcp.dns.<meinedomain>.de. IN TLSA 3 1 1 <sha256-hash>
TLSA _853._udp.dns.<meinedomain>.de. IN TLSA 3 1 2 <sha512-hash>
TLSA _853._udp.dns.<meinedomain>.de. IN TLSA 3 1 1 <sha256-hash>
CAA 0 issue "letsencrypt.org"
CAA 0 issuewild "letsencrypt.org"

Da die Domains keine Emails sendet oder empfängt, habe ich auch Null-MX sowie SPF und DMARC-Einträge angelegt. SSHFP für den SSH-Zugang gibt es ebenfalls.

Mittels UFW sind nur die nötigen Ports freigegeben. SSH ist auf meine eigenen IP-Adressen beschränkt.

Das (Wildcard) Zertifikat habe ich mit Certbot erstellt und in die Datei unter /etc/letsencrypt/renewal habe ich unterhalb von [renewalparams] noch ein reuse_key = true eingetragen. Das sollte dafür sorgen, dass der Public Key im TLSA Record sich auch bei Cert-Erneuerung nicht ändert, richtig?

Das Webinterface ist ebenfalls erreichbar auf Port 443. Das lässt sich auch leider nicht unabhängig vom DoH-Server abschalten. Aber das Passwort ist lang und zufällig und Rate Limiting sperrt fehlversuche für 12 Stunden aus. Das ist erst mal ok, denke ich. In AdGuard Home v0.108 soll es dann eine Möglichkeit geben, das Webinterface zu deaktivieren.

Ich habe mich noch etwas in systemd Hardening eingelesen und der Unit noch folgende Optionen hinzugefügt:

[Service]
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/mnt/dietpi_userdata/adguardhome
PrivateTmp=true
PrivateDevices=true
MemoryDenyWriteExecute=true
ProtectControlGroups=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectProc=invisible
ProcSubset=pid
LockPersonality=true
RestrictRealtime=true
#SystemCallArchitectures=native
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK
RestrictSUIDSGID=true

SystemCallArchitectures=native musste ich wieder rausnehmen, damit hat der Dienst nicht mehr gestartet:

May 21 15:14:46 vps01 AdGuardHome[2172]: 2026/05/21 15:14:46.461191 [error] client_storage: refreshing arp container err="each arpdb failed: opening \"proc/net/arp\": open proc/net/arp: no such file or directory\ncmd arpdb: running command: unexpected exit code 255\ncmd arpdb: running command: unexpected exit code 1"

Kann ich das so betreiben oder habe ich noch irgendwas wichtiges übersehen? Irgendwelche DNS-Einträge, weiteres Hardening etc?

Ein Problem ist mir aufgefallen. Da die Client IDs als Subdomain übergeben werden, kann ja zumindest der Bootstrap-DNS-Server die Clients IDs sehen. Das mag kein Problem sein mit ISP-DNS-Servern, aber der Router im Hotel WLAN könnte das loggen und damit die Client IDs exposen. Da gibt es für DoT / DoQ keine Lösung, nehme ich an? Aber ich kann die IDs ja jährlich oder so rotieren und neu verteilen.

 

[DHC]

Sehr interessantes Thema.

Ich befasse mich auch seit einiger Zeit mit dem Thema AdGuard/Pihole und Unbound, etc.
Ich plane da auch etwas in die Richtung zu realisieren. Wohl aber eher lokal auf einem Mini-Server (Proxmox?).

Aber ich bin da sehr stark Laie, was diese Thematik angeht.
Aber ich sauge mir da gerne Informationen dazu auf.

 

[CoMo]

Lokal betreibe ich das schon lange bei mir zuhause. Unbound läuft auf der OPNSense und AdGuard Home in einem LXC-Container auf Proxmox. Das funktioniert problemlos, da braucht es auch keine speziellen DNS-Records, das ist ja einfach nur Plain DNS auf 53/UDP. Da braucht es auch kein Hardening.

Öffentlich im Internet sieht die Sache ja ganz anders aus

 

[SpiII]

Mal wegen DNSSEC überlegt? Deine TLSA-Records sind ohne DNSSEC "praktisch wertlos" - ein Angreifer könnte die TLSA-Records im DNS einfach durch eigene ersetzen. DANE setzt DNSSEC als Vertrauensanker voraus. Du brauchst also DS-Records bei deinem Registrar und DNSKEY/RRSIG-Records in deiner Zone. Ohne das gibt es keine Integritätsgarantie für deine TLSA-Einträge.
Ist die Frage wie groß hier die Wahrscheinlichkeit ist, dass das jemand versucht und wieviel Schaden er dann ausrichten könnte.

Ein Problem ist mir aufgefallen. Da die Client IDs als Subdomain übergeben werden, kann ja zumindest der Bootstrap-DNS-Server die Clients IDs sehen. Das mag kein Problem sein mit ISP-DNS-Servern, aber der Router im Hotel WLAN könnte das loggen und damit die Client IDs exposen. Da gibt es für DoT / DoQ keine Lösung, nehme ich an? Aber ich kann die IDs ja jährlich oder so rotieren und neu verteilen.

Korrekt, bei DoT und DoQ steckt die Client-ID in der Subdomain und ist damit im SNI sichtbar, bevor TLS established ist.

Aber AdGuard Home unterstützt Client-IDs auch im URL-Pfad:
https://dns.beispiel.de/dns-query/clientid ← Pfad, verschlüsselt ✓
clientid.dns.beispiel.de/dns-query ← Subdomain, im SNI sichtbar ✗

DoH-Nutzer sollten also die Pfad-Variante konfigurieren, dann sieht der Hotel-Router im SNI nur dns.beispiel.de, nicht die Client-ID.
Bei DoT/DoQ bleibt das Problem aber bestehen. Periodische Rotation ist tatsächlich die pragmatischste Lösung. ECH würde das lösen, ist aber für self-hosted noch nicht praktikabel.

 

[CoMo]

DNSSEC: Deine TLSA-Records sind ohne DNSSEC praktisch wertlos

DNSSEC funktioniert natürlich einwandfrei. Mein DNS-Anbieter ist deSEC.

Aber AdGuard Home unterstützt Client-IDs auch im URL-Pfad:

Logisch, aber Android z.B. macht nur DoT. Da geht das nur über den Hostnamen.

 

[TSKNF]

Habe das schon länger und irgendwo gibt es immer (leichte) Probleme.

Willst du diese Sicherheit mit den abgewiesenen DNS Anfragen? Ich gebe meinen DNS Server jedem der Möchte.

Die Frage ist ob dein Anbieter dir eine saubere ip4 zur Verfügung stellt. Wenn nein bleibt, nur ip6. Funktioniert trotzdem gut. Dyndns Anbieter sind nur so zu 90% bis 95% zuverlässig.

Eine eigene Domain verbessert das Ergebniss deutlich. Und eine eigene ip4 nochmals.

Das mit der IP regel ich mit einem vps Server für 2€ und dazu eine Domain. Der Server ist quasi nur dazu gekommen weil ich E-Mail ohne ip4 einfach nicht (zufriedenstellend) abdecken kann.

 

[CoMo]

Die Frage ist ob dein Anbieter dir eine saubere ip4 zur Verfügung stellt.

Natürlich bekommt ein VPS bei Netcup eine feste IPv4 Adresse. Die habe ich schon seit über 5 Jahren.

Willst du diese Sicherheit mit den abgewiesenen DNS Anfragen? Ich gebe meinen DNS Server jedem der Möchte.

Ich habe nicht vor, einen offenen Resolver zu betreiben. Das würde Netcup auch ganz sicher nicht gefallen.

 

[TSKNF]

Ich wüsste nicht was netcup gegen einen offenen DNS Dienst haben sollte?

Habe jetzt keine Regel gefunden die dies verbietet. Aber auch nicht lange gesucht.

 

[CoMo]

Zumindest bei klassischem 53/UDP DNS wird der Server dann ganz schnell zum Ziel von Amplification Attacks.

Stimmt, bei verschlüsseltem DNS mag das vielleicht keine große Rolle mehr spielen. Vielleicht wäre das dem Hoster dann auch egal. Ich möchte trotzdem keinen offenen Resolver betreiben, sondern meine Clients explizit freischalten.

 

[andy_m4]

Ich möchte trotzdem keinen offenen Resolver betreiben,

Du kannst ja ein offenes Mailrelay daneben stellen, um davon abzulenken. ;-)