DNS64

DNS64 ist der DNS-Filter in Node64: ein cachender DNS-Server fürs Heimnetz, der Werbung, Tracker und Malware über Blocklisten filtert und nach außen nur verschlüsselt fragt. Hier richtest du ihn Schritt für Schritt ein – vom Port 53 über Blocklisten bis zum verschlüsselten DNS auf iPhone und Android.

Netzwerk und Ports

DNS64 ist ein Modul von Node64. Ist es ausgeschaltet, läuft nichts und kein Port ist offen. Eingeschaltet öffnet es diese Dienste für deine Geräte:

Ohne feste Adresse lauscht DNS64 auf allen Adressen, IPv4 und IPv6 gleichzeitig. Welche Ports belegt sind und ob sich etwas überschneidet, zeigt Einstellungen → Ports. Das Image erlaubt dem Programm Ports unter 1024, der Prozess läuft trotzdem ohne Root.

Host-Netzwerk (empfohlen)

Mit network_mode: host sieht DNS64 die echten IP-Adressen deiner Geräte (wichtig für Abfrage-Log und Top-Clients) und findet den Router für lokale Namen selbst. Die Weboberfläche erreichst du dann direkt auf Port 8080 des Hosts.

services:
  node:
    image: ghcr.io/ipv64net/node64:latest
    container_name: node64
    restart: unless-stopped
    network_mode: host        # statt ports:, Oberfläche auf Port 8080
    volumes:
      - node64-data:/data
    read_only: true
    tmpfs:
      - /tmp
volumes:
  node64-data:

Das öffentliche Image ghcr.io/ipv64net/node64:latest erscheint in Kürze. Alles zur Installation steht unter Installation, alle Variablen unter Konfiguration.

Bridge-Netzwerk

Ohne Host-Netzwerk gibst du die Ports einzeln frei. Den Router für lokale Namen trägst du dann unter DNS64 → Einstellungen → Router für lokale Namen von Hand ein, weil DNS64 im Container sonst nur das Docker-Gateway sieht – und das Docker-Gateway ist kein Router: Mit veröffentlichtem Port 53 leitet es Anfragen zurück in den Container. Die automatische Suche erkennt das und nimmt das Gateway nicht; trag die LAN-IP deines Routers ein, damit lokale Namen und Gerätenamen funktionieren.

    ports:
      - "8080:8080"
      - "53:53/udp"
      - "53:53/tcp"
      - "443:443/tcp"     # DoH (nur wenn eingeschaltet)
      - "853:853/tcp"     # DoT
      - "853:853/udp"     # DoQ

Docker: was im Bridge-Netz zu beachten ist

• Gateway statt Geräte-IP: Je nach Weg ersetzt Docker den Absender durch das Gateway – etwa über 127.0.0.1 des Hosts bzw. den Userland-Proxy, bei IPv6 ohne ip6tables oder auf manchen NAS. Im Log steht dann 172.17.0.1 statt der Geräte-IP, und Gerätegruppen greifen nicht. Für echte Client-IPs nimm network_mode: host. Die Log-Seite zeigt einen Hinweis, wenn das Gateway in den letzten 24 Stunden unter den Clients war.
• Abgewiesene Netze: Anfragen aus nicht erlaubten Netzen bekommen REFUSED und erscheinen nie im Log. Im Bridge-Netz kennt DNS64 zum Beispiel dein öffentliches IPv6-/64 oder weitere VLANs nicht – trag sie unter Weitere erlaubte Client-Netze ein. Die Log-Seite zeigt dazu einen Zähler und die zuletzt abgewiesene IP.
• Ports prüfen: Im Bridge-Netz prüft DNS64 beim Start und alle 30 Minuten, ob 53/udp, 53/tcp und 853 (DoT/DoQ) wirklich auf dem Docker-Host veröffentlicht sind. Fehlt einer, warnen Übersicht, Log, Einstellungen und Verschlüsselung – mit Beispielen für docker run -p 53:53/udp -p 53:53/tcp …, ports: in Compose oder network_mode: host.
• Anonymisierung: Mit „gekürzt“ sehen alle Geräte eines /24 gleich aus, mit „nicht speichern“ steht nur „-“ im Log.
• Unter sehr hoher Last können Log-Einträge verworfen werden; ein Zähler zeigt, wie viele.

Port 53 ist belegt (systemd-resolved)

Läuft auf dem Host schon ein DNS-Dienst auf Port 53, zeigt die DNS64-Seite den Fehler. Das Modul versucht es jede Minute erneut, sobald der Port frei wird. Auf vielen Linux-Systemen (z. B. Ubuntu) belegt systemd-resolved mit seinem „Stub-Listener“ den Port 53 auf 127.0.0.53. Wer den Port belegt, siehst du so:

sudo ss -lntup | grep ':53 '

Alternativ stellst du unter DNS64 → Einstellungen einen anderen DNS-Port ein – das taugt aber nur für Tests, denn Geräte im Heimnetz fragen immer auf Port 53.

DNS64 einschalten

1. Modul einschalten
   In Node64 unter Einstellungen → Module das Modul DNS64 aktivieren. DNS64 startet sofort mit den Standard-Blocklisten und den Standard-Upstreams.
