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.

ICANN
Des accents qui engagent tout un registre
La possibilité d’exploiter ensemble un suffixe ASCII et ses formes à signes diacritiques aurait une contrepartie durable. Le rapport final du GNSO propose de lier leurs changements de prestataire et de contrôle. L’intérêt linguistique ne dispense pas d’examiner les conditions de…

Histoire d'Internet
L’entrée de domaine pointait vers l’organisation sans être l’organisation : RFC 1279
Un alias fait une promesse forte: deux chemins mènent au même objet. RFC 1279 refusa précisément cette promesse entre l’arbre des domaines et l’arbre des organisations. Le domaine pouvait conduire vers une université, une unité ou un gestionnaire, mais ce lien ne transformait pas…

IETF
Wes Hardaker et le serveur DNS contraint de survivre à deux TTL
Une migration DNS ne s'achève pas quand le nouveau serveur répond. Elle s'achève quand plus aucun cache encore légitime ne peut conduire une requête vers l'ancien — et cette frontière dépend parfois d'une horloge que l'opérateur de la zone ne commande pas.

Histoire d'Internet
Le nom était local. Le numéro devait encore être consigné : la frontière de cartographie DNS de la RFC 1101
En 1989, le DNS distribuait déjà des informations sur les hôtes, mais ne donnait pas encore un moyen normalisé de demander le nom d’un numéro de réseau. La RFC 1101 a proposé une réponse faite de PTR, d’entrées d’hôte zéro dans `IN-ADDR.ARPA` et de masques. Sa retenue est sa…

IETF
Tobias Fiebig et les quatre preuves de joignabilité du DNS
Le moment le plus risqué d’un changement de fournisseur DNS n’est pas toujours la publication des nouveaux serveurs. Il survient quand les anciennes adresses fonctionnent encore, que les nouvelles apparaissent dans la délégation et qu’un succès en double pile masque le chemin qui…

Histoire d'Internet
Le service de noms a failli négocier : comment la RFC 830 séparait domaines et capacités
La source connaît le domaine de destination. Elle ne sait pourtant pas encore quel programme l'attend, quel transport il accepte ni même s'il propose le service demandé. La RFC 830 faisait de cet écart un élément d'architecture: localiser le domaine constituait une première…

IETF
David Lawrence et la réponse DNS qui survécut à son TTL
Une réponse DNS vient d'expirer alors que sa source autoritative ne répond plus. La RFC 8767 permet au résolveur récursif d'assurer une continuité limitée avec l'ancienne valeur, à condition d'avoir réellement tenté un rafraîchissement, de borner cette exception et de continuer à…

IETF
Steve Sheng et le verrou qui n’a pas arrêté la maintenance DNSSEC
Un domaine peut rester « verrouillé » alors que son jeu de DS évolue sans fraude ni contournement. La RFC 10026 oblige à abandonner l’image d’un cadenas universel: il faut nommer l’acteur, le type de commande bloqué et la voie de maintenance authentifiée qui demeure ouverte.

IETF
Peter Thomassen et la mise à jour qui exigeait chaque serveur faisant autorité
Dans le DNS, obtenir une réponse suffit souvent à poursuivre la résolution. Modifier une délégation exige une règle plus sévère: le parent doit savoir si la demande existe dans l’ensemble du service faisant autorité. Avec le RFC 9975, Peter Thomassen transforme cette différence…

Dossier
Un domaine se dit à vendre dans le DNS. Qui a qualité pour engager la vente ?
Avec RFC 10023, une disponibilité devient repérable sans retirer le domaine du service. Cette publicité technique est précieuse à condition de ne pas la transformer en titre de propriété, mandat du vendeur ou promesse de transfert.

Dossier
Deux cartes pour un même nom : RFC 10001 et la continuité DNS selon la famille d’adresses
Une délégation DNS n’a pas une seule carte de dépendances. Elle en possède au moins deux: celle que peut parcourir un résolveur IPv4 et celle qu’emprunte un résolveur IPv6. Elles peuvent publier les mêmes noms et aboutir à des réalités différentes. RFC 10001 demande aux…

Dossier
La réponse tenait dans un paquet, pas la preuve entière : RFC 10029 et l’autorité entre types DNS
Au bord d’une délégation, un serveur peut répondre avec autorité pour DS mais pas pour les données NS visibles au même endroit. RFC 10029 permet de demander les deux types ensemble; il interdit justement de faire disparaître cette différence dans un en-tête commun. Le gain de…

Dossier
Le registre affiche un TTL, le résolveur garde son temps : RFC 10037 et le pouvoir de décrire une fenêtre DNS
RDAP peut désormais montrer le TTL configuré dans la base d’un registre. Ce témoin extérieur est précieux lors d’un changement de délégation, à condition de ne pas lui demander l’heure d’une autre machine. Il ne dit ni ce que chaque serveur faisant autorité a déjà publié, ni…

Dossier
L’erreur est revenue sous forme de question : DNS Report-Channel et l’autorité du retour
Un serveur faisant autorité peut répondre correctement à ses propres yeux tout en livrant une zone que les résolveurs validateurs refusent. RFC 9567 lui donne une adresse de retour, pas un droit de commander le diagnostic: le résolveur transforme son échec local en une nouvelle…

Dossier
Le paquet masquait sa longueur exacte, mais le rythme parlait encore : EDNS Padding et les limites de la confidentialité DNS
Chiffrer une requête DNS retire le nom du regard indiscret, mais pas nécessairement sa silhouette. EDNS Padding ajoute des octets pour brouiller cette silhouette. La protection réelle dépend toutefois d'une chaîne de choix: la politique du client, celle du serveur…

Dossier
L’enregistrement liait les options, pas la connexion : SVCB, HTTPS et l’autorité du client
Un service peut publier avant toute requête HTTP le serveur, le protocole et le port qu’il préfère. Le client doit encore déterminer si cet ensemble est intelligible, joignable, conforme à sa politique et capable de prouver l’identité de l’origine.

Dossier
Le flux était valide, mais la réponse venait d’ici : RPZ et pouvoir local sur la résolution DNS
Une liste de menaces peut arriver intacte, à l’heure et depuis le bon éditeur. Il reste pourtant à décider qui elle touche, ce que le résolveur répond et à quel moment une recommandation externe devient une affirmation locale.

Dossier
L’empreinte concordait, mais la zone était fausse : ZONEMD et les limites de l’intégrité cryptographique
Une preuve cryptographique peut être impeccable tout en couvrant une décision erronée. Avec ZONEMD, l’enjeu n’est donc pas seulement de vérifier une zone DNS, mais de ne pas demander au condensat de juger ce qui relève encore de l’exploitation.

Dossier
Le signal était signé. La délégation ne l’était pas encore : CDS/CDNSKEY et le pouvoir de publier le DS
CDS et CDNSKEY permettent à un opérateur de demander une modification du lien DNSSEC sans recopier une empreinte à chaque rotation. Mais une demande signée n’est pas encore le DS du parent: elle doit être située dans le bon état de confiance, admise par l’agent parental, publiée…

Dossier
Le catalogue était valide. La suppression ne l’était pas : DNS Catalog Zones et pouvoir de provisionnement
Un catalogue DNS peut être irréprochable au regard du protocole et pourtant porter une décision désastreuse. Lorsque sa liste de membres devient vide, l’authentification du transfert prouve l’origine du message; elle ne prouve ni l’intention de supprimer, ni le droit d’effacer…
