Zusammenfassung

  • RFC 9953 empfiehlt die DNS-Header-ID 0, damit gleichartige DoC-Anfragen dieselbe CoAP Cache-Key-Grundlage verwenden können.
  • Ein wiederverwendbares Cache-Objekt bleibt an die gemeinsame Zeitrechnung aus Max-Age und DNS-TTL gebunden und ersetzt keine Evidenz für DNS-Ergebnis, Herkunft, Validierung oder Wirkung.

Ein Cache ist keine kleine autoritative Zone. Er kann eine gespeicherte Darstellung liefern, weil eine Anfrage zu ihr passt. Für ein begrenztes IoT-Gerät ist das wertvoll: weniger Übertragungen, weniger Energie, weniger Wartezeit. Der Treffer sagt aber zunächst nur etwas über die Wiederverwendbarkeit dieser Darstellung. Er sagt nicht, ob ein bestimmter Upstream zuständig war, ob die Antwort validiert wurde, ob sie unter der lokalen Regel noch zulässig ist oder ob eine Anwendung daraus einen Erfolg erzeugte.

RFC 9953 beschreibt DNS over CoAP (DoC) seit März 2026 als Standards-Track-Protokoll für DNS-Abfragen mit OPCODE 0. Ein DNS-Anfrage-Antwort-Paar wird zu einer CoAP Request-Response-Operation. Die DNS-Anfrage steht im Body eines CoAP FETCH; application/dns-message hat dabei Content-Format 553. Das nutzt für eingeschränkte Umgebungen CoAP-Eigenschaften wie Body-Übertragung und Caching. Es erhebt die CoAP-Hülle nicht zur Aussage über die gesamte DNS-Realität.

Die Null in der ID hat einen klaren technischen Zweck. Ein DoC-Client SHOULD die DNS-Header-ID auf 0 setzen, damit mehrere Anfragen nach denselben DNS-Daten nicht allein wegen wechselnder herkömmlicher Transaktions-IDs unterschiedliche CoAP Cache-Keys erhalten. Ein Cache oder Proxy auf dem Weg kann so dieselbe Repräsentation verwenden. Der DoC-Server MUST die ID aus der Anfrage in die zugehörige Antwort kopieren. Null ist kein Vertrauenslabel, kein Nachweis der Serverrolle und keine Befugnis für die folgende Automatisierung; sie normalisiert nur einen Cache-Key-Eingang.

Entscheidend ist, dass RFC 9953 diese Normalisierung nicht von der Lebensdauer trennt. Der DoC-Server MUST sicherstellen, dass Max-Age der CoAP-Antwort plus jeder enthaltene DNS-TTL nicht größer ist als der entsprechende vom Upstream empfangene TTL. Auch ohne Option zählt der CoAP-Standardwert von 60 Sekunden. Beim Empfang MUST der Client den Max-Age zu allen DNS-TTL addieren und die berechneten TTL verwenden. Transportalter und DNS-Alter beschreiben dieselbe verbleibende Berechtigung zur Wiederverwendung aus zwei Blickwinkeln.

Der empfohlene Algorithmus setzt Max-Age auf den kleinsten DNS-TTL und zieht diesen Wert von allen TTL im DNS-Body ab. Damit soll ein Zwischen-Cache keinen abgelaufenen Eintrag unbeabsichtigt ausliefern; gleichzeitig kann ein inhaltsbasierter ETag trotz einer Upstream-TTL-Aktualisierung unverändert bleiben. Für Fehler, die nur kurz cachebar sein sollen, darf Max-Age kleiner oder null sein. Die Vorschrift verhindert eine unbegründete Zeitverlängerung, nicht jede denkbare Fehlentscheidung.

Zwei Ergebnisfelder müssen nebeneinander stehen. Eine parsebare DNS-Antwort soll auch dann als CoAP 2.05 Content kommen, wenn ihr DNS-Header NXDOMAIN oder einen anderen RCODE-Fehler enthält. Nicht erfolgreiche CoAP-Codes sind für Fehler der CoAP-Schicht oder nicht regelkonforme DoC-Anfragen bestimmt. Wer nur das äußere 2.05 misst, schreibt DNS-Fehler um. Wer nur den RCODE sieht, verwischt den Unterschied zwischen einer DNS- und einer Transportstörung.

Auch die Rolle des DoC-Servers bleibt eine separate Tatsache: Er kann autoritativ, Stub oder rekursiv sein und MAY für eingeschränkte Clients DNSSEC validieren. (D)TLS und OSCORE können Nachrichten schützen. Daraus folgt nicht, dass jede Antwort DNSSEC-validiert ist, eine lokale Richtlinie erfüllt oder eine Anwendung korrekt gehandelt hat. Daniel Kade verwendet Heng Lus Running-Code-Perspektive hier bewusst nur editorial: Ein optimierter Übertragungsweg darf nicht die Evidenz anderer Verantwortungsebenen vereinnahmen.

Quellen