Sujet
Pouvoir de délégation DNS
Au sein de la facette Sujet, la veille thématique Pouvoir de délégation DNS rassemble des articles qui partagent un même sujet, un même signal ou un même thème de suivi. Cette page offre aux lecteurs un parcours plus riche à travers les reportages associés, les preuves issues de sources publiques, les acteurs du marché et les implications pour l’infrastructure, avec suffisamment de contexte pour comprendre pourquoi le sujet compte pour les mouvements d’entreprises, les décisions de gouvernance, l’exposition régionale et le risque opérationnel. Les lecteurs peuvent comparer les signaux récurrents, les organisations concernées, les preuves publiques, le contexte du marché, la continuité de service, les achats, la concurrence, la conformité et les questions de planification stratégique liées au sujet, au lieu de se contenter d’une liste succincte d’articles correspondants. Elle explique ce que couvre le sujet, quels acteurs ou politiques de l’infrastructure sont impliqués, quelles preuves étayent la couverture et pourquoi le sujet peut être important pour les opérateurs, les clients, les investisseurs et les lecteurs de politiques publiques.

Entreprises services cloud Europe et Moyen-Orient
Genesis Cloud : le peering distant documenté face à la visibilité routage de 2026
Le résumé de veille Genesis Cloud: le peering distant documenté face à la visibilité routage de 2026 explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional, l’exposition au marché et les conséquences possibles pour…

IETF
Le renvoi était exact. L’autorité avait changé en chemin.
Le service public a répondu proprement, puis a indiqué où poursuivre la recherche. L’utilisateur a suivi le renvoi et cru transporter avec lui la certitude du premier serveur. Or RFC 5144 organise précisément une séparation: le contrôle DCHK peut être léger, le registre détaillé…

IETF
La réponse faisait autorité. Le résolveur pouvait encore se tromper : RFC 9606
RFC 9606 permet à un résolveur DNS de publier quelques propriétés de confidentialité et de filtrage dans un format commun. L’authenticité de cette déclaration ne garantit pourtant pas l’exécution qu’elle décrit.

IETF
Le numéro d’algorithme existe. Le chemin de validation, pas forcément : RFC 9558
Un registre peut attribuer un numéro à une suite cryptographique avec une précision parfaite. Il ne peut pas obliger le résolveur qui se trouve devant l’utilisateur à savoir l’employer.

IETF
La clé reste au domicile, mais la publication part chez un tiers : RFC 9526
Externaliser le DNS d'un réseau résidentiel ne revient pas à céder une autorité unique. Le RFC 9526 laisse au domicile la fabrication et la signature de la zone, puis confie à d'autres acteurs sa diffusion, son rattachement au parent et sa visibilité publique.

IETF
Le service annonçait OHTTP. Sa clé pouvait encore désigner le client : RFC 9540
La RFC 9540 rend découvrables une cible Oblivious HTTP, sa passerelle et la configuration cryptographique de celle-ci. Cette commodité révèle aussi une frontière décisive: une annonce DNS exacte et un échange chiffré réussi ne prouvent pas qu’une clé, un chemin ou une redirection…

Histoire d'Internet
Le DNS trouvait un nom exact. Il ne cherchait pas ce que vous vouliez dire : RFC 3467
Une résolution exacte peut mener avec rigueur au mauvais endroit si le nom choisi ne correspondait pas à l'intention. En 2003, RFC 3467 a séparé le travail mécanique du DNS de la découverte incertaine propre aux humains.

Entreprises services cloud mondiales
Couches de service de l'AS210973 : ce que les trois /24 restants de DATAMATIX révèlent sur le bloc 212.236.x
Le résumé de veille Couches de service de l'AS210973: ce que les trois /24 restants de DATAMATIX révèlent sur le bloc 212.236.x explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional, l’exposition au marché et les…

IETF
Le petit identifiant correspondait. Personne n’avait prouvé que les deux grands objets étaient les mêmes.
Deux valeurs sur seize bits étaient égales: celle annoncée par le serveur faisant autorité et celle conservée près du RRset en cache. L’équipe en a déduit que la version était identique. Elle avait comparé les étiquettes, pas encore la provenance des objets.

