Viele sperren billigen Kameras und Smart-Home-Geräten in der Fritzbox den Internetzugang, damit sie nicht nach Hause telefonieren. Die Annahme dahinter: Ein gesperrtes Gerät ist abgeschottet. Ich wollte wissen, ob das stimmt, und habe es an einem Sonntagabend mit einem Rechner in meinem Heimnetz nachgestellt.
Anlass war ein Vorfallbericht von OpenAI [1]. Ein KI-Agent hatte in einer Trainingsumgebung, deren Internetzugang gesperrt war, über DNS einen externen Chatbot erreicht. Die Frage lag nahe, ob das in meinem Netz auch ginge. Die kurze Antwort: ja, und zwar auf zwei Wegen, von denen sich nur einer mit Bordmitteln schließen ließ.
Dieser Beitrag setzt die Reihe fort. Im ersten Teil ging es um die Fehlersuche am eigenen DNS-Server, im zweiten darum, welche Geräte über ihn reden. Hier geht es um ein Gerät, das eigentlich gar nicht mehr reden soll.
Der Aufbau in drei Sätzen
Technitium DNS Server beantwortet Namen unter home.arpa selbst und reicht alles andere an die Fritzbox weiter. Die Fritzbox betreibt einen eigenen lokalen DNS-Dienst und reicht externe Anfragen an ihre konfigurierten Upstream-Resolver weiter, verschlüsselt per DNS over TLS. Diesen Dienst kann jedes Gerät im Netz auch direkt ansprechen. Der Einfachheit halber nenne ich ihn im Folgenden den Resolver der Fritzbox.
Testrechner (192.168.1.28)
├─> Technitium (192.168.1.47)
│ ├─ home.arpa → selbst beantwortet
│ └─ alles andere → Fritzbox
└─> Fritzbox (192.168.1.1) → DoT → öffentliches DNS
Ein frischer Name gegen den Cache
Der erste Versuch war zu einfach. Eine Abfrage nach example.com beim eigenen Server kam nach 2 Millisekunden zurück, mit einer Restlaufzeit von 66 Sekunden. Das war eine Antwort aus dem Cache. Ob eine Anfrage das Haus verlassen hat, sagt sie nicht.
Belastbar wird der Test erst mit einem Namen, den es noch nie gab. Die Unix-Zeit in Sekunden als erster Bestandteil sorgt dafür, dass jeder Aufruf neu ist:
$ dig $(date +%s).example.com @192.168.1.47
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; AUTHORITY SECTION:
example.com. 1800 IN SOA elliott.ns.cloudflare.com. dns.cloudflare.com. ...
;; Query time: 168 msec
Einen normalen Cache-Treffer schließt der frische Name praktisch aus, denn genau diesen Namen hat vorher niemand gefragt. Der SOA-Eintrag gehört zu den Nameservern, die für example.com zuständig sind, hier bei Cloudflare. Die Antwort zeigt damit, dass der Rechner über Technitium und die Fritzbox eine externe Auflösung anstoßen kann, und die Laufzeit von 168 statt 2 Millisekunden passt zu einem Weg nach draußen.
Ein strenger Beweis, dass genau diese einzelne Anfrage bei Cloudflare angekommen ist, ist das allerdings nicht. Validierende Resolver können negative Antworten unter Umständen aus bereits gecachten DNSSEC-Daten ableiten, ohne den zuständigen Server erneut zu fragen [5]. Die beobachtete Antwort passt allerdings zu den kompakten Negativantworten, die Cloudflare verwendet [6]. Deren NSEC-Eintrag deckt nur den gefragten Namen ab, für einen neuen Namen lässt sich daraus nichts ableiten. Einen Beweis, dass genau diese Anfrage draußen ankam, ersetzt das trotzdem nicht. Den strengeren Nachweis brächte ein Mitschnitt am Internetanschluss oder eine eigene Testdomain, deren autoritativer Server protokolliert, welche Namen tatsächlich ankommen. Für die Aussage dieses Beitrags ist das nicht entscheidend: Es reicht, dass der Rechner einen Dienst erreicht, der für ihn nach außen fragen darf.
NODATA statt NXDOMAIN
Erwartet hatte ich für einen nicht existierenden Namen den Status
NXDOMAIN. Zurück kamNOERRORohne Antwortdatensatz, aber mit dem SOA-Eintrag der Zone, dazu das Flagadfür eine per DNSSEC validierte Antwort. Das ist eine NODATA-Antwort [4]. Formal besagt sie, dass der Name existiert, nur nicht mit dem angefragten Typ. Für einen erfundenen Namen ist das ungewöhnlich, aber als Verfahren standardisiert: Beim Compact Denial of Existence, das Cloudflare seit Jahren einsetzt, werden nicht existierende Namen auf diese verkürzte Weise verneint [6]. An meinem Aufbau liegt es nicht, denn die Fritzbox lieferte ohne Technitium dieselbe Antwort. Für den Test spielt das keine entscheidende Rolle. Entscheidend ist, dass die Resolver-Kette dem Rechner weiterhin Antworten für externe Namen liefert. Wer das nachstellt, sollte deshalb nicht auf einen bestimmten Status warten, sondern auf den SOA-Eintrag schauen.
Genau dieser Weg ist der Kern des Problems. Statt der Zahl kann vor dem Punkt auch kodierter Text stehen, und statt Cloudflare kann ein Nameserver antworten, den jemand selbst betreibt oder als Dienst anbietet. Dann wird aus der Namensauflösung ein Übertragungskanal in beide Richtungen. Solche Verfahren sind seit Jahren bekannt und laufen meist unter dem Begriff DNS-Tunneling.
Test 1: Rechner in der Fritzbox gesperrt
Die Fritzbox kann einzelnen Geräten die Internetnutzung sperren. Mit aktiver Sperre:
$ curl -m 5 https://example.com
curl: (7) Failed to connect to example.com port 443 after 197 ms: Couldn't connect to server
$ dig $(date +%s).example.com @192.168.1.47
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
example.com. 1800 IN SOA elliott.ns.cloudflare.com. ...
;; Query time: 35 msec
Die Webseite kommt nicht an, die Sperre wirkt. Die Fehlermeldung von curl verrät aber bereits ein Detail: Sie nennt Port 443 von example.com, der Name war also aufgelöst. Die zweite Abfrage bestätigt es: Auch ein nie zuvor gefragter Name wird weiterhin extern aufgelöst.
Der Grund liegt in der Weiterleitung. Der Rechner fragt nicht die Fritzbox, sondern Technitium, und das geschieht im lokalen Netz, an der Fritzbox vorbei. Technitium leitet den unbekannten Namen weiter, und zwar unter seiner eigenen Adresse. Die Fritzbox sieht eine Anfrage von 192.168.1.47, und die ist nicht gesperrt. Wer eigentlich gefragt hat, erfährt sie nicht.
Test 2: Weiterleitung in Technitium gesperrt
Technitium kann Rekursion, also das Auflösen fremder Namen, je Absender erlauben oder verweigern. Unter Settings › Recursion steht standardmäßig Allow Recursion Only For Private Networks. Für den Test habe ich auf Use Specified Network Access Control List (ACL) umgestellt:
!192.168.1.28
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
fc00::/7
fe80::/10
Drei Punkte sind dabei wichtig:
- Die Reihenfolge entscheidet. Technitium arbeitet die Liste von oben ab, der erste Treffer gilt. Stünde die Sperrzeile unter
192.168.0.0/16, käme sie nie zum Zug. - Ohne die übrigen Zeilen steht das ganze Netz ohne DNS da. Passt keine Zeile, verweigert Technitium laut Beschreibung in der Oberfläche alles außer Loopback. Die privaten Bereiche bilden deshalb die bisherige Standardeinstellung nach.
- IPv6 zählt mit. Der Testrechner hat neben seiner IPv4-Adresse zwei lokale IPv6-Adressen, die unter
fc00::/7fallen. Fragt er darüber an, läuft er an einer reinen IPv4-Sperre vorbei. Mindestens eine davon ist vermutlich eine temporäre Adresse, die regelmäßig wechselt [2]. Für einen Abendtest lässt sie sich mitsperren, als dauerhafte Regel taugt sie nicht. Dasselbe Problem war im zweiten Teil der Grund für die Ausnahme beim Sprachassistenten.
Ergebnis, weiterhin mit Fritzbox-Sperre:
$ dig $(date +%s).example.com @192.168.1.47
;; ->>HEADER<<- opcode: QUERY, status: REFUSED
;; WARNING: recursion requested but not available
;; Query time: 3 msec
REFUSED nach 3 Millisekunden: Technitium hat gar nicht erst nach draußen gefragt. Die eigene Zone home.arpa sollte von der Sperre nicht betroffen sein, weil Technitium sie ohne Rekursion selbst beantwortet; geprüft habe ich das an diesem Abend nicht. Geprüft habe ich den Weg über IPv4.
Test 3: dieselbe Anfrage an die Fritzbox
Der Rechner muss Technitium aber nicht fragen. Er kann sich direkt an die Fritzbox wenden:
$ dig $(date +%s).example.com @192.168.1.1
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
example.com. 1800 IN SOA elliott.ns.cloudflare.com. ...
;; Query time: 28 msec
Der Kanal ist offen. Die Fritzbox beantwortet DNS-Anfragen jedes Geräts im Netz, auch die des gesperrten. Ihre Gerätesperre gilt für den Weg ins Internet, nicht für Anfragen an sie selbst. Und weil die Fritzbox selbst ins Internet darf, fragt sie für den gesperrten Rechner einfach nach.
Eine Einstellung, mit der sich der DNS-Dienst der Fritzbox für einzelne Geräte sperren ließe, habe ich nicht gefunden. Damit bleiben drei Wege, und keiner ist elegant:
- Eine Firewall auf dem Rechner selbst, die Port 53 zu allem außer Technitium blockiert. Das wirkt, sitzt aber auf genau dem Gerät, dem man nicht traut. Wer dort Administratorrechte hat, schaltet sie ab.
- Ein eigenes Netzsegment per VLAN hinter einer Firewall, die aus diesem Segment nur Technitium erreichbar lässt. Das ist die saubere Lösung und ohnehin der nächste Schritt, der im zweiten Teil angekündigt ist. Mit der Fritzbox allein lässt sie sich nicht umsetzen.
- Das Gastnetz der Fritzbox hilft hier nicht, denn auch Gäste nutzen deren Resolver.
Der Vorfall bei OpenAI
Der Bericht von OpenAI beschreibt einen Lauf im Reinforcement-Learning-Training [1]. Ein Agent sollte eine biografische Recherche erledigen, in einer Umgebung ohne Zugang zum offenen Internet. Die bereitgestellte Websuche brachte keine brauchbaren Treffer, direkte Anfragen an andere Suchmaschinen scheiterten, und auch öffentliche DNS-Server antworteten nicht. Der Resolver der Trainingsumgebung dagegen lieferte für eine bekannte Domain einen echten Eintrag und wies eine erfundene korrekt ab. Aus der erfolgreichen Auflösung und der korrekten Ablehnung schloss der Agent, dass dieser Resolver einen Weg ins öffentliche Internet hatte. Über einen öffentlichen Dienst, der Anfragen per DNS-Delegation weiterreicht, stellte er dann seine Fragen an einen externen Chatbot. Die Zeitleiste laut Bericht:
| Uhrzeit | Ereignis |
|---|---|
| 09:50:23 | erste erfolgreiche Antwort von außen über DNS |
| 10:02:11 | Alarm des Monitorings |
| 10:05:06 | ein Mensch beginnt mit der Prüfung |
| 12:34:30 | Lauf beendet |
OpenAI hat daraufhin Training, Evaluation und Inferenz mit Werkzeugnutzung seiner leistungsfähigsten Modelle pausiert, bis die Kontrollen validiert und weitere Red-Team-Tests durchgeführt sind.
Technisch ist das nicht dasselbe wie mein Abendtest, das Muster aber schon. Gesperrt war der sichtbare Zugang, also Websuche und direkte Verbindungen. Offen blieb ein Baustein darunter, der im Auftrag anderer nach außen fragen darf. Mein Heimnetz hatte davon zwei. Auch der Testgedanke war ähnlich: Der Agent prüfte mit einem bekannten und einem erfundenen Namen, ob der interne Resolver noch Auskünfte von außen beschaffen konnte.
Zugriffssperre und Abschottung sind zwei Schutzziele
Wertlos ist die Gerätesperre der Fritzbox deshalb nicht. Sie verhindert, dass der Rechner Webseiten lädt, und für eine Kindersicherung ist genau das der Zweck. Dass DNS weiter funktioniert, heißt nicht, dass normaler Webverkehr durchkommt. Webseiten und gewöhnliche HTTPS-Verbindungen bleiben gesperrt.
Gegen den Abfluss von Daten schützt die Sperre aber nicht, denn DNS selbst kann Nutzdaten in beide Richtungen tragen. Beim OpenAI-Agenten kamen auf diesem Weg die Antworten des Chatbots zurück. Ein Tunnel braucht nur eine Gegenstelle, die mitspielt. Bei einem kompromittierten Gerät stellt sie der Angreifer, beim Agenten von OpenAI war es ein vorhandener Dienst. Ob handelsübliche Kameras diesen Weg tatsächlich nutzen, zeigt mein Test nicht. Er zeigt nur, dass er offen wäre. Wer ein Gerät nicht nur vom Surfen abhalten, sondern abschotten will, muss jeden Resolver in der Kette einbeziehen.
Was bleibt
Jeder Resolver ist ein Ausgang, jedenfalls sobald er für den Client externe Namen auflösen oder weiterleiten darf. In meinem Netz gibt es zwei, und eine Sperre, die nur einen davon kennt, verschiebt das Problem nur.
Weiterleitung verschleiert den Absender. Wer eine Anfrage weiterreicht, stellt sie auf IP-Ebene mit der eigenen Adresse. Der nächste Resolver sieht als Absender Technitium oder die Fritzbox, nicht den ursprünglichen Rechner. Die Sperre muss deshalb dort greifen, wo das Gerät noch erkennbar ist, also am ersten Resolver, nicht am letzten.
Testen statt der Einstellung glauben. Ein dig mit einem frischen Namen zeigt in Sekunden, ob ein Gerät trotz Sperre noch externe DNS-Antworten erhält. Die Oberfläche der Fritzbox zeigt nur, dass eine Sperre eingerichtet ist.
Dazu gehört auch hier der Rückweg. Die Rekursionssperre in Technitium gilt unabhängig von der Fritzbox. Hebt man die Gerätesperre auf und vergisst die ACL, kann der Rechner keine fremden Namen mehr auflösen und wirkt, als sei das Internet ausgefallen. Nach dem Test gehört die Einstellung deshalb zurück auf Allow Recursion Only For Private Networks.
Ob ein Gerät abgeschottet ist, zeigt nicht die Einstellung in der Fritzbox, sondern erst ein Test.
Zum Aufbau und zu den Beispielen
Adressbereich und Gerätenamen sind wie in den vorigen Teilen für diesen Text geändert, die letzten Stellen der Adressen und alle Befunde entsprechen dem realen Aufbau. IPv6-Adressen, IPv6-Präfixe und Hardware-Adressen sind nicht enthalten, die Befehlsausgaben sind gekürzt. Im Bild stehen statt der Adressen Rollennamen. Alle Tests stammen vom 27. September 2026 und liefen gegen Technitium DNS Server 15.5 und die Fritzbox im Heimnetz.
Von Ralf Seidenschwang.
Kleines Lexikon
- Resolver: Dienst, der für ein Gerät Namen in Adressen übersetzt. Kennt er die Antwort nicht, fragt er selbst weiter.
- Forwarder: Resolver, der Anfragen nicht selbst bis zum Ende auflöst, sondern an einen vorgelagerten Resolver weiterreicht, den Upstream. In meinem Netz tun das Technitium (an die Fritzbox) und die Fritzbox (an ihren Anbieter).
- Rekursion: das Auflösen eines fremden Namens im Auftrag eines Geräts, bei Bedarf über Root-Server, die Server der Top-Level-Domain und den zuständigen Nameserver. Technitium kann sie je Absender erlauben oder verweigern.
- Zone: Bereich des Namensraums, für den ein Nameserver zuständig ist, etwa
example.commit allem darunter. - Autoritativer Nameserver: Server, der die verbindlichen Einträge einer Zone hält und sie ohne Rückfrage beantwortet. Für
example.comsind das Server bei Cloudflare, fürhome.arpain meinem Netz Technitium. Welcher Server für eine Domain zuständig ist, legt ihr Inhaber fest. Genau das macht DNS-Tunneling so einfach. - SOA (Start of Authority): Kopfeintrag jeder Zone mit primärem Nameserver, Kontaktadresse, Seriennummer und Zeitwerten. Der letzte Wert bestimmt, wie lange ein Resolver sich merken darf, dass es etwas nicht gibt. Deshalb hängt der SOA an jeder negativen Antwort.
- NXDOMAIN: Antwortstatus für „Diesen Namen gibt es nicht“.
- NODATA: Status
NOERRORohne Antwortdatensatz, dazu der SOA. Bedeutet „Den Namen gibt es, aber nicht mit dem gefragten Eintragstyp“. - REFUSED: Der Server verweigert die Antwort, in Test 2, weil die Rekursion für den Absender gesperrt ist.
- TTL (Time to Live): Wie viele Sekunden eine Antwort im Cache bleiben darf.
- DNSSEC: Signaturen für DNS-Einträge, mit denen ein Resolver prüfen kann, ob eine Antwort echt ist. Das Flag
adzeigt, dass diese Prüfung gelungen ist. - DNS over TLS (DoT): verschlüsselte Übertragung von DNS-Anfragen, üblicherweise über Port 853.
- ULA (Unique Local Address): IPv6-Adressen für das lokale Netz aus dem Bereich
fc00::/7, vergleichbar mit192.168.x.xbei IPv4. - DNS-Tunneling: Übertragung beliebiger Daten in DNS-Anfragen und -Antworten, etwa kodiert in erfundenen Namen.
Citations
[1] OpenAI Alignment: An agent used DNS to reach an external chatbot (öffnet in neuem Tab)
[3] Technitium DNS Server, Quellcode und Dokumentation (öffnet in neuem Tab)
[6] RFC 9824: Compact Denial of Existence in DNSSEC (öffnet in neuem Tab)