Zum Inhalt

Lokale DNS-Namen mit Technitium einrichten: Heimserver statt IP-Adressen aufrufen

Veröffentlicht am 12. Oktober 2026 · Geschätzte Lesezeit: 12 Minuten

Mit Technitium DNS Server betreibst du einen eigenen DNS-Dienst im Heimnetz und gibst deinen Servern verständliche Namen wie nas.home.arpa oder homeassistant.home.arpa. Statt http://192.168.1.50:8080 tippst du danach http://nas.home.arpa:8080 – und alle Geräte im Netz finden deine Dienste unter denselben Namen. Technitium ist ein kostenloser, quelloffener, autoritativer und rekursiver DNS-Server mit Weboberfläche, der gezielt für lokale DNS-Server in kleinen Netzen entwickelt wurde.[5] Die Einrichtung per Docker dauert etwa 35 bis 60 Minuten inklusive Portprüfung, lokaler Zone und Tests mit einem einzelnen Client.[1][4]

Diese Anleitung folgt der offiziellen Docker-Compose-Vorlage und der offiziellen Dokumentation der Docker-Umgebungsvariablen.[1][2] Eine visuelle Einführung zeigt das Video Technitium: The Self-Hosted DNS Server You Should Run auf YouTube.[7]

Voraussetzungen

  • Ein dauerhaft laufender Linux-Server mit Docker und Docker Compose (Plugin)
  • Zugriff auf den Router beziehungsweise DHCP-Server
  • Eine feste LAN-IP-Adresse für den Docker-Host (DHCP-Reservierung)
  • Terminal-Zugriff mit sudo-Rechten und ein Testgerät im selben Netzwerk

1. Feste IP-Adresse für den Docker-Host festlegen

Der DNS-Server muss dauerhaft unter derselben Adresse erreichbar sein, sonst verlieren alle Geräte nach der Umstellung den Zugang. Vergib dem Docker-Host deshalb eine feste LAN-IP:

  • Im Router: DHCP-Reservierung für den Docker-Host einrichten (MAC-Adresse → feste IP, z. B. 192.168.1.100).
  • Alternativ: statische IP-Adresse direkt im Server konfigurieren.

Prüfe anschließend, welche Adresse der Server tatsächlich hat:

hostname -I

Ersetze <server_ip> im Rest dieser Anleitung durch diese feste LAN-Adresse, zum Beispiel 192.168.1.100.

2. Prüfen, ob Port 53 und 5380 frei sind

Technitium nutzt Port 53 (UDP und TCP) für den DNS-Dienst und Port 5380 (TCP) für die Weboberfläche.[1] Prüfe, ob diese Ports bereits belegt sind:

sudo ss -lntup | grep -E ':(53|5380)\b'

Keine Ausgabe bedeutet: beide Ports sind frei. Zeigt die Ausgabe einen Dienst, lauscht er auf Port 53 oder 5380. Häufige Übeltäter sind systemd-resolved (auf 127.0.0.53:53) und dnsmasq. Da wir die Ports später nur an die LAN-IP binden, stört ein Dienst, der ausschließlich auf Loopback lauscht, nicht weiter – ein dnsmasq auf derselben LAN-IP muss dagegen deaktiviert werden. Die offizielle Anleitung erklärt das Stoppen von Stub-Resolvern wie dnsmasq oder systemd-resolved im Detail.[4]

3. Projektordner und Passwort-Datei anlegen

Lege die Ordner für Konfiguration, Logs und Geheimnisse an:

mkdir -p ~/docker/technitium/config ~/docker/technitium/logs ~/docker/technitium/secrets
cd ~/docker/technitium

Erzeuge eine leere, nur für dich lesbare Passwort-Datei:

install -m 600 /dev/null secrets/admin_password.txt
nano secrets/admin_password.txt

Trage in die Datei nur eine Zeile ein: <starkes-passwort>. Ersetze <starkes-passwort> durch ein langes, zufällig erzeugtes Passwort, zum Beispiel mit:

openssl rand -base64 24

Speichere in Nano mit Strg+O, bestätige mit Enter und beende mit Strg+X. Die Datei bleibt mit chmod 600 nur für dich lesbar – wer sie kennt, hat Zugriff auf die DNS-Verwaltung.

Passwort von Anfang an setzen

