Summary

  • Der IOTOPS-Entwurf zu DNS-Sicherheit und Datenschutz bei IoT-Geräten, Revision 06 wurde am 2. November 2026 aktualisiert und befindet sich weiter in der Arbeitsgruppe. Abschnitt 4.3 unterscheidet übermäßige Abfragen trotz TTL von vorhersagbaren Abfragen derselben Namen in festen Abständen.
  • Hersteller müssen für ihre Verwaltungszone passende TTLs setzen. Geräte, die Antworten zwischenspeichern, müssen deren Lebensdauer beachten, sofern keine ausdrücklich konfigurierten Mindest- oder Höchstwerte gelten.
  • Notwendige regelmäßige Prüfungen kritischer Domains sollen unregelmäßig stattfinden. Nach Auflösungsfehlern sollen Geräte den Abstand vergrößern; RFC 9520 begrenzt Wiederholungen und schreibt eine Mindestdauer für das Zwischenspeichern von Fehlern vor.

Man stelle sich Kameras vor, die eine Verwaltungsdomain alle sechzig Sekunden abfragen. Nach einem Firmwarewechsel sind es neunzig Sekunden. Wer den DNS-Verkehr beobachtet, kann die beiden Gruppen am Rhythmus unterscheiden, ohne ein Gehäuse zu sehen. Diese Intervalle sind ein Gedankenversuch zum Mechanismus im Entwurf, keine Messwerte einer realen Geräteflotte.

Der DNS-Datensatz bringt bereits eine Uhr mit: Seine TTL gibt gemäß RFC 1035 die zulässige Cache-Dauer vor. Die regelmäßige Kontrolle einer wichtigen Verwaltungsadresse hat eine zweite Uhr. Die Pause nach einer fehlgeschlagenen Auflösung hat eine dritte. Ein einziger starrer Zeitgeber kann alle drei Regeln verletzen und zugleich ein gut lesbares Verhaltensmuster erzeugen.

Wenn Routine zum Typenschild wird

Abschnitt 4.3 beschreibt Geräte, die denselben Namen unabhängig von TTL und Betriebsänderungen in gleichbleibendem Takt abfragen. Der Entwurf verbindet dieses Verhalten mit dem Risiko, Modell oder Firmwarestand aus den Abfragezeiten abzuleiten. Unnötige Abfragen kosten außerdem Energie am Gerät und Kapazität am Resolver. Was im Entwicklungsbüro nach einem sauberen Zeitplan aussieht, verrät im Netz etwas über den installierten Bestand.

Die autoritative Zone liegt ebenfalls in der Verantwortung des Herstellers. Eine zu kurze TTL erhöht die Zahl der Abfragen. Eine zu lange TTL verzögert den Wechsel einer Verwaltungsadresse oder eines Update-Ziels. Der Entwurf verlangt eine TTL, die zum Zweck des jeweiligen Eintrags passt. Geräte sollen Antworten zwischenspeichern, soweit ihre Ressourcen es erlauben. Wo sie das tun, müssen sie die TTL beachten, sofern ausdrücklich gesetzte Grenzen nichts anderes vorgeben. Mindest- und Höchstwerte sollen verwaltbar sein. Ein fest eingebrannter Wert kann eine spätere Netzumstellung blockieren.

Manche kritische Domain muss tatsächlich regelmäßig neu geprüft werden. Dafür fordert der Entwurf keinen Verzicht, sondern nicht deterministische Abstände. Gleichzeitig braucht der Betreiber eine begrenzte Umschaltzeit. Ein Test kann die Adresse planmäßig wechseln und die alte TTL, das Ende des Geräte-Caches, die nächste DNS-Abfrage und die erste Verbindung zum neuen Ziel protokollieren. Eine Einstellungsseite mit dem Wort „Jitter“ beweist noch kein entsprechendes Verhalten auf der Leitung.

Ein Resolverausfall liefert den zweiten Belastungstest. Geräte mit identischem Timer können gleichzeitig wieder und wieder fragen. Der Entwurf fordert ein Zurücknehmen der Abfragefrequenz und verweist auf RFC 9520. Dieselbe Frage an dieselbe Server-IP über denselben Transport darf vor der Einstufung als nicht antwortend höchstens zweimal erneut gestellt werden; ein Auflösungsfehler muss mindestens eine Sekunde im Cache bleiben. RFC 8767 erlaubt unter bestimmten Bedingungen alte DNS-Antworten weiterzugeben. Für die Diagnose müssen lokaler Geräte-Cache, erneute Fehlversuche und vom Resolver gelieferte alte Antworten auseinandergehalten werden.

Die Firmware bestimmt mit über das Netz des Kunden

Abschnitt 4.1 verlangt außerdem, dass die Resolver-Konfiguration durch das Netz oder eine autorisierte Verwaltung gesetzt werden kann. Ein Gerät darf nicht auf einen fest eingebauten öffentlichen Resolver ausweichen. Die empfohlene Reihenfolge lautet manuelle Einstellung, autorisierte Verwaltungssoftware und schließlich Netzkonfiguration per RA oder DHCP. Ein heimlicher öffentlicher Ausweg umgeht die DNS-Regeln des Betreibers gerade dann, wenn ein Ausfall sorgfältige Fehlersuche erfordert.

Die offiziellen Texte liefern keine gemessene Trefferquote für Geräteerkennung und keine Zahl für zusätzlichen Stromverbrauch. Paketmitschnitte über Firmwareversionen, TTL-Änderungen, Adresswechsel und Resolverausfälle könnten beides prüfen. Die unmittelbare technische Entscheidung liegt dennoch klar auf dem Tisch: passende TTL veröffentlichen, sie im Gerät einhalten, nötige Nachfragen zeitlich streuen und nach Fehlern warten. Die Uhr der Firmware darf nicht allein über das Kundennetz herrschen.

IOTOPS-Entwurf · RFC 1035 · RFC 9520 · RFC 8767