DNS par pigeons voyageurs : le stack protocolaire le plus absurde que vous adorerez

Soyons honnêtes : j'ai passé un temps considérable à éplucher un draft IETF intitulé « DNS over Avian Carriers (DoAC) ». Et je n'ai aucun remords.

Pour ceux qui découvrent le concept, l'IETF, c'est cette organisation qui définit les standards techniques au cœur d'Internet. Leurs documents sont généralement austères, méthodiques, d'un sérieux imperturbable. Alors quand on tombe sur un draft qui propose officiellement d'utiliser des pigeons voyageurs pour résoudre des noms de domaine, on s'arrête. Non pas parce que c'est实用性 (spoiler : ça ne l'est pas), mais parce que ça révèle des trucs fascinants sur notre façon d'envisager les protocoles réseau.

Le stack protocolaire bloqué en 1990

L'histoire commence en 1990 avec le RFC 1149. Son titre ? « IP over Avian Carriers ». L'IETF a publié une spécification formelle pour transmettre des datagrammes IP via des pigeons. Le document contient des estimations de perte de paquets (« environ 55% en moyenne »), des calculs de latence, des comparaisons de débit. Le tout avec le plus grand sérieux.

En 2001, rebelote avec le RFC 2549 (« Quality of Service support for avian carriers »). Puis en 2011, le RFC 6214 qui garantit la compatibilité IPv6 pour les volatiles.

Ce n'étaient pas des blagues. Des chercheurs et des groupes de hackers ont réellement testé ces protocoles. Des universités ont déployé des réseaux pigeons pour l'éducation et le fun.

Sauf qu'il y avait un problème de taille. Pendant trente ans, une faille énorme existait dans ce stack protocolaire : impossible de résoudre les noms de domaine. Chaque destination devait être codée en dur, directement sur l'oiseau, sous forme d'adresse IP. Essayez d'expliquer à vos administrateurs réseau que l'ajout d'un nouveau serveur nécessitait de réentraîner vos pigeons.

DoAC : le DNS pour les oiseaux

Le draft DoAC vient combler ce vide avec un sérieux technique admirable. Il définit :

• Les formats de messages pour les requêtes et réponses DNS accrochables aux pigeons
• L'AA (Avian Authority) Resource Record pour publier les adresses de pigeonnier
• Le comportement de retransmission pour gérer la nature imprévisible du transport aviaire
• Les procédures de bootstrap, incluant le « Pigeon of Last Resort » pour découvrir le résolveur initial

Le niveau de détail impressionne vraiment. La section 5.2 aborde la « Découverte de résolveur sans état préalable ». Le problème ? Votre premier pigeon ne sait pas où trouver un serveur DNS, justement parce qu'il n'a pas DNS pour le chercher. La solution ? Un pigeon d'urgence préconfiguré.elogicz

Considérations de sécurité dignes d'un documentaire animalier

C'est dans l'analyse de sécurité que DoAC atteint des sommets. Le draft identifie des menaces comme :

• Les attaques Hawk-in-the-Middle où un rapace intercepte votre requête en vol
• Le spoofing de pigeon et sa solution proposée : « Plumage-Based Authentication »
• Le détournement de pigeonnier où un attaquant prend le contrôle de votre destination
• Les attaques Denial of Flight (DoF) — l'équivalent DDoS mais pour les volatiles
• Le chat affamé comme menace de couche physique (le nom est explicite)
• Les attaques par rejeu via pigeon naturalisé — quelqu'un envoie un pigeon mort avec d'anciennes réponses en cache

Je paierais réellement pour voir une équipe red team tenter certains de ces vecteurs d'attaque.

Ce que ça nous enseigne vraiment

Voici le secret des documents techniques absurdes : ils sont souvent plus instructifs que les autres.

DoAC vous force à confronter des suppositions implicites que vous ne soupçonniez même pas. Quand vous utilisez DNS aujourd'hui, vous faites confiance, sans y penser :

• À vos résolveurs ISP qui ne vous mentiront pas
• Au fait que vos paquets ne seront ni interceptés ni modifiés
• À la disponibilité des serveurs quand vous en avez besoin
• À ce que l'infrastructure physique ne lâchera pas

DoAC rend toutes ces rumeurs confiance explicites — et ridicules. Un réseau pigeon n'a aucun sens pour de la production, mais l'exercice de conception révèle exactement à quel point nous dépendons d'une infrastructure que nous considérons comme acquise.

La vraie leçon

Pour les développeurs qui construisent des systèmes modernes, surtout ceux qui bossent sur l'edge computing, les réseaux maillés ou la connectivité intermittente, il y a une leçon importante :

Chaque protocole suppose un transport sous-jacent avec des propriétés spécifiques. Quand ces propriétés changent, vous avez besoin de nouveaux protocoles.

DNS sur TCP/IP suppose une livraison de paquets fiable et rapide. DNS sur transport aviaire suppose... que vos paquets arriveront peut-être, un jour, probablement. Le draft DoAC n'est pas qu'une blague — c'est un rappel que « toujours allumé, faible latence, haute fiabilité » est un luxe, pas une constante.

Pour les startups qui développent des apps pour les marchés émergents, les zones rurales ou les scénarios de catastrophe, comprendre ces compromis compte. L'IETF a passé 30 ans à réfléchir à ce qui se passe quand votre réseau est une volée de pigeons. Ce travail pourrait être plus pertinent que vous ne le pensez.

Vous avez déjà rencontré un protocole qui vous a fait douter de vos certitudes sur le fonctionnement des réseaux ? Partagez votre RFC absurde préférée dans les commentaires. Et si vous trouvez un pigeon naturalisé avec des enregistrements DNS attachés, svp, racontez-nous comment ça s'est passé.