Qu'advient-il des TLD spécifiques à un pays dans une guerre impliquant ce pays?


30

J'essaie de savoir ce qui pourrait arriver et ce qui est susceptible de se produire - je suis basé au Royaume-Uni et possède des domaines britanniques ainsi que des domaines étrangers tels que les TLD russes et américains, par exemple: domain.co.uk, domain .ru, domain.us.

Je ne comprends pas bien comment fonctionne DNS, mais ce que j'essaie de savoir, c'est si je possède des TLD étrangers et qu'ils sont hébergés sur un serveur qui est dans mon propre pays, l'accès à l'URL peut-il être arrêté ou restreint le pays hôte du TLD, et si cela est possible, y a-t-il une probabilité que cela se produise en cas d'implication dans une guerre ou de rupture politique majeure entre les pays?

  • Est-il physiquement possible qu'un pays puisse restreindre ou interdire l'accès à leurs TLD spécifiques de certains ou de tous les autres pays? (Par exemple, les États-Unis et la Russie en guerre, est-il physiquement possible d'empêcher la Russie d'accéder à leurs TLD .us?)
  • Est-il probable que les TLD soient restreints ou interdits de quelque manière que ce soit? Serait-il avantageux pour un pays de le faire? (Par exemple, le Royaume-Uni et les États-Unis en guerre, les États-Unis auraient-ils intérêt à interdire au Royaume-Uni d'accéder à leurs TLD .uk?)
  • Un pays restreindrait-il son propre pays d'accéder aux TLD d'autres pays? (Par exemple, le Royaume-Uni en guerre contre la Russie, le Royaume-Uni aurait-il une raison d'interdire l'accès aux sites Web russes?)

5
Un sujet quelque peu connexe: les .eudomaines appartenant au Royaume-Uni ne seront plus autorisés en raison du Brexit et, apparemment, ils seront fermés: dot-eu-is-going.uk
a_horse_with_no_name

1
@a_horse_with_no_name Page principale officielle du registre sur toutes les informations relatives au Brexit: eurid.eu/en/register-a-eu-domain/brexit-notice . TL; DR: la situation n'est pas claire, ne l'a jamais été depuis des mois, ne le sera probablement jamais non plus pour les mois à venir
Patrick Mevzek

@a_horse_with_no_name - intéressant de voir que le lien a maintenant des dates - le 1er janvier, le domaine .eu se ferme apparemment pour les résidents britanniques ... Comment est-ce possible quand le Brexit n'a toujours pas été approuvé?
5Diraptor le

Réponses:


35

J'essaie de savoir si je possède des TLD étrangers et qu'ils sont hébergés sur un serveur qui est dans mon propre pays, l'accès à l'URL peut-il être arrêté ou restreint par le pays hôte du TLD

La réponse courte est oui (mais s'il vous plaît ne pensez pas seulement aux URL, c'est le web, mais à tout type de services, comme le courrier électronique, la VOIP, etc.)

Voici pourquoi. La racine DNS IANA délègue chaque TLD à certains registres. Les gTLD sont délégués par des registres sous contrat avec l'ICANN et les registres ccTLD sont délégués aux gouvernements des pays concernés, qui décident chacun techniquement de la façon dont le ccTLD est géré (il existe de nombreux modèles: parfois il est toujours géré par le gouvernement lui-même, parfois il l'est sous-traite à une organisation à but non lucratif et parfois elle est simplement mise en adjudication pour la meilleure offre, y compris les entreprises).

Ces registres gèrent des serveurs de noms dans lesquels chaque domaine enregistré sous le TLD est délégué, via des enregistrements NS.

Autrement dit, sans cache, chaque accès à un nom de domaine dans un TLD, pour sa résolution, arrive à un moment donné au serveur de noms du TLD. Par conséquent, théoriquement, ils pourraient répondre à n'importe quoi et transférer votre domaine vers autre chose.

