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.

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
La zone a été transférée. L’histoire de signature, elle, est restée derrière.

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…

30 sept. 2026
Un projet EPP introduit la suppression en bloc des enregistrements DELEG

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…

30 sept. 2026
Le registre a accepté la délégation. Le parent avait encore deux réponses

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…

29 sept. 2026
Martin J. Dürst et la frontière cachée d’une URL en Unicode

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…

29 sept. 2026
Le serveur enfant répondait encore. Le parent avait déjà déplacé la délégation

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…

29 sept. 2026
La clé ACME a tourné. L’autorisation DNS d’hier tient toujours

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.

29 sept. 2026
Deux réponses DNS honnêtes, un pare-feu qui se trompe : la frontière de la RFC 9726

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…

28 sept. 2026
Le visage commercial de JPRS : le contrat .jprs et une entreprise de services de registre évaluée par l'ICANN

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…

28 sept. 2026
Robert Elz et .au : comment une délégation personnelle est devenue une autorité d'institution

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…

28 sept. 2026
Le .jp sous contrôle : la chaîne qui encadre Japan Registry Services

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…

28 sept. 2026