Ohne gesetztes Passwort meldet sich die Weboberfläche automatisch mit dem Standard-Zugang admin/admin an.[3] Genau das verhindert die Passwort-Datei: Technitium liest sie beim ersten Start über die Variable DNS_SERVER_ADMIN_PASSWORD_FILE.[1][2]

4. docker-compose.yml erstellen

Erstelle die Datei compose.yaml im Ordner ~/docker/technitium:

services:
  dns-server:
    image: docker.io/technitium/dns-server:latest
    container_name: dns-server
    hostname: dns-server
    restart: unless-stopped
    ports:
      - "<server_ip>:5380:5380/tcp"
      - "<server_ip>:53:53/udp"
      - "<server_ip>:53:53/tcp"
    environment:
      - DNS_SERVER_DOMAIN=dns-server
      - DNS_SERVER_ADMIN_PASSWORD_FILE=/run/secrets/admin_password
      - DNS_SERVER_RECURSION=AllowOnlyForPrivateNetworks
      - DNS_SERVER_LOG_FOLDER_PATH=/var/log/technitium/dns
      - TZ=Europe/Berlin
    volumes:
      - ./config:/etc/dns
      - ./logs:/var/log/technitium/dns
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://127.0.0.1:5380/api/dnsClient/healthCheck | grep '\"status\":\"ok\"'"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 10s
    secrets:
      - admin_password

secrets:
  admin_password:
    file: ./secrets/admin_password.txt

Die Einstellungen im Überblick:

Einstellung Bedeutung
"<server_ip>:5380:5380/tcp" Weboberfläche, erreichbar nur über die feste LAN-IP des Servers[1]
"<server_ip>:53:53/udp" und "<server_ip>:53:53/tcp" DNS-Dienst für UDP und TCP, ebenfalls nur an die LAN-IP gebunden[1]
DNS_SERVER_DOMAIN=dns-server Primärer Name, unter dem sich der DNS-Server selbst identifiziert[1]
DNS_SERVER_ADMIN_PASSWORD_FILE=/run/secrets/admin_password Liest das Admin-Passwort beim ersten Start aus der Secret-Datei[1][2]
DNS_SERVER_RECURSION=AllowOnlyForPrivateNetworks Rekursive Auflösung nur für Anfragen aus privaten Netzen – erlaubte Werte sind Allow, Deny, AllowOnlyForPrivateNetworks und UseSpecifiedNetworkACL[1][2]
DNS_SERVER_LOG_FOLDER_PATH=/var/log/technitium/dns Ablage der Logdateien[1]
./config:/etc/dns Speichert Zonen, Einstellungen und Rekursions-Cache dauerhaft[1]
./logs:/var/log/technitium/dns Speichert die Logs dauerhaft[1]
healthcheck Prüft alle 30 Sekunden, ob der Dienst antwortet – Vorlage aus der offiziellen Compose-Datei[1]

Docker Compose Secrets stellt die Datei dem Container als /run/secrets/admin_password bereit (siehe Zugangsdaten mit Docker Compose Secrets schützen). Die offizielle Compose-Vorlage verwendet benannte Docker-Volumes statt der Bind-Mounts ./config und ./logs; die Bind-Mounts haben hier den Vorteil, dass du die Konfiguration direkt sichern und einsehen kannst.[1] Das Image läuft als Root, die Ordner aus Schritt 3 sind also beschreibbar.

Wiederhole hier den Platzhalter aus Schritt 1: Ersetze <server_ip> durch die feste LAN-Adresse deines Docker-Hosts.

5. Technitium starten und anmelden

Starte den Container und prüfe seinen Zustand:

docker compose up -d
docker compose ps

Erwartete Ausgabe (Auszug):

NAME         IMAGE                              STATUS
dns-server   docker.io/technitium/dns-server    Up 2 minutes (healthy)

Details findest du in den Logs:

docker compose logs --tail=100 dns-server

Öffne dann die Weboberfläche im Browser: http://<server_ip>:5380.[4] Melde dich mit dem Benutzernamen admin und dem Passwort aus secrets/admin_password.txt an.[3] Aktiviere anschließend in der Weboberfläche die TOTP-basierte Zwei-Faktor-Anmeldung (2FA) – Technitium unterstützt sie direkt.[3]

Umgebungsvariablen gelten nur beim ersten Start

Technitium liest die Docker-Umgebungsvariablen nur dann, wenn noch keine Konfigurationsdatei existiert, also beim allerersten Start.[2] Änderst du später die Passwort-Datei oder DNS_SERVER_RECURSION in der compose.yaml, hat das keine Wirkung mehr – solche Werte änderst du danach in der Weboberfläche.

