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 NS
enregistrements 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 .LY
et 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 .US
serveurs 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
.XXX
dé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.
.eu
domaines appartenant au Royaume-Uni ne seront plus autorisés en raison du Brexit et, apparemment, ils seront fermés: dot-eu-is-going.uk