Résumé
- À la séance de clôture de RIPE 92, Warren Kumari a raconté avoir enregistré des domaines valides obtenus en changeant un bit d’autres noms. Son serveur a reçu des noms d’hôte, des indications SNI, des URL et des cookies ; il a tenté d’écarter les fautes de frappe et le bruit des robots.
- Avant de suggérer une règle pour les futurs domaines de premier niveau, il a compté environ 60 paires déjà séparées d’un seul bit. La fiche officielle du talk présente dix minutes de résultats expérimentaux. Kumari en était encore à examiner une éventuelle proposition.
La règle avait l’élégance d’une porte fermée à temps : refuser tout nouveau TLD qui ne se distinguerait d’un TLD existant que par un bit. Kumari s’apprêtait à la formuler lorsqu’il a regardé la liste déjà publiée. Environ 60 paires s’y trouvaient, selon son compte rendu du 22 mai 2026. La porte pouvait ralentir les nouveaux entrants ; elle ne déplacerait aucun des voisins installés.
L’idée venait d’une expérience moins abstraite que la liste de la racine. Kumari avait produit des variantes de domaines qui restent syntaxiquement valides après une erreur binaire, enregistré quelques variantes et placé un serveur derrière elles. Les requêtes sont arrivées. Dans la transcription de RIPE 92, il décrit des noms composés par des systèmes, des chemins d’API, des URL complètes, des indications SNI et des cookies. Un utilisateur n’a pas besoin de taper le mauvais nom pour qu’un programme l’expédie.
Un compteur brut lui aurait donné une victoire trop facile. Des robots frappent à toutes les portes et des doigts se trompent de touche. Kumari a donc choisi certaines variantes éloignées sur le clavier et filtré les visites automatisées. Les longs noms techniques et les chemins fournis par un logiciel rendaient la simple faute de frappe moins convaincante. La transcription ne fournit pas le journal complet des requêtes : chaque visite ne peut pas recevoir un diagnostic individuel. L’expérience montre tout de même le pouvoir d’accueil d’un domaine voisin enregistré.
Ce pouvoir devient sérieux quand la requête transporte des données. Kumari a parlé de milliers d’accès à des fichiers JavaScript et de nombreux cookies, dont certains ressemblaient à des jetons de connexion. Il a également montré des connexions TLS qui ont poursuivi l’échange vers son domaine et lui ont transmis un cookie. L’endroit exact de l’erreur dans la pile change le résultat. Les propriétaires de ces données n’avaient rien demandé à son serveur.
Le chercheur avait commencé ce travail avant la nouvelle vague envisagée de gTLD. Il aurait été tentant de transformer l’observation en interdit de registre. Son propre décompte a forcé une question plus difficile : comment protéger les requêtes destinées aux noms déjà voisins ? La mémoire à correction d’erreurs peut aider du côté des machines ; l’attribution des TLD agit du côté de la racine ; le contrôle du destinataire appartient aussi aux logiciels. Aucun de ces acteurs ne possède à lui seul tout le trajet.
Kumari a quitté la scène sans annoncer de règle ICANN. Il avait déjà fait quelque chose de plus utile qu’un slogan : tester une solution simple contre l’état réel du système. Quand une interdiction arrive après les délégations, le travail commence par l’inventaire des voisins existants et des données qui franchissent la mauvaise porte.
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance





