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.

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…

IETF
La zone a été transférée. L’histoire de signature, elle, est restée derrière.
Le secondaire avait reçu tous les RRsets, le numéro de série SOA et la clé privée protégée par le HSM de relève. Il pouvait répondre au DNS. Pourtant, il ne savait pas quel index attribuer à la prochaine feuille ni quelle échelle prolongeait la série en cours. Le transfert avait…

IETF
Un projet EPP introduit la suppression en bloc des enregistrements DELEG
Dans la troisième version d'un projet individuel, un client EPP pourrait demander que tous les enregistrements DELEG d'un domaine soient retirés d'un seul coup. Ce geste bref appelle une décision d'autorisation qui ne se confond pas avec l'entretien courant d'un enregistrement…

IETF
Le registre a accepté la délégation. Le parent avait encore deux réponses
Le code de succès est arrivé avant la preuve DNS. Avec la révision 03 du projet EPP pour DELEG, cet écart devient une question de conduite du changement: une transaction peut supprimer tous les enregistrements DELEG alors que les NS traditionnels continuent d’indiquer que le…

Dirigeants
Martin J. Dürst et la frontière cachée d’une URL en Unicode
Avant de juger une adresse à sa graphie, il faut savoir à quel composant on la confie. Les travaux de Martin J. Dürst sur les identifiants de ressource internationalisés ont contribué à rendre cette question explicite: un lien lisible, un nom DNS et une cible URI peuvent être…

Dossier
Le serveur enfant répondait encore. Le parent avait déjà déplacé la délégation
Une réponse DNS peut être parfaitement autoritaire et néanmoins provenir d’une autorité que le parent a cessé de désigner. La révision 14 du projet sur la revalidation des délégations impose donc une discipline simple: la crédibilité de l’enfant ne doit jamais prolonger…

IETF
La clé ACME a tourné. L’autorisation DNS d’hier tient toujours
La révision 02 du mécanisme DNS persistant d’ACME sépare une opération familière — changer de clé — du retrait réel d’une autorisation. La vieille clé ne signe plus rien, mais son empreinte publique peut encore soutenir une validation en cours de vie.

Dossier
Deux réponses DNS honnêtes, un pare-feu qui se trompe : la frontière de la RFC 9726
Le fichier MUD autorisait bien le service du fabricant. L’objet connecté et son contrôleur ont pourtant reçu deux ensembles d’adresses différents, puis le pare-feu a transformé ce décalage en incident. La RFC 9726 montre que le nom, sa résolution et la règle exécutée ne…

ICANN
Le visage commercial de JPRS : le contrat .jprs et une entreprise de services de registre évaluée par l'ICANN
Japan Registry Services Co., Ltd. (JPRS) est surtout connue comme l'opérateur du registre du domaine national .jp, un rôle de délégation d'intérêt public déjà audité en profondeur. Mais la même société exploite depuis 2014 une seconde piste d'autorité, purement contractuelle…

Histoire d'Internet
Robert Elz et .au : comment une délégation personnelle est devenue une autorité d'institution
Le 5 mars 1986, l'IANA consigne la délégation du domaine de premier niveau .au à Robert Elz, programmeur réseau à l'Université de Melbourne. Pendant quinze ans, l'autorité sur le domaine national australien a reposé sur une personne, sans que le dossier public conserve des…

ICANN
Le .jp sous contrôle : la chaîne qui encadre Japan Registry Services
Le registre des noms de domaine japonais fonctionne sous une architecture de supervision rarement détaillée. Le gouvernement japonais détient le pouvoir de direction; la JPNIC évalue chaque année les performances de Japan Registry Services (JPRS) au regard de critères qu'elle…
