Zusammenfassung

  • RFC 5158 ist ein Informational RFC vom März 2008 für die selbstbediente Reverse-DNS-Delegation von 6to4-Sites.
  • 6to4 bettete eine externe IPv4-Adresse nach 2002::/16 ein und leitete daraus ein Site-/48 ab.
  • Der Dienst setzte eine einstufige gewöhnliche DNS-Delegation unter 2.0.0.2.ip6.arpa ein.
  • Ein Client durfte nur die /48-Zone beantragen, die zu seiner beobachteten 6to4-Quelladresse gehörte.
  • Primär- und Sekundärserver mussten erreichbar, autoritativ sowie bei SOA und NS-Bestand übereinstimmend sein.
  • HTTPS schützte die Transaktion, belegte aber keinen organisatorischen Auftrag des Antragstellers.
  • Das Dokument bezeichnete die Adressauthentisierung als rudimentär und potenziell fälschbar.
  • Ein interner Client konnte ohne lokale Zugriffskontrolle die Delegation am Administrator vorbei ändern.
  • Bei dynamischer IPv4-Neuvergabe konnte ein neuer Anschluss alten Reverse-Zustand übernehmen.
  • Kurze TTLs und Prüfintervalle begrenzten Altlasten, bewiesen aber keine fortdauernde Ressourcenkontrolle.
  • Laut RFC validierte weder das Vorhandensein noch das Fehlen eines PTR zuverlässig die Beziehung zwischen Name und Adresse.
  • Prüfpfade müssen Quellbesitz, Sperrbefugnis, Administratorauftrag, DNS-Bereitschaft und PTR-Aussage getrennt halten.

Selbstbedienung entstand aus einer Lücke der Hierarchie

Ein 6to4-Router nahm die externe IPv4-Adresse und setzte deren 32 Bits hinter 2002::/16. So entstand deterministisch ein /48. Für dieses Präfix ließ sich auch die Reverse-Zone berechnen. Der technische Zusammenhang war enger als ein frei gewählter Kontoname: Die beobachtete Quelle begrenzte, welche Zone der Client anfordern konnte.

Trotzdem fehlte ein natürlicher Delegationsgeber. Wer nur eine einzelne IPv4-Adresse nutzte, besaß in der IPv4-Reverse-Hierarchie meist keine eigene Zonengrenze. Der 6to4-Zugang wiederum setzte keine normale IPv6-Providerbeziehung voraus, über die ein ip6.arpa-Zweig hätte delegiert werden können.

Der vorgeschlagene Registrierungsdienst schloss diese Lücke und veröffentlichte eine reguläre DNS-Delegation. Er machte aus dem Anschluss eine begrenzte Handlungsfähigkeit. Er machte den Anschluss nicht zum obersten Verwalter der IPv4-Ressource.

Das Sperrrecht verriet die tatsächliche Rangordnung

RFC 5158 sah vor, dass der für die IPv4-Adresse zuständige Akteur separat verlangen konnte, Registrierungen zu blockieren. Diese Möglichkeit war kein nebensächlicher Missbrauchsschalter. Sie erkannte an, dass derjenige, der gerade Pakete von einer Adresse sendet, und derjenige, der über die Vergabe dieser Adresse entscheidet, nicht dieselbe Instanz sein müssen.

Die Befugnisse waren daher gerichtet. Der Client erhielt eine positive Fähigkeit: für die eigene abgeleitete Zone einen Nameserver-Satz vorschlagen. Der Adressverwalter erhielt eine negative Fähigkeit: dieses Verfahren für die Ressource unterbinden. Ein Site-Administrator brauchte wiederum lokale Regeln, um festzulegen, welcher interne Client den Antrag überhaupt stellen durfte.

Eine Plattform, die diese drei Rollen zu „Eigentümer“ zusammenzieht, verliert den Konfliktfall. Sie kann dann nicht erklären, warum eine technisch passende Quelle berechtigt erschien, ein Ressourcenverwalter aber widersprach oder der lokale Administrator nichts von dem Antrag wusste.

HTTPS authentisierte nicht die Zuständigkeitskette

Die Schnittstelle sollte HTTPS verwenden. Das schützte den Antrag vor einfacher Beobachtung und Veränderung, authentisierte den Webdienst und vermied problematische Proxy-Zwischenspeicherung. Zusammen mit der Quellprüfung war dies ein brauchbarer Schutz für einen automatisierten Vorgang.