6. Lokale Zone home.arpa anlegen

Der Domainname home.arpa ist per RFC 8375 offiziell für private Heimnetze reserviert und wird nirgendwo im öffentlichen DNS verwendet.[8] Damit ist er ideal für lokale Namen – im Gegensatz zu frei erfundenen öffentlichen Domains (die es so im Internet nicht gibt oder die jemand anderem gehören) und zu .local-Namen (die mit Multicast-DNS kollidieren können).[8]

So legst du die Zone an:

  1. Klicke in der Weboberfläche auf Zones.
  2. Klicke auf Add Zone.
  3. Wähle den Zonentyp Primary Zone – eine Primary Zone hostet die Zone autoritativ auf deinem Server.[5]
  4. Trage als Namen home.arpa ein und speichere.

Die Zonenübersicht zeigt die neue Zone; über Edit verwaltest du ihre Einträge.[5]

7. Namen für deine Heimserver eintragen

Öffne die Zone home.arpa über Edit und lege für jeden Dienst einen A-Record an. Ein DNS-Eintrag besteht aus Name, Typ, TTL und Daten – für IPv4-Adressen verwendest du den Typ A.[5]

Name Typ Daten
nas A <nas_ip>
homeassistant A <homeassistant_ip>

Ersetze <nas_ip> durch die IP-Adresse deines NAS und <homeassistant_ip> durch die IP-Adresse deines Home-Assistant-Servers. Danach ist der Server unter nas.home.arpa beziehungsweise homeassistant.home.arpa ansprechbar. Weitere Geräte ergänzt du genauso, zum Beispiel drucker oder pihole.

8. DNS-Auflösung testen

Führe die Tests von einem anderen Rechner im Heimnetz aus (nicht vom Docker-Host). dig ist in Debian/Ubuntu im Paket dnsutils enthalten, in Fedora/RHEL im Paket bind-utils.

Lokale Namen:

dig @<server_ip> nas.home.arpa A

Erwartung: In der Antwortzeile ANSWER SECTION erscheint exakt <nas_ip>.

Öffentliche Namen (Rekursion):

dig @<server_ip> example.org A

Erwartung: Eine plausible IP-Adresse, zum Beispiel 93.184.216.34.

TCP-Transport:

dig +tcp @<server_ip> example.org A

Erwartung: Dieselbe Antwort wie über UDP. Schlägt nur dieser Test fehl, blockiert eine Firewall den TCP-Port 53 – große DNS-Antworten brechen dann ab.[4]

Unter Windows nutzt du entsprechend:

nslookup nas.home.arpa <server_ip>

Im Dashboard der Weboberfläche erscheinen die Testanfragen in den Statistiken und Logs – so siehst du, dass der Server wirklich antwortet.[5]

9. (Optional) Verschlüsselte Forwarder einrichten

Ohne weitere Konfiguration löst Technitium Namen rekursiv über die Root-Server auf.[5] Wer die Anfragen stattdessen an einen öffentlichen Resolver weiterreichen möchte, richtet Forwarder ein – etwa 1.1.1.1 (Cloudflare) oder 8.8.8.8 (Google). Technitium unterstützt dafür neben klassischem UDP/TCP auch die verschlüsselten Protokolle DNS-over-TLS, DNS-over-HTTPS und DNS-over-QUIC; sie schützen deine DNS-Anfragen vor dem Mitlesen im Netz.[3]

In der Weboberfläche unter Settings → Forwarders:

  1. Klicke auf Add Forwarder.
  2. Trage 1.1.1.1 als Adresse ein.
  3. Wähle als Protokoll TLS (DNS-over-TLS) – unterstützte Werte sind Udp, Tcp, Tls, Https und Quic.[2]
  4. Speichere und teste mit dig @<server_ip> example.org A.

Alternativ lassen sich Forwarder beim ersten Start per Umgebungsvariablen setzen (DNS_SERVER_FORWARDERS und DNS_SERVER_FORWARDER_PROTOCOL).[2] Da die Variablen nur bei der Erstinitialisierung gelesen werden, ist die Einrichtung über die Weboberfläche meist einfacher.

10. (Optional) Blocklisten für Werbung und Malware aktivieren

