DNS over HTTPS est un protocole permettant de chiffrer les requêtes DNS et protéger leur intégrité. En théorie, il devient impossible de suivre ce qui a été consulté ou de dévier le trafic. Une solution intéressante sur le papier, mais qui pose question dans ses premières implémentations. On vous explique pourquoi.
Ces dernières années, le respect de la vie privée et la sécurité des données sont devenus des enjeux majeurs. Ce, tant pour résister à des attaques de pirates que pour contrer un espionnage dont les États ne se cachent pas.
Si l'on pense souvent au chiffrement des fichiers, des emails, des flux de communication via les accès sécurisés (HTTPS) et des protocoles comme TLS, on en oublie parfois des briques moins visibles, mais tout aussi essentielles. C'est le cas du DNS (Domain Name System), autre grand maillon de la chaîne permettant de convertir des noms de domaine facile à retenir en adresses IP permettant aux équipements réseau de communiquer entre eux.
Créé il y a près de 40 ans, utilisé au quotidien par des milliards d'internautes, son fonctionnement fait débat. Car même si vous naviguez sur des sites de manière sécurisée (HTTPS), rien n'empêche la structure hébergeant les serveurs DNS que vous utilisez de savoir précisément les sites que vous avez consultés.
Le DNS : un élément simple au centre de nombreux enjeux
Dans la pratique, qu'est-ce qu'un résolveur DNS ? Lorsque vous voulez accéder à un site web, vous tapez son adresse (URL) dans la barre principale de votre navigateur. Pour ce faire, votre machine doit savoir à quel serveur s'adresser. Pour cela, elle doit connaître son adresse IP. Fournir cette réponse, c'est le rôle de l'application que l'on appelle résolveur DNS.
Elle a été pensée pour être simple et peu gourmande en ressource. Il suffit ainsi de lui envoyer une requête (passant par le port 53) pour avoir une réponse. Des outils permettent de le faire simplement avec un résultat plus ou moins détaillé. Par exemple nslookup sous Windows ou host sous Linux (vous pouvez également utiliser ceux de dnsutils) :
La réponse du résolveur DNS d'une Livebox pour le site du gouvernement, avec le détail de ses alias
Dans la pratique, lorsqu'une requête est effectuée, le résolveur regarde dans son cache, s'il connaît déjà la réponse. Si ce n'est pas le cas, il remonte la chaîne du nom de domaine, s'adressant d'abord aux serveurs racines (.), qui le renverront ensuite vers celui du domaine de premier niveau (TLD, « fr » et donc l'AFNIC dans notre exemple), puis de second niveau (SLD, « gouvernement » ), le sous-domaine (« www »), etc. En bout de chaîne, c'est en général l'hébergeur qui répond.
Notez que cela ne concerne pas que les sites que vous visitez, mais également pour toutes les requêtes des éléments qu'ils intègrent au sein de leurs pages : images, scripts, publicités, etc.
Pour l'internaute, cette brique logicielle est le plus souvent invisible puisqu'elle est fournie par la box de son opérateur. Lorsque vous vous y connectez pour accéder à internet elle attribue automatiquement une adresse IP à votre machine via le protocole DHCP, puis se déclare comme passerelle et serveur DNS de référence.
L'intérêt pour l'utilisateur, c'est qu'il n'a rien à faire. Le problème, c'est que ces DNS peuvent être « menteurs ». C'est à dire renvoyer une réponse fausse. C'est notamment le cas lorsque la justice demande le blocage d'un site par les fournisseurs d'accès : pour une liste de noms de domaines, ils ne renvoient pas l'adresse IP correspondante.
Une procédure récemment mise en application pour des sites de streaming par exemple. Mais parfois, il y a des ratés. Comme lorsqu'Orange avait bloqué par erreur de très nombreux sites en 2016, redirigeant ses clients vers la fameuse page à la « main rouge » devant s'afficher à la place de sites à caractère terroriste.
Dès lors, on conseille le plus souvent d'utiliser d'autres résolveurs DNS que ceux des FAI, non menteurs. Il y a bien ceux de Google, mais cela revient à faire connaître toute votre navigation au géant américain. Même s'il affirme ne pas exploiter ces données, certains sont méfiants et se tournent vers French Data Network (FDN), 1.1.1.1 (Cloudflare) ou Quad9.
Vous pouvez également installer simplement votre propre résolveur DNS, sur votre machine, un serveur ou un NAS, etc. Mais d'une certaine manière, cela ne fait que déplacer le problème, des requêtes étant tout de même effectuées vers des serveurs tiers (racine, premier et second niveau, etc.) lorsque le cache local n'est pas utilisé.
Le besoin de chiffrement du DNS
Mais dans tous les cas, le DNS fait face à un problème qui tient à sa conception : les requêtes ne sont pas chiffrées et circulent donc en clair sur l'ensemble de la chaîne. On peut certes minimiser les échanges, mais cela reste un problème.
Car elles peuvent être interceptées (notamment sur un réseau Wi-Fi ouvert par exemple), modifiées, et sont connues par les serveurs qui auront à vous répondre. À ce titre, la position des fournisseurs d’accès vers qui la police peut se tourner en cas d’enquête pour fournir ces informations diffusées en clair, pose particulièrement question.
Ces dernières années, de multiples initiatives ont été lancées pour renforcer la sécurité de cette brique essentielle. Il y a bien entendu DNSSEC, qui permet d'ajouter une signature cryptographique aux enregistrements DNS, permettant d'en vérifier la validité. Mais même après quelques années, sa mise en place reste minoritaire.
La conférence DNS et vie privée de Shaft
Depuis, d'autres initiatives ont vu le jour, comme DNSCrypt, GNUnet, DNS over TLS (DoT), etc. Mais aucune n'a été largement implémentée. C'est là qu'intervient DNS over HTTPS (DoH), qui semble désormais faire consensus. Proposant d'encapsuler les requêtes DNS dans une requête HTTPS, qui est donc chiffrée, il a de nombreux avantages.
Mais bien qu’elle soit en théorie un apport majeur à la vie privée, ce n’est pas une panacée.
DoH, comment ça marche ?
Cette solution est récente, ayant fait l’objet d’une standardisation par l’IETF (Internet Engineering Task Force) en octobre 2018 (RFC 8484). Le mécanisme décrit comment les requêtes et réponses sont chiffrées, encapsulées dans un flux HTTPS.
Une solution intéressante puisqu'elle exploite des technologies assez basiques et maitrisées. Surtout, DoH se repose sur le port 443 utilisé pour les connexions sécurisées, très rarement bloqué. Là où DoT nécessite l'accès au port 853. Elle profite également d'autres avantages comme l'assurance de l'origine de la réponse et de sa non-altération. DoH permet ainsi de se prémunir de toute attaque impliquant un tiers, de l’homme du milieu aux middleboxes.
Là aussi, on peut en vérifier le fonctionnement via des outils simples, comme les versions récentes de curl :
curl -v --doh-url https://dns.quad9.net/dns-query www.gouvernement.fr
Dans cet exemple, on demande au serveur DoH de Quad9 de nous donner le résultat pour le site du gouvernement. D'autres résolveurs peuvent être utilisés, une liste est proposée par ici ou par là. La requête est envoyée, via HTTP/2 (obligatoire pour DoH) avec TLS 1.3. On reçoit ensuite une longue réponse, dont les éléments suivants :
* DOH Host name: www.gouvernement.fr
* TTL: 175 seconds
* DOH A: 8.249.51.252
* DOH A: 8.252.38.252
* DOH A: 67.26.251.252
* CNAME: www.premier-ministre.gouv.fr
* CNAME: sni.www.gouvernement.fr.c.footprint.net
* CNAME: www.premier-ministre.gouv.fr
* CNAME: sni.www.gouvernement.fr.c.footprint.net
Quad9 permet aussi d'effectuer la requête dans un simple navigateur, avec un résultat au format JSON :
https://dns.quad9.net:5053/dns-query?name=www.gouvernement.fr
Dans ces deux cas on retrouve le résultat obtenu via la méthode classique, avec une différence de taille : notre FAI ne voit ici passer qu'un échange chiffré, sans savoir pour quel site une requête DNS est effectuée.
Reste tout de même un problème dans cette façon de faire : dans le cas ci-dessus, Quad9 sait ce qui lui a été demandé, par quelle machine. De plus, utiliser un DNS over HTTPS n'assure que du chiffrement et de l'intégrité, pas du comportement et de l'éthique du résolveur. Si ce dernier décide de collecter des données, de mentir, DoH n'y changera rien.
La confiance est donc essentielle. D'autant que tout semble indiquer que les internautes profiteront de cette solution d'une manière assez inhabituelle : dans les navigateurs, tels que Chrome et Firefox. Ces derniers passeront ainsi outre la configuration de la machine pour exploiter DoH via des serveurs tiers de leur choix. Une façon de faire qui pose question.
Un sujet que nous aborderons dans la suite de ce dossier, où nous évoquerons également les méthodes pour activer DoH.
Notre dossier sur DNS over HTTPS :
- Qu'est-ce que DNS over HTTPS (DoH), qu'est-ce que cela peut vous apporter ?
- DNS over HTTPS (DoH) : au-delà de Firefox, une « question de confiance »
- DNS over HTTPS (DoH) : pour Stéphane Bortzmeyer, « le diable est dans les détails »
- Comment activer DNS over HTTPS (DoH) ? (à venir)
Commentaires (77)
#1
Tres intéressant merci. Vivement la suite.
#2
une question cependant : dans la commande “curl -v –doh-url https://dns.quad9.net/dns-query www.gouvernement.fr”, il y’a bien une résolution DNS classique de dns.quad9.net qui est effectué ?
Le fournisseur DNS initial est donc au courant qu’on va chez quad9.net.
Même si il ne sait pas que c’est pour aller sur www.gouvernement.fr, cela ne fait t’il pas que déplacer le problème ou apposer un pansement sur une jambe de bois ?
#3
“Quad9 sait ce qui lui a été demandé, par quelle machine”
Est-ce que DoH + proxy ne serait pas la solution?
Le proxy lui ne verra qu’un échange chiffré et à l’inverse le résolver n’aura que l’ip de la machine faisant serveur proxy. Ca pourrait le faire non ?
#4
On dit « la tablette de Michel », non ?
#5
#6
On déplace le tiers de confiance, au risque de le centraliser.
#7
Ton serveur racine, TLD/SLD c’est pas déjà un point de centralisation ? Tu sembles confondre deux soucis : DoH en tant que tel (qui est une technologie intéressante, n’ajoutant pas de centralisation spécifique) et l’implémentation dans les navigateurs (sujet sur lequel on reviendra dans le prochain papier).
#8
#9
Non, on dit « la main de ma sœur dans la culotte d’un zouave », mais on dit « la tablette à Michel » ou « le frère à mon beau frère ».
#10
Le fournisseur initial sait que tu as ouvert l’annuaire, mais ne sait pas ce que tu as cherché :)
#11
Sur un Pi-hole cela fonctionne très bien avec Cloudflared –>https://docs.pi-hole.net/guides/dns-over-https/
:)
#12
Bonsoir,
Parallèlement j’ai vu qu’il y a DNS over TLS, ce qui serait directement au niveau OS (je préfère par rapport au navigateur) ; est-ce que quelqu’un sait si c’est un sujet qui avance par exemple pour un support par Windows et les fournisseurs de DNS publics connus ?
Merci
#13
Par contre ça doit parasiter certain contrôle de flux passif qu’on peu trouver sur des UTM comme Fortigate non ?
#14
Le truc, c’est que DoH c’est bien quand on surf depuis un état sous surveillance, mais c’est moins bien quand on surf depuis un pays “libre”.
On se plaint de la centralisation d’Internet, mais quand on a un protocole décentralisé, qui fonctionne parfaitement bien, on invente des technos pour recentraliser ca chez QuadNine ou chez CloudFlare…
Déjà que cloudflare fait transiter la moitier du web par ses serveurs (étude au doigt mouillé, mais l’idée est là) et peut donc savoir ce que vous consultez, maintenant, les quelques boites comme cloudflare, capable d’héberger des serveurs DoH qui sont bien plus gourmand que du DNS classique, vont aussi récupérer le noms des sites qu’ils ne protègent pas. En terme de BigBrother, je crois qu’on tient le vainqueur.
Le bon, c’est qu’on arrêtera de filer nos info à 8.8.8.8…
Bref… Je ne suis franchement pas convaincu par DoH.
#15
Après je vois cela comme une autre possibilité de naviguer sur le web en contournant des limitations ou des restrictions, pas toujours que dans un pays totalitaire.
Cela donne aussi aux navigateurs un moyen de trouver un site web si le DNS est menteur => popcorn pour les nayansdroits.
Mais tu as raison, si implémenté dans Chrome, on sait que ça va finir sur 8.8.8.8 like ^^
#16
Le seul cas où on peut utiliser « à » (pour l’appartenance, la possession), c’est lorsqu’il est suivi d’un pronom personnel (je, tu, il, elle, etc.) (ou dans une construction verbale).
Donc on dit bien « La tablette de Michel » et « le frère de mon beau frère », mais « sa tablette à lui » et « son frère à elle ».
Edit : +lien
Et sinon, j’ai hâte de lire la suite.
#17
Je ne suis vraiment pas fan de ces résolutions de noms “sauvage” des navigateurs. J’ai découvert cela par hasard, en me demandant pourquoi IE résolvait en utilisant le fichier hosts en premier, mais par FF, Opera ou Chrome.
Au final, on s’aperçoit qu’ils peuvent interroger le DNS qu’ils veulent, pas celui du système (et donc contourner les anciens DNS menteurs qui servaient à faire un “filtre” parental basique).
Je préfèrerais avoir une liste tournante de 10 DNS. Par ailleurs, si nos ordis font des requêtes DNS, est-ce que la BOX ne devrait pas être le cache DNS local pour tous les téléphones/ordis de la maison?
#18
#19
DoH ou DoT, si c’est implémenté au niveau de l’OS et pas du navigateur (pas de bypass du fichier hosts, choix du resolveur via conf statique ou via DHCP, …) ca me va, mais il me semble que la rfc 8484 va prendre du temps avant d’être implémentée sur tous les systèmes
#20
#21
Est-ce que ça peut s’implémenter en auto hébergé ?
#22
Oui tu as des résolveurs DNS qui gèrent nativement DoH (donc cache local puis sinon un serveur distant avec chiffrement). J’essaierai de détailler ça dans la partie activation
" />
#23
#24
Et une bouse protocolaire de plus à ajouter au tableau de chasse de ceux qui ne savent pas penser autrement qu’au travers de HTTP -.-
#25
L’histoire des nouvelles technologies est pleine de solution parfaites mais utilisées par personne ;)
#26
#27
#28
Le but est justement de bloquer ce genre de logiciel malveillant
#29
Idéalement, il faudrait utiliser DoT, mais il est trivial a bloquer puisqu’il passe par un port dédié (853 par défaut). En France, on peut facilement tester ce blocage sur les accès Wi-Fi des TGV me semble-t-il (le port 53 est bloqué, et 853 aussi de ce que j’ai compris)
Le port 443 en revanche est quasi impossible a bloquer. Et l’encapsulation de la requête DNS dans une requête HTTP ne rend pas le trafic suspect
Alors oui, c’est une étape de plus vers Internet-over-HTTPS, mais en l’état pas d’autres choix.
Et par ailleurs, il faut considérer DoH comme un dernier recours (si DoT est bloqué, on passe sur DoH). Le hic étant que le protocole est utilisé n’importe comment (implémenter ça dans les applications type navigateur). Il y a un risque qu’à terme tous les logiciels et bidules connectés utilisent leur propre mécanisme de résolution DNS.
#30
Deux solutions : 1) ignorer le problème car ce n’est pas la même chose que de dire qu’on utilise tel ou tel résolveur, que de dire qu’on visite pornhub.com ou alcooloques-anonymes.org 2) Mettre l’adresse de Quad9 au lieu de son nom.
#31
#32
Faire du DoH au dessus de Tor serait plus simple et donnerait le même résultat.
#33
D’abord, il est tout à fait faux, comme on le lit souvent, que DoT (DNS sur TLS) serait « dans l’OS » alors que DoH (DNS sur HTTPS) serait « dans le navigateur ». Les deux techniques (et le DNS classique) peuvent parfaitement être déployées dans l’OS ou dans l’application. Zéro différence entre DoT et DoH sur ce point.https://www.bortzmeyer.org/doh-et-ses-adversaires.html
Ensuite, DoT est déployé, la plupart des résolveurs DoH acceptent également DoT, Android a DoT en standard depuis une ou deux versions, etc. Chacun peut choisir.
#34
Rien à voir avec DoH qui n’est après tout qu’un protocole. Quand la moitié du courrier électronique file chez Gmail, est-ce qu’on dit que SMTP est « centralisé ».
DoH n’implique pas du tout d’aller chez CloudFlare. L’article donne d’ailleurs une liste de résolveurs DoH. J’y ajoute le mien, pendant qu’on y est, cf.https://www.bortzmeyer.org/doh-bortzmeyer-fr-policy.html
#35
#36
Sans problème, un exemple avec mon résolveur personnel :https://www.bortzmeyer.org/doh-mon-resolveur.html
#37
Il n’y a pas le choix : dans beaucoup d’endroits (notamment les hotspots Wifi d’hôtels ou d’aéroports), seuls 80 et 443 passent. Tout sur HTTPS n ‘est pas un choix, c’est une obligation.
#38
#39
#40
#41
Après, tu peux aller encore plus loin. Par exemple, en utilisant un routeur OPNsense, via DNS Unbound (DNS over TLS dans ce cas) et ensuite en montant ton propre serveur DNS sécurisé (sur un serveur dédié par exemple).
#42
Là, on fera du SNI chiffré, du domain fronting… La lutte de l’épée et de la cuirasse est éternelle.
#43
“le truc à Machin”
#44
Oui d’ailleurs SNI est aussi poussé pas mal en marge de DoH, ce qui est plutôt une bonne chose.
#45
Sympa cet article Merci
Et gros bonus : on apprend plein de trucs en lisant les commentaires
#46
#47
Quand j’avais activé la fonctionnalité sous Firefox avec mon VPN, cela exposait mon IP réel (DNSLeak). Je ne sais pas si c’est mon client VPN qui a un problème ou Firefox mais en tout cas maintenant je me méfie de ce genre d’implémentation.
#48
Donc pour réusumer, il n’y a pas (encore) de solution parfaite ?
#49
#50
Merci pour le chouette article assez compréhensible pour ma part
" />
Pour la partie menteur, le protocole ne pourrait-il pas interroger plusieurs résolveurs, et comparer les résultats ? En cas de divergences, il y aurait un message d’erreur à l’utilisateur lui demandant de choisir quelle IP (en récupérant le titre de page par exemple).
Ça ne solutionne évidemment pas les soucis point de vue vie privée, mais en termes de contournement et de résilience, ça ne me paraîtrait pas déconné ?
#51
En sécurité, il n’y a JAMAIS de solution parfaite.
#52
Ça aggrave même les problèmes de vie privée, en envoyant la requête à davantage de monde.
Si le but est juste de savoir quelle est la bonne réponse, DNSSEC me parait une approche préférable.
#53
On utilise “de” dès lors qu’ une personne est évoquée “de” suite.
“à” c’ est plutôt pour parler d’ un objet comme dans le cas “le balai à chiotte”.
On ne peut pas l’ utiliser autrement à moins de vouloir donner à une personne la valeur d’ un objet tel celui d’ un balai à chiottes.
Fin du troll.
#54
Quel est l’apport de DNSSEC (je ne connais pas bien le domaine des DNS) par rapport à savoir quelle est la bonne réponse ?
(Mais oui, j’imagine bien que ça serait envoyer les infos à plus de monde et donc augmenterait les risques d’écoute)
#55
DNSSEC signe cryptographiquement les données, et le résolveur peut donc facilement vérifier que la donnée est correcte.
#56
Merci pour les précisions
" />
#57
#58
Non, ce n’est pas exact. DNSSEC est de bout en bout, puisque la signature est faite par le serveur maitre. (Sur .fr, c’est même un maitre caché, sans accès public depuis l’Internet, donc plus difficile à pirater.) Donc, rien à voir avec « celui à qui on a demandé la résolution ».
Quant aux résolveurs menteurs, DNSSEC ne supprime pas la nécessité d’avoir un résolveur de confiance (soit sur son réseau local, ce qui est quand même recommandé, soit distant et sécurisé par DoT ou DoH.)
#59
#60
Il y a un usage humoristique bien établi, mais évidemment tout le monde n’y est pas sensible.
" />
#61
#62
Perso, j’ai déjà testé plusieurs fois le Net chinois, je suis préparé :P
#63
Je réponds plus sérieusement mais toujours pour causer de la Chine, ils n’ont a priori pas bloqué le silo DoH de CloudFlare utilisé par Mozilla pour l’instant, selon les mesures que j’ai pu faire avec un résolveur local. Le hic étant que la fiabilité de la mesure est aléatoire vu qu’idéalement il faut faire la requête depuis un accès Internet chinois, or la j’interroge depuis la France un résolveur ouvert sur place (à environ 300 bornes de Wuhan
" />)
" />
Donc a priori, la technique chinoise c’est : OSEF de DoH, on a d’autres méthodes de blocage. Je suis très curieux de voir si eSNI va avoir un impact sur la censure là-bas (je pense pas, mais sait-on jamais, à la marge peut-être).
Je testerai la prochaine fois que j’y vais (histoire de se préparer à ce qui nous attends)
#64
#65
La question sur le fond, ce n’est pas plutôt : à quand la possibilité d’interroger les serveurs racine, TLD/SLD directement via DoH, DoT ou autre ?
" />
Parce qu’on peut faire toutes les modifications sur un résolveur ou un autre, en bout de chaîne, la centralisation existe, elle est déjà là, et la couche de sécurité en est encore dramatiquement absente. Mais je pense que Stéphane répondra plus complètement que moi sur le sujet
#66
#67
#68
Pour les DNS, on peut utiliser pi-hole (DNS + DHCP) + unbound (configuré pour le DoT ou DoH comme DNS upstream pour Pi-Hole), et mettre le tout sur un NAS ou autre serveur local. Ainsi on a un bloqueur de pubs au niveau du réseau.
Sinon, sur un PC on peut aussi par exemple utiliser “DNSCrypt client proxy” qui permet de mettre en place simplement une configuration sécurisée pour tout le système. La configuration est assez simple (fichier texte dnscrypt-proxy.toml). Il est même possible de le lancer automatiquement comme service Windows.
#69
Sur la résistance aux dDoS, j’ai des doutes sérieux : UDP est au contraire bien plus vulnérable, puisqu’il n’y a aucune authentification, même minimale, de l’adresse IP source.
Sur le résolveur local, cela n’a rien d’utopique, c’est assez facile à faire et des tas de gens le font.
#70
« à quand la possibilité d’interroger les serveurs racine, TLD/SLD directement via DoH, DoT ou autre ? »
On y travaille (dans le groupe de travail DPRIVE de l’IETF) et des expérimentations existent (les serveurs faisant autorité pour facebook.com répondent déjà en DoT). L’authentifictaion n’est pas triviale car un client d’un résolveur ne parle qu’à deux ou trois résolveurs, mais un résolveur parle à des milliers de serveurs faisant autorité. Les solutions d’authentification évidentes utilisent le DNS mais on a alors un problème d’œuf et de poule. Mais on avance.
#71
« voir une racine alternative sérieuse (je sais qu’il y en a, mais rien qui ne prend de l’ampleur) »
Le problème des racines alternatives n’est pas technique (monter une racine simple est très facile, cf. le projet Yetihttps://www.afnic.fr/fr/ressources/blog/le-projet-yeti-d-experimentation-d-une-r… monter une vraie racine de production est évidemment plus difficile mais on sait faire). Il est 100 % politique : qui va la diriger ? Les russes ? Les chinois ? Google ? Facebook ? Moi (je veux bien devenir Dictateur en Chef de l’Internet Mondial) ?
Qu’on ne me dise pas qu’il faut qu’elle soit gérée démocratiquement par les utilisateurs. Quand c’est trois types dans leur garage, ça va. Mais à l’échelle mondiale ?
#72
« Est ce que tout l’argent gagné a créer des tld “à la con” sert uniquement les intérêts de l’IANA? »
Une bonne partie de la motivation pour cet argent est juridique. L’ICANN étant une boîte privée, elle ne bénéficie pas de l’impunité juridique dont jouit, par exemple, un gouvernement ou une organisation internationale. Le système juridique étatsunien étant propice aux DoS, il faut être gros pour tenir le coup.
#73
« - L’argent suffit t’elle à ce que l’IANA reste indépendante? L’est elle vraiment? »
L’indépendance est une notion complexe. Indépendant de qui ? La gestion de la racine n’est pas vraiment indépendante du gouvernement des États-Unis, qui continue à déléguer son fonctionnement à Verisign. Quant à l’ICANN, indépendante du gouvernement des États-Unis ne signifie pas indépendante de la vision états-unienne du monde (aux réunions ICANN, une bonne partie de la soi-disant diversité, les gens qui prétendent représenter l’Afrique, par exemple, sont des gens qui vivent et travaillent aux USA depuis 30 ans…). Et l’ICANN est très marquée par l’idéologie capitaliste (cf. la vente de .org).
#74
« - Qui prend / Comment on été prisent les décisions de créer des nouveaux TLD? »
Deux cas, les TLD ICANN et les autres.
Pour les TLD ICANN, c’est l’ICANN. Le mécanisme, long, compliqué et cher, est certes très contestable mais,à la décharge de l’ICANN, il faut préciser que personne n’a encore trouvé un mécanisme correct (les idées sont les bienvenues mais le problème est vraiment très difficile ; pensez par exemple au .ISLAM, à qui l’attribuer ?).
Pour les TLD autres, ils dépendent d’un pays. La création de .SS était automatique à l’indépendance du Soudan du Sud. La suppression dépend du bon vouloir du pays (cf. le feuilleton du .SU, qui se porte toujours bien, 28 ans après la fin de l’Union Soviétique). Il reste les cas difficiles comme .EH mais ceux-ci sont difficiles de toute façon. Là encore, personne n’a de solution miracle pour résoudre ces problèmes.
#75
« - Concernant le .Org, comment est-ce possible qu’une société se soit approprié et se donne le droit de vendre un bien commun datant du début de l’Internet? »
Je suis d’accord, c’est scandaleux.
#76
Ouahou, merci pour toutes ces réponses hautement intéressante, ca explique pas mal de décisions qui sont prises. Il faudrait écrire un livre sur la politique interne et la gouvernance du DNS!
Juste sur une des réponses, quand je parlais de “qui décide de créer les tld à la con”, je parlais plus des .car .business .travel , etc… Si j’ai envi de créer mon .forcerouge, c’est possible? Je fais un chèque et hop ?
Merci encore :)
!mode pression=on!
NXI, n’oubliez pas l’article :)
!mode pression=off!
#77
Comme je disais, c’est long, compliqué et cher.
Il n’y a pas d’ouverture en ce moment, on parle d’un prochain cycle de candidatures en 2021 ou 2022. Prix pas encore connu. Attention, les frais de dossier ne sont qu’une petite partie de ce qu’il faut payer.