IETF
La réponse était signée. La publication restait au futur.
Le récepteur du parent avait authentifié la requête et renvoyé `NOERROR`. Pourtant sa phrase opérationnelle restait au futur: les nouvelles données de délégation devaient être publiées plus tard. Entre la réponse et le DNS public subsistait tout le pouvoir du système de…

IETF
Le parent avait publié le DS. Personne ne savait quand l’attente avait commencé.
Dans un cas opératoire construit, trois signataires affichaient le même ensemble DNSKEY et le parent servait désormais le DS combiné. Le contrôleur annonçait pourtant deux heures d’attente déjà consommées. Son horloge avait démarré à l’envoi de la demande, pas à la première…

IETF
L’administrateur DNS a publié la valeur. Personne ne lui avait montré le privilège.
Dans un cas construit, un ticket demandait d’ajouter un TXT « pour vérifier le domaine ». L’administratrice a contrôlé le nom, publié la valeur opaque et vu le ticket se fermer. Le service a ensuite activé une délégation persistante couvrant plusieurs fonctions. L’acte DNS était…

Histoire d'Internet
Un alias DNS pouvait déplacer un service, pas prouver son existence : RFC 2219
En 1997, des noms familiers comme `www` ou `ftp` offraient une porte d’entrée commode vers un service susceptible de changer de machine. La RFC 2219 a mis cette coutume en forme tout en traçant une limite nette: un nom utile est un indice, non la preuve qu’un service fonctionne.

Histoire d'Internet
La zone était critique, mais elle ne devait pas rester la tâche des serveurs racine : RFC 3172
La RFC 3172 imposait aux serveurs de `.arpa` une discipline digne de la racine du DNS. Elle disait pourtant que leur présence sur des machines de la racine devait changer. Cette tension révèle un principe solide: préserver le nom et le service n’oblige pas à consacrer l’opérateur…

ICANN
Les 1 616 dossiers de l’ICANN ne sont pas encore 1 616 extensions
Le « Reveal Day » rendra enfin visibles les ambitions déposées pour le prochain cycle des nouveaux gTLD. Cette transparence modifiera les rapports de force, mais elle ne mettra pas les chaînes révélées dans la racine du DNS. Entre l’inventaire public et un espace de noms…

Histoire d'Internet
Un atelier d’un jour ne pouvait pas tester une signature qui expire : RFC 3130
Autour de l’IETF 49, la communauté DNSSEC comprit qu’une démonstration brève pouvait réussir précisément parce qu’elle se terminait avant les événements difficiles. Les signatures étaient encore valides, les clés n’avaient pas tourné et les organisations n’avaient pas dû…

IETF
Une mise à jour atomique peut être entièrement mauvaise
Le mérite de DUJ est d’empêcher qu’une modification DNS composée s’arrête au milieu. Sa limite est tout aussi importante: l’atomicité protège la cohérence de l’opération, pas la légitimité de celui qui l’a demandée ni la justesse de son résultat.

Récits
Le document de gouvernance des RIR, version 3 : comment un projet final redessine l'équilibre des pouvoirs entre l'ICANN et les registres régionaux
Le 1er septembre 2026, le Number Resource Organization (NRO) a publié la version 3 du « Governance Document for the Recognition, Operation, and Derecognition of Regional Internet Registries », présentée comme le projet final recommandé de l'Address Council de l'ASO (ASO AC). Ce…

Entreprises institutionnelles Asie-Pacifique
Cloud Registry Pty Ltd : l'outsider qui a réclamé un appel d'offres, et ce que le dossier de registre .au révèle ensuite
Cloud Registry Pty Ltd, société australienne de Sydney, n'a jamais détenu l'autorité de registre pour le .au. Mais sa soumission de juillet 2012 au comité consultatif industriel de auDA — qui réclamait un appel d'offres public complet pour le registre .au plutôt qu'une…

IETF
Quand le silence fait foi, la collision attend le retour du réseau
Une adresse multicast peut sembler disponible non parce que personne ne l’utilise, mais parce que celui qui l’utilise se trouve momentanément de l’autre côté d’une coupure. La révision 12 d’un projet du groupe PIM expose ce paradoxe sans détour: l’absence de réponse vaut…
