Synthèse

  • dotSaarland GmbH est l’organisation de parrainage enregistrée pour.saarlandet.ruhr; les registres publics établissent un rôle de registre borné plutôt qu’une autorité souveraine sur l’identité régionale ou le DNS.
  • Les enregistrements de délégation et de transfert de l’IANA, les accords de l’ICANN, les observations DNS/DNSSEC actuelles, les objets RDAP, les politiques d’exploitation et les normes protocolaires exposent une capacité et une responsabilité réelles sans prouver une fiabilité longitudinale ni des résultats de production client.
  • Un schéma d’exploitation répété sur deux TLD peut simplifier les contrôles tout en concentrant les risques corrélés de changement, de fournisseur, de contact, de DNSSEC, de données d’enregistrement et de traitement des exceptions.
  • La supervision, l’intégration, la maintenance, la portabilité et la réponse autorisée aux exceptions demeurent des coûts d’exploitation même lorsque des prestataires spécialisés et l’automatisation effectuent le travail technique courant.

Note sur l’image:La photographie Creative Commons jointe montre un équipement générique de stockage d’archives au CERN. Elle ne représente ni dotSaarland GmbH, ni son personnel, ses installations, l’infrastructure de registre, les systèmes de production.saarlandou.ruhr, ses clients, ses incidents ou ses résultats de service mesurés.

dotSaarland GmbH apparaît dans le répertoire BTW actuel comme entité de type entreprise et dans la base de données de la zone racine de l’IANA comme organisation de parrainage de deux domaines génériques de premier niveau délégués,.saarlandet.ruhr.[1][2][3] Ces registres font de l’entreprise un sujet de recherche technologique utile pour une raison plus étroite, et plus importante sur le plan opérationnel, que l’image de marque régionale. Ils exposent une surface de contrôle où la responsabilité contractuelle rencontre une infrastructure Internet en fonctionnement.

Cette surface de contrôle comprend les données de délégation de la zone racine, les serveurs de noms faisant autorité, les extensions de sécurité du DNS, les points de terminaison WHOIS, les services du protocole d’accès aux données d’enregistrement (RDAP), les relations avec les registrars, les politiques d’enregistrement, le traitement des abus, la protection des données, le dépôt de données et les obligations de transition d’urgence. Les pages d’accord de l’ICANN et les accords de registre sous-jacents établissent les obligations pour les deux TLD.[6][7][8][9] Les documents publics propres à dotSaarland ajoutent des politiques et une identité juridique, tandis que les rapports historiques de l’IANA documentent la délégation initiale de.saarlandet le transfert ultérieur de.ruhr.[4][5][10][11][12]

Les registres ne divulguent pas d’architecture privée. Ils ne prouvent ni la disponibilité, ni la capacité, ni les effectifs, ni la vitesse de reprise, ni le volume d’enregistrements, ni la réussite client. Ils n’établissent pas non plus que chaque point de terminaison technique visible est exploité directement par dotSaarland. Les pages de l’IANA listent des adresses RDAP CentralNic, mais un nom d’hôte de service public ne constitue pas une carte complète de la responsabilité contractuelle ou technique.[2][3] Une évaluation rigoureuse maintient donc trois questions séparées:

  • Capacité du modèle ou du système:le système visible peut-il remplir une fonction définie, comme répondre au DNS faisant autorité, publier un enregistrement DS ou renvoyer un objet RDAP?
  • Fiabilité du produit:cette fonction reste-t-elle correcte, disponible, sécurisée et récupérable à travers les changements normaux, les pannes, les défaillances de dépendances et les transitions d’opérateur?
  • Résultat de production client:un titulaire, un registrar, un organisme public, un processus métier ou un utilisateur nommé a-t-il obtenu un résultat mesuré parce que le service a fonctionné?

Les registres publics et les observations protocolaires bornées peuvent étayer la première question et cadrer la deuxième. Ils ne fournissent presque aucune base pour la troisième. Aucun référentiel inventé, récit client, incident ou conception interne n’est nécessaire pour établir le dossier technologique. Le dossier réside dans la quantité de coordination continue requise pour maintenir la cohérence de deux espaces de noms régionaux entre organisations et dans le temps.

La conclusion centrale est qu’un registre se comprend au mieux comme un conservateur de registres et un opérateur au sein d’un système technique partagé, et non comme un propriétaire souverain de l’identité Internet d’une région. Son autorité est bornée par le contrat, la délégation, le protocole et les données que d’autres systèmes peuvent vérifier. Le travail continue après la délégation d’un TLD: les enregistrements doivent rester exacts, le code en cours d’exécution doit correspondre à ces enregistrements, et les mécanismes de continuité doivent être utilisables avant qu’une urgence ne survienne.

Identité, historique de délégation et limite de l’autorité

L’identité exacte de l’entreprise importe, car un TLD n’est pas exploité par une marque abstraite. Les pages.saarlandet.ruhrde l’IANA nomment toutes deux dotSaarland GmbH comme organisation de parrainage et fournissent la même adresse à St. Ingbert.[2][3] Les mentions légales de l’entreprise identifient dotSaarland GmbH et mentionnent la référence du registre du commerce HR B 19630.[12] Les index des accords de registre de l’ICANN associent l’entreprise aux deux accords de TLD.[6][7] Ensemble, ces sources étayent une déclaration précise: dotSaarland GmbH est l’opérateur de registre actuellement enregistré, responsable de ces deux délégations.

Cette déclaration ne doit pas être gonflée en une affirmation selon laquelle dotSaarland régule l’Internet, possède la racine DNS, contrôle les registrars ou gouverne tous ceux qui utilisent un nom régional. L’opérateur travaille dans un système en couches. L’ICANN maintient le cadre contractuel. L’IANA enregistre la délégation de la zone racine. Les opérateurs de serveurs racine distribuent la racine. Les registrars interagissent avec les titulaires et le registre. Les résolveurs récursifs et les opérateurs de réseau transportent les requêtes. Les normes définissent le comportement des protocoles.

Les tribunaux et les régulateurs peuvent trancher les questions juridiques. Le rôle public de dotSaarland est substantiel, mais borné.