Der RFC war dennoch deutlich: Authentisierung allein über die Adresse ist rudimentär und kann unter bestimmten Bedingungen getäuscht werden. Noch ohne Fälschung kann ein Rechner innerhalb der Site eine gültige 6to4-Quelle besitzen. Ohne Firewall oder ACL könnte er die Delegation ändern, obwohl er keinen Auftrag der Netzwerkleitung hat.

Der HTTPS-Beleg gehört deshalb in die Transportspalte. Der Beleg für organisatorische Zuständigkeit braucht Principal, Rolle, Umfang, Zustimmung und Widerruf. Der Beleg für IPv4-Kontrolle braucht Vergabezeitraum und zuständige Ressourceninstanz. Ein grüner Webvorgang ersetzt keine dieser Ketten.

Bereitschaft der Nameserver war eine vierte Ebene

Vor Aktivierung musste der Dienst die vorgeschlagenen Server abfragen. Primärserver und mindestens ein Sekundärserver sollten online, erreichbar und für die Zone autoritativ sein. SOA-Daten und NS-RRsets mussten übereinstimmen. Damit blieb eine unfertige Kindzone aus der öffentlichen Delegation heraus.

Diese Kontrolle war wichtig, verlieh den Servern aber keine weitergehende Legitimität. Zwei Server können konsistent eine falsche PTR-Aussage verteilen. Sie können nach dem Ende einer IPv4-Zuweisung weiterlaufen. Und sie können von einem internen Akteur eingerichtet worden sein, den der Administrator nie beauftragt hat.

Bereitschaft ist damit weder Ressourcenkontrolle noch Auftrag. Sie ist die Aussage, dass die vorgeschlagene technische Projektion zum Prüfzeitpunkt funktionierte.

Dynamische Vergabe verschob die Akteure

Wurde eine dynamische IPv4-Adresse neu zugeteilt, erzeugte der nächste Anschluss dasselbe 6to4-/48. Die Form der Reverse-Zone änderte sich nicht, obwohl der Nutzer wechselte. Delegation, autoritative Antworten oder Caches konnten noch den vorherigen Akteur abbilden.

Kurze TTLs reduzierten die Cache-Dauer. Prüfungen im Abstand von dreißig Tagen, Warnung, erneute Prüfung nach vierzehn Tagen und anschließende Entfernung räumten ausgefallene Delegationen auf. Ein weiterlaufender alter Server konnte diese Prüfungen jedoch bestehen.

Die negative Sperrbefugnis des IPv4-Verwalters war deshalb besonders wertvoll, erforderte aber einen eigenen, rechtzeitigen Vorgang. Sie war kein automatisch aus der Neuvergabe abgeleitetes Ereignis. Ohne Verbindung zwischen Vergabesystem und Register blieb ein Zeitfenster mit alter Autorität offen.

PTR war keine von allen Rollen gemeinsam signierte Aussage

Das Dokument warnte davor, Reverse DNS als zuverlässige Validierung einer Domain-Adress-Beziehung zu verwenden. Ein vorhandener PTR beweist die Beziehung nicht; ein fehlender widerlegt sie nicht. Auch eine passende Vorwärtsauflösung zeigt Konfigurationskohärenz und nicht notwendig Identität oder Verantwortung.

Das passt zur verteilten Autorität des Verfahrens. Der Client beantragte, der Registerdienst delegierte, Nameserver veröffentlichten, der IPv4-Verwalter konnte sperren, und lokale Administratoren kontrollierten idealerweise den Zugang. Ein PTR trug keine gemeinsame Unterschrift all dieser Rollen.

Spätere Dokumente beschrieben die Betriebsprobleme von 6to4 und stuften den Anycast-Relay-Mechanismus herab; moderne TLS-Vorgaben aktualisierten zudem alte Abhängigkeiten. Das historische Dienstmodell sollte nicht als heutige Verfügbarkeit gelesen werden. Seine Autoritätslandkarte bleibt aber hochaktuell.

Quellen

  1. RFC 5158, HTML
  2. RFC 5158, Text
  3. RFC-Editor-Eintrag
  4. IETF-Datatracker-Eintrag
  5. Geschichte von RFC 5158
  6. Referenzen von RFC 5158
  7. Errata zu RFC 5158
  8. RFC 3056
  9. RFC 3068
  10. RFC 3964
  11. RFC 6343
  12. RFC 7526
  13. RFC 2136
  14. RFC 3596
  15. RFC 2317
  16. RFC 1034
  17. RFC 1035
  18. RFC 4033
  19. RFC 8996
  20. RFC 8446
  21. IANA-Register besonderer IPv6-Adressen
  22. RFC 3172
  23. RFC 8020
  24. RFC 2308
  25. Minimum Initial Specification
  26. On Reality Layers
  27. Running-Code Primacy