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.

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
Le parent avait publié le DS. Personne ne savait quand l’attente avait commencé.

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…

3 oct. 2026
L’administrateur DNS a publié la valeur. Personne ne lui avait montré le privilège.

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…

3 oct. 2026
Un alias DNS pouvait déplacer un service, pas prouver son existence : RFC 2219

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.

3 oct. 2026
La zone était critique, mais elle ne devait pas rester la tâche des serveurs racine : RFC 3172

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…

2 oct. 2026
Les 1 616 dossiers de l’ICANN ne sont pas encore 1 616 extensions

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…

1 oct. 2026
Un atelier d’un jour ne pouvait pas tester une signature qui expire : RFC 3130

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

1 oct. 2026
Une mise à jour atomique peut être entièrement mauvaise

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.

1 oct. 2026
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

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…

1 oct. 2026
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

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…

30 sept. 2026
Quand le silence fait foi, la collision attend le retour du réseau

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…

30 sept. 2026