Technitium kann Domains netzweit blockieren: Unter Settings → Blocking aktivierst du die Blockier-Funktion und trägst eine oder mehrere Blocklisten ein. Die Quick Add-Auswahl schlägt beliebte Listen vor.[3] Technitium aktualisiert die Blocklisten automatisch täglich.[3]

Bedenke: Das ist eine Zusatzfunktion. Der eigentliche Zweck dieses Artikels sind die lokalen Namen – wer nur einen Werbeblocker sucht, ist mit Pi-hole oder AdGuard Home genauso gut bedient.[6] Blocklisten können Fehltreffer liefern und sollten erst nach den Tests aus Schritt 8 aktiviert werden.

11. Testclient umstellen – und erst dann das Heimnetz

Stelle zuerst ein einzelnes Gerät auf den neuen DNS-Server um, nicht das ganze Netz. Im Testgerät trägst du unter den Netzwerkeinstellungen als DNS-Server manuell <server_ip> ein. Prüfe dann die Punkte aus Schritt 8 erneut.

Erst wenn alles funktioniert, stellst du das Heimnetz um: Trage im Router beziehungsweise in dessen DHCP-Server als auszuliefernden DNS-Server <server_ip> ein. Alle Geräte erhalten den neuen DNS-Server ab dem nächsten DHCP-Lease automatisch. Ersetze <server_ip> auch hier durch die feste LAN-Adresse deines Docker-Hosts.

Erst testen, dann umstellen

Fällt der DNS-Server aus, verlieren umgestellte Geräte die Namensauflösung – auch fürs Internet. Stelle das gesamte Heimnetz deshalb erst um, wenn der Testclient über Tage zuverlässig funktioniert hat. Manche Router erzwingen zusätzlich ihren eigenen DNS-Proxy oder bieten DNS-Rebind-Schutz an – solche Funktionen können lokale Namen stören und gehören getrennt geprüft.

Backup und Rückweg

Sicherung: Die gesamte Konfiguration (Zonen, Einstellungen, Cache) liegt in ./config.[1] Ein Backup ist eine einfache Archivierung:

cd ~/docker/technitium
tar czf technitium-config-$(date +%F).tgz config

Wiederherstellung: Stoppe den Container, benenne das defekte Verzeichnis um und spiele das Archiv zurück:

docker compose stop
mv config config.defekt
tar xzf technitium-config-<datum>.tgz
docker compose up -d

Ersetze <datum> durch das Datum aus dem Archivnamen, zum Beispiel 2026-10-12. Erst wenn die Wiederherstellung geprüft ist, darfst du config.defekt löschen.

Kompletter Rückweg: Container entfernen und den Router wieder als DNS-Server eintragen:

cd ~/docker/technitium
docker compose down

Setze im Router den DNS-Server zurück (auf automatisch beziehungsweise den bisherigen Wert). Am umgestellten Client hilft zusätzlich das Leeren des DNS-Caches – unter Windows ipconfig /flushdns, unter Linux mit systemd-resolved sudo resolvectl flush-caches.

Risiken

  • DNS ist kritische Infrastruktur. Ist der Server nicht erreichbar (Update, Stromausfall, Fehlkonfiguration), löst kein umgestelltes Gerät mehr Namen auf. Teste erst mit einem Client, behalte den Router-DNS als dokumentierten Fallback und stelle das Heimnetz nur nach erfolgreicher Testphase um.
  • Offene Rekursion verhindern. DNS_SERVER_RECURSION=AllowOnlyForPrivateNetworks erlaubt rekursive Anfragen nur aus privaten Netzen.[1][2] Leite Port 53 niemals im Router nach außen weiter, sonst kann Fremde deinen Server als kostenlosen Resolver missbrauchen.
  • Weboberfläche ohne HTTPS. Die Konsole läuft standardmäßig über unverschlüsseltes HTTP auf Port 5380.[1][4] Aktiviere die Zwei-Faktor-Anmeldung[3] und sichere die Konsole bei Bedarf über die HTTPS-Variante (Port 53443) oder einen Reverse Proxy ab – der Zugangsschlüssel zum DNS ist mindestens so wertvoll wie der zum Router.
  • Klartext-Passwort auf dem Host. Die Datei secrets/admin_password.txt enthält das Admin-Passwort im Klartext. Die Rechte chmod 600 und ein sicheres Backup sind Pflicht – mehr dazu in der Anleitung Zugangsdaten mit Docker Compose Secrets schützen.
  • Umgebungsvariablen nur beim ersten Start. Spätere Änderungen an compose.yaml oder der Passwort-Datei greifen nicht; die Werte in der Weboberfläche sind dann maßgeblich.[2]
  • home.arpa ist nur intern gültig. Die Domain ist für private Heimnetze reserviert und wird im öffentlichen DNS nicht aufgelöst – genau das macht sie sicher für lokale Namen.[8]