Ceci est limité car le DNS a un cache, donc le serveur de noms TLD ne sera pas interrogé à chaque résolution, seulement pendant un certain temps.

Ce processus est facilement visible en utilisant dns +trace, comme:

dig www.openstreetmap.fr +trace @1.1.1.1 +nodnssec

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.openstreetmap.fr +trace @1.1.1.1 +nodnssec
;; global options: +cmd
.           6313    IN  NS  a.root-servers.net.
.           6313    IN  NS  b.root-servers.net.
.           6313    IN  NS  c.root-servers.net.
.           6313    IN  NS  d.root-servers.net.
.           6313    IN  NS  e.root-servers.net.
.           6313    IN  NS  f.root-servers.net.
.           6313    IN  NS  g.root-servers.net.
.           6313    IN  NS  h.root-servers.net.
.           6313    IN  NS  i.root-servers.net.
.           6313    IN  NS  j.root-servers.net.
.           6313    IN  NS  k.root-servers.net.
.           6313    IN  NS  l.root-servers.net.
.           6313    IN  NS  m.root-servers.net.
;; Received 431 bytes from 1.1.1.1#53(1.1.1.1) in 64 ms

fr.         172800  IN  NS  f.ext.nic.fr.
fr.         172800  IN  NS  d.ext.nic.fr.
fr.         172800  IN  NS  g.ext.nic.fr.
fr.         172800  IN  NS  e.ext.nic.fr.
fr.         172800  IN  NS  d.nic.fr.
;; Received 357 bytes from 192.33.4.12#53(c.root-servers.net) in 62 ms

openstreetmap.fr.   172800  IN  NS  a.dns.gandi.net.
openstreetmap.fr.   172800  IN  NS  c.dns.gandi.net.
openstreetmap.fr.   172800  IN  NS  b.dns.gandi.net.
;; Received 110 bytes from 194.0.36.1#53(g.ext.nic.fr) in 68 ms

www.openstreetmap.fr.   10800   IN  CNAME   osm146.openstreetmap.fr.
osm146.openstreetmap.fr. 10800  IN  A   217.182.186.67
openstreetmap.fr.   10800   IN  NS  b.dns.gandi.net.
openstreetmap.fr.   10800   IN  NS  a.dns.gandi.net.
openstreetmap.fr.   10800   IN  NS  c.dns.gandi.net.
;; Received 147 bytes from 217.70.179.1#53(c.dns.gandi.net) in 81 ms

Vous pouvez voir chaque étape de manière récursive, à gauche l'étiquette (racine, puis le TLD, puis le domaine, puis le nom d'hôte final) et à droite dans les NSenregistrements les serveurs de noms faisant autorité à chaque étape, d'abord ceux de l'IANA pour la racine, puis ceux pour le TLD, puis celui pour le nom de domaine.

À chaque étape, un serveur de noms peut mentir et fournir une fausse réponse, comme tout élément actif du chemin pourrait modifier la requête ou la réponse. DNSSEC fournit certaines protections contre cela, mais tout d'abord, tous les domaines ne sont pas protégés avec DNSSEC (très peu d'entre eux en fait), et ensuite cela n'a pas pu résoudre un TLD "voyou".

Ceci est la partie technique. Vos autres questions sont davantage un problème politique. Mais notez que pour ces mêmes raisons, certains pays ont décidé, ou du moins annoncé, qu'ils souhaitent exploiter leur propre racine DNS. La raison en est que la racine actuelle est sous la supervision des États-Unis (ce qui est un point compliqué qui pourrait être débattu à l'infini, donc je ne développerai pas ce point spécifique ici et maintenant), et certains pays craignent que les États-Unis puissent "censurer" un TLD de cette façon. , en particulier certains pays considérés comme ennemis par le gouvernement américain. Cependant, de nombreux acteurs estiment que si cela devait se produire un jour, ce serait métaphoriquement au même niveau qu'une attaque nucléaire et fragmenterait Internet d'une manière qui pourrait ne jamais être recousue.

Notez par exemple ce cas: certains plaignants ont poursuivi pour obtenir des indemnités pour les victimes après une attaque terroriste et ont demandé (mais cela a été refusé) pour que cela prenne le contrôle de ccTLD qu'ils considéraient comme la source du terrorisme. Voir cet article pour une partie de cette histoire: " Tuer .IR pour indemniser les victimes terroristes: les OIG à la rescousse? "

L'autre point important à comprendre également en premier est que dès que vous achetez un nom de domaine dans un TLD, vous êtes lié (même si vous ne le lisez pas quand vous le devriez) par les réglementations de ce TLD, qui dictent les conditions d'éligibilité et tout d'autres contraintes concernant l'enregistrement et la conservation d'un nom de domaine. Pour les ccTLD, cela inclut spécifiquement le respect des lois du pays. Et comme certains ccTLD sont commercialisés comme de jolis TLD pour les jeux de noms de domaine, certaines personnes ne s'en rendent pas compte. Par exemple, la tendance était à un moment donné .LY, et aussi drôle que vous voulez le regarder pour faire un joli nom de domaine, c'est toujours le ccTLD du pays "Lybia" et donc vous devez suivre ses lois et la charia. Certaines entreprises ont perdu ou risqué de perdre leur nom de domaine pour ces mêmes raisons. Voir par exemple:Problèmes dans les domaines intelligents du domaine: Bit.ly et d'autres risquent de perdre leur Swift.ly "ou" L'arrêt du domaine libyen n'est pas une menace, insiste bit.ly "

Puisque nous sommes en marche .LYet que vous avez parlé des guerres, ces articles pourraient vous donner un aperçu de ce que les guerres peuvent faire pour les noms de domaine (TLD) ou tout simplement se débattre autour des contrôles:

Mais remarquez aussi que des changements radicaux peuvent arriver aux ccTLD, même sans guerres. Ceci est un exemple (in) célèbre: " L'histoire du domaine national slovaque volé .SK "

Revenons à vos questions spécifiques, mais notez qu'elles impliquent une partie des réponses subjectives.

Est-il physiquement possible qu'un pays puisse restreindre ou interdire l'accès à leurs TLD spécifiques de certains ou de tous les autres pays? (Par exemple, les États-Unis et la Russie en guerre, est-il physiquement possible d'empêcher la Russie d'accéder à leurs TLD .us?)

Oui, vous pourriez techniquement imaginer que les .USserveurs de noms refusent de répondre aux demandes provenant de lieux géographiques spécifiques dans le monde. Cependant, cela serait loin de 100% pour de nombreuses raisons: la géolocalisation IP n'est pas une science difficile avec une fiabilité à 100%, les DNS ont des caches, il est facile d'utiliser un VPN, n'importe qui (y compris les personnes des pays concernés) pourrait utiliser un résolveur ouvert , comme Google Public DNS ou CloudFlare one ou Quad9 one (en fait, cela a été utilisé dans le passé pour contrer la censure de l'État, voir par exemple: " Google DNS Freedom Fight: 8.8.8.8 "), etc.

Est-il probable que les TLD soient restreints ou interdits de quelque manière que ce soit? Serait-il avantageux pour un pays de le faire? (Par exemple, le Royaume-Uni et les États-Unis en guerre, les États-Unis auraient-ils intérêt à interdire au Royaume-Uni d'accéder à leurs TLD .uk?)

Comme écrit ci-dessus, techniquement, la racine IANA répertorie le TLD actif aujourd'hui. Techniquement, cela pourrait changer et change, mais dans le cadre de processus spécifiques, comme le cycle des nouveaux gTLD de l'ICANN en 2012. Quant aux changements dans les ccTLD (puisque les pays peuvent décider de modifier divers détails sur leur TLD, y compris le responsable technique), ils doivent suivre " Délégation ou transfert d'un domaine de premier niveau de code pays (ccTLD) ".

Maintenant, outre la partie technique, il y a la "politique" au sens générique:

  • L'IANA est actuellement plus une "fonction" qu'une structure. La structure est PTI (Public Technical Identifiers) qui est actuellement affilié à l'ICANN. Voir https://www.iana.org/about pour plus de détails
  • L'ICANN est une organisation à but non lucratif, constituée en Californie, aux États-Unis. Il y a eu récemment un ensemble de changements profonds, sous la pression de nombreux gouvernements étrangers, afin qu'il puisse être considéré comme plus "international" et moins sous le contrôle direct du gouvernement américain, comme cela s'est produit par le passé (voir le fameux fiasco autour de la .XXXdélégation) . Maintenant, il n'y a plus de contrat spécifique entre l'ICANN et le gouvernement américain spécifiquement pour les fonctions IANA.
  • l'opérateur technique du serveur de noms racine A qui est le maître de tous dont chaque autre serveur de noms racine est "purement" une copie est géré par VeriSign, une société américaine sous contrat direct avec le gouvernement américain.

Un pays restreindrait-il son propre pays d'accéder aux TLD d'autres pays? (Par exemple, le Royaume-Uni en guerre contre la Russie, le Royaume-Uni aurait-il une raison d'interdire l'accès aux sites Web russes?)

Il s'agit d'une forme de censure DNS qui cible davantage les serveurs de noms récursifs que ceux faisant autorité. Oui, les pays peuvent ordonner aux opérateurs locaux d'interdire l'accès (plus précisément: la résolution) à certains sites Web spécifiques. Cela se produit partout: USA, Allemagne, France, Chine, Australie, etc. (pour être honnête, je ne suis pas sûr que vous puissiez trouver beaucoup de pays sans aucune censure comme ça) pour diverses raisons basées sur la politique locale et parce que certains sites Web sont réputés illégaux pour être consultés dans un pays donné.

Mais comme toute forme de censure, elle peut être éludée par des mécanismes plus ou moins compliqués. Comme dans les exemples ci-dessus, lorsque dans certains pays les serveurs de noms récursifs locaux ont été interdits pour résoudre certains prénoms, des personnes ont écrit 8.8.8.8(adresse IPv4 de Google Public DNS Resolver) afin que quiconque puisse reconfigurer son système pour l'utiliser au lieu du local (mentir). ) Résolveur DNS, car, évidemment, le pays concerné ne pouvait pas imposer à Google de modifier ses réponses pour certaines des requêtes. Dans d'autres cas dans le passé, où même Internet en tant que transport était perturbé, certains FAI dans d'autres pays fournissaient des lignes téléphoniques attachées à des modems vers lesquels vous pouviez composer pour avoir à nouveau accès à Internet, même si tous les FAI locaux étaient fermés.

La censure DNS concerne actuellement plus souvent certains noms de domaine spécifiques, dans plusieurs TLD, mais la base serait exactement la même pour censurer un TLD entier.

Cet article technique pourrait vous donner de nombreuses informations sur la façon dont cela est fait et comment il est contourné: " La censure DNS (DNS Lies) telle que vue par RIPE Atlas "

Ce seul point de censure DNS / Internet pourrait être élargi de nombreuses manières pour détailler tout ce qui s'est passé dans le passé, mais j'espère que les points précédents vous donnent déjà des idées sur ce qui est techniquement possible et comment cela s'intègre dans l'ensemble du cadre politique / gouvernance.


3

C'est une question intéressante. Est-il possible pour un pays de refuser l'accès aux sous-domaines de leur ccTLD? Oui. Est-il probable, même à distance, qu'ils le fassent? Non.

Si quelqu'un navigue vers vos adresses domain.ru, leurs résolveurs iront finalement vers les serveurs de noms pour le ccTLD .ru et demanderont «où sont les serveurs de noms pour domain.ru?

Selon les normes internationales, le DNS est un protocole équitable, ce qui signifie que chaque question reçoit une réponse. Il est possible que les serveurs TLD .ru disent «aha! cette adresse IP vient du Royaume-Uni et nous ne leur dirons pas où se trouve le serveur de noms domain.ru, mais cela ne se passerait pas bien pour eux.

En fin de compte, la direction de tout est contrôlée par les serveurs racine. Il s'agit de 13 serveurs racine indépendants, exploités par 12 organisations indépendantes, qui travaillent ensemble pour maintenir l'égalité d'accès au DNS. Si cela devait vraiment se produire, les serveurs racine, en collaboration avec les organismes de normalisation internationaux, pourraient littéralement remplacer les serveurs russes par quelqu'un d'autre. Autrement dit, au lieu de dire «allez trouver .ru là-bas en Russie», ils pourraient dire «allez trouver .ru ici en Urkraine».

Bien que cela soit possible, cela va vraiment à l'encontre de tout comportement international et est extrêmement improbable.

modifié: changer le libellé pour clarifier non pas 13 organisations indépendantes, mais 13 serveurs racine.


1
Juste pour indiquer à quel point il est peu probable qu'un ccTLD soit désactivé: .SUle ccTLD pour l'Union soviétique, un pays qui n'existe pas depuis plus d'un quart de siècle, est toujours bien vivant.
Calle Dybedahl

Réponse très intéressante et détaillée, merci! Cela signifie-t-il que le seul contrôle dont dispose le pays hôte est le contrôle des serveurs qui se trouvent dans ce pays? Et si mon domaine .ru pointait vers un serveur qui était au Royaume-Uni, alors la Russie n'a aucun moyen d'interrompre le service?
5Diraptor

Je ne peux pas garantir sa précision, mais j'ai
5Diraptor

Pour nitpick, il y a 13 serveurs racines logiques mais pas 13 organisations. Par exemple, deux d'entre eux (A et J) sont gérés par VeriSign. Voir root-servers.org qui indique clairement: En date du 2018-06-15, le système de serveur racine se compose de 928 instances exploitées par les 12 opérateurs de serveur racine indépendants.
Patrick Mevzek

3
@CalleDybedahl .suest un exemple célèbre mais certainement pas la règle. Vous avez aujourd'hui .sket .czaprès la scission, et avez .csdisparu. Idem pour .yupar qui disparaissaient à remplacer .si, .hr, .rset .ms.
Patrick Mevzek

0

J'essaie de savoir si je possède des TLD étrangers et qu'ils sont hébergés sur un serveur qui se trouve dans mon propre pays, l'accès à l'URL peut-il être arrêté ou restreint par le pays hôte du TLD, et si cela est possible, y a-t-il une probabilité que cela se produise en cas d'implication dans une guerre ou de rupture politique majeure entre les pays?

C'est possible et c'est déjà arrivé sans guerre.

La Chine possède le TLD .cn. Il était ouvert sur le monde. Si le gouvernement chinois souhaite supprimer un domaine .cn parce qu'il n'aime pas certains contenus, il pourrait modifier l'enregistrement DNS de ce domaine .cn.

Cependant, ce n'était pas un moyen parfait pour le gouvernement chinois de le gérer, car qui sait quel contenu est servi à partir de quel domaine .cn. Un jour, le gouvernement a donc décidé que tous les domaines .cn devaient pointer physiquement vers des adresses IP en Chine. (Si vous possédiez un domaine .cn pointant vers une adresse IP hors de Chine à l'époque, ils vous ont donné le temps de migrer ou d'arrêter votre domaine.)

En forçant les gens à héberger physiquement les domaines .cn en Chine, le gouvernement chinois peut inspecter les services fournis par chaque domaine et le contenu de chaque domaine. Cela pourrait même obliger les gens à installer une porte dérobée sur leurs serveurs comme une condition pour mettre n'importe quel serveur dans un centre de données. (Il a essayé cette idée pendant un certain temps.)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.