2. Status prüfen
   Auf DNS64 → Übersicht steht, auf welcher Adresse der DNS-Dienst läuft („DNS auf …“). Läuft er nicht, steht dort der Grund – meist ein belegter Port.
3. Testen
   Von einem Rechner im Heimnetz eine Anfrage direkt an DNS64 stellen. Taucht sie im Abfrage-Log auf, läuft alles:

   nslookup example.com IP-DER-NODE

4. Im Router eintragen
   Damit alle Geräte DNS64 nutzen – siehe Router einrichten.

Router einrichten

Deine Geräte bekommen ihren DNS-Server normalerweise automatisch vom Router. Dort trägst du deshalb einmal die Adresse des Hosts ein, auf dem Node64 läuft:

• IPv4: In den DHCP-Einstellungen des Routers die IPv4-Adresse des Hosts als DNS-Server eintragen.
• IPv6: Die IPv6-Adresse des Hosts als DNS-Server verteilen lassen (per Router Advertisement/RDNSS bzw. DHCPv6). Nimm am besten eine Adresse, die sich nicht ändert, z. B. eine ULA (fd…).

DNS64 ist selbst kein DHCP-Server – die Adressvergabe bleibt beim Router. Geräte übernehmen den neuen DNS-Server meist erst, wenn sie ihre Adresse erneuern (WLAN kurz trennen oder Gerät neu starten).

FRITZ!Box und andere Router: Bei der FRITZ!Box legst du in den Netzwerk-Einstellungen des Heimnetzes fest, welchen DNS-Server die FRITZ!Box per DHCP an die Geräte verteilt – getrennt für IPv4 und IPv6. Wo die Einstellung genau liegt und wie sie heißt, hängt von Modell und FRITZ!OS-Version ab; die eingebaute Hilfe der FRITZ!Box führt dich hin. Bei anderen Routern heißt die Option meist ähnlich, etwa „DNS-Server“ in den DHCP- oder LAN-Einstellungen.

So beantwortet DNS64 eine Anfrage

Jede Anfrage durchläuft dieselbe Reihenfolge. Die erste Stufe, die eine Antwort hat, gewinnt:

1. Client-Netz prüfen – kommt die Anfrage nicht aus einem erlaubten Netz, gibt es REFUSED (siehe Erlaubte Client-Netze).
2. Geteilter DNS für CDN64 – Namen, die du über CDN64 veröffentlichst, zeigen für Geräte im Heimnetz direkt auf die Node.
3. Eigene Einträge – deine A-, AAAA-, CNAME-, TXT-, MX-, SRV-, PTR- und CAA-Einträge.
4. Umschreiben – ein Name antwortet wie ein anderer (siehe Umschreiben).
5. Lokale Zonen – Namen unter einer Zone wie home.lan samt Gerätenamen (siehe Lokale Zonen).
6. Lokale Namen – gehen an eine passende Weiterleitung oder an den Router, nie ins Internet. Ohne Router gibt es NXDOMAIN.
7. Gerätegruppen, eigene Sperrliste und Blocklisten – außer das Blockieren ist pausiert oder die Domain ist freigegeben (siehe Eigene Sperrliste).
8. Weiterleitungen – Domains mit eigenen DNS-Servern gehen dorthin statt an die Upstreams.
9. Cache – bekannte Antworten kommen sofort.
10. Verschlüsselter Upstream – danach prüft DNS64 noch die CNAME-Kette der Antwort gegen die Blocklisten.

Erlaubte Client-Netze

DNS64 ist nie ein offener Resolver. Es antwortet nur diesen Netzen, alles andere bekommt REFUSED:

• private IPv4-Netze (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) und das Tailscale-/CGNAT-Netz 100.64.0.0/10
• IPv6-ULA (fc00::/7), Link-Local und Loopback
• direkt angeschlossene Netze, wenn sie privat sind oder ein IPv6-/64 (bzw. kleiner) – also auch dein eigenes öffentliches IPv6-/64 zu Hause

Unter DNS64 → Einstellungen → Weitere erlaubte Client-Netze trägst du zusätzliche Netze ein, eins je Zeile – etwa ein VPN-Netz oder ein weiteres IPv6-Präfix. 0.0.0.0/0 und ::/0 werden abgelehnt. Trägst du ein öffentliches Netz ein, warnt die Seite: DNS64 antwortet dann jedem Gerät darin.

Freigabeliste auch für DoH: Dieselben Netze gelten für DoT, DoQ und DoH. Über DoH bekommen Geräte außerhalb der erlaubten Netze ein neutrales 404 – so verrät der gemeinsame Port 443 nicht, dass dort ein DNS-Server läuft. Für DoH öffnet Node64 keinen Port 80.

Abgelehnte Anfragen von fremden Adressen zählt DNS64 (Anzahl, letzte Adresse) und schreibt sie höchstens einmal pro Stunde ins Log.

Upstream-Server

Was DNS64 nicht selbst beantworten kann, fragt es bei Upstream-Servern im Internet – ausschließlich verschlüsselt per DoH, DoT oder DoQ. Unverschlüsseltes DNS nach außen gibt es nicht. Bei einer neuen Installation sind Cloudflare (DoH), Quad9 (DoH) und dnsforge (DoQ und DoH, Server nur in Deutschland) eingestellt. Bestehende Installationen behalten ihre Auswahl; dnsforge hakst du dort einfach an. Du änderst das unter DNS64 → Einstellungen; mindestens ein Server muss an sein.

