Domaine principal
DNS
Au sein de la facette Domaine principal, l'analyse DNS regroupe les articles par domaine principal afin que les lecteurs puissent suivre un périmètre précis de l'infrastructure Internet, de la gouvernance, des marchés de connectivité ou du capital numérique. Cette page rassemble les articles associés, les preuves publiques, les institutions, les entreprises, les personnes, l'exposition régionale, les dépendances opérationnelles et le contexte de marché qui pourraient sinon être répartis entre différentes pages de catégories. Elle explique le domaine, la classe d'acteurs probable, le contexte de marché ou de gouvernance, ainsi que les sources que les lecteurs devraient utiliser pour comparer les signaux. Opérateurs, analystes et lecteurs de gouvernance peuvent voir comment un même domaine se manifeste à travers les événements, les profils, les évolutions de marché, les preuves issues de sources publiques, les dépendances régionales et les décisions d'infrastructure à plus long cycle au fil du temps.
IETF
Un numéro d’algorithme ne crée pas une chaîne de confiance
RFC 9563 donne à la signature SM2 et au condensat SM3 des identifiants DNSSEC stables. Ce progrès rend les formats désignables; il ne vaut ni consensus de l’IETF, ni évaluation cryptographique, ni preuve de prise en charge par les validateurs.
IETF
Le serveur de secours a répondu. La clé en cache ne convenait pas : RFC 8901
Un second fournisseur DNS peut continuer à répondre après la panne du premier sans pour autant livrer une réponse acceptable aux résolveurs validateurs. RFC 8901 montre que la redondance DNSSEC est un contrat de synchronisation entre signataires, et non un simple nombre de…
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.
Dossier
Quand un correctif DNS ne suffit pas : la chaîne de réparation après les vulnérabilités BIND
Les vulnérabilités qui frappent un résolveur DNS ne se mesurent pas seulement au nombre de versions corrigées. Elles se mesurent à la capacité d’une organisation à repérer son exposition, déployer la correction et démontrer que le service résiste encore au mécanisme qui l’a…
IETF
James Gould et le signal de masquage qui ne prouve pas la règle
Un logiciel compare deux réponses RDAP et découvre qu’un numéro de téléphone a disparu. La tentation est immédiate: le champ aurait été supprimé pour des raisons juridiques. Mais la différence ne dit encore ni si la donnée existait, ni qui pouvait la voir, ni quelle règle a été…
Dossier
Le coût discret d’une exception DNS
Accorder à un résolveur local un périmètre stable évite de rouvrir un dossier à chaque nouveau service interne. Encore faut-il savoir ce que cette commodité délègue et ce qu’elle révèle. Le RFC 9704 permet de rendre l’autorisation vérifiable sans publier tout l’annuaire privé.
IETF
Suzanne Woolf et l’étiquette de serveur qui n’est pas une identité machine
Lorsqu’un serveur DNS renvoie un identifiant avec sa réponse, la tentation est forte d’y lire le nom certain d’une machine. L’anycast et les répartiteurs de charge rendent cette lecture dangereuse. Les exigences formulées par Suzanne Woolf dans le RFC 4892 conduisent à une…
IETF
Sara Dickinson et la promesse du résolveur que le chiffrement ne peut pas prouver
Le cadenas affiché à côté d’un résolveur DNS dit une chose juste: entre le client et un service identifié, la conversation est protégée. L’erreur commence lorsqu’on lui demande de témoigner sur la suite. Le RFC 8932, cosigné par Sara Dickinson, accompagne la requête au-delà du…
ICANN
Allison Mankin et l’échantillon de collision de noms qui ne prouvait pas sa cause
Un nom observé mille fois à la racine du DNS paraît raconter une histoire complète. Il ne livre pourtant ni l’application qui l’a formé, ni l’organisation responsable, ni la population exposée. Le rapport RFC 8023 cosigné par Allison Mankin apprend à ne pas confondre cette trace…
Dossier
La clé était connue, mais elle n'était pas encore digne de confiance
Le danger tient à un ordre d'exécution. Une mise à jour DNS auto-signée apporte une nouvelle clé et demande la suppression de l'ancienne. La signature établit la possession de la nouvelle clé; elle ne donne pas, à elle seule, le droit de modifier la délégation. Au terme annoncé…
Dossier
Un point final, et la frontière de confiance se déplace
Dans le DNS, `example.co.uk` et `example.co.uk.` peuvent conduire au même nœud. Dans une application, ces deux écritures peuvent pourtant ouvrir des périmètres différents. À la clôture, le 7 septembre, de l’appel à commentaires du groupe DNSOP, une faille récente de curl rappelle…
IETF
La minimisation du QNAME est un contrat de séquence, pas un interrupteur de confidentialité
Un résolveur peut annoncer la minimisation du QNAME tout en exposant des noms, des coûts et des échecs très différents selon l’état de son cache. La preuve utile n’est donc pas un indicateur binaire, mais la séquence bornée produite par les délégations connues, les réponses…
Dossier
DNS a reçu le signal. Le parent devait encore décider : la frontière de délégation de la RFC 9859
La RFC 9859 raccourcit le chemin vers un contrôle de délégation. Elle ne transforme ni un message DNS ni son accusé de réception en décision du parent.