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
L’essai d’APNIC à deux serveurs a produit moins de répétitions, mais il lui manque encore un reçu de reproduction
Lors d’un second essai utilisant deux serveurs de noms, APNIC a observé moins de requêtes DNS autoritatives que lors de son précédent essai à un seul serveur. L’écart est établi dans les agrégats publiés; sa cause ne l’est pas. Pour en faire un résultat de décision, les deux…

Histoire d'Internet
RFC 2065 : le serveur transportait la réponse, le résolveur jugeait la preuve
En janvier 1997, le RFC 2065 a proposé une façon singulièrement modeste de sécuriser le DNS: ne pas transformer chaque serveur intermédiaire en autorité de confiance. Un serveur ordinaire pouvait remettre des enregistrements signés; le résolveur conscient de la sécurité examinait…

Récits
Le nœud anycast d’AFRINIC en Ouganda recouvre deux services, pas un seul
Le résumé de veille Le nœud anycast d’AFRINIC en Ouganda recouvre deux services, pas un seul 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’intégration de noms alternatifs d’ICANN exige un arrêt vérifiable
Prévoir l’arrêt d’un service ne prouve pas que toutes ses traces de contrôle disparaîtront au bon moment. Le rapport initial de l’ICANN sur l’intégration d’un gTLD avec d’autres systèmes de nommage recommande un plan d’arrêt obligatoire. Il faut lui ajouter une preuve d’exécution…

Récits
AFRINIC : le DNS du ccTLD ne fixe pas la limite de l’IPv6
Le contrôle des serveurs du registre apporte une information utile. Il ne suffit pourtant pas à déclarer tous les sites situés sous ce domaine inaccessibles en IPv6: le résolveur récursif peut emprunter une autre voie.

IETF
DNS ANY doit disparaître usage par usage, pas seulement par code de requête
Supprimer une réponse DNS ambiguë est une décision de serveur. Remplacer les raisons pour lesquelles des logiciels la demandaient est un travail de gouvernance. Entre les deux, il faut des usages identifiés, des solutions explicites et des exceptions dont quelqu’un répond.

IETF
Un basculement de serveur ULD doit prouver que les services locaux ont survécu
Lorsqu’un réseau local change de serveur de découverte, tout peut sembler normal: le nouveau routeur répond, les clients l’ont préféré et l’accès à Internet n’a jamais été interrompu. Pourtant, la caméra de la salle, une imprimante ou un automate peuvent avoir disparu du…
IETF
La zone répond encore. La clé, elle, ne reviendra pas
Après la perte d’une clé privée DNSSEC, des réponses « Secure » peuvent continuer à donner une impression de normalité. Elles ne signalent pourtant qu’un état ancien encore vérifiable: un délai compté pendant lequel l’opérateur doit reconstruire la fonction de signature et…

IETF
DANCE 14 ramène quatre résultats TLSA à une décision serveur binaire
Un serveur peut fermer la connexion parce que le nom du client n’existe pas, parce que ce nom existe sans TLSA, parce que la chaîne DNS n’est pas authentifiée ou parce que la validation échoue. La révision 14 du projet DANCE distingue enfin ces quatre observations, puis les…

IETF
EDE 33 peut signaler une NTA sans prouver qu’elle a changé la réponse
Le code 33 est déjà visible dans le registre IANA alors que le groupe DNSOP n’a pas encore clos son appel à l’adoption. Cette coexistence n’est pas contradictoire: le numéro coordonne les implémentations, la procédure décide qui portera le document. Mais le futur signal a…

Récits
Chez RIPE NCC, quatre glues IPv6 obsolètes ne sont plus que trois — car la racine ne se répare pas par lot
Le cas de `.ps` s’est résorbé tandis que ceux de `.ne`, `.sd` et `.tj` restent visibles. Cette différence n’est pas un détail de calendrier: elle montre que chaque délégation suit sa propre chaîne d’autorisation, même lorsque les quatre adresses proviennent du même renumérotage.

Histoire d'Internet
Gihan Dias, quand l’Internet sri-lankais a appris deux écritures
Un pays peut être relié au réseau mondial tout en restant mal nommé par celui-ci. Le parcours de Gihan Dias montre comment le Sri Lanka a dû prolonger la construction de ses liaisons par un autre chantier: faire une place au cingalais et au tamoul dans la racine du DNS.

Récits
LACNIC signe 150 fichiers DNS inverses, sans manifeste de lot
Le répertoire public de LACNIC protège chaque fichier séparément. Il ne publie toutefois aucun reçu signé indiquant au miroir qui télécharge l’ensemble où commence et où finit une génération complète.

Histoire d'Internet
Demi Getschko et le code pays arrivé avant que le Brésil ne parle TCP/IP
Le 18 avril 1989, `.br` entre dans la racine du DNS alors que les réseaux universitaires brésiliens utilisent encore BITNET, HEPnet et d'autres protocoles. Le parcours de Demi Getschko montre qu'une infrastructure commence parfois par une responsabilité acceptée avant même que le…

Récits
La carte des ccTLD d’AFRINIC en compte 27. Trois exigent de relier l’adresse.
Le total affiché par AFRINIC résiste à la vérification, mais pas à une lecture limitée aux noms de serveurs. Pour .so, .ng et .ml, le lien avec le service NS2 n’apparaît qu’en rapprochant les adresses déléguées des préfixes anycast publiés par le registre.

ICANN
Anne-Marie Eklund Löwinder et la clé qui ne pouvait pas signer la racine
On a souvent raconté les cérémonies DNSSEC comme si quelques gardiens possédaient chacun une clé d’Internet. Le parcours d’Anne-Marie Eklund Löwinder montre une réalité plus solide: sa clé n’avait de sens qu’au sein d’un dispositif qui rendait toute personne isolée incomplète.
Entreprises services cloud mondiales
AlmazCloud : le maillon manquant entre ASN, déploiement et service client
Le résumé de veille AlmazCloud: le maillon manquant entre ASN, déploiement et service client 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
Le pouvoir d’ICANN ne tient pas dans un seul texte
ICANN n’exerce pas son autorité par un acte unique. Son contrôle opérationnel naît d’une chaîne: une finalité d’entreprise, des statuts internes, des contrats conclus avec les opérateurs de registres et les bureaux d’enregistrement, puis des procédures qui permettent — ou…

Entreprises services cloud mondiales
AlmazCloud et AS210328 : ce que les traces publiques permettent réellement d’établir
Le résumé de veille AlmazCloud et AS210328: ce que les traces publiques permettent réellement d’établir 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…
Entreprises services cloud mondiales
AlmazCloud et AS210328 : la continuité opérationnelle reste à démontrer
Le résumé de veille AlmazCloud et AS210328: la continuité opérationnelle reste à démontrer 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 l’infrastructure.…
