Zusammenfassung
- Ein geschützter DoC-Kontext belegt nur den Austausch seiner Endpunkte, nicht den späteren DNS-Weg des Servers.
- Discovery, Kontext, Antwort, Upstream, DNSSEC und Anwendungsannahme sind getrennte Belege.
RFC 9953 ordnet DNS-Anfrage und -Antwort einem CoAP-Austausch zu. DTLS, TLS oder OSCORE kann diesen Abschnitt schützen. Der Standard sagt aber ausdrücklich, dass der DoC-Server upstream ungeschützt, etwa über DNS/UDP, kommunizieren kann. Ein anderer geschützter Kontext ist möglich, bleibt dem Client jedoch auf Protokollebene verborgen.
Auch die Serverentdeckung ersetzt keinen Laufzeitbeleg. Automatische Konfiguration muss aus einer vertrauenswürdigen Quelle stammen; das belegt ihre Herkunft, nicht die DNSSEC-Prüfung dieser Antwort oder ihre Annahme durch eine Anwendung. Ein belastbarer Datensatz verbindet Quelle, URI, Kontextzeit, Frage, Antwort, behauptete Upstream-Belege, Validierung und lokale Entscheidung. Amsüss ist Mitautor des Standards, nicht Betreiber eines bestimmten Resolvers.
Quellen
- https://www.rfc-editor.org/rfc/rfc9953.html
- https://www.rfc-editor.org/rfc/rfc8613.html
- https://christian.amsuess.com/
- https://github.com/chrysn
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