Europäische Vorlagen: DNS4EU (Whalebone, Tschechien, von der EU kofinanziert), dnsforge (adminForge, Server nur in Deutschland), Freifunk München (Deutschland, zweiter Standort Wien) und Digitalcourage (Deutschland). Eingetragen ist jeweils die ungefilterte Variante, denn DNS64 filtert selbst. Bei bestehenden Installationen erscheinen sie ausgeschaltet – einschalten und Cloudflare abschalten genügt. Mehr dazu unter Souveränität.

Betriebsart

Zu den Servern verbindet DNS64 nach „Happy Eyeballs“: IPv6- und IPv4-Adressen abwechselnd, der nächste Versuch nach 250 ms, die zuletzt erfolgreiche Familie zuerst. Verbindungen werden wiederverwendet. Antwortet kein Server innerhalb von 8 Sekunden, bekommt das Gerät SERVFAIL.

Eigener Server

Unter Eigener Server trägst du eine Adresse und ihre Bootstrap-IPs ein:

• Einfacher DNS-Server: nur die IP, z. B. 8.8.8.8 (Port 53), oder IP:Port – unverschlüsselt, in der Liste als „DNS (unverschlüsselt)“ gekennzeichnet. Bootstrap-IPs braucht es dafür nicht.
• DoH: https://…/dns-query
• DoT: tls://name[:853]
• DoQ: quic://name[:853]

Die Bootstrap-IPs sind Pflicht, wenn in der Adresse ein Name steht: Damit erreicht DNS64 den Server, ohne vorher selbst DNS zu brauchen – sonst entstünde eine Schleife, wenn der Host DNS64 selbst als Resolver nutzt. Das Zertifikat des Servers wird auf den Namen geprüft (DoT mit mindestens TLS 1.2, DoQ mit TLS 1.3). Alle Vorlagen haben IPv4- und IPv6-Bootstrap-Adressen.

Blocklisten

Blocklisten verwaltest du unter DNS64 → Freigaben & Blocklisten: Haken setzen, „Übernehmen“, fertig – der DNS-Dienst lädt die Listen im Hintergrund neu, ohne Unterbrechung.

Jede Vorlage trägt in der Oberfläche ein Kategorie-Abzeichen. Alle Vorlagen außer den sechs Standardlisten sind zunächst aus. Global eingeschaltet gelten Listen für alle Geräte im Netz; je Gerätegruppe lassen sie sich gezielt ein- oder ausschalten – etwa Kinderschutz nur für die Kinder.

Dazu kommen eigene Listen per URL. „Domains“ zählt in der Übersicht nur Einträge, die nicht schon in einer Liste davor stehen.

Formate

• hosts-Datei, z. B. 0.0.0.0 ads.example.com
• Eine Domain je Zeile, z. B. ads.example.com
• Platzhalter *.example.com: gilt für die Domain samt allen Subdomains. *.com allein sperrt nie eine ganze Endung.
• Adblock-Syntax, der DNS-relevante Teil: ||ads.example.com^ blockt, @@||ads.example.com^ nimmt aus. Browser-Regeln wie Pfade, kosmetische Filter oder Modifier werden übersprungen.

Internationalisierte Domains (z. B. bücher.example) werden automatisch in Punycode umgewandelt und greifen – auf Listen, in Freigaben und in eigenen Einträgen.

Aktualisierung und Antwort

• Aktualisierung: alle 6, 12, 24 oder 48 Stunden (Standard 24). Eine Liste darf höchstens 64 MB groß sein. Lässt sich eine Liste dreimal hintereinander nicht laden, bekommst du eine Meldung.
• Antwort bei Blockierung (Einstellungen): 0.0.0.0 bzw. :: (empfohlen; andere Typen bekommen eine leere Antwort) oder NXDOMAIN.
• CNAME-Cloaking: Zeigt eine erlaubte Domain per CNAME auf einen gelisteten Tracker, blockt DNS64 die Antwort trotzdem.

Freigaben (Allowlist)

Eine freigegebene Domain wird nie blockiert – inklusive aller Subdomains. So gibst du frei:

