Seit dem 17. September hängt der Fernseher nicht mehr selbst im Netz. Anfragen an Netflix-Protokollierungsdienste tauchten trotzdem weiter im DNS-Log auf. Dass andere Geräte dafür infrage kamen, war naheliegend. Ich wollte genauer wissen, welche Geräte diese Anfragen stellten und welche Filterregeln dafür sinnvoll waren.
Die Frage, wer da eigentlich redet, war schnell beantwortet. Interessanter ist der Weg dorthin, weil er an zwei Stellen scheitert, bevor er funktioniert: Das Protokoll zeigt keine Namen, und meine Annahme über die Quelle war falsch. Dieser Beitrag geht die Kette in der Reihenfolge durch, in der ich sie gelaufen bin: Symptom, Lesbarkeit, Auflösung, Regel, Ausnahme.
Er schließt an den ersten Teil der Reihe an, in dem es um die Fehlersuche am selben DNS-Server ging.
Der Aufbau in drei Sätzen
Im Heimnetz läuft Technitium DNS Server als Container auf einem kleinen
Linux-Server. Namen unter home.arpa beantwortet er selbst, alles andere reicht
er an den Router weiter, der verschlüsselt per DNS over TLS nach außen fragt.
Gefiltert wird mit der App Advanced Blocking, die unterschiedlichen Geräten
unterschiedliche Blocklisten zuordnen kann.
Gerät im Heimnetz
└─> Technitium (Port 53)
├─ home.arpa → selbst beantwortet
├─ 1.168.192.in-addr.arpa → selbst beantwortet (Rückwärtszone)
├─ Advanced Blocking → Gruppe je Absenderadresse
└─ alles andere → Router → DoT
Symptom: ein Name, der nicht verschwindet
Der gesperrte Name war nrdp26.logs.netflix.com. Der Bestandteil logs deutet
auf einen Protokollierungsdienst hin, also darauf, dass ein Gerät hier eher
Daten abliefert als Inhalte abholt. Was genau übertragen wird, verrät der Name
nicht. Eine fast gleichlautende Anfrage (nrdp.logs.netflix.com) hatte ich
einige Tage zuvor vom Fernseher gesehen, als ich einem ganz anderen Fehler
nachging. Seitdem stand in meinem Kopf die Gleichung „Netflix-Telemetrie gleich
Fernseher”.
Die Zuordnung zum Fernseher allein war zu kurz gegriffen. Nur konnte das Log sie mir zunächst nicht widerlegen.
Erste Hürde: Das Log kennt keine Namen
Das Query Log von Technitium führt zu jeder Anfrage die Absenderadresse, aber keinen Gerätenamen. So sieht die Kopfzeile des CSV-Exports aus:
RowNumber,Timestamp,ClientIpAddress,Protocol,ResponseType,ResponseRtt,RCODE,Domain,Type,Class,Answer
Eine Spalte für den Gerätenamen gibt es nicht, weder im Export noch in der Tabelle der Oberfläche. Wer mehr als drei Geräte im Netz hat, übersetzt Adressen dann im Kopf oder in einer Nebentabelle, und beides geht bei der dritten Rückfrage schief.
Dazu kommt eine zweite, stillere Falle: Der Export schreibt Zeitstempel in UTC
(2026-09-17T08:30:23.636Z), die Oberfläche im Browser zeigt dieselbe Anfrage
in Ortszeit, also als 10:30 Uhr. Eine Einstellung für Ortszeit im Export gibt es
nicht. Wer beides nebeneinander liest, sucht zwei Stunden daneben und wundert
sich, warum die Ereignisse nicht zusammenpassen.
Die Rückwärtszone
DNS kann Adressen zu Namen auflösen, man muss es nur einrichten. Für ein
IPv4-Netz 192.168.1.0/24 heißt die zuständige Zone 1.168.192.in-addr.arpa:
die Netzadresse rückwärts gelesen, darunter je Gerät ein PTR-Eintrag.
25.1.168.192.in-addr.arpa. PTR streaming-a.home.arpa.
41.1.168.192.in-addr.arpa. PTR streaming-b.home.arpa.
26.1.168.192.in-addr.arpa. PTR sprachdisplay.home.arpa.
47.1.168.192.in-addr.arpa. PTR server.home.arpa.
Das Vorgehen je Gerät ist immer gleich. Zuerst im Router eine feste IPv4-Adresse
reservieren, sonst zeigt der Eintrag irgendwann auf ein anderes Gerät. Dann in
der Zone home.arpa den A-Record anlegen; Technitium bietet dabei an, den
passenden PTR gleich mitzuschreiben. Zwei Details waren dabei für meine Auswertung wichtig.
Erstens gilt eine Asymmetrie. Vorwärts dürfen viele Namen auf dieselbe Adresse zeigen, auf dem Server laufen mehrere Dienste hinter einem Reverse Proxy. Rückwärts soll für meine Auswertung pro Adresse genau ein Gerätename erscheinen. Mehrere PTR-Einträge auf einer Adresse sind zwar möglich, welchen davon ein Werkzeug anzeigt, ist dann aber nicht festgelegt. Dienstnamen lege ich deshalb als CNAME auf den Servernamen an und setze bei ihnen kein Häkchen für den Rückwärtseintrag.
Zweitens pflegen Router und DNS-Server ihre Namen getrennt. Benenne ich ein Gerät im Router um, erfährt Technitium davon nichts, und ein vorhandener PTR mit altem Namen wurde beim Anlegen des neuen A-Records auch nicht ersetzt. Das musste ich von Hand nachziehen.
Kontrolle beider Richtungen vom Laptop aus:
$ dig streaming-a.home.arpa +short
192.168.1.25
$ dig -x 192.168.1.25 +short
streaming-a.home.arpa.
Ein Nebeneffekt: Für Rückwärtsanfragen im eigenen Netz ist jetzt der eigene Resolver zuständig und reicht sie nicht mehr weiter. RFC 6303 [1] empfiehlt, Rückwärtszonen privater Adressbereiche lokal zu bedienen, damit solche Anfragen nicht im öffentlichen DNS landen. Die PTR-Einträge ergänzen diese lokale Zuständigkeit um lesbare Namen.
Vom PTR zurück ins Log
Die Namen aus der Rückwärtszone erscheinen in Technitium nur an einer Stelle, im
Dashboard unter Top Clients. Im Query Log selbst bleibt es bei Adressen.
Deshalb bereite ich Exporte mit einem kleinen Python-Skript nach: Es rechnet die
Zeitstempel über Europe/Berlin in Ortszeit um, Sommer- und Winterzeit
eingeschlossen, und ergänzt eine Spalte ClientName per PTR-Abfrage beim
eigenen Server.
Das hat zwei Grenzen, die man kennen sollte. Die Namen spiegeln den Stand zum Zeitpunkt der Umrechnung, nicht den zum Zeitpunkt der Anfrage. Und für IPv6 bleibt es weitgehend bei Adressen. Viele Geräte verwenden dort temporäre Adressen, andere stabile, die sich aber nicht aus der Hardware ablesen lassen. Solange ich nicht weiß, wie dauerhaft eine Adresse ist, bekommt sie keinen PTR.
Ein Satz ist mir dabei wichtig, weil er in vielen Homelab-Texten untergeht: Ein PTR-Eintrag findet nichts heraus. Er gibt nur den Namen zurück, den ich ihm vorher gegeben habe. Seine Leistung ist nicht die Diagnose, sondern dass ich das Log überhaupt lesen kann, ohne bei jeder Zeile nachzuschlagen.
Auflösung: die falsche Gleichung
Die Anfragen kamen von der Adresse .25, und die kannte ich: die kleine
Streaming-Box, im Artikel streaming-a. Im Router trug sie längst einen Namen,
den ich ihr irgendwann selbst gegeben hatte. Technitium wusste davon nichts,
weil beide Systeme ihre Namen getrennt führen. Den PTR habe ich im selben Zug
nachgetragen, damit mir die nächste Auswertung diese Übersetzung abnimmt. Die
Anfragen kommen auch, wenn die Box im Standby ist. Naheliegend ist, dass ihr
System die Netflix-Funktion im Hintergrund aktiv hält; belegen lässt sich das
mit einem DNS-Log allein nicht.
Beim Nachsehen in den älteren Exporten fand sich dann der eigentlich lehrreiche
Teil. Die Antwort stand schon am 12. September im Log, in genau dem Ausschnitt,
aus dem ich die Gleichung abgeleitet hatte. Zwischen 10:04 und 10:14 Uhr
Ortszeit stehen dort 22 gesperrte Anfragen vom Fernseher und zwei von .25
(Export in UTC, Spalte RowNumber weggelassen):
2026-09-12T08:04:24.6793072Z,192.168.1.25,Udp,Blocked,,NxDomain,nrdp26.logs.netflix.com,A,IN,
2026-09-12T08:08:47.3322722Z,192.168.1.22,Udp,Blocked,,NxDomain,nrdp.logs.netflix.com,A,IN,
2026-09-12T08:08:48.1957658Z,192.168.1.22,Udp,Blocked,,NxDomain,nrdp.logs.netflix.com,A,IN,
2026-09-12T08:08:49.5274184Z,192.168.1.22,Udp,Blocked,,NxDomain,nrdp.logs.netflix.com,A,IN,
2026-09-12T08:11:39.2009837Z,192.168.1.25,Udp,Blocked,,NxDomain,nrdp26.logs.netflix.com,A,IN,
2026-09-12T08:12:06.4187679Z,192.168.1.22,Udp,Blocked,,NxDomain,nrdp.logs.netflix.com,A,IN,
Im Log waren alle 24 Zeilen nackte Adressen. Die .22 hatte ich als Fernseher
im Kopf, auf die .25 habe ich nicht geachtet, und zwei Zeilen zwischen
zweiundzwanzig überliest man leicht. Die Telemetrie hing also nie allein am
Fernseher, sondern an der Netflix-Funktion, und die steckt in mehr als einem
Gerät. Der Fernseher war nur das erste, bei dem ich hingeschaut hatte.
Bestätigt hat sich das am Vormittag des 18. September. Da standen im Log 116
gesperrte Anfragen an nrdp26.logs.netflix.com, die meisten davon vom zweiten
Streaming-Gerät (.41), dazwischen einzelne von .25. Zwei Geräte, derselbe
Name.
Bei meiner Nutzung blieb die Wiedergabe trotz der Sperre möglich. Wohin der Name führt, wenn er aufgelöst wird, zeigt die CNAME-Kette dahinter. Sichtbar wurde sie während einer vorübergehenden Freigabe, um die es im nächsten Abschnitt geht:
nrdp26.logs.netflix.com
→ logs.dradis.netflix.com
→ logs.eu-west-1.internal.dradis.netflix.com
→ apiproxy-logging-….elb.eu-west-1.amazonaws.com
→ drei Adressen
Die ersten Glieder gehören dem Anbieter, die letzten verraten den Betreiber der Infrastruktur, hier ein Load Balancer von Amazon Web Services in Irland. Mehrere Adressen am Ende dienen üblicherweise Lastverteilung und Ausfallsicherheit, die genaue Verteilung zeigt das DNS-Log nicht. Für die Sperre genügt das erste Glied, der Rest der Kette wird dann gar nicht mehr aufgelöst.
Eine Falle am Rande: „Allow" im Dashboard
Beim Durchsehen der gesperrten Namen liegt ein Menüpunkt verführerisch nah: ⋮ › Allow. Er schreibt den Namen in die eingebaute Freigabeliste von Technitium, und die greift vor den Listen von Advanced Blocking. Intern legt Technitium dafür eine eigene Zone an, nur mit
NSundSOA, ohne Adressen; die Anfrage läuft danach normal rekursiv.Am selben Namen ließ sich das am 17. September nachvollziehen. Drei Zeilen aus dem Export, Zeitstempel in UTC, also 11:37, 11:45 und 11:48 Uhr Ortszeit:
2026-09-17T09:37:28.8679747Z,192.168.1.25,Udp,Blocked,,NoError,nrdp26.logs.netflix.com,A,IN,"A 0.0.0.0" 2026-09-17T09:45:20.4833608Z,192.168.1.25,Udp,Recursive,73.027,NoError,nrdp26.logs.netflix.com,A,IN,"CNAME logs.dradis.netflix.com., CNAME logs.eu-west-1.internal.dradis.netflix.com., CNAME apiproxy-logging-s4-….elb.eu-west-1.amazonaws.com., A 3.254.26.105, A 54.246.169.239, A 54.229.239.201" 2026-09-17T09:48:41.5691413Z,192.168.1.25,Udp,Blocked,,NoError,nrdp26.logs.netflix.com,A,IN,"A 0.0.0.0"Die mittlere Zeile entstand bei aktiver Freigabe:
Recursive, 73 Millisekunden Antwortzeit, vollständige CNAME-Kette bis zu den Adressen in Irland. Die letzte Zeile folgte nach dem Löschen unter Allowed. Eine versehentliche Freigabe fällt also nicht auf, sie funktioniert einfach. Wer gesperrte Namen durchklickt, sollte die Liste Allowed danach einmal ansehen.
Regel: eine eigene Gruppe für zwei Geräte
Jetzt, wo klar war, wer redet, ließ sich entscheiden, was davon erlaubt bleibt.
Im Haushalt gibt es zwei Streaming-Geräte desselben Herstellers, die kleine Box
und ein zweites Gerät am anderen Fernseher (streaming-b, .41). Beide haben
in Advanced Blocking eine eigene Gruppe bekommen:
"networkGroupMap": {
"0.0.0.0/0": "everyone else",
"[::]/0": "everyone else",
"192.168.1.25/32": "amazon",
"192.168.1.41/32": "amazon"
},
"groups": [
{
"name": "amazon",
"enableBlocking": true,
"allowTxtBlockingReport": true,
"blockAsNxDomain": false,
"blockingAddresses": [ "0.0.0.0", "::" ],
"blockListUrls": [
"https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts",
"https://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/wildcard/native.amazon-onlydomains.txt"
]
}
](Auszug aus der Konfiguration der App, leere Felder weggelassen. Die Listen werden alle 24 Stunden neu geladen.)
Die Gruppe führt zwei Listen: StevenBlack als breite Basis und von hagezi die
Liste native.amazon, die sich gezielt gegen die Telemetrie dieses Herstellers
richtet. Der Rest des Haushalts bleibt davon unberührt, weil die Herstellerliste
dort nichts zu suchen hat.
Beim Einrichten sind mir drei Punkte begegnet, die man nicht vergessen darf:
- Gruppen erben nichts. Die Liste der Standardgruppe muss in der neuen Gruppe wiederholt werden, sonst filtert sie schwächer als der Rest des Netzes.
- Die Sperrantwort am konkreten Client prüfen. In meinem Fall führte
NXDOMAIN am 12. September zu einer Schleife: Der Client hängte die Suchdomain
des Routers an, bekam wieder NXDOMAIN und fragte erneut, jeweils für A, AAAA
und HTTPS. In 15 Minuten kamen so 6.382 Anfragen zusammen, davon 5.140 für
einen einzigen gesperrten Namen. Mit
blockAsNxDomain: falseund der Antwort0.0.0.0bzw.::verschwand diese Schleife. Normale Wiederholungsversuche gibt es weiterhin, dazu gleich. Jede neue Gruppe braucht diese Einstellung ebenfalls. - Die Zuordnung greift nur, wenn das Gerät auch unter dieser Adresse fragt. In den ausgewerteten Logs fragten beide Geräte ausschließlich über IPv4, ihre Einträge decken also alles Beobachtete ab. Genau hier liegt die Ausnahme, dazu weiter unten.
Ob eine Regel greift, muss man nicht raten. Mit gesetztem
allowTxtBlockingReport liefert eine TXT-Abfrage die Gruppe und den Eintrag, der
gesperrt hat:
$ dig @192.168.1.47 trck.ahs.prod-zaz.turntable.sonic.advertising.amazon.dev +short
0.0.0.0
$ dig @192.168.1.47 TXT trck.ahs.prod-zaz.turntable.sonic.advertising.amazon.dev +short
"source=advanced-blocking-app; group=everyone else; domain=advertising.amazon.dev"
$ dig @192.168.1.47 unagi-eu.amazon.com +short
3.254.238.10
108.130.186.25
…
Gefragt hat hier mein Laptop, der in der Standardgruppe liegt. Die ersten beiden
Zeilen zeigen zweierlei: Die Sperre greift, und der Bericht nennt als
auslösenden Eintrag advertising.amazon.dev, obwohl nach einem viel längeren
Namen gefragt wurde. Ein eigener Eintrag trifft also auch alles darunter, dazu
unten mehr. Die dritte Abfrage liefert dagegen echte Adressen, denn
unagi-eu.amazon.com ist nur in der Gruppe amazon gesperrt. Derselbe Name,
eine andere Antwort, je nachdem, wer fragt. Genau das ist der
Zweck von Client-Gruppen.
Dass die Regel bei den Streaming-Geräten angewendet wird, zeigt ein gefilterter
Export vom Morgen des 18. September. Zwischen 4:57 und 11:12 Uhr sperrte die
Gruppe 1.602 Anfragen an unagi-eu.amazon.com, einen Namen, den die Liste als
Telemetrie des Herstellers führt: 820 vom einen, 782 vom anderen Gerät, jeweils
als Paar aus A und AAAA, beantwortet mit 0.0.0.0 und ::. Das sind 410
beziehungsweise 391 Paare in 375 Minuten, im Mittel also etwa eines pro Minute
und Gerät. Die vielen Treffer sind vor allem Wiederholungen. Wie viel
Datenverkehr dadurch tatsächlich unterbleibt, lässt sich aus DNS-Anfragen nicht
ablesen.
Genauso wichtig ist, was nicht gesperrt wird. Namen wie m.media-amazon.com
(Bilder und Cover) oder api.amazonalexa.com (Sprachsteuerung) liefern Inhalte
oder Funktionen, die man behalten will. Auf die Prüfliste nach jeder
Listenänderung gehören deshalb die Dinge, die an einer zu scharfen Liste als
Erstes scheitern: Sprachsteuerung, App-Store und Käufe. Ein erster Test nach der
Umstellung: Wiedergabe und Sprachsteuerung funktionierten, der App-Store war
erreichbar. Käufe habe ich noch nicht geprüft. Für das Streaming-Gerät des
anderen Herstellers am Fernseher gibt es bewusst keine Herstellerliste, dort
bleibt es bei der allgemeinen Basis.
Ausnahme: warum der Sprachassistent nicht in die Gruppe kommt
Im Netz hängt außerdem ein Sprachassistent mit Display (sprachdisplay, .26)
desselben Herstellers. Er wäre der naheliegende dritte Kandidat für die Gruppe.
Er bleibt trotzdem in der Standardgruppe, und das ist die Entscheidung, die ich
in diesem Projekt am sorgfältigsten begründet habe.
Die zeitliche Übereinstimmung der Anfragen spricht dafür, dass das Gerät DNS sowohl über IPv4 als auch über IPv6 nutzt. In den Exporten vom 12. bis 17. September fanden sich 263 IPv6-Anfragen, zu denen es in derselben Sekunde eine gleichlautende über IPv4 gab. Einen Werbe-Tracker des Herstellers fragte es 154-mal über IPv4 und 118-mal über IPv6 an. Advanced Blocking ordnet Gruppen aber nach Absenderadresse zu. Was das bedeutet, zeigt der Weg einer einzelnen Anfrage für den Fall, dass das Gerät der Gruppe zugeordnet wäre:
Annahme: X ist nur in der Gruppe "amazon" gesperrt
├─ Anfrage über IPv4 (192.168.1.26) → Gruppe "amazon" → 0.0.0.0
└─ Anfrage über IPv6 → Gruppe "everyone else" → reguläre Antwort
Gemeint ist hier der Weg, über den die DNS-Anfrage läuft, nicht der abgefragte Typ; A- und AAAA-Einträge lassen sich über beide Wege abfragen. Eine reine IPv4-Zuordnung würde also nur einen Teil der Anfragen erfassen, über den anderen Weg bekäme das Gerät eine reguläre Antwort. Welche Antwort es dann tatsächlich nutzt, zeigen die Logs nicht. Klar ist aber: Eine Regel für dieses Gerät würde nicht alle beobachteten Wege abdecken.
Bleibt ein /128-Eintrag für die IPv6-Adresse. Sie blieb in meinen Exporten
über fünf Tage gleich. Dass sie nicht aus der Hardware-Adresse abgeleitet ist,
sagt aber nichts darüber, ob sie temporär oder stabil ist (RFC 7217 [2]).
Solange das nicht geklärt ist, mache ich diese eine Adresse nicht zur Grundlage
einer Regel. Prüfen ließe sich die Regel heute durchaus. Ich müsste aber
dauerhaft überwachen, ob sie das Gerät morgen noch erfasst, und eine Regel, die
still ihre Wirkung verliert, ist genau das, was ich vermeiden will. Das ist eine
Entscheidung für meinen derzeitigen Aufbau, keine grundsätzliche Grenze von
IPv6.
Welche IPv6-Adresse zu einem IPv4-Gerät gehört, erschließe ich in den Exporten aus Anfragen nach demselben Namen in derselben Sekunde. Das ist ein Indiz, kein Beweis; belastbarer wird es mit einem Abgleich gegen die Nachbartabellen des Routers. Für die Suche nach solchen Paaren habe ich ein zweites Skript. Dasselbe Muster zeigt auch das Handy. Gefiltert auf seine IPv4-Adresse erschienen über einen ganzen Vormittag nur 17 Anfragen, ohne Filter lief der größere Teil über IPv6. Wer bei Android-Geräten nur nach IPv4 filtert, zieht falsche Schlüsse.
Was trotzdem geht
Ganz ohne Regel bleibt der Sprachassistent nicht. Die Standardgruppe gilt für
alle Adressen, IPv4 wie IPv6, und ist in meinem Aufbau deshalb die Stelle, die
bei diesem Gerät verlässlich wirkt. Dort steht seit dem 17. September ein
eigener Eintrag: advertising.amazon.dev. Angefragt hatte das Gerät einen
langen Namen darunter,
trck.ahs.prod-zaz.turntable.sonic.advertising.amazon.dev. Die hagezi-Liste
führte zum Zeitpunkt meiner Auswertung genau diesen langen Namen. Ein Eintrag
wirkt in Technitium auf den Namen und alles darunter, ein langer Listeneintrag
deckt also nur diesen einen Zweig ab. Ändert der Hersteller einen Bestandteil
innerhalb dieses langen Namens, verfehlt ihn der Listeneintrag. Der kurze eigene
Eintrag erfasst dagegen alles unter advertising.amazon.dev, wie der
TXT-Bericht weiter oben zeigt.
Daraus ist eine einfache Zuordnungsregel geworden: Namen, die nur die beiden
Streaming-Geräte anfragen, kommen in deren Gruppe. Namen vom Sprachassistenten
oder von mehreren Geräten kommen in die Standardgruppe. Kandidaten sammle ich
nicht einzeln, sondern lasse sie aus einem Export ziehen, alle nicht gesperrten
Namen mit Bestandteilen wie metric, telemetr, analytic oder beacon, samt
Anzahl der Anfragen und Geräte. Ein solcher Wortbestandteil ist ein Anlass zum
Hinsehen, kein Sperrgrund. Was danach übrig bleibt, trage ich gebündelt ein,
beobachte es einen Tag und streiche es im Zweifel wieder.
Was bleibt
Methodisch sind es drei Punkte, und keiner davon ist DNS-spezifisch.
Erst lesbar machen, dann regeln. Die Rückwärtszone hat an der Sicherheit nichts geändert, aber alles an der Frage, ob ich meinem eigenen Log glaube. Aufgefallen ist mir die falsche Gleichung, weil ich auf die Adresse geschaut habe statt auf meine Erinnerung. Die Rückwärtszone sorgt dafür, dass dieser Blick künftig nicht mehr vom Gedächtnis abhängt.
Belegen statt annehmen. Der TXT-Bericht zeigt, welche Regel für den anfragenden Client greift. Der Export zeigt, welche Anfragen danach tatsächlich gesperrt wurden. Ob die Geräte weiter funktionieren, zeigt nur ein Test am Gerät, und welche Daten am Ende nicht mehr fließen, zeigt ein DNS-Log überhaupt nicht. Jede dieser Quellen beantwortet eine andere Frage. Zusammen halten sie auseinander, was ich beobachtet und was ich nur angenommen habe.
Jede Regel mit Grund und Rückweg. Zu jeder Gruppe steht in meiner Dokumentation, warum sie existiert, woran man sieht, dass sie wirkt, und wie man sie zurücknimmt. Hier ist der Rückweg ein einziger Handgriff: den Map-Eintrag löschen, und das Gerät fällt in die Standardgruppe zurück. Genau das passiert allerdings auch unbemerkt, wenn ein Gerät unter einer nicht zugeordneten Adresse fragt. Die gerätespezifische Filterung entfällt dann, und es gelten wieder nur die Regeln der Standardgruppe. Deshalb gehört zur Regel auch der regelmäßige Blick, ob die Treffer noch von den erwarteten Adressen kommen.
Die Grenzen gehören dazu. DNS sieht Namen, keine URL-Pfade und keine Inhalte; Tracking und Nutzdaten auf demselben Host kann es nicht trennen. Die Regeln erfassen außerdem nur Anfragen, die meinen Resolver erreichen. Ein Gerät mit fest eingetragenem fremden DNS-Server oder mit direkten IP-Verbindungen umgeht sie. Mein Ziel ist hier Datensparsamkeit, keine Sicherheitsmaßnahme: Telemetriesperren ersetzen weder Updates noch Netztrennung. Der nächste Schritt wäre deshalb ein eigenes Netzsegment per VLAN mit passenden Firewall-Regeln. Dabei müssen die Absenderadressen bis zum Resolver erhalten bleiben. Setzt ein zweiter Router die Anfragen per NAT auf seine eigene Adresse um, sieht der DNS-Server nur noch diese eine Quelle, und die einzelnen Geräte ließen sich im Log nicht mehr unterscheiden.
Ein Heimnetz wird nicht dadurch nachvollziehbar, dass man viel sperrt, sondern dadurch, dass man zu jeder Sperre sagen kann, wen sie trifft und warum.
Die Reihe geht weiter mit dem dritten Teil: Dort geht es um ein Gerät, das gar nicht mehr reden soll, und warum eine Sperre in der Fritzbox dafür nicht reicht.
Zum Aufbau und zu den Beispielen
Adressbereich und Gerätenamen sind für diesen Text geändert, die letzten Stellen der Adressen und alle Befunde entsprechen dem realen Aufbau. Eigene öffentlich erreichbare Adressen, IPv6-Präfixe, Hardware-Adressen und Schlüssel sind nicht enthalten. Die genannten Domains und öffentlichen Adressen gehören zu Herstellern und Diensten, nicht zu besuchten Webseiten. Alle Beobachtungen stammen aus Technitium DNS Server 15.4 mit der App Advanced Blocking 11.1, Stand September 2026.
Von Ralf Seidenschwang.
Citations
[1] RFC 6303: Locally Served DNS Zones (öffnet in neuem Tab)
[2] RFC 7217: Semantically Opaque Interface Identifiers with IPv6 SLAAC (öffnet in neuem Tab)
[3] Technitium DNS Server, Quellcode und Apps (öffnet in neuem Tab)
[4] hagezi dns-blocklists, Native-Tracker-Listen (öffnet in neuem Tab)