Zusammenfassung

  • RFC 3123 definierte den APL RR als geordnete Liste von IPv4- und IPv6-Präfixen samt Negationsbit, verlangte aber von jeder Anwendung eigene Regeln für leere Listen, mehrere RRs, unbekannte Adressfamilien und !.
  • Ein gültiger oder authentisierter APL Record belegte eine veröffentlichte Darstellung. Er belegte weder Präfixkontrolle noch Policybefugnis, ACL-Installation, Packet-Match oder Serviceergebnis.

DNS bekam einen Datentyp, keine Weisungsbefugnis

2001 war DNS längst mehr als Namensauflösung. Das Resource-Record-Modell aus RFC 1034 und RFC 1035 trug Mailrouten, Nameserver und weitere Infrastrukturdaten. RFC 1101 hatte Organisationsnetze beschrieben. Ältere BIND-Versionen nutzten sogar Adressbereiche in TXT Records als schwache Zugriffsbeschränkung für Zonendaten.

Dabei konnten Darstellung und Handlung unbemerkt zusammenfallen. RFC 3123 trennte sie. Das im Juni 2001 als Experimental veröffentlichte Dokument wies APL den Typ 42 zu. Jedes Element enthielt Adressfamilie, Präfixlänge, N-Bit, Länge und relevante Adressbytes. Familie 1 stand für IPv4, Familie 2 für IPv6; beide konnten in einem Record vorkommen.

Der Text gab der Liste aber keine allgemeine Bedeutung. APL war ein Rahmen. Adressräume einer Organisation, classless Reverse-Zonen oder Material für Zugriffskontrolle waren mögliche Anwendungen, die separat spezifiziert werden mussten. Die Beispiele standardisierten nichts und belegten keine Implementierung.

Name, Typ und Payload konnten zeigen, welche Darstellung unter welchem DNS-Namen lag. Sie bestimmten nicht den Principal, der einen Betreiber binden durfte, die lokale Entscheidungsregel oder die tatsächlich ausgeführte Aktion.

Das Ausrufezeichen wartete auf seinen Vertrag

In der Zonendatei konnte ! einem Element vorausgehen; das N-Bit bewahrte diese Tatsache. Es sofort als Verbot, Ausnahme oder fehlende Berechtigung zu lesen, hätte Semantik erfunden. Die Anwendungsspezifikation musste die genaue Bedeutung negierter Elemente festlegen.

Leeres RDATA war gültig und stellte eine leere Liste dar. Ob das niemand, alle, keine Aussage oder Vererbung bedeutete, blieb offen. Mehrere APL RRs in einem RRset waren legal, doch ihre gemeinsame Auswertung gehörte ebenfalls zur Anwendung.

Auch erwartete Adressfamilien und der Umgang mit anderen oder unbekannten Familien mussten genannt werden. Element ignorieren, RRset ablehnen oder für zukünftige Leser bewahren sind verschiedene Entscheidungen. Ein Parser versteht Felder, erhält dadurch aber kein Mandat.

Die gemeinsame Schicht blieb auf lokal prüfbare Darstellung begrenzt. Künftige Policy blieb bei Anwendung und Betreiber, statt unbemerkt in ein Satzzeichen eingebaut zu werden.

Reihenfolge und Duplikate waren keine Unordnung

Server und Resolver durften APL nicht aufräumen. Duplikate waren erlaubt und durften nicht verschmolzen werden. Die Reihenfolge musste erhalten bleiben; Umordnen und Aggregieren waren verboten. Nur unter der Annahme einer mathematischen Menge wirkt das verschwenderisch. RFC 3123 vermied diese Annahme, weil spätere Anwendungen Position oder Wiederholung auswerten konnten.

Der Vermittler transportierte eine Erklärung, ohne ihr unbekanntes Regelwerk zu optimieren. Benachbarte Präfixe zusammenzufassen oder eine Wiederholung zu entfernen, konnte Priorität oder Ausnahme verändern.

Auf Byteebene gab es dagegen gezielte Canonicalization. Nachlaufende Nulloktette ohne Präfixinformation mussten aus AFDPART verschwinden. Semantisch gleiche IPv4- und IPv6-Präfixe erhielten so eine einzige Wireform, wichtig für das damals referenzierte DNSSEC-Modell.