L’histoire des deux chaînes est différente. Le rapport de délégation de l’IANA pour.saarland, daté du 28 mars 2014, enregistre des vérifications incluant l’éligibilité, l’identité du demandeur, la confirmation du contact et la conformité technique avant la délégation.[4] Le rapport de transfert de l’IANA pour.ruhr, daté du 31 août 2022, enregistre le transfert vers dotSaarland GmbH et l’achèvement des vérifications de traitement relatives au demandeur, au contact, à la conformité technique et aux autres contrôles.[5] La page actuelle de la zone racine de.ruhrrenvoie également à la délégation initiale de 2013 et au transfert de 2022.[3]

Ces rapports sont importants car ils montrent que la responsabilité peut se déplacer alors que l’espace de noms doit continuer à fonctionner. Un transfert n’est pas une simple annonce d’entreprise. Le sponsor enregistré, les contacts, les serveurs de noms, les données d’enregistrement, les éléments de dépôt, les politiques, les identifiants, la surveillance et l’autorité de changement doivent rester cohérents pendant la transition. Le rapport de transfert confirme qu’un processus défini s’est achevé. Il ne prouve pas que chaque changement ultérieur a été sans faille ni qu’un objectif de fiabilité particulier a été atteint.

La distinction entre conformité historique et fiabilité continue est facile à perdre. Une configuration peut satisfaire aux exigences minimales à une date donnée et dériver plus tard. Un contact peut être confirmé lors d’un transfert et devenir obsolète. Un service peut répondre lors d’une revue et échouer lors d’un futur incident de dépendance. Un registre peut avoir une politique saine mais un traitement de cas incohérent. La conformité est une porte; la fiabilité est un historique d’exploitation.

Les rapports de l’IANA expliquent aussi pourquoi l’organisation de parrainage importe. Ils décrivent cette organisation comme portant la responsabilité globale de la gestion des détails de délégation avec les fonctions IANA et exigent qu’elle corresponde à la partie contractante.[4][5] Il s’agit d’une responsabilité de type grand livre. Elle établit qui est responsable du registre et qui est autorisé à demander des modifications. Elle ne signifie pas que le sponsor doit physiquement exploiter chaque serveur ou écrire chaque ligne de logiciel.

Cette limite crée à la fois de la flexibilité et un coût. Un registre peut recourir à des prestataires spécialisés pour l’infrastructure, la sécurité, le juridique, les registrars et l’infrastructure. La spécialisation peut améliorer la capacité et réduire le besoin de construire chaque composant seul. Elle crée aussi des dépendances d’intégration. L’organisation de parrainage doit savoir quelle partie peut diagnostiquer un problème, quelle partie peut exécuter un changement, quelle partie peut l’approuver et quelle partie reste responsable lorsque plusieurs prestataires sont impliqués.

Pour les responsables technologiques, la leçon transférable est que les données d’identité font partie du système. Les noms d’entreprise, les identifiants d’entité, les contacts authentifiés et les rôles délégués ne sont pas une décoration administrative autour de l’infrastructure. Ils déterminent si une action techniquement correcte est autorisée et si un intervenant peut passer de l’observation à la remédiation sans ambiguïté.

Deux délégations comme un portefeuille unique de contrôles en fonctionnement

Les registres de l’IANA montrent un schéma technique répété entre.saarlandet.ruhr. Chaque délégation liste quatre serveurs de noms faisant autorité:a.nic.<tld>,b.nic.<tld>,c.nic.<tld>etd.nic.<tld>.[2][3] Chaque page publie des enregistrements glue IPv4 et IPv6 pour ces noms, un service WHOIS propre au TLD et une base RDAP CentralNic. Tous deux sont signés dans la racine par des enregistrements DS observés au même moment de capture borné.

La répétition peut réduire la complexité d’exploitation. Un schéma de nommage commun facilite la comparaison des inventaires. Des procédures partagées peuvent standardiser la surveillance, les revues de gestion des clés, l’intégration des registrars, l’escalade des incidents et la conservation des preuves. Le personnel peut poser les mêmes questions de contrôle pour chaque TLD et concentrer son attention sur les différences inattendues.

La répétition peut aussi créer des pannes corrélées. Si les deux TLD dépendent du même flux de travail, du même système de contrôle d’accès, du même service d’arrière-plan, de la même pratique de déploiement ou du même chemin de contact, une seule erreur peut affecter les deux. Les données publiques ne révèlent pas le degré de partage de l’arrière-plan; il serait donc faux d’affirmer une topologie particulière. Il reste raisonnable de traiter les schémas visibles partagés comme une raison de tester le risque de mode commun plutôt que de supposer l’indépendance.

L’enregistrement de la zone racine est la délégation publique prévue, pas le service complet. Quatre noms de serveurs listés ne signifient pas automatiquement quatre machines indépendantes, quatre sites, quatre chemins de systèmes autonomes ou quatre domaines de défaillance. L’anycast peut placer de nombreuses instances derrière un seul nom et une seule adresse. Plusieurs noms peuvent partager une infrastructure. Inversement, une adresse peut être annoncée depuis de nombreux emplacements. L’enregistrement décrit des identifiants et des enregistrements glue; il ne fournit ni carte physique ni score de résilience.

Cette distinction est là où la primauté du code en cours d’exécution devient utile. Une équipe de registre devrait comparer au moins quatre couches:

  1. Enregistrement faisant autorité:les noms, adresses, contacts, WHOIS, RDAP et informations DS actuellement enregistrés par l’IANA.
  2. Réponse protocolaire:ce que les serveurs faisant autorité et les points de terminaison de données d’enregistrement renvoient à un moment donné.
  3. Joignabilité distribuée:ce que des sondes provenant de différents réseaux et familles d’adresses peuvent atteindre et valider.
  4. Conséquence utilisateur:ce que les registrars, titulaires, résolveurs et applications expérimentent.

Une observation à une couche ne peut pas remplacer les quatre. Une page IANA correcte ne prouve pas que chaque serveur est joignable. Une réponse DNS réussie d’un résolveur ne prouve pas la joignabilité mondiale. Une réponse HTTP 200 d’un point de terminaison RDAP ne prouve pas que chaque objet est exact. Une défaillance d’application client ne localise pas, à elle seule, la panne dans le registre.

La vue portefeuille modifie la planification de la maintenance. Un changement de serveur de noms ou d’adresse peut être techniquement simple pour un TLD mais dangereux s’il est copié sur les deux sans préparation. Une rotation DNSSEC peut être répétable, mais répéter une commande erronée multiplie l’effet. Une mise à jour de contact commune réduit l’incohérence, mais une boîte aux lettres erronée peut affaiblir simultanément les deux chemins d’escalade. La standardisation devrait réduire la variation arbitraire, pas éliminer la vérification indépendante.

La bonne question opérationnelle n’est donc pas « Y a-t-il quatre serveurs de noms? » mais « Quelles preuves montrent que la délégation reste correcte et joignable face aux pannes qui comptent? ». Cela appelle des vérifications des réponses faisant autorité, de la cohérence des enregistrements glue, des chemins IPv4 et IPv6, de la validation DNSSEC, de la visibilité des routes, des taux d’erreur de requête, des opérations des registrars et de la capacité à isoler un changement sur un seul TLD lorsque nécessaire.

La documentation publique ne permet pas de dire comment dotSaarland effectue ces vérifications. Elle montre les objets qui doivent être supervisés. Un lecteur doit résister à transformer une capacité visible en affirmation de fiabilité. Les deux TLD étaient présents dans la racine, leurs noms de serveurs et enregistrements DS attendus étaient observables, et leurs points de terminaison RDAP renvoyaient les objets attendusnic.saarlandetnic.ruhrlors d’une vérification bornée. Ce sont des observations à l’instant de capture, pas une évaluation longitudinale du service ni un référentiel.

DNS, DNSSEC et le coût du changement sûr

La délégation DNS est un enregistrement public compact avec un effet opérationnel important. Un changement de l’ensemble des serveurs faisant autorité d’un TLD peut affecter chaque nom sous ce TLD. Les adresses glue peuvent être nécessaires pour briser une dépendance de résolution. L’IPv4 et l’IPv6 exigent une joignabilité distincte même lorsqu’ils représentent le même service logique. Les valeurs de durée de vie, les caches de résolveurs et la propagation créent une période pendant laquelle anciens et nouveaux états coexistent.

Les accords de registre reconnaissent l’importance des désignations de serveurs de noms et de la coordination de la zone racine.[8][9] Les rapports de délégation et de transfert de l’IANA enregistrent séparément les vérifications de conformité technique.[4][5] Ces contrôles réduisent le risque, mais ils n’éliminent pas le besoin d’un processus de changement local sûr. L’opérateur a toujours besoin d’un état prévu, de soumissionnaires autorisés, d’une validation avant changement, d’une capacité de chevauchement, d’une observation pendant la propagation et de critères de retour arrière.

DNSSEC ajoute une seconde machine à états. La RFC 4035 décrit comment les résolveurs valident les signatures et authentifient la preuve de non-existence, et comment les échecs peuvent produire un résultat non sécurisé ou bogus plutôt qu’une réponse normale.[20] L’enregistrement DS de la racine relie le parent au matériel de clé du TLD. Cette chaîne doit rester valide pendant que les clés sont générées, protégées, publiées, activées, renouvelées, retirées et récupérées.

dotSaarland publie une déclaration de pratiques DNSSEC pour.saarlandparmi ses documents de politique.[11][14] Une déclaration de pratiques définit les rôles et procédures prévus; elle ne prouve pas que chaque cérémonie ou rotation s’est déroulée exactement comme prévu. Sa valeur opérationnelle dépend de l’alignement entre la garde réelle des clés, la signature, la surveillance, la réponse aux incidents et les preuves d’audit avec le document.

L’automatisation peut rendre ce cycle de vie plus sûr. Elle peut calculer les identifiants de clé, comparer les jeux DS et DNSKEY, valider les signatures, détecter les expirations et simuler le comportement des résolveurs. Mais la capacité du système n’est pas la fiabilité du produit. Un validateur peut correctement détecter une incompatibilité après qu’un changement dangereux a déjà été propagé. Un flux de travail peut publier la mauvaise clé de façon cohérente si son inventaire source est faux. Une alerte peut se déclencher alors que le seul intervenant autorisé est injoignable.

La supervision n’est donc pas une couche optionnelle ajoutée quand l’automatisation échoue. C’est le mécanisme qui relie une sortie techniquement valide à l’intention. Le propriétaire du changement doit savoir à quel TLD, quelle clé, quel environnement et quelle fenêtre temporelle l’action appartient. Les réviseurs ont besoin de preuves indépendantes plutôt que d’une capture d’écran d’un statut vert. L’accès de récupération doit fonctionner lorsque le plan de contrôle normal est indisponible. Ces contrôles représentent un coût de supervision même lorsqu’aucun incident ne survient.

Le coût d’intégration apparaît là où les processus de clé et de zone du registre rencontrent la racine de l’IANA, le service d’arrière-plan, le système de surveillance et le chemin d’approbation organisationnel. Les formats de données peuvent être standardisés, mais l’autorité et le calendrier traversent toujours des frontières. Une mise à jour DS soumise trop tôt ou trop tard peut casser la chaîne. Un changement de serveur de noms peut passer les vérifications syntaxiques tout en pointant vers un système non prévu.

Une fenêtre de maintenance peut être techniquement adéquate mais entrer en conflit avec une dépendance de prestataire ou de registrar.

Le coût de maintenance inclut les cérémonies de clés de routine, les mises à jour logicielles, le renouvellement des certificats, le cycle de vie du matériel, la revue des accès, la revue des dépendances, les tests de sauvegarde et la révision des politiques. Aucune de ces activités ne crée une nouvelle fonctionnalité visible pour un titulaire. Elles préservent les conditions dans lesquelles l’espace de noms peut continuer à répondre.

Le coût de traitement des exceptions apparaît lorsque la séquence prévue ne tient pas. Un résolveur voit des données bogus tandis qu’un autre réussit. Une famille d’adresses échoue. Un enregistrement DS a changé mais une DNSKEY ne s’est pas propagée. Un prestataire signale un succès alors que la validation externe échoue. L’équipe doit déterminer si la cause est le cache, la route, la délégation, la signature, l’horloge, le logiciel, l’autorité ou l’erreur d’observation. Cette investigation ne peut pas se réduire à réessayer la même commande.

Le modèle de coût importe car un TLD calme peut rester exigeant sur le plan opérationnel. Un faible volume de changements visibles peut augmenter le risque que les procédures rares soient peu familières au moment nécessaire. Un opérateur mature traite les changements peu fréquents de racine et de DNSSEC comme des travaux à forte conséquence, les répète et conserve suffisamment de preuves pour qu’un intervenant puisse reconstituer l’intention.

WHOIS, RDAP et intégrité des données d’enregistrement

Les pages de l’IANA listentwhois.nic.saarlandetwhois.nic.ruhr, ainsi que les bases RDAP CentralNic enregistrées pour.saarlandet.ruhr.[2][3] Ces points de terminaison exposent une seconde surface de contrôle: les données qui aident les registrars, titulaires, équipes de sécurité, ayants droit, chercheurs et clients automatisés à identifier les objets de domaine et à comprendre leur statut.

RDAP est conçu comme un protocole structuré plutôt qu’un format texte orienté présentation. La RFC 9082 définit les modèles de requête, tandis que la RFC 9083 définit les objets de réponse, les avis, les liens, les statuts, les événements, les entités et le comportement en cas d’erreur.[18][19] Les réponses structurées peuvent améliorer l’interopérabilité car les clients peuvent traiter les champs de façon cohérente. C’est une capacité.

La fiabilité dépend encore de la découverte du service, de l’exactitude des objets, du calendrier de mise à jour, des contrôles de débit, de l’authentification le cas échéant, du traitement de la vie privée et des réponses d’échec significatives.

Une requête bornée pournic.saarlandetnic.ruhra renvoyé des objets dont les identifiants correspondaient aux domaines demandés. Cela confirme que ces chemins de requête ont répondu à ce moment-là. Cela ne prouve pas une couverture complète, une disponibilité continue, l’exactitude de chaque champ, ni l’adéquation à chaque usage d’enquête. Un seul objet réussi n’est pas une mesure de niveau de service.

Les données d’enregistrement ont plusieurs dimensions souvent réduites à « le point de terminaison fonctionne »:

  • Unicité:l’identifiant doit résoudre vers l’objet prévu plutôt que vers un enregistrement ambigu ou dupliqué.
  • Exactitude:les champs doivent refléter l’état faisant autorité et être mis à jour dans un temps contrôlé.
  • Provenance:les clients doivent savoir quel service et quelle autorité ont produit une réponse.
  • Métadonnées de sécurité:les statuts, événements, liens et avis ne doivent pas être silencieusement perdus ou déformés.
  • Continuité:le service doit rester découvrable et utilisable à travers la maintenance, la défaillance de dépendance et la transition d’opérateur.
  • Vie privée:la divulgation doit respecter la politique et les contraintes juridiques applicables sans rendre le protocole sémantiquement trompeur.

dotSaarland publie une politique WHOIS et de protection des données, une politique générale d’enregistrement et une politique anti-abus.[13][15][16] Ces documents soutiennent une limite utile: l’opérateur définit publiquement le traitement prévu des données d’enregistrement et liées aux abus. Ils ne montrent pas les volumes de cas, les temps de réponse, les résultats d’enquête, ni si un signalement particulier a été résolu correctement.

La séparation des rôles d’arrière-plan est particulièrement importante ici. Les pages de l’IANA pointent vers l’infrastructure RDAP CentralNic.[2][3] Il est raisonnable de signaler ce point de terminaison enregistré. Il n’est pas raisonnable d’en déduire une architecture privée, une relation de prestataire exclusive, un engagement de capacité ou un historique d’incidents. L’opérateur de registre reste le sponsor enregistré tandis que l’exécution technique peut traverser des frontières organisationnelles.

Cette frontière génère un travail d’intégration. Les transactions des registrars doivent produire le bon état de registre. Les changements de registre doivent apparaître dans les données d’enregistrement. Les codes de statut doivent avoir des significations cohérentes. Les décisions de confidentialité doivent être reflétées sans corrompre la structure du protocole. Les contacts anti-abus doivent acheminer les signalements vers un processus responsable. La découverte du service et les liens doivent rester valides lorsque l’infrastructure change.

L’automatisation peut comparer les enregistrements, détecter les événements obsolètes, valider le JSON et surveiller le comportement des points de terminaison. Elle ne peut pas décider de chaque question de divulgation, distinguer chaque signalement malveillant d’un signalement légitime, ni prouver le résultat de production d’un client. La revue humaine reste nécessaire pour les exceptions juridiques, les litiges d’identité, les demandes d’urgence, les preuves ambiguës et les changements dont la correction syntaxique cache une erreur sémantique.

Pour la direction, la question opérationnelle n’est pas simplement de savoir si RDAP a remplacé WHOIS. C’est de savoir si le système de données d’enregistrement préserve le sens à travers les protocoles, les prestataires, les politiques et le temps. Une interface moderne ne compense pas des enregistrements obsolètes, une autorité brisée ou une escalade injoignable.

Rôles distincts du registre, du registrar et de l’arrière-plan

La FAQ de dotSaarland indique que l’entreprise n’est ni un registrar ni un fournisseur d’accès Internet.[10] C’est une limite publique précieuse. Un registre maintient la base de données et les services faisant autorité d’un TLD. Les registrars fournissent des services d’enregistrement aux clients et communiquent avec le registre via des interfaces définies. Les fournisseurs d’accès Internet acheminent la connectivité. Ces rôles peuvent interagir étroitement sans devenir interchangeables.

La séparation des rôles aide à répartir le travail spécialisé et peut limiter les conflits. Elle signifie aussi qu’un problème visible par le client peut traverser plusieurs organisations. Un titulaire peut contacter un registrar au sujet du statut d’un domaine. Le registrar peut avoir besoin que le registre inspecte un objet ou une transaction. Le registre peut dépendre d’un opérateur d’arrière-plan. La résolution DNS peut impliquer l’infrastructure faisant autorité, les routes, les résolveurs récursifs et les réseaux locaux. Une affaire juridique ou d’abus peut nécessiter un chemin politique distinct.

Lorsque la propriété est floue, les équipes peuvent résoudre le mauvais problème. Un registrar peut réessayer une transaction que le registre a déjà acceptée. Un registre peut enquêter sur le DNS alors que le domaine est retenu par un statut défini en amont. Une équipe réseau peut diagnostiquer la joignabilité alors que la délégation est incorrecte. Une équipe politique peut recevoir un incident technique via une boîte aux lettres anti-abus. Le coût n’est pas seulement le retard; des actions répétées, non autorisées ou contradictoires peuvent aggraver l’état.

Une carte de responsabilité mature devrait répondre:

  • Qui possède l’enregistrement faisant autorité pour chaque objet?
  • Qui peut approuver un changement, et qui peut l’exécuter?
  • Quelle partie peut observer le système depuis l’extérieur de la frontière prestataire?
  • Quel chemin de contact fonctionne lorsque le portail normal ou le fournisseur d’identité échoue?
  • Quelles preuves sont nécessaires pour distinguer une panne de registre d’une défaillance de registrar, de résolveur, de route ou d’application?
  • Quelle partie communique avec les utilisateurs affectés sans exagérer le diagnostic?

Ces questions ne sont pas la preuve que dotSaarland présente une faiblesse particulière. Elles découlent de la chaîne de rôles visible. Les registres de l’IANA nomment le sponsor et exposent les services techniques; la FAQ de l’opérateur définit ce que l’entreprise n’est pas; les accords définissent les devoirs; les politiques publiques définissent le traitement prévu.[2][3][8][9][10][11] La division privée du travail reste hors du registre disponible.

La dépendance vis-à-vis d’un prestataire est souvent discutée comme un choix binaire entre externalisation et construction en interne. L’exploitation d’un registre montre pourquoi ce cadre est trop simple. Un arrière-plan spécialisé peut fournir un support protocolaire mature, de l’échelle, une pratique de sécurité et une continuité. Le remplacer peut être coûteux. Le conserver exige aussi que l’opérateur conserve l’autorité, des données portables, une observation indépendante et un chemin de transition testé.

La question pertinente d’enfermement n’est donc pas de savoir si un prestataire est utilisé. C’est de savoir si l’opérateur peut préserver la continuité de l’espace de noms si un contrat, un service, une structure de propriété, un système d’identifiants ou une plateforme technique change. Le dépôt de données, les interfaces documentées, les contacts à jour, l’autorité transférable et les registres indépendants réduisent le risque de transition. Ils ne rendent pas la migration indolore.

Quatre coûts d’exploitation récurrents

La surface visible du registre crée quatre catégories de coûts récurrents faciles à sous-estimer, car la majeure partie du travail se produit avant une défaillance publique.

Coût de supervision

Le coût de supervision couvre les personnes et les contrôles qui relient l’action automatisée à l’intention autorisée. Il inclut la revue des changements, la séparation des rôles, l’approbation des accès, l’interprétation des politiques, le commandement des incidents, la conservation des preuves et la confirmation depuis un point d’observation indépendant. Il inclut aussi le maintien d’un niveau de connaissance suffisant pour contester un outil qui signale un succès.

Pour deux TLD aux schémas répétés, la supervision doit empêcher qu’une hypothèse erronée ne se propage aux deux. Un réviseur doit pouvoir voir si un changement est intentionnellement partagé ou accidentellement copié. Un événement DNSSEC doit avoir une séquence explicite et un point de retour arrière. Un changement RDAP doit être revu pour le sens, pas seulement pour la validité du schéma.

Coût d’intégration

Le coût d’intégration couvre les interfaces entre dotSaarland, les registrars, les services d’arrière-plan, l’IANA, l’ICANN, la surveillance, le dépôt de données, les processus juridiques et les résolveurs externes. Les normes réduisent l’ambiguïté de format mais ne suppriment pas les transferts organisationnels. Les identifiants, horloges, fenêtres de maintenance, chemins de contact et règles d’approbation restent locaux.

Le transfert de.ruhrillustre pourquoi ce coût persiste. Le processus de transfert a enregistré l’identité du demandeur, les contacts et la conformité technique.[5] Après le transfert, le nouveau sponsor devait encore maintenir une relation de travail entre les enregistrements de racine, les services de registre, les opérations des registrars, les politiques et les devoirs de continuité. Un transfert achevé est le début d’un nouvel état d’exploitation, pas la fin de l’intégration.

Coût de maintenance

Le coût de maintenance couvre le travail nécessaire pour préserver la capacité: mises à jour logicielles et de dépendances, cycle de vie DNS et DNSSEC, renouvellement des certificats, garde des clés, entretien des bases de données, vérification des sauvegardes, dépôts de séquestre, changements de surveillance, compatibilité des interfaces registrars, mises à jour des politiques, accès du personnel et documentation.

Certaines maintenances ont de longs intervalles. Cela peut les rendre plus risquées, car le personnel et les systèmes peuvent changer entre deux répétitions. Un identifiant de récupération rarement utilisé peut expirer sans être remarqué. Un manuel opérationnel peut décrire une plateforme qui n’existe plus. Une sauvegarde peut se terminer pendant des années sans jamais être restaurée. La qualité de la maintenance se mesure par l’état utilisable, pas par la présence d’une tâche planifiée.

Coût de traitement des exceptions

Le coût de traitement des exceptions couvre les cas qui ne suivent pas le chemin normal: enregistrements contradictoires, propagation partielle, joignabilité d’une seule famille, signalements d’abus ambigus, contraintes de confidentialité, transactions de registrar échouées, contacts obsolètes, anomalies de rotation de clé, incidents de prestataire et autorité contestée. Ces cas consomment une attention expérimentée car la réponse correcte dépend du contexte.

Le traitement des exceptions exige aussi de la retenue. Toute sonde échouée n’est pas une panne. Tout signalement d’abus n’est pas valide. Tout symptôme client n’appartient pas au registre. Un opérateur a besoin d’une méthode pour réduire le périmètre sans écarter une défaillance réelle. Cette méthode doit préserver les horodatages, les enregistrements faisant autorité, les réponses observées, l’historique des changements et la propriété.

Les quatre coûts interagissent. Une maintenance faible crée des exceptions. Une intégration médiocre rend les exceptions plus difficiles à localiser. Une supervision insuffisante laisse les erreurs automatisées se propager. Un traitement faible des exceptions transforme une panne bornée en incident prolongé. Un achat qui ne chiffre que le chemin de transaction visible manque le travail nécessaire pour garder toute la surface de contrôle digne de confiance.

Continuité, dépôt de données et transition d’urgence

Les accords de registre de.saarlandet.ruhrincluent le dépôt de données, les services de données d’enregistrement, l’interopérabilité et la continuité, la transition d’urgence et les obligations de performance.[8][9] Le programme Emergency Back-End Registry Operator (EBERO) de l’ICANN décrit un mécanisme de protection des fonctions critiques du registre si un opérateur ne peut pas les fournir.[17] Ce ne sont pas des clauses de gouvernance abstraites. Elles définissent ce qui doit rester transférable lorsque l’exploitation ordinaire échoue.

Le dépôt de données répond à un problème de continuité élémentaire: un successeur ou un opérateur d’urgence peut avoir besoin des données actuelles du registre pour maintenir les fonctions critiques. Le dépôt n’aide que si les dépôts sont complets, à jour, correctement formatés, chiffrés et accessibles sous la bonne autorité. Un fichier qui existe mais ne peut pas être validé, déchiffré ou rapproché n’est pas une capacité de continuité.

La transition d’urgence dépend de même de plus que la désignation d’un prestataire de secours. L’autorité doit être claire. Les enregistrements de racine et de données d’enregistrement peuvent nécessiter des changements. Les contacts doivent fonctionner. Les identifiants et les données doivent être disponibles. L’opérateur d’urgence a besoin d’un contexte suffisant pour éviter d’introduire une nouvelle incohérence. Les parties prenantes ont besoin d’une communication qui distingue les fonctions techniques préservées des services métier plus larges qui peuvent rester indisponibles.

Le libellé de transition d’urgence des accords ne montre pas que dotSaarland a échoué ni qu’un opérateur d’urgence a été invoqué. Le programme EBERO appartient à cette analyse car il fixe une limite extérieure au type de service exploité.[17] Il démontre que la continuité est traitée comme une exigence de système partagé, et non uniquement comme une préférence commerciale privée.

La planification de continuité ordinaire devrait s’activer bien avant cette limite extérieure. Elle devrait traiter l’interruption du prestataire d’arrière-plan, la perte d’identifiants, l’indisponibilité du personnel, la corruption des données, la compromission DNSSEC, la défaillance de l’interface registrar, la défaillance des contacts, la restriction juridique et la transition d’opérateur planifiée. L’opérateur doit savoir quelles fonctions peuvent être isolées, lesquelles doivent être restaurées ensemble et quelles preuves établissent qu’un état de récupération fait autorité.

La portabilité est une mesure pratique du contrôle. L’opérateur peut-il récupérer les données actuelles du registre sous une forme utilisable? Peut-il établir l’autorité auprès d’un autre prestataire? Peut-il reproduire l’état du DNS et des données d’enregistrement? Peut-il préserver les mêmes identifiants et statuts? Peut-il vérifier les résultats de manière indépendante? Ces questions n’exigent pas un plan de changement de prestataire. Elles réduisent le risque qu’une transition future devienne une reconstruction incontrôlée.

La continuité a aussi une dimension temporelle. Une sauvegarde d’hier peut suffire pour une fonction et être inacceptable pour une autre. Les données DNS, les statuts de domaine, les transactions de registrar et les cas d’abus évoluent à des rythmes différents. Les objectifs de récupération devraient refléter la conséquence d’un état perdu ou obsolète plutôt que d’utiliser un chiffre générique unique.

L’image accompagnant cet article montre un équipement de stockage d’archives au CERN et n’est utilisée que comme contexte générique de continuité. Elle ne représente ni dotSaarland ni aucun système de registre. Cette limite importe car l’analyse de continuité doit s’appuyer sur des responsabilités vérifiables, et non sur une suggestion visuelle.

Registre des modes de défaillance

Les registres publics étayent une analyse concrète des modes de défaillance sans impliquer qu’aucun de ces événements se soit produit chez dotSaarland.

1. Dérive de l’identité du sponsor

L’entreprise, le contrat, le sponsor de la zone racine, les mentions légales et les contacts autorisés ne s’alignent plus. Une demande techniquement valide peut alors être retardée ou rejetée parce que l’autorité est ambiguë. La détection exige une comparaison entre les registres, et pas seulement une vérification de base de données.

2. Contact administratif obsolète

Une boîte aux lettres ou un contact nommé reste publié après un changement de responsabilité. L’exploitation courante peut continuer, masquant le problème jusqu’à ce qu’une approbation urgente ou un avis d’incident ne puisse atteindre la partie responsable.

3. Désignation de serveur de noms incorrecte

Un changement de zone racine désigne un serveur valide mais non prévu. La syntaxe et la joignabilité peuvent passer alors que l’autorité pointe vers le mauvais système. Une comparaison indépendante avec l’intention approuvée est nécessaire.

4. Incohérence des enregistrements glue

Une adresse de serveur de noms dans le domaine parent diffère de l’adresse attendue par l’opérateur. La résolution peut devenir dépendante du chemin, notamment pendant les changements ou les transitions de cache.

5. Défaillance de joignabilité IPv6 seule

L’IPv4 répond tandis qu’une route, une politique ou un chemin de service IPv6 échoue. Un moniteur monofamille signale un succès et rate des utilisateurs dont les résolveurs préfèrent ou exigent l’IPv6.

6. Erreur de changement corrélée sur deux TLD

Une procédure partagée applique la même valeur incorrecte à.saarlandet.ruhr. La standardisation multiplie l’erreur parce qu’une préparation ou une revue indépendante a été sautée.

7. Erreur d’ordre de publication DNSSEC

Un changement de DS ou de DNSKEY se produit dans le mauvais ordre. Des signatures peuvent exister, mais les validateurs ne peuvent pas construire une chaîne correcte et renvoient des résultats bogus.

8. Panne d’horloge ou d’expiration DNSSEC

Des signatures sont générées avec un horodatage invalide, expirent de façon inattendue ou sont évaluées sur des hôtes dont l’horloge est fausse. La zone peut être présente et joignable alors que la validation échoue.

9. Indisponibilité de la clé de récupération

Les identifiants normaux de signature ou du plan de contrôle sont perdus, et la clé de récupération ou le chemin d’accès ne peut pas être utilisé. Une documentation sans accès testé crée une fausse confiance.

10. Obsolescence des objets RDAP

Le point de terminaison renvoie un HTTP 200 et un JSON valide, mais les statuts, événements, liens ou données d’entité sont en retard sur l’état du registre faisant autorité. Le succès du transport masque une défaillance sémantique.

11. Rupture de découverte ou de lien RDAP

Les clients atteignent un service de base mais suivent un lien obsolète ou mal formé, ou un déménagement de service n’est pas reflété de manière cohérente. Les vérifications humaines par navigateur peuvent rater les défaillances des clients automatisés.

12. Divergence entre WHOIS et RDAP

Le WHOIS hérité et le RDAP structuré exposent des informations de statut ou d’événement matériellement différentes. Les utilisateurs prennent des décisions différentes selon le protocole interrogé.

13. Ambigüité des transactions de registrar

Un registrar expire après avoir soumis un changement et ne peut pas savoir s’il a été validé. Réessayer sans sémantique idempotente peut créer un travail contradictoire ou dupliqué.

14. Échec d’acheminement du contact anti-abus

Un signalement atteint une adresse surveillée par la mauvaise équipe, bloquée par un filtre, ou qui n’appartient plus à l’entité. Une politique publiée existe, mais le chemin opérationnel échoue.

15. Sur-caviardage de la vie privée

Les contrôles de divulgation suppriment des données ou des relations nécessaires à l’interprétation d’un objet, sans avis clairs ni accès légal alternatif. La réponse reste syntaxiquement valide mais opérationnellement trompeuse.

16. Inutilisabilité du dépôt de données

Les dépôts se terminent dans les délais mais échouent plus tard à la validation, au déchiffrement, au rapprochement de schéma ou à la restauration. L’existence d’un fichier est confondue avec la récupérabilité.

17. Panne du plan de contrôle du prestataire d’arrière-plan

Le DNS public peut continuer pendant que l’opérateur ne peut pas soumettre de changements, inspecter l’état ou coordonner les opérations des registrars. La disponibilité du plan de données masque la perte de contrôle.

18. Angle mort de mode commun de surveillance

Le service de registre et ses moniteurs dépendent du même réseau, fournisseur d’identité, résolveur ou région cloud. Tous deux échouent ensemble, et le tableau de bord montre le silence plutôt qu’une alerte.

19. Lacune d’autorité de transfert

Pendant une transition d’opérateur ou de prestataire, les anciens identifiants sont révoqués avant que la nouvelle autorité, les contacts, les données et l’observation soient pleinement utilisables. Chaque partie suppose que l’autre peut agir.

20. Inadéquation d’état de la relève d’urgence

Un opérateur d’urgence reçoit des données à jour pour un sous-système mais obsolètes pour le DNS, les transactions de registrar ou l’autorité de contact. Restaurer une fonction crée une incohérence ailleurs.

Ce registre n’est utile que si chaque élément a un propriétaire, un signal observable, une action de confinement, une méthode de récupération et une règle de conservation des preuves. Une liste de risques génériques n’améliore pas la fiabilité. L’objectif est de rendre les conditions exceptionnelles diagnostiquables avant que la pression temporelle n’encourage une action dangereuse.

Capacité, fiabilité et résultat client comme décisions distinctes

L’empreinte publique de dotSaarland étaye plusieurs énoncés de capacité. Les deux TLD sont délégués. Leurs pages IANA listent serveurs faisant autorité, enregistrements glue, WHOIS, RDAP et données de sponsor.[2][3] La racine porte le matériel de délégation DNSSEC. Les chemins RDAP ont renvoyé les identifiantsnic.*attendus lors d’une observation bornée. Des politiques existent pour l’enregistrement, DNSSEC, les données d’enregistrement, la vie privée et les abus.[11][13][14][15][16] Les accords définissent des obligations de continuité et d’urgence.[8][9]

Ces faits ne répondent pas aux questions de fiabilité produit telles que:

  • Quel pourcentage des requêtes mondiales ont réussi sur une période définie?
  • Quelle est la diversité des domaines de défaillance de routage et physiques?
  • À quelle fréquence les transactions de registrar ont-elles échoué ou nécessité une réparation manuelle?
  • À quelle vitesse les enregistrements obsolètes ont-ils été corrigés?
  • Les rotations DNSSEC se sont-elles terminées sans perte de validation?
  • Les données déposées peuvent-elles être restaurées dans un objectif testé?
  • Combien de temps prendrait une transition d’arrière-plan?

Répondre à ces questions exige des mesures longitudinales, des registres de changements, des observations indépendantes, des preuves d’incidents et des exercices de récupération. Aucun ne doit être inventé à partir des pages de délégation publiques.

Les résultats de production client exigent à nouveau un autre ensemble de preuves. Une entreprise régionale peut valoriser un nom en.saarlandou.ruhr, mais cette proposition ne prouve pas le trafic, la confiance, le chiffre d’affaires, la résilience, la performance de recherche ou les économies d’exploitation. Un résultat client nommé exigerait un cas divulgué, une base de référence définie, une méthode de mesure, une fenêtre temporelle et des limites causales. Cet article ne formule aucune affirmation de ce type.

Séparer les trois niveaux améliore la qualité des décisions. La capacité détermine si un service peut être envisagé. La fiabilité détermine s’il peut porter une dépendance de production. Le résultat client détermine s’il a apporté de la valeur dans un contexte particulier. Le marketing saute souvent de la capacité au résultat. La gouvernance d’ingénierie devrait exiger le maillon manquant du milieu.

Pour un opérateur de registre, un tableau de bord de direction utile se concentrerait sur les preuves qui préservent la couche de réalité:

  • contacts actuels de sponsor, juridique, technique et d’urgence;
  • rapprochement entre la zone racine et l’état faisant autorité;
  • joignabilité IPv4 et IPv6 indépendante;
  • preuves de validation et de rotation DNSSEC;
  • cohérence sémantique entre RDAP et WHOIS;
  • succès des transactions de registrar et gestion de l’ambiguïté;
  • joignabilité du chemin anti-abus et propriété des cas;
  • validation du dépôt et exercices de restauration;
  • cartes de dépendances de l’arrière-plan et des fournisseurs d’identité;
  • autorité de transition testée et accès de récupération.

Tous ces éléments ne devraient pas être publics, et les sources disponibles ne montrent pas le score de dotSaarland. La liste découle des systèmes et obligations visibles autour de l’entreprise. Elle fournit aussi une conversation d’achat plus pertinente que de demander si le registre utilise une plateforme à la mode ou possède un grand nombre de serveurs.

Ce que les responsables technologiques devraient demander

Les dirigeants qui évaluent un registre, un prestataire d’arrière-plan ou une autre dépendance de nommage partagée devraient poser des questions qui distinguent les enregistrements du contrôle opérationnel.

Premièrement, demander qui détient l’autorité à chaque frontière. L’organisation de parrainage, l’opérateur d’arrière-plan, le registrar, le prestataire de sécurité, le contact juridique et le soumissionnaire IANA peuvent ne pas être la même partie. Une carte des responsabilités doit identifier l’approbation et l’exécution séparément.

Deuxièmement, demander comment l’état prévu est rapproché de l’état en cours d’exécution. Un tableau de bord est insuffisant s’il ne rend compte que de sa propre plateforme. Les observations DNS, DNSSEC, RDAP, de routes et de données d’enregistrement indépendantes doivent être liées aux enregistrements approuvés et aux horodatages.

