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.

Récits
Le registre AuthDNS du RIPE NCC compte 43 nœuds, sans mesurer les réseaux d’accès qu’ils couvrent
Le RIPE NCC ne cherche pas simplement des points supplémentaires sur une carte: son plan vise les grands réseaux d’accès, leurs pairs et les points d’échange capables d’attirer leurs requêtes. Or son registre public atteste 43 déploiements opérationnels sans encore relier chacun…
Entreprises services cloud Europe et Moyen-Orient
Genesis Cloud : ce que les registres publics peuvent réellement prouver sur son réseau
Le résumé de veille Genesis Cloud: ce que les registres publics peuvent réellement prouver sur son réseau 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…

ICANN
L’autorité de l’ICANN ne vaut que par l’instrument qui l’exécute
L’ICANN n’est ni un régulateur général d’Internet ni un simple forum consultatif. Son pouvoir devient concret lorsqu’une mission définie, une politique élaborée par la communauté et un contrat applicable s’enchaînent jusqu’à une obligation opérationnelle. La question décisive est…

ICANN
Le renouvellement du .COM : comment l’autorité de l’ICANN devient un contrat opératoire
Le renouvellement de l’accord du registre .COM montre où se situe réellement le pouvoir de l’ICANN: ni dans le seul commentaire public, ni dans une injonction de droit public, mais dans une chaîne institutionnelle qui relie participation, décision du Conseil, délégation…

ICANN
L’autorité d’ICANN ne tient pas dans un seul pouvoir
Le contrôle exercé par l’ICANN sur le système des noms de domaine ne repose ni sur une compétence générale de régulateur public, ni sur un acte unique. Il se construit par couches: un mandat institutionnel, des contrats avec les opérateurs de registres et les bureaux…
ICANN
L’autorité d’ICANN n’est pas un bloc : qui peut réellement imposer, bloquer ou réparer une décision ?
ICANN est souvent décrite comme l’organisation qui gouverne les noms et les numéros de l’Internet. Cette formule est pratique, mais elle masque la question décisive: quelle règle donne à quel acteur le pouvoir de produire une conséquence concrète, et quel recours peut atteindre…

IETF
Shumon Huque et le verrou qui promettait une preuve, pas DANE pour toujours
Un engagement de sécurité peut porter sur la continuité d’une réponse sans figer son contenu. RFC 9102 organise précisément cette nuance: un serveur TLS promet de continuer à fournir une preuve DNSSEC vérifiable, mais la preuve positive d’un enregistrement TLSA peut ensuite…

ICANN
ICANN : l’autorité ne se trouve pas à une seule porte
L’ICANN n’administre pas l’Internet comme une administration mondiale qui détiendrait seule le pouvoir de modifier la racine du DNS. Son influence repose sur une chaîne plus précise: une mission et des pouvoirs définis dans ses textes constitutifs, des accords qui assignent des…
IETF
Le service répondait, mais l’identité `.onion` n’avait encore rien prouvé : RFC 9799
Dans une émission ACME ordinaire, une réponse réseau correcte semble souvent clore la question du contrôle. Pour un service Onion, elle n’en clôt qu’une partie. RFC 9799 distingue la présence du service, la possession de sa clé d’identité, la visibilité accordée à l’AC…
Entreprises services cloud mondiales
AlmazCloud : ce que l’empreinte publique d’AS210328 permet — et ne permet pas — d’établir
Une enquête fondée sur les registres, le routage, le DNS et la présence web distingue ce qui est administrativement enregistré de ce qui est effectivement observable — et ce qui pourrait encore être démontré sur la fourniture de services cloud.

IETF
Paul Mockapetris et le bit d’autorité qui ne couvrait pas toute la réponse
Une réponse DNS peut être souveraine sur le premier nom, servir une cible d’alias depuis son cache et ajouter des adresses utiles. Le bit AA reste exact; c’est l’étiquette « tout est autoritatif » qui falsifie le reçu.

IETF
Les types DNS 69 et 70 délèguent le sens sans nommer la version du registre
Un archiviste reçoit un RRset correctement signé: le type, le code et la valeur sont intacts. Pourtant, pour expliquer une décision prise six mois plus tôt, il doit encore répondre à une question que la signature ne contient pas: quelle édition de la nomenclature externe était…

Entreprises institutionnels Europe et Moyen-Orient
La Fondation de l’infrastructure Internet : deux systèmes, une identité encore incertaine
La continuité d’un domaine national ne repose pas sur les mêmes mécanismes que l’attribution d’adresses IP ou de numéros de système autonome. Dans le cas de la Fondation de l’infrastructure Internet, cette distinction est essentielle: les sources publiques relient l’organisation…

Récits
AFRINIC qualifie son tableau NS2 de « temps réel » alors que ses douze mesures liées sont ponctuelles et arrêtées
Un résultat peut être récupéré à l’instant sans avoir été produit à l’instant. C’est toute l’ambiguïté du tableau public NS2 d’AFRINIC: son habillage promet une supervision anycast en temps réel, mais les douze mesures RIPE Atlas qu’il consulte sont des campagnes ponctuelles…

Récits
Un plan DNS de secours n’est pas un second résolveur
Le récit publié le 9 septembre sur le blog d’APNIC transforme une panne domestique en règle d’infrastructure très concrète: un service de remplacement n’existe vraiment que lorsqu’il fonctionne, parvient jusqu’aux clients, passe une épreuve de basculement et permet un retour en…

Récits
Le renouvellement de K-root par le RIPE NCC exige trois procès-verbaux, pas un statut global
Une ligne de suivi peut être exacte et rester insuffisante. Le RIPE NCC indique que le renouvellement de trois sites centraux de K-root est en cours et qu’Amsterdam a déjà été renouvelé. Ce que l’on peut en conclure s’arrête là: pour savoir si chaque changement est clos, il faut…
Tendances institutionnelles mondiales
ISC : la chaîne de contrôle opérationnel, entre dispositifs conçus et fonctionnement démontré
Les pages publiques d’Internet Systems Consortium décrivent une chaîne complète: corriger BIND, concevoir la haute disponibilité de Kea, surveiller certains services et exploiter F-Root. Mais une architecture décrite, un test documenté ou une version publiée ne suffisent pas à…

IETF
Un enregistrement `_for-sale` signale une offre, pas l’autorité du vendeur
Un domaine affiché comme disponible dans le DNS peut ouvrir une négociation. Il ne dit pourtant ni qui peut engager le titulaire, ni si le prix tient encore, ni si le transfert aboutira. La RFC 10023 rend l’annonce lisible par les machines; la gouvernance commence précisément là…
IETF
Les standards de l’IETF deviennent une infrastructure opérationnelle — mais qui contrôle la continuité ?
Les standards de l’IETF ne font pas fonctionner directement les réseaux. Ils définissent plutôt les états, les échanges, les mécanismes de récupération et les dépendances de sécurité que les opérateurs doivent ensuite implémenter, maintenir et mesurer. Quand un chemin de routage…

IETF
DNSOP adopte le problème multi-algorithme, pas l’étiquette « UNIVERSAL »
Le 1er septembre, les présidents de DNSOP ont fermé un appel en laissant volontairement une porte ouverte. Le groupe prendra le document en charge, ont-ils constaté, mais la complexité du mécanisme reste à travailler. Cette réserve n’est pas une note de bas de page: elle définit…