Canonical Bytes beantworten, was verglichen oder signiert wird. Sie beantworten nicht, was der signierte Inhalt bewirkt. Deterministische Darstellung ist keine deterministische Autorität.

Authentizität vervollständigte die Policy nicht

RFC 3123 erklärte DNS-Daten ohne die genannten DNSSEC- oder TSIG-Techniken für unsicher. Zugleich warnte sie vor Topologieoffenlegung und davor, aus APL-Daten Access-Control-Listen zu bauen.

DNSSEC hilft Herkunft und Integrität signierter Daten zu prüfen. TSIG authentisiert Nachrichten oder Transaktionen zwischen konfigurierten Parteien. Beides schützt vor Veränderung, entscheidet aber nicht, ob der Zonebetreiber eine Firewall anweisen durfte, ob die Anwendung aktuelle Daten las, ob Compilation gelang, ob die Regel an der richtigen Schnittstelle hing oder ob ein Packet diesen Punkt passierte.

Die Betriebskette braucht getrennte Belege: Owner Name und Abfragezeit, exaktes RRset, Validation State, Anwendungsvertrag und Version, lokale Konfiguration, compilierte Policy, Enforcement-Acknowledgment und Trafficbeobachtung. Vom DNS-Record direkt zum Outcome zu springen, erfindet Kontrolle.

Delegation und Caching machten DNS zu einem attraktiven Verteilungskanal. Verteilte Aussage bedeutet jedoch nicht verteilte Entscheidungsbefugnis. Der Zonenverwalter publiziert; der empfangende Betreiber entscheidet über Adoption.

Typ 42 zählte keine Deployments

Die Beispiele nennen Organisationsbereiche, Reverse-Zonen, AXFR-Beschränkung und Multicast. Sie illustrieren Syntax unter Beispieldomains. Das Dokument sagt ausdrücklich, dass keine Anwendung spezifiziert und ihre Existenz weder gegenwärtig noch künftig behauptet wird.

Experimental ist ein Dokumentstatus, kein Feldversuchsbeleg. RFC 3597 behandelte später unbekannte RR-Typen, ohne APL-Nutzung zu messen. RFC 4034 präzisierte DNSSEC und canonical processing, ohne der signierten Liste universelle Semantik zu geben.

Belegt ist die Konstruktion: ein kompakter, erweiterbarer Container, der Familie, Länge, Negation, Reihenfolge und Wiederholung erhält. Für Deployment, Scheitern oder Erfolg wären Code, Zonendaten oder Messungen nötig.

Die erhaltene Grenze war der eigentliche Wert

Das gemeinsame Format löste nur unverfälschten Austausch. Anwendung definierte Namen, Leere, mehrere RRs, Familien und Negation. Betreiber entschieden Adoption. Policy Engine installierte. Packets trafen den Enforcement Point oder nahmen einen anderen Pfad.

Trennung garantierte keinen Erfolg, machte Fehler aber zurechenbar. Ein authentischer RR konnte stale sein, eine richtige Spezifikation falsch konfiguriert, eine ACL an die falsche Schnittstelle gebunden, ein positives Receipt durch einen anderen Trafficpfad bedeutungslos werden.

Dasselbe Präfix in DNS, Modell, ACL und Log war nicht dieselbe Tatsache. Zeitpunkt, Akteur und Autorität wechselten.

RFC 3123 machte DNS nicht zum Souverän des Netzes. Sie gab ihm eine präzise Sprache für Präfixmaterial und ließ die Entscheidung außerhalb des Records, wo sie belegt werden musste.

Quellen

  1. https://www.rfc-editor.org/rfc/rfc3123.txt
  2. https://www.rfc-editor.org/info/rfc3123
  3. https://datatracker.ietf.org/doc/rfc3123/
  4. https://www.rfc-editor.org/rfc/rfc1034.txt
  5. https://www.rfc-editor.org/rfc/rfc1035.txt
  6. https://www.rfc-editor.org/rfc/rfc1101.txt
  7. https://www.rfc-editor.org/rfc/rfc2317.txt
  8. https://www.rfc-editor.org/rfc/rfc2535.txt
  9. https://www.rfc-editor.org/rfc/rfc2845.txt
  10. https://www.rfc-editor.org/rfc/rfc2874.txt
  11. https://www.rfc-editor.org/rfc/rfc3597.txt
  12. https://www.rfc-editor.org/rfc/rfc4034.txt