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
Une erreur DNS étendue explique l’échec sans autoriser une autre réponse
Un échec DNS peut être exact au regard du protocole et rester presque inutilisable pour l’exploitation. La RFC 8914 permet au répondant d’ajouter une cause plus précise, sans modifier le résultat DNS. Cette séparation crée un canal d’observation précieux, mais impose de ne jamais…

IETF
Quand l’identifiant d’un drone devient une délégation DNS : RFC 9886 et la chaîne de registre
Un Broadcast Remote ID peut transporter un DET compact, tandis que les éléments publics nécessaires pour authentifier son inclusion dans un registre sont répartis entre les délégations DNS inverses, les enregistrements HHIT et BRID, et une chaîne de certificats. Il faut donc…

IETF
Une racine locale transforme la résilience DNS en décision de basculement
La RFC 8806 autorise un résolveur récursif à consulter sur sa propre machine une copie complète de la zone racine. Cette proximité réduit la dépendance au chemin vers les serveurs racine et soustrait les requêtes racine au regard du réseau intermédiaire. Elle confie aussi à…

Dossier
L’en-tête disait NOERROR ; le corps signé prouvait que le nom n’existait pas : RFC 9824
Le cache avait conservé la preuve DNSSEC, sa signature et sa durée de vie. Il avait oublié un seul bit: la capacité CO annoncée par l’amont. Au moment de répondre, le résolveur savait encore que le nom n’existait pas, mais ne savait plus s’il pouvait présenter cette conclusion…

Histoire d'Internet
Le nom figurait sous .US. La zone n’avait pas pour autant été déléguée : RFC 1480
Une réponse DNS positive semble clore la question: le nom existe. En 1993, cette réponse pouvait pourtant provenir de trois montages distincts sous `.US` — une fiche directe avec adresse IP, une fiche directe acheminant le courrier vers une passerelle, ou une branche réellement…

Histoire d'Internet
Le TXT portait l’attribut. Le DNS n’en donnait pas le sens : RFC 1464
Un signe égal suffisait à faire apparaître deux champs dans une chaîne TXT. En 1993, RFC 1464 permettait ainsi de publier un attribut sans apprendre un nouveau type d’enregistrement aux serveurs DNS. Cette économie d’infrastructure laissait pourtant ouvertes les questions…

Récits
La racine DNS locale a aussi une facture de mise à jour
Installer une copie de la zone racine près d’un résolveur évite de nombreuses requêtes externes. Cela ne supprime pas le trafic: il réapparaît dans la boucle de mise à jour. Une étude présentée par APNIC montre pourquoi la cadence et le logiciel comptent davantage que l’étiquette…

Dossier
Le titulaire était à l'étranger ; le registre du .com était en Virginie : CNN c. CNNews.com
Un nom de domaine peut circuler dans une langue, servir un public et être exploité par une société situés loin du tribunal qui en décide. Dans le dossier de `cnnews.com`, l'opérateur était chinois et le site s'adressait principalement à un lectorat chinois. Pourtant, la fiche de…

IETF
Un résolveur peut choisir le chiffrement avant que les opérateurs DNS se coordonnent
Chiffrer la liaison entre un utilisateur et son résolveur récursif ne protège pas l’étape suivante. Lorsque la réponse manque dans le cache, le résolveur peut encore interroger un serveur faisant autorité en clair. La RFC 9539 propose un compromis expérimental: permettre à chaque…

IETF
Les zones catalogue transforment une liste DNS en pouvoir de provisionnement à l’échelle du parc
Un fichier vide signifie généralement qu’il ne contient rien. Dans une zone catalogue DNS, il peut constituer une instruction. Si un générateur publie par erreur un catalogue valide mais sans membres, les serveurs qui en dépendaient peuvent retirer les zones et leur état associé.…

ICANN
Un fichier de zone donne un accès partagé, pas le droit de republier l’espace de noms
À 9 heures, un chercheur autorisé télécharge par le CZDS de l’ICANN le fichier de zone d’un gTLD. L’archive est reçue et sa somme de contrôle correspond. Cela prouve la livraison de ces octets. Cela ne prouve ni l’identité du bénéficiaire de chaque nom, ni son usage, ni un droit…

IETF
Une commande de suppression peut briser le domaine d’autrui : RFC 9874 et le contrôle des dépendances EPP
Une transition EPP destructive ne reste pas forcément limitée au client qui la demande. Lorsqu’un hôte subordonné est encore associé à des domaines parrainés par d’autres clients, sa suppression peut modifier leurs dépendances DNS et compromettre leur résolution. Le RFC 9874…

Dossier
Soixante noms étaient défendeurs; la loi définissait toujours l'action: Harrods v Sixty Internet Domain Names
Le titre de l'affaire ne désignait pas une société ou une personne, mais soixante noms de domaine. Cette forme procédurale a fourni au demandeur une voie contre les noms eux-mêmes. Elle n'a toutefois ni transformé le lieu d'enregistrement en preuve de responsabilité, ni supprimé…

IETF
ZONEMD permet au secondaire de vérifier la zone après le transfert
Un transfert achevé prouve que la livraison s’est terminée, pas que la copie assemblée correspond exactement à la zone voulue par l’éditeur. ZONEMD ajoute un condensat de la zone entière et sépare ainsi réception et vérification.

ICANN
Deux commissions de noms, un prestataire : ICANN garde des frais distincts
Analysys Mason assurera deux évaluations du prochain élargissement des gTLD. Le regroupement du travail ne gomme pas la différence entre une prestation comprise dans le forfait et un examen facturé en supplément.

IETF
Une ancre de confiance négative permet au résolveur de suspendre DNSSEC sans modifier la zone
Lorsqu’une zone signée est mal configurée, le résolveur validant peut maintenir l’échec ou ouvrir une exception locale très ciblée. L’ancre de confiance négative rétablit l’accès sans réparer la zone: elle confie temporairement à l’opérateur du résolveur le pouvoir de retirer…

ICANN
ccTLD IDN : le ccNSO distingue enquête ciblée et contrôle permanent
La réponse adoptée en juillet autorise des demandes de justificatifs fondées sur un motif raisonnable. Elle refuse d’en faire une surveillance systématique, alors que le Board prépare un nouvel examen de ccPDP4.

ICANN
Un changement ISO peut déclencher la sortie d’un ccTLD IDN. Il ne donne pas à l’ICANN un verdict territorial.
Une infrastructure de coordination peut avoir besoin d’un repère entretenu par une autre institution. Elle ne devrait pas, pour autant, se présenter comme l’institution qui tranche la réalité désignée par ce repère. C’est cette discipline que la ccPDP4 de la ccNSO rend visible…

Dossier
L’identifiant a été résolu. L’aéronef n’a pas été localisé : RFC 9886
La RFC 9886 rend un DRIP Entité Tag consultable dans le DNS, mais la réponse appartient au registre des identifiants, pas à la surveillance aérienne. Un certificat HHIT et un endorsement BRID validés attestent une inscription; ils ne disent ni où se trouve l’aéronef, ni qui le…

Histoire d'Internet
Les codes concordaient. Le circuit exigeait encore une autorisation : RFC 1394
En 1993, savoir que `FR`, un indicatif téléphonique et un answerback télex renvoyaient à la France ne suffisait pas à joindre qui que ce soit. Il fallait encore un réseau, une passerelle, une permission et un destinataire. La RFC 1394 rassembla les repères sur une même ligne sans…