Troisièmement, demander comment les schémas partagés sont empêchés de devenir des défaillances partagées. Les deux TLD peuvent bénéficier de procédures communes, mais les changements critiques devraient avoir une préparation, une revue indépendante et la capacité de contenir une erreur à un seul espace de noms.

Quatrièmement, demander ce qui reste sous le contrôle de l’opérateur lorsqu’un plan de contrôle de prestataire est indisponible. Les réponses publiques peuvent continuer pendant que l’autorité de changement, la surveillance ou les opérations des registrars sont altérées. L’accès de récupération et les données portables doivent être testés, pas supposés.

Cinquièmement, demander comment la politique devient un traitement de cas. Les documents publiés sur les abus et la protection des données sont nécessaires, mais la préparation opérationnelle dépend de contacts joignables, de la propriété, des normes de preuve, de l’escalade et des exceptions légales.

Sixièmement, demander quels mécanismes de continuité ont réellement été exercés. La validation du dépôt, les tests de restauration, la récupération de clé, les exercices de contact et les répétitions de transition de prestataire révèlent plus que l’existence d’un langage contractuel.

Enfin, demander quelles preuves étayeraient une affirmation de résultat client. La réponse devrait identifier un client, une base de référence, une mesure, une fenêtre temporelle et des limites. Si elle ne le peut pas, traiter la déclaration comme une proposition de capacité plutôt que comme un résultat de production.

Ces questions ne présument pas un échec. Elles convertissent la surface de contrôle visible en une méthode de diligence raisonnable. L’objectif n’est pas d’exiger la divulgation d’une architecture sensible. C’est d’établir que l’autorité, les enregistrements, les systèmes en fonctionnement et la continuité peuvent être rapprochés par des personnes responsables.

Conclusion

La portée technologique de dotSaarland GmbH réside dans l’exploitation de deux espaces de noms régionaux délégués, et non dans une affirmation générique d’être une entreprise technologique. L’IANA, l’ICANN et les politiques publiques de l’opérateur montrent une entreprise responsable de.saarlandet.ruhrà travers les frontières de délégation, de données d’enregistrement, de DNSSEC, de politique et de continuité.[2][3][6][7][10][11]

Les registres montrent une capacité et une responsabilité réelles. Ils ne révèlent pas d’architecture privée, ne prouvent pas une fiabilité longitudinale et n’établissent pas de résultats de production client. Cette limite renforce l’analyse plutôt qu’elle ne l’affaiblit. Elle dirige l’attention vers ce qui peut être vérifié: identité, autorité, points de terminaison protocolaires, devoirs contractuels, politiques et état public en fonctionnement.

La charge opérationnelle est continue. La supervision maintient l’automatisation liée à l’intention. L’intégration aligne les organisations et les protocoles. La maintenance préserve les clés, les données, les logiciels, les contacts et l’accès de récupération. Le traitement des exceptions résout les cas où des systèmes apparemment corrects divergent. Le dépôt et la transition d’urgence fournissent une limite de sécurité extérieure, mais la continuité ordinaire reste la responsabilité quotidienne de l’opérateur.

La leçon plus large est qu’un espace de noms dépend d’enregistrements auxquels d’autres systèmes peuvent faire confiance et d’un code qui continue à les honorer. L’identité régionale peut expliquer pourquoi un TLD existe. La légitimité opérationnelle vient d’une délégation exacte, de métadonnées sécurisées, de données d’enregistrement utilisables, d’une autorité bornée et d’une continuité qui survit au changement.

Sources

[1] BTW Directory, « dotSaarland GmbH »:https://btw.media/en/directory/dotsaarland-gmbh

[2] Base de données de la zone racine de l’IANA, «.SAARLAND »:https://www.iana.org/domains/root/db/saarland.html

[3] Base de données de la zone racine de l’IANA, «.RUHR »:https://www.iana.org/domains/root/db/ruhr.html

[4] IANA, « Délégation du domaine.SAARLAND à dotSaarland GmbH »:https://www.iana.org/reports/c.2.9.2.d/20140328-saarland

[5] IANA, « Rapport de transfert pour ruhr »:https://www.iana.org/reports/tld-transfer/20220831-ruhr

[6] ICANN, « Accord de registre.saarland »:https://www.icann.org/en/registry-agreements/details/saarland

[7] ICANN, « Accord de registre.ruhr »:https://www.icann.org/en/registry-agreements/details/ruhr

[8] ICANN, « Texte de l’accord de registre.saarland »:https://itp.cdn.icann.org/en/files/registry-agreements/saarland/saarland-agmt-html-12dec13-en.htm

[9] ICANN, « Texte de l’accord de registre.ruhr »:https://itp.cdn.icann.org/en/files/registry-agreements/ruhr/ruhr-agmt-html-02oct13-en.htm

[10] dotSaarland, FAQ:https://nic.saarland/en/faq

[11] dotSaarland, Politiques:https://nic.saarland/en/policies

[12] dotSaarland, Mentions légales:https://nic.saarland/en/legal-notice

[13] dotSaarland, Politique générale d’enregistrement:https://nic.saarland/files/general_registration_policy.pdf

[14] dotSaarland, Déclaration de pratiques DNSSEC:https://nic.saarland/files/dps_saarland.pdf

[15] dotSaarland, Politique WHOIS et de protection des données:https://nic.saarland/files/whois_and_data_protection_policy.pdf

[16] dotSaarland, Politique anti-abus:https://nic.saarland/files/anti_abuse_policy.pdf

[17] ICANN, « Emergency Back-End Registry Operator (EBERO) »:https://www.icann.org/resources/pages/ebero-2013-04-02-en

[18] IETF, RFC 9082, « Format de requête du protocole d’accès aux données d’enregistrement (RDAP) »:https://www.rfc-editor.org/rfc/rfc9082.txt

[19] IETF, RFC 9083, « Réponses JSON pour le protocole d’accès aux données d’enregistrement (RDAP) »:https://www.rfc-editor.org/rfc/rfc9083.txt

[20] IETF, RFC 4035, « Modifications du protocole pour les extensions de sécurité du DNS »:https://www.rfc-editor.org/rfc/rfc4035.txt

[21] CentralNic RDAP, « nic.ruhr »:https://rdap.centralnic.com/ruhr/domain/nic.ruhr

[22] CentralNic RDAP, « nic.saarland »:https://rdap.centralnic.com/saarland/domain/nic.saarland

[23] Wikimedia Commons, « CERN Computer Center 04 »:https://commons.wikimedia.org/wiki/File:CERN_Computer_Center_04.jpg