Typische Fehler

  1. „Address already in use“ beim Start: Port 53 oder 5380 ist belegt, meist durch dnsmasq oder systemd-resolved. Belegung mit sudo ss -lntup | grep -E ':(53|5380)\b' finden und den störenden Dienst deaktivieren.[4]
  2. Weboberfläche nicht erreichbar: Falsche IP im Port-Binding (<server_ip> prüfen), Host-Firewall blockiert 5380 oder der Container läuft nicht (docker compose ps). Auf Ubuntu/Debian mit UFW hilft beispielsweise sudo ufw allow from 192.168.1.0/24 to any port 5380 proto tcp – passe das Netz an dein Heimnetz an.
  3. Öffentliche Namen funktionieren, lokale nicht: Der Client fragt einen anderen DNS-Server. Teste direkt mit dig @<server_ip> nas.home.arpa A; stimmt die Antwort, liegt es an der Client- oder Router-Konfiguration.
  4. Lokale Namen funktionieren sporadisch: Der DHCP-Server verteilt zusätzlich einen zweiten DNS-Server, der home.arpa nicht kennt. Im Router nur einen DNS-Server ausliefern.
  5. Passwort- oder Variablenänderung wirkt nicht: Die Datei wird nur beim ersten Start gelesen.[2] Passwort und Einstellungen danach über die Weboberfläche ändern.
  6. DNS über UDP klappt, große Antworten scheitern: TCP-Port 53 wird von einer Firewall blockiert – mit dig +tcp prüfen.
  7. .local als Zone angelegt: Kollidiert mit Multicast-DNS. home.arpa verwenden.[8]

Fertig

Dein lokaler DNS-Server läuft. Prüfe abschließend diese Punkte:

  • docker compose ps zeigt dns-server mit Status Up (healthy)
  • dig @<server_ip> nas.home.arpa A liefert exakt <nas_ip>
  • dig @<server_ip> example.org A liefert eine plausible öffentliche Adresse
  • dig +tcp @<server_ip> example.org A funktioniert ebenfalls
  • Die Weboberfläche http://<server_ip>:5380 meldet dich mit admin und deinem Passwort an, 2FA ist aktiviert
  • Nach der Umstellung eines Testclients löst nslookup nas.home.arpa die richtige IP auf – ping nas.home.arpa darf ruhig fehlschlagen, wenn das Zielgerät ICMP blockiert; entscheidend ist die aufgelöste Adresse

Ab jetzt rufst du deine Dienste mit Namen statt IP-Adressen auf. Gute nächste Schritte: die Zone um weitere Geräte ergänzen, die HTTPS-Absicherung lokaler Dienste umsetzen oder die verschlüsselten Forwarder und Blocklisten aus den Schritten 9 und 10 aktivieren.

Sources

[1] https://raw.githubusercontent.com/TechnitiumSoftware/DnsServer/master/docker-compose.yml — Technitium DNS Server – offizielle Docker-Compose-Vorlage (GitHub) [2] https://github.com/TechnitiumSoftware/DnsServer/blob/master/DockerEnvironmentVariables.md — Technitium DNS Server – offizielle Docker-Environment-Variablen (GitHub) [3] https://technitium.com/dns — Technitium DNS Server – offizielle Produktseite [4] https://blog.technitium.com/2017/11/running-dns-server-on-ubuntu-linux.html — Technitium Blog – offizielle Installations- und Fehlerbehebungsanleitung [5] https://technitium.com/dns/help.html — Technitium DNS Server – offizielle Hilfe [6] https://www.virtualizationhowto.com/2023/08/technitium-dns-server-in-docker-is-this-the-best-home-server-dns — Virtualization Howto – Technitium DNS Server in Docker (Praxisanleitung) [7] https://www.youtube.com/watch?v=9buji0Vnbo0 — YouTube: Technitium – The Self-Hosted DNS Server You Should Run [8] https://www.rfc-editor.org/rfc/rfc8375 — RFC 8375 – Special-Use Domain 'home.arpa.'