• Im Abfrage-Log: neben einer blockierten Anfrage auf „Freigeben“ klicken. Geräte übernehmen das in wenigen Sekunden.
• Von Hand unter Freigaben & Blocklisten.
• Freigaben übernehmen: eine Liste einfügen, eine Domain je Zeile – etwa eine Pi-hole-Whitelist. Kommentare (#) und Zeitstempel werden ignoriert, vorhandene Freigaben bleiben.

Die Freigaben liegen in /data/dns64/allowlist.txt.

Eigene Sperrliste

Domains, die du selbst sperrst, gelten samt aller Subdomains für alle Geräte – zusätzlich zu den Blocklisten. So sperrst du:

• Im Abfrage-Log: neben einer erlaubten oder gecachten Anfrage auf „Blockieren“ klicken.
• Von Hand in der Karte Eigene Sperrliste unter „Freigegebene Domains“ (Reiter Blocklisten); dort nimmst du Sperren auch wieder heraus.
• Eine Freigabe derselben Domain hebt die Sperre auf, eine genauere Freigabe gewinnt: Ist example.com gesperrt und cdn.example.com freigegeben, bleibt cdn.example.com erreichbar. Sperren entfernt eine gleiche Freigabe und umgekehrt; der Cache wird dabei geleert.
• Im Log steht als Grund „eigene Sperrliste (…)“. Die Liste liegt in /data/dns64/denylist.txt, ist im Export enthalten und im Cluster ein eigener Bereich.

Blockieren pausieren

Oben rechts auf den DNS64-Seiten pausierst du das Blockieren für 10 Minuten oder bis zum Wiedereinschalten. Der DNS läuft weiter, eigene Einträge, lokale Namen, Freigaben und die eigenen Sperren der Gerätegruppen bleiben aktiv, und das Log zeigt, was sonst blockiert worden wäre.

Eigene Einträge und lokale Namen

Unter Lokaler DNS → Zonen legst du DNS-Einträge für dein Heimnetz an. Sie gelten sofort, kommen vor den Blocklisten und gehen nie ins Internet. Die Namen eines Proxy-Hosts trägt PROXY64 auf Knopfdruck ein – siehe Lokal in DNS64 eintragen.

• Wildcards wie *.home.lan gelten für alle Namen darunter.
• Zu A und AAAA beantwortet DNS64 automatisch auch die Rückwärtssuche (PTR) – je Eintrag abschaltbar, etwa wenn mehrere Namen auf dieselbe IP zeigen.
• TTL 1 bis 86.400 Sekunden, Standard 300. Jeder Eintrag lässt sich einzeln an- und ausschalten.
• Ein CNAME steht allein: kein weiterer Eintrag für denselben Namen. CNAME-Ketten löst DNS64 bis zu einer Tiefe von 8 auf.
• Bearbeiten im selben Formular, mit Kommentar je Eintrag; Werte prüft und vereinheitlicht DNS64 beim Speichern. Die Liste hat eine Suche.
• Nur diese Node: Einträge mit diesem Haken gleicht der Cluster nie ab.

Import und Export

Einträge lassen sich als Text oder Datei importieren und exportieren:

• Hosts-Datei, z. B. 10.0.0.20 nas nas.home.lan – Zeilen mit localhost und 0.0.0.0 werden übersprungen,
• CSV und JSON mit allen Feldern.

Per API: POST /api/dns64/records/import und GET /api/dns64/records/export?format=hosts|csv|json; einzelne Einträge ändert PUT /api/dns64/records/{id}.

Lokale Namen

Diese Namen fragt DNS64 nur bei deinem Router, nie im Internet:

• einteilige Namen wie nas oder drucker
• .local, .lan, .home, .home.arpa, .internal, .localdomain, .localhost, .fritz.box, .speedport.ip
• Rückwärtssuchen für private Adressbereiche – so zeigt DNS64 die Gerätenamen deiner Clients, die der Router kennt

Als Router nimmt DNS64 automatisch das IPv4-Default-Gateway, ohne IPv4 das IPv6-Gateway (auch Link-Local wie fe80::1%eth0). Unter Einstellungen → Router für lokale Namen kannst du ihn fest eintragen, als IP, IP:Port oder [IPv6]:Port. Findet DNS64 keinen Router, werden lokale Namen nicht aufgelöst. Die eigene Node erkennt die Suche und nimmt sie nie als Router; Anfragen, die vom Router selbst kommen, gibt DNS64 für lokale Namen nicht an ihn zurück.

Lokaler DNS

Eigene Einträge, Zonen und Weiterleitungen haben einen eigenen Menüpunkt: Lokaler DNS mit den Reitern Zonen und Weiterleitungen. DNS64 selbst bleibt der Werbeblocker. Die alten Adressen /dns64/records und /dns64/forwards leiten weiter.

• Zonen-Ansicht: links die Zonen mit der Zahl ihrer Einträge, dazu Alle Einträge und Ohne Zone; rechts die Einträge der gewählten Zone, Namen relativ zur Zone (@ = die Zone selbst).
• Je Zone einstellbar: Standard-TTL und SOA (Refresh, Retry, Expire, TTL für „nicht vorhanden“, verantwortliche Mail).
• Ein Netz wie 10.0.0.0/24 wird zur Rückwärtszone.

Lokale Zonen und Gerätenamen

Unter Lokaler DNS → Zonen machst du DNS64 zum zuständigen DNS-Server für eine Zone wie home.lan:

• Namen unter der Zone beantwortet DNS64 selbst – aus deinen eigenen Einträgen, mit SOA und NS der Zone, damit sich nslookup und Clients sauber verhalten.
• Ist die Zone zuständig, bekommen unbekannte Namen NXDOMAIN mit SOA. Sonst gehen sie weiter an eine Weiterleitung oder an den Router.
• Gerätenamen: Geräte deiner Gerätegruppen mit Bezeichnung erscheinen automatisch als <name>.<zone> – aus „Tablet Lea“ wird tablet-lea.home.lan – mit ihrer aktuellen IP (über die MAC aus der Nachbartabelle oder die eingetragene IP) und mit Rückwärtssuche. Je Zone abschaltbar; die Karte zeigt die Namen mit ihren Adressen.
• Ohne Zone bleibt alles wie unter Lokale Namen beschrieben.
• API: GET|POST /api/dns64/zones, PUT|DELETE /api/dns64/zones/{id}, POST /api/dns64/zones/{id}/enable|disable, GET /api/dns64/device-names.

Zonendatei (BIND)

Jede Zone lässt sich als Zonendatei im BIND-Format herunterladen – mit $ORIGIN, $TTL, SOA, NS, relativen Namen und Kommentaren. Zonendateien aus Bind, Technitium oder Windows-DNS importierst du über denselben Import wie Hosts-Datei, CSV und JSON: SOA-Werte gehen an die Zone, NS und nicht unterstützte Typen werden übersprungen. API: GET /api/dns64/zones/{id}/zonefile und POST /api/dns64/records/import?zone=….

Dynamische Updates (RFC 2136)

Je Zone lassen sich dynamische Updates mit einem TSIG-Schlüssel einschalten. Dann tragen DHCP-Server wie pfSense, OPNsense oder Kea die Namen ihrer Geräte selbst ein.

• Den Schlüssel (HMAC-SHA256) erzeugt die Node; Neuer Schlüssel ersetzt ihn, der alte gilt dann sofort nicht mehr. Die Zone zeigt DNS-Server, Schlüsselname, Algorithmus und ein Beispiel für nsupdate.
• Erlaubt sind A, AAAA, CNAME, TXT, PTR, SRV, MX und DHCID; Vorbedingungen und Löschen nach RFC, alles oder nichts.
• Abgelehnt wird ohne gültigen Schlüssel, außerhalb der Zone und für SOA oder NS. Per Update angelegte Einträge sind markiert.
• Der Schlüssel bleibt auf der Node – nie in API, Export oder Cluster.

Weiterleitungen

Unter Lokaler DNS → Weiterleitungen schickst du eine Domain an eigene DNS-Server – etwa firma.local an den DNS im VPN oder ein Netz wie 192.168.0.0/16 (daraus wird die Rückwärtszone) an den Router.

• Server als IP, IP:Port, tls:// (DoT), https:// (DoH) oder quic:// (DoQ). Mehrere Server fragt DNS64 der Reihe nach, fällt einer aus, kommt der nächste.
• Die Domain gilt mit allen Unternamen; die längste passende Domain gewinnt.
• Blocklisten und Regeln der Gerätegruppen gelten weiter – außer für lokale Namen und die private Rückwärtssuche.
• Antwortet kein Server, gibt es SERVFAIL. Der Name geht nie an die öffentlichen Upstreams – interne Namen bleiben intern.
• Testen je Weiterleitung (fragt die SOA ab), Statistik je Server, und im Abfrage-Log steht als Grund „Weiterleitung … über …“.
• Nur diese Node: wird im Cluster nie abgeglichen, z. B. firma.local nur am Büro-Standort.
• Prometheus: node64_dns64_forward_up, node64_dns64_forward_requests_total, node64_dns64_forward_errors_total mit domain und server.
• API: GET|POST /api/dns64/forwards, PUT|DELETE /api/dns64/forwards/{id}, POST /api/dns64/forwards/{id}/enable|disable|test.

Umschreiben

Beim Umschreiben antwortet ein Name – auch mit Platzhalter wie *.example.de – so wie ein anderer. DNS64 löst das Ziel selbst auf und antwortet unter dem gefragten Namen, ohne CNAME. Ketten verfolgt DNS64, Schleifen ergeben SERVFAIL. API: GET|POST /api/dns64/rewrites, PUT|DELETE /api/dns64/rewrites/{id}, POST /api/dns64/rewrites/{id}/enable|disable.

DNS64 im Cluster

Im Cluster erscheint DNS64 mit acht Schaltern, die ohne Einstellung alle aus sind:

• Ein Bereich wird nur mit Nodes abgeglichen, bei denen er ebenfalls an ist; die jüngere Änderung gewinnt. „Internet aus“ wirkt so auf allen Nodes zugleich.
• Einträge und Weiterleitungen mit Nur diese Node werden nie abgeglichen, und ein gleicher Eintrag einer anderen Node überschreibt sie nicht.
• Gibt es dieselbe Gruppe (gleicher Name) schon auf beiden Nodes, wird sie beim ersten Abgleich zusammengeführt.
• Eine Node übernimmt die Einträge auch, solange DNS64 bei ihr noch aus ist.
• Nie abgeglichen: Ports, Schnittstellen, Router, DoH/DoT/DoQ, Namen und Zertifikat, Client-Netze, Pause und Abfrage-Log.

Cache

DNS64 arbeitet mit einem optimistischen Cache: Häufige Domains werden kurz vor Ablauf automatisch erneuert. Abgelaufene Einträge liefert DNS64 bis zu einer Stunde lang sofort aus und erneuert sie im Hintergrund. Die längste TTL im Cache ist 24 Stunden.

• Größe: Standard 20.000 Einträge, einstellbar von 1.000 bis 200.000 (Einstellungen → DNS-Cache).
• Anzeige in der Übersicht: Trefferquote, Einträge, eingesparte Wartezeit, veraltet ausgeliefert, im Hintergrund erneuert (Zähler seit dem letzten Start).
• Cache leeren per Knopf – die nächsten Anfragen gehen dann wieder an die Upstreams.

Statistik und Abfrage-Log

Die Übersicht zeigt Kennzahlen (Anfragen, blockiert, aus dem Cache, Clients, Ø Upstream-Zeit, Blocklisten), ein Diagramm über 1 Stunde, 24 Stunden oder 7 Tage (am Diagramm Anfragen im Zeitverlauf zusätzlich eigene Knöpfe für 30 min, 6 h, 24 h und 7 Tage), den Zustand der Upstreams und des Caches sowie die Top blockierten Domains, Top erlaubten Domains und Top-Clients. Eine Kachel mit den letzten 24 Stunden gibt es auch im Node64-Dashboard.

Das Abfrage-Log filtert nach Alle, Blockiert, Erlaubt, Cache, Lokal und Fehler, sucht nach Domain oder IP, zeigt das Protokoll jeder Anfrage (UDP, TCP, DoH, DoT, DoQ) und läuft auf Wunsch live mit. Die Trefferzahl zählt es höchstens bis 100.000 und zeigt darüber „100.000+“. Übersicht, Dashboard-Karte, Top-Listen und Geräteliste lesen aus Zählern je Minute und Stunde statt aus dem ganzen Log – so bleiben sie auch bei Millionen Einträgen schnell. Beim Update auf DNS64 1.28.0 baut die Node diese Zähler einmal aus dem vorhandenen Log auf.

Fragt ein Gerät eine öffentliche Domain mit angehängter lokaler Suchdomain an, etwa example.com.home.local, steht dabei „Suchdomain vom Gerät angehängt“. Das macht das Gerät selbst, meist nachdem die eigentliche Anfrage gescheitert ist (z. B. SERVFAIL, weil die Upstreams kurz nicht antworteten). DNS64 hängt nichts an.

Gekürzt oder nicht gespeichert gilt für neue Einträge; Gerätenamen und Top-Clients gibt es dann nur eingeschränkt bzw. gar nicht. Das Log liegt in einer eigenen SQLite-Datei (/data/dns64/dns64.db), Abgelaufenes wird stündlich in kleinen Stücken gelöscht.

Für Grafana & Co. liefert DNS64 Kennzahlen an GET /api/metrics – Anfragen je Ergebnis und Protokoll, Antwortzeiten, Cache, Blocklisten und Upstreams. Details unter Prometheus.

Gerätegruppen

Im Reiter Gruppen fasst du Geräte zusammen, z. B. „Kinder“, „Smart-TV“ oder „Gäste“. So siehst du im Abfrage-Log auf einen Blick, welche Gruppe gerade was abfragt.

• Erkennung per MAC zuerst: DNS64 liest die MAC-Adresse aus der Nachbartabelle des Hosts (IPv4 und IPv6). Ein Gerät bleibt so in seiner Gruppe, auch wenn es eine neue IPv4- oder IPv6-Adresse bekommt. Das klappt nur für Geräte im selben Netz und mit Host-Netzwerk.
• Sonst per IP-Adresse oder Netz, z. B. ein Teilnetz deines Heimnetzes oder einzelne Adressen.
• Reihenfolge = Vorrang: Ein Gerät gehört zu höchstens einer Gruppe; passt es auf mehrere, gilt die oberste. Die Reihenfolge änderst du per Verschieben.
• Per Klick zuordnen: Die Geräte der letzten 24 Stunden (aus dem Abfrage-Log, mit Name vom Router und MAC) lassen sich direkt einer Gruppe zuweisen.
• Abfrage-Log: zeigt die Gruppe am Client und filtert nach Gruppe, auch nach „ohne Gruppe“.

# Gruppen und erkannte Geräte abrufen
curl -H "Authorization: Bearer DEIN_API_KEY" http://IP-DER-NODE:8080/api/dns64/groups
curl -H "Authorization: Bearer DEIN_API_KEY" http://IP-DER-NODE:8080/api/dns64/devices
# Abfrage-Log einer Gruppe
curl -H "Authorization: Bearer DEIN_API_KEY" "http://IP-DER-NODE:8080/api/dns64/log?group=GRUPPEN_ID"
# Regeln einer Gruppe (Listen, Kategorien, safesearch, youtube, bypass): PUT /api/dns64/groups/GRUPPEN_ID/rules
# eigene Freigaben/Sperren: POST /api/dns64/groups/GRUPPEN_ID/domains, DELETE /api/dns64/groups/domains/ID

Regeln je Gruppe

Unter Gruppen → Regeln bekommt jede Gruppe ihre eigenen Regeln – etwa strenger für die Kinder, lockerer für die Arbeitsgeräte:

• Blocklisten: wie für alle Geräte oder eine eigene Auswahl aus allen Vorlagen und eigenen Listen.
• Kategorien sperren: Soziale Netzwerke, Spiele und Streaming (kleine, von Node64 gepflegte Listen, u. a. TikTok, Instagram, Roblox, Fortnite, YouTube, Netflix) sowie Glücksspiel und Erwachseneninhalte (schalten HaGeZi Gambling bzw. HaGeZi NSFW für die Gruppe ein).
• Eigene Freigaben und Sperren je Gruppe, jeweils samt Subdomains.
• Reihenfolge: Freigabe der Gruppe vor Sperre der Gruppe vor Kategorien vor Blocklisten.
• Abfrage-Log: zeigt als Grund „Sperre der Gruppe“ bzw. „Kategorie …“.

Geladen werden die global eingeschalteten Listen plus die, die eine Gruppe zusätzlich nutzt – jede Liste nur einmal (insgesamt höchstens 64). Der Cache ist für alle Gruppen gemeinsam; versteckte Tracker hinter CNAMEs werden auch bei Antworten aus dem Cache geprüft. Die globale Pause setzt Blocklisten und Kategorien aus, nicht die eigenen Sperren einer Gruppe. Jede Änderung an Gruppen steht im Audit-Log.

SafeSearch je Gruppe

Ein Schalter je Gruppe zwingt die großen Suchmaschinen in den sicheren Modus – per DNS, ohne Software auf den Geräten:

• Google (alle Länderendungen) → forcesafesearch.google.com
• Bing → strict.bing.com
• DuckDuckGo → safe.duckduckgo.com
• YouTube eingeschränkt: streng (restrict.youtube.com), mittel (restrictmoderate.youtube.com) oder aus

Das gilt auch, wenn die Gruppe die Domain freigegeben hat. HTTPS bleibt unberührt; im Abfrage-Log steht der Grund „SafeSearch → …“.

Schutz gegen Umgehen

Damit Geräte einer Gruppe den Filter nicht einfach umgehen, schaltet „Schutz gegen Umgehen“ für die Gruppe ein:

• die Liste HaGeZi DoH/VPN/Proxy Bypass (fremde DoH-Server, VPNs und Proxys),
• iCloud Private Relay aus: mask.icloud.com und mask-h2.icloud.com bekommen NXDOMAIN,
• Firefox-DoH aus: use-application-dns.net bekommt NXDOMAIN.

Zeitpläne, Sperren und Frei

Für feste Zeiten – etwa „unter der Woche kein Internet nach 21 Uhr“ – legst du je Gruppe Zeitpläne an:

• Wann: gewählte Wochentage, von–bis in der Zeitzone der Node. Über Mitternacht geht auch; sind Beginn und Ende gleich, gilt der ganze Tag.
• Was: „Internet aus“ oder zusätzliche Kategorien sperren (z. B. Soziale Netzwerke und Spiele während der Hausaufgaben).
• Jeder Zeitplan lässt sich einzeln an- und ausschalten.

Für spontane Fälle gibt es im Kopf jeder Gruppe Knöpfe:

„Internet aus“ heißt: Es funktionieren nur noch lokale Namen, eigene Einträge und die Freigaben der Gruppe. Alle anderen Namen bekommen die Adresse der Node (TTL 10 s). Ruft ein Gerät dann eine Seite per http:// auf, zeigt der gemeinsame Eingang auf Port 80 eine Hinweisseite mit Gruppe, Grund und Ende der Sperre; bei https:// zeigt der Browser nur einen Zertifikatsfehler. Port 80 ist dafür nur offen, solange eine Gruppe gesperrt sein kann. Im Abfrage-Log stehen die Gründe „Internet aus“ bzw. „Zeitplan …: Internet aus“.

# Gruppe für 60 Minuten sperren (mode: block, free oder "" zum Aufheben)
curl -X POST -H "Authorization: Bearer DEIN_API_KEY" -H "Content-Type: application/json" \
  -d '{"mode":"block","minutes":60}' http://IP-DER-NODE:8080/api/dns64/groups/GRUPPEN_ID/hold
# Zeitplan: Mo–Fr 21:00–07:00 Internet aus
curl -X POST -H "Authorization: Bearer DEIN_API_KEY" -H "Content-Type: application/json" \
  -d '{"label":"Schlafenszeit","days":[1,2,3,4,5],"start":"21:00","end":"07:00","action":"off"}' \
  http://IP-DER-NODE:8080/api/dns64/groups/GRUPPEN_ID/schedules

GET /api/dns64/groups liefert je Gruppe den aktuellen Zustand (state: Internet aus, Frei, per Knopf, bis zum Aufheben, bis wann, welcher Zeitplan). Die Dashboard-Karte von DNS64 zeigt die Zahl der Gerätegruppen und wie viele davon gerade „Internet aus“ haben; für Prometheus gibt es Werte je Gruppe (siehe Prometheus). Weitere Endpunkte: POST /api/dns64/groups/schedules/{id}/enable bzw. /disable und DELETE /api/dns64/groups/schedules/{id}.

Verschlüsselt im Heimnetz (DoH, DoT, DoQ)

Deine Geräte können DNS64 auch verschlüsselt fragen statt über Port 53. Es gelten dieselben Blocklisten, Freigaben und erlaubten Netze. Du schaltest jeden Dienst einzeln ein unter DNS64 → Verschlüsselung; ist ein Port belegt, stoppt nur dieser Dienst.

DoH läuft über den gemeinsamen Eingang von Node64 und teilt sich Port 443 mit PROXY64, auch über HTTP/3. Der DoH-Port darf nicht der Port der Weboberfläche sein, und DoH- und DoT-Port müssen sich vom DNS-Port unterscheiden.

Unter Namen für Geräte trägst du ein, unter welchen Namen Geräte DNS64 erreichen – z. B. dns.home.lan, angelegt als eigener Eintrag auf die IP der Node. Die IPs der Node stehen automatisch im Zertifikat.

Zertifikat

Für DoT, DoH und DoQ braucht DNS64 ein Zertifikat. Es gibt drei Wege:

iPhone, iPad und Mac: Profil

Im Reiter Verschlüsselung lädst du unter „Für Geräte“ ein fertiges Profil herunter – wahlweise für DoH oder DoT (dns64-doh.mobileconfig bzw. dns64-dot.mobileconfig). Es enthält die DNS-Einstellungen und, bei eigener CA, gleich das CA-Zertifikat.

1. Profil laden
   Am besten direkt auf dem Gerät in Safari öffnen.
2. Installieren
   Auf iPhone und iPad unter Einstellungen → Allgemein → VPN und Geräteverwaltung. Auf dem Mac die Datei öffnen und die Installation in den Systemeinstellungen bestätigen.
3. CA vertrauen (nur bei eigener CA)
   Auf iPhone und iPad unter Einstellungen → Allgemein → Info → Zertifikatsvertrauenseinstellungen das Vertrauen für die DNS64-CA einschalten.

Android: Privates DNS

Android „Privates DNS“ nutzt DoT und akzeptiert nur öffentlich gültige Zertifikate, keine eigene CA. So geht es:

1. In der Zertifikatsverwaltung ein Let's-Encrypt-Zertifikat für einen Namen unter deiner ipv64-Domain anlegen, z. B. dns.DEINE-DOMAIN.ipv64.de.
2. Unter DNS64 → Verschlüsselung dieses Zertifikat wählen und DoT einschalten.
3. Damit der Name im Heimnetz auf die Node zeigt, leg ihn in DNS64 als eigenen Eintrag (A/AAAA auf die IP der Node) an.
4. Auf dem Android-Gerät den Namen als Anbieter für „Privates DNS“ eintragen.

Windows und Browser

• Windows 11: Bei eigener CA das CA-Zertifikat unter „Vertrauenswürdige Stammzertifizierungsstellen“ importieren. Dann in den Netzwerkeinstellungen den DNS-Server manuell auf die IP der Node stellen, mit DNS-over-HTTPS und der DoH-Adresse.
• Firefox und Chrome: „Sicheres DNS“ mit der DoH-Adresse einschalten. Firefox hat einen eigenen Zertifikatspeicher – die CA dort importieren.
• Firefox nutzt DNS64: Standardmäßig beantwortet DNS64 use-application-dns.net mit NXDOMAIN. Firefox schaltet dann sein eingebautes DoH ab und fragt DNS64 – sonst würde es am Filter vorbei auflösen. Abschaltbar unter Einstellungen (API: firefox_canary in /api/dns64/settings); im Log steht „Firefox-DoH abgeschaltet“.

Das CA-Zertifikat allein lädst du ebenfalls im Reiter Verschlüsselung herunter (per API: GET /api/dns64/ca.crt).

Benachrichtigungen

DNS64 meldet sich an deinen Standardkanälen (nicht in der Ruhezeit), wenn

• ein Upstream-Server länger als 3 Minuten gestört ist – und wieder, wenn er antwortet,
• eine Blockliste dreimal hintereinander nicht geladen werden kann.

Beides schaltest du unter DNS64 → Einstellungen → Benachrichtigungen ab. Webhooks bekommen die Arten dns64_upstream, dns64_upstream_ok und dns64_lists. Kanäle richtest du unter Benachrichtigungen ein.

Daten, Export und API

• Dateien unter /data/dns64/: dns64.db (Abfrage-Log), allowlist.txt (Freigaben), denylist.txt (eigene Sperrliste), lists/ (Blocklisten). Einstellungen und eigene Einträge liegen in der Datenbank der Node.
• Export/Import enthält Einstellungen, Freigaben, die eigene Sperrliste, eigene Einträge, lokale Zonen (ohne TSIG-Schlüssel), Weiterleitungen und Umschreiben – siehe Update & Backup.
• Lokale API unter /api/dns64/…: Status, Kennzahlen, Zeitverlauf, Top-Listen, Log, Listen, Upstreams, Cache, Freigaben, eigene Sperrliste (/api/dns64/denylist), Einstellungen, eigene Einträge, Gerätegruppen samt Regeln (/api/dns64/groups, /api/dns64/devices), Pause sowie CA-Zertifikat und Apple-Profil. Jede Änderung steht im Audit-Log. Mehr unter API.

# Blockieren für 10 Minuten pausieren (0 = bis zum Wiedereinschalten), dann wieder einschalten
curl -X POST -H "Authorization: Bearer DEIN_API_KEY"   -H "Content-Type: application/json" -d '{"minutes": 10}'   http://IP-DER-NODE:8080/api/dns64/pause
curl -X POST -H "Authorization: Bearer DEIN_API_KEY"   http://IP-DER-NODE:8080/api/dns64/resume

Fehlerbehebung

Etwas unklar, fehlt etwas oder hast du eine Frage zu Node64? Frag im offiziellen Forum v64.tech.