DNS per Brieftaube: Das absurdeste Protokoll-Stack, das ihr je lieben werdet

Kurze Beichte vorweg: Ich habe viel zu viel Zeit damit verbracht, einen IETF-Entwurf namens „DNS over Avian Carriers (DoAC)" zu lesen. Und ich bereue nichts davon.

Falls ihr noch nicht das Vergnügen hattet: Die IETF ist die Organisation hinter den technischen Standards, die das moderne Internet antreiben. Ihre Dokumente sind normalerweise dicht, methodisch und todernst. Deshalb stehst du auf, wenn du auf einen Entwurf stößt, der es ernsthaft vorschlägt, Brieftauben zur Namensauflösung einzusetzen. Nicht weil es praktisch wäre, sondern weil es etwas Faszinierendes darüber verrät, wie wir über Netzwerkprotokolle nachdenken.

Das Protokoll-Stack der Vergangenheit

Die Geschichte beginnt 1990 mit RFC 1149 – IP over Avian Carriers (IPoAC). Ja, die IETF hat eine formale Spezifikation für die Übertragung von IP-Datagrammen per Brieftaube veröffentlicht. Das Dokument enthält Paketverlustschätzungen („ungefähr 55% ungewichtet"), Latenzberechnungen und Durchsatzvergleiche. 2001 kam RFC 2549 (Quality of Service für Vogellieferanten) und 2011 RFC 6214 (IPv6-Kompatibilität).

Das waren keine Aprilscherze – das waren legitime experimentelle Protokolle, komplett mit funktionierenden Implementierungen und Tests in der echten Welt. Universitäten und Hacker-Gruppen haben tatsächlich taubenbasierte Netzwerke zum Spaß und zum Lernen aufgebaut.

Das Problem

Aber da fehlte etwas – drei Jahrzehnte lang. Du konntest IP-Pakete per Taube verschicken, aber Domains auflösen? Fehlanzeige. Ohne DNS musste jede Zieladresse direkt als IP-Nummer auf den Vogel geschrieben werden. Stellt euch vor, ihr müsst euren Netzwerkadministratoren erklären, dass ein neuer Server bedeutet, eure Tauben umzutrainieren.

DoAC: DNS für die Vogelwelt

Der DoAC-Entwurf versucht genau das zu lösen – mit der typischen technischen Ernsthaftigkeit. Er definiert:

• Nachrichtenformate für DNS-Abfragen und -Antworten, die an Tauben befestigt werden können
• Den AA (Avian Authority) Resource Record zur Veröffentlichung von Schlagadressen
• Wiederholungsverhalten angesichts der unvorhersehbaren Natur des aviären Transports
• Bootstrapping-Verfahren einschließlich der „Taube letzter Instanz" für die erste Resolver-Erkennung

Der Detailgrad ist beeindruckend. Abschnitt 5.2 diskutiert „Resolver-Erkennung ohne vorherigen Zustand" – eure erste Taube kann nicht wissen, wo ein DNS-Server ist, weil sie ja gerade kein DNS hat, um danach zu suchen. Die Lösung? Eine vorkonfigurierte Notfall-Taube.

Sicherheitsbetrachtungen wie aus einem Naturfilm

Wo DoAC wirklich glänzt, ist die Sicherheitsanalyse. Der Entwurf identifiziert Bedrohungen wie:

• Hawk-in-the-Middle-Angriffe, bei denen ein Greifvogel eure Abfrage im Flug abfängt
• Tauben-Spoofing und die vorgeschlagene Lösung: „federbasierte Authentifizierung"
• Schlag-Übernahme, bei der ein Angreifer euer Ziel kontrolliert
• DoF-Angriffe (Denial of Flight) – im Grunde DDoS, aber für Vögel
• Die hungrige Katze als physische Bedrohung (selbsterklärend)
• Replay-Angriffe per präparierten Taxidermie-Vogel (jemand schickt eine alte Taube mit gecachten Antworten)

Ich würde tatsächlich Geld dafür zahlen, ein Red Team zu sehen, das einige dieser Angriffsvektoren ausprobiert.

Was uns das wirklich sagt

Das ist das Faszinierende an absurden technischen Dokumenten: Sie sind oft lehrreicher als vernünftige. DoAC zwingt dich, Annahmen zu hinterfragen, von denen du gar nicht wusstest, dass du sie machst.

Wenn du heute DNS nutzt, vertraust du stillschweigend darauf, dass:

• Die Resolver deines ISPs dich nicht belügen
• Die Pakete nicht abgefangen oder verändert werden
• Die Server verfügbar sind, wenn du sie brauchst
• Die physische Infrastruktur nicht komplett ausfällt

DoAC macht all diese impliziten Vertrauensstellungen explizit – und absurd. Ein Taubennetzwerk ergibt für Produktivsysteme keinen Sinn, aber die Übung, dafür zu entwerfen, zeigt genau, wie sehr wir von Infrastruktur abhängen, die wir für selbstverständlich halten.

Die eigentliche Erkenntnis

Für Entwickler, die moderne Systeme bauen – besonders im Edge Computing, Mesh-Netzwerken oder bei intermittierender Konnektivität – gibt es hier eine Lektion:

Jedes Protokoll setzt einen zugrunde liegenden Transport mit bestimmten Eigenschaften voraus. Wenn sich diese Eigenschaften ändern, brauchst du neue Protokolle.

DNS über TCP/IP setzt zuverlässige, schnelle Paketlieferung voraus. DNS über Brieftauben setzt voraus... naja, dass eure Pakete irgendwann ankommen, wahrscheinlich, vielleicht. Der DoAC-Entwurf ist nicht nur ein Witz – er erinnert uns daran, dass „permanent verfügbar, niedrige Latenz, hohe Zuverlässigkeit" ein Luxus ist, keine Konstante.

Für Startups, die Anwendungen für Schwellenländer, ländliche Gebiete oder Katastrophenszenarien entwickeln, sind diese Abwägungen relevant. Die IETF hat 30 Jahre lang darüber nachgedacht, was passiert, wenn euer Netzwerk aus einem Schwarm Tauben besteht. Diese Arbeit könnte relevanter sein, als ihr denkt.

Habt ihr schon mal ein Protokoll gesehen, das euch an euren Annahmen über Netzwerkarbeit zweifeln ließ? Teilt euren liebsten absurden RFC in den Kommentaren. Und falls ihr eine präparierte Taube mit DNS-Einträgen gefunden habt – lasst uns wissen, wie das gelaufen ist.