Aller au contenu principal

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.

Panama : cinq identités racine, six instances recensées

Récits

Panama : cinq identités racine, six instances recensées

LACNIC cite cinq identités de serveurs racine pour le Panama dans son article d’avril 2026. Les fiches publiques des opérateurs, consultées en octobre, totalisent six instances. Ces nombres portent sur des unités et des dates différentes; le graphique de temps de réponse pose une…

10 oct. 2026
APNIC : ses deux signaux sur la clé racine ne mesurent pas la même chose

Récits

APNIC : ses deux signaux sur la clé racine ne mesurent pas la même chose

Le 11 octobre, la racine DNS doit commencer à être signée avec KSK-2024. Les mesures publiées par APNIC placent deux pourcentages à côté de cette échéance: l’un provient de signaux émis par des résolveurs, l’autre de tests exécutés depuis des terminaux derrière des résolveurs…

9 oct. 2026
Qui pouvait demander un domaine de premier niveau ? La première liste de la RFC 920

Histoire d'Internet

Qui pouvait demander un domaine de premier niveau ? La première liste de la RFC 920

En octobre 1984, la première liste de domaines de premier niveau fixait aussi des conditions d’admission: certains noms étaient temporaires, d’autres correspondaient à de grandes catégories, et aucun ne pouvait entrer dans l’arbre sans administrateur ni procédure d’autorisation.

9 oct. 2026
Le cache a changé la destination, pas la racine : le détournement d’InterNIC par AlterNIC en 1997

Histoire d'Internet

Le cache a changé la destination, pas la racine : le détournement d’InterNIC par AlterNIC en 1997

Dans le réseau d’un opérateur, un résolveur a renvoyé une adresse d’AlterNIC pour `www.internic.net`. Sa mémoire DNS montre le chemin du détournement: une donnée supplémentaire est devenue une réponse locale. Cela prouve une destination modifiée par un résolveur, pas la prise de…

9 oct. 2026
L’extension `.mcp` ferait de l’appartenance au protocole un droit d’entrée

ICANN

L’extension `.mcp` ferait de l’appartenance au protocole un droit d’entrée

Le fichier préliminaire de l’ICANN regroupe cinq candidatures pour `.mcp`. Charleston Road Registry, qui exerce sous le nom de Google Registry, propose de réserver les noms de second niveau à quatre catégories de personnes ou d’organisations liées au Model Context Protocol. Une…

9 oct. 2026
Tina Dam et le test de la racine qui ne pouvait pas valider un nom

Dirigeants

Tina Dam et le test de la racine qui ne pouvait pas valider un nom

Avant d’ajouter un domaine de premier niveau internationalisé à la racine, l’ICANN a posé une question volontairement étroite: des étiquettes encodées perturberaient-elles les serveurs et les résolveurs qui acheminent les requêtes DNS ? Le laboratoire a répondu dans les limites…

8 oct. 2026
.agent : cinq candidats réapparaissent dans au moins onze groupes ICANN

ICANN

.agent : cinq candidats réapparaissent dans au moins onze groupes ICANN

Le premier fichier CSV du cycle ICANN 2026 place treize candidats dans le groupe `.agent`. Cinq de ces entités candidates figurent dans au moins onze groupes de contention numérotés du fichier: le dossier révèle ainsi des portefeuilles d’engagements, au-delà du seul affrontement…

8 oct. 2026
Une inscription réservait un ensemble, pas un seul nom : RFC 3743

Histoire d'Internet

Une inscription réservait un ensemble, pas un seul nom : RFC 3743

Un bureau d’enregistrement peut accepter une étiquette CJK tout en traitant plusieurs variantes comme un seul objet administratif. En 2004, l’équipe d’ingénierie conjointe JET a décrit comment réserver ces formes au même titulaire sans les publier toutes dans le DNS.

7 oct. 2026
Pour l’ICANN, 56,4 % des domaines associés ne désignent pas un même titulaire

ICANN

Pour l’ICANN, 56,4 % des domaines associés ne désignent pas un même titulaire

Le nouveau rapport OCTO de l’ICANN indique que 56,4 % d’un échantillon défini de nouveaux noms gTLD signalés en 2025 par des listes de réputation avaient au moins un domaine techniquement associé. Ce résultat peut élargir une piste d’enquête, mais il n’établit ni un titulaire…

6 oct. 2026
Une référence UCAS pour les labels, sans approbation automatique des registres

ICANN

Une référence UCAS pour les labels, sans approbation automatique des registres

Le 5 octobre, l’ICANN a annoncé l’ajout d’un jeu de règles de référence de second niveau pour l’écriture syllabique autochtone canadienne unifiée. La proposition prévoit une utilisation compatible avec des IDN français dans une même zone, mais sa publication ne vaut ni validation…

6 oct. 2026
Genesis Cloud : le peering distant documenté face à la visibilité routage de 2026

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…

5 oct. 2026
Le renvoi était exact. L’autorité avait changé en chemin.

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é…

5 oct. 2026
La réponse faisait autorité. Le résolveur pouvait encore se tromper : RFC 9606

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.

4 oct. 2026
Le numéro d’algorithme existe. Le chemin de validation, pas forcément : RFC 9558

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.

4 oct. 2026
La clé reste au domicile, mais la publication part chez un tiers : RFC 9526

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.

4 oct. 2026
Le service annonçait OHTTP. Sa clé pouvait encore désigner le client : RFC 9540

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…

4 oct. 2026
Le DNS trouvait un nom exact. Il ne cherchait pas ce que vous vouliez dire : RFC 3467

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.

4 oct. 2026
Couches de service de l'AS210973 : ce que les trois /24 restants de DATAMATIX révèlent sur le bloc 212.236.x

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…

4 oct. 2026
Le petit identifiant correspondait. Personne n’avait prouvé que les deux grands objets étaient les mêmes.

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.

3 oct. 2026
La réponse était signée. La publication restait au futur.

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…

3 oct. 2026