Étiquette : DNS

ICANN76, Sally Costerton, la nouvelle présidente par intérim de l’ICANN imprime son style

Candidate en mars 2020 puis en mars 2021, la ville de Cancun aura finalement dû attendre mars 2023 et la fin de la pandémie de COVID pour retrouver une nouvelle édition d’un sommet de l’ICANN en présentiel. 2023, une année très importante pour l’organisation. Celle-ci va en effet célébrer ses 25 années d’existence alors qu’elle traverse une période à risques avec une présidence intérimaire après la démission de son Président le 22 décembre 2022.

ICANN76, Sally Costerton, la nouvelle présidente par intérim de l’ICANN imprime son style

Deux femmes à la tête de l’instance

C’est l’anglaise Sally Costerton qui était vice-présidente du Global Stakeholder Engagement (GSE) en charge de l’engagement et de la sensibilisation des parties prenantes à l’ICANN et à sa mission dans le monde entier depuis 2012, qui a été nommée Présidente Directrice Générale par interim de l’ICANN suite au départ de Goran Marby fin 2022. Elle est secondée par Tripti Sinha, qui occupe la fonction de présidente du conseil d’administration de l’ICANN. Tripti est également vice-présidente adjointe et directrice de la technologie à l’université du Maryland, au sein de la division des technologies de l’information. C’est la première fois que l’ICANN a à sa tête deux femmes. La situation fait toutefois écho à la création de l’ICANN. Comme cela a été rappelé lors de la cérémonie d’ouverture, en 1998, année où le gouvernement américain confia à l’ICANN la mission de gérer le système d’adressage DNS, une femme occupait également la position de présidente du conseil d’administration. Il s’agissait d’Esther Dyson.

Si les interims de direction sont rares à l’ICANN, cette situation a donné lieu à l’organisation d’une session particulière nommée « L’avenir de l’ICANN et le prochain président-directeur général ». Une session où l’on pouvait s’attendre à ce que les participants puissent interagir avec le nouveau Conseil d’Administration. Il n’en a rien été puisque cette session s’est apparentée à une sorte de micro libre sans interlocuteur direct pour exprimer les attentes vis-à-vis de la nouvelle Direction de l’organisation.

Qui dit interim pour une organisation de gouvernance dit également période à risques, d’autant que les sujets à adresser ne manquent pas et que le contexte géopolitique tend vers une fragmentation accrue. Toutefois, si l’on ne connait pas la durée de l’interim de présidence, Sally Costerton a su rapidement imprimer sa marque dès le début du sommet où elle a notamment déclaré  « Je ne suis pas au fait de tout mais je m’appuie sur des experts ». Des propos de nature à rassurer et qui dénote une approche pragmatique.

La transparence à l’épreuve de l’expérience

L’ICANN est une organisation bien rodée puisqu’elle tient des sommets depuis 25 années. La tendance observée ces dernières années, était que les Organisations de soutien (SO) et Comités consultatifs (AC) qui la constituent, allaient vers plus de transparence en ouvrant toutes leurs sessions au public. La transformation la plus significative est à mettre au crédit du GAC, l’instance représentant les gouvernements dont les sessions ont été fermées de nombreuses années avant d’être totalement ouvertes à tous les participants. L’occasion de saluer le travail de Manal Ismail, qui après près de six années à la tête du GAC, laisse sa place au paraguayen Nicolas Caballero. Une tendance globale donc de nature à générer de la confiance, une valeur clé pour répondre aux détracteurs de plus en plus nombreux du mode gouvernance de l’ICANN.

Mais cette tendance s’est inversée lors de ce sommet car de nombreuses sessions étaient fermées, des « Closed sessions » auxquelles même certains utilisateurs affiliés n’ont pas pu avoir accès ni en présentiel ni en distanciel. Des participants remontés, n’ont d’ailleurs pas manqué de le souligner lors du traditionnel Forum Public qui clôture généralement la semaine de réunions.

Des avancées à marche forcée ?

L’approche consensuelle, marque de fabrique de l’ICANN, est à la fois un atout pour fédérer le plus d’acteurs autour des obligations qui sont adoptées mais aussi une tare car cela ralentit considérablement l’avancée de travaux importants.

Exemple marquant, celui des abus du DNS. Les usages malveillants sont en effet un réel problème étant donné les préjudices subis par les usagers d’Internet impactés. Le GAC n’a pas manqué de le rappeler une nouvelle fois lors d’une session où des experts externes ont été conviés comme un représentant du Bureau Fédéral d’Investigation, le FBI. Ce dernier a indiqué qu’au niveau des Etats-Unis, en 2022 plus de 800,000 noms de domaine ont fait l’objet de plaintes causant des pertes supérieures à 10 milliards de dollars US. Si le sujet des abus du DNS n’a pas manqué de s’inviter à chaque sommet de l’ICANN au fil des années passées, force est de constater que le consensus a montré ses limites. Les parties prenantes présentes au GNSO, l’instance chargée des politiques des noms génériques, ne sont en effet jamais parvenues à s’entendre sur la voie à suivre entre notamment un Processus de développement de politique ou des négociations contractuelles pour réviser les contrats des parties prenantes avec l’ICANN. Après des consultations des parties prenantes, c’est finalement le second moyen qui a été retenu par le GNSO et le moins que l’on puisse dire c’est que lors de l’ICANN76, la volonté affichée était cette fois de vite parvenir à un résultat. Un amendement des contrats des registres et des bureaux d’enregistrement est en cours d’élaboration et doit être présenté en juin puis soumis aux votes des parties concernées dès octobre.   

Le GNSO entend s’appuyer sur la dynamique d’un autre amendement des contrats soumis aux votes des parties prenantes: un amendement « RDAP ». Le RDAP est un protocole alternatif au Whois qui permet de consulter les données d’enregistrement des noms de domaine. L’issue des votes et donc de l’adoption de ces révisions de contrats, demeurait incertaine à la fin du sommet de l’ICANN car différents seuils de participation et de votes favorables doivent être atteints.

Adoption partielle des recommandations pour des séries ultérieures de nouveaux gTLDs

Autre sujet que certains aimeraient voir avancer plus vite, celui de prochaines séries de nouvelles extensions génériques. Il faut en effet remonter à janvier 2012, pour la dernière fenêtre de candidatures à des extensions génériques. Depuis lors, un processus de développement de politique a été conduit depuis 2015 pour définir un train de recommandations pour la tenue de nouvelles fenêtres de candidatures. Le rapport final de ce processus a été remis au Conseil d’administration de l’ICANN en février 2021. A l’automne 2021, l’ICANN avait surpris la communauté en annonçant la tenue d’une phase de cadrage, un ODP (Operational Design Phase) qui aura finalement duré jusqu’au début de cette année. Le conseil d’administration n’avait donc pas encore statué sur le rapport final des recommandations, un préalable pour pouvoir engager les travaux d’implémentation des recommandations. Autant dire que la nouvelle présidente par interim de l’ICANN était donc aussi très attendue sur ce sujet.

Et elle a rapidement prévenu que le temps était aussi à l’action sur ce sujet : « Vous allez voir que les choses vont être clarifiées » (ndlr : sur les prochaines séries) a-t-elle déclaré lors d’une session en semaine. A la fin de la semaine, lors d’une session du conseil d’administration, 98 recommandations du processus de développement de politiques ont été adoptées, 38 autres mises en balance car nécessitant des compléments d’information. Un plan de mise en œuvre est aussi attendu, ordonné pour août, avec un accent mis sur les noms et extensions internationalisées que l’organisation ICANN souhaite largement mettre en avant et le besoin de clarifier si des extensions génériques fermées vont pouvoir être proposées.

Observations de NAMESHIELD

On peut regretter un retour à une certaine opacité dans les prises de décisions lors de l’ICANN76 où se sont tenues pas moins de 25 sessions fermées. Néanmoins, c’est peut-être de là que viennent aussi les avancées constatées sur des sujets qui avançaient difficilement comme sur les abus du DNS, sujet très important pour NAMESHIELD qui met à votre disposition plusieurs solutions pour défendre vos actifs en ligne et la tenue d’une prochaine série de nouvelles extensions, où les experts NAMESHIELD peuvent également vous accompagner.

L’autre question demeurait de voir comment la nouvelle Présidente d’ICANN par interim Sally Costerton allait endosser son nouveau rôle dans une période à risques pour l’ICANN dont le modèle est lui aussi de plus en plus challengé par les Etats, des organisations internationales et même des alternatives technologiques. Sur ce point, la nouvelle présidente est apparue volontariste, joignant les paroles aux actes, comme sur le sujet de séries ultérieures de nouvelles extensions génériques. Sally Costerton semble avoir déjà commencé à tracer son sillon pour mieux endosser un rôle de PDG pour un mandat plein de l’organisation.

Source de l’image : Site de l’ICANN

SVCB/HTTPS : de nouveaux enregistrements DNS

SVCB/HTTPS : de nouveaux enregistrements DNS

Deux types nouveaux

Le DNS, système de noms de domaine, est un service essentiel au fonctionnement d’Internet. Il est souvent présenté comme un annuaire permettant d’associer des noms de domaine à des adresses IP, mais c’est en réalité qu’une petite partie de ses fonctions.

Les enregistrements DNS de types A et AAAA permettent en effet de configurer des adresses IP derrière un nom de domaine. Il existe également des dizaines d’autres types d’enregistrements DNS, utiles pour divers cas d’usage.

Deux nouveaux types d’enregistrement DNS vont prochainement être introduits par une nouvelle RFC : les types SVCB et HTTPS.

Faciliter les services et réduire la latence

Type SVCB

Le type SVCB, pour SerViCe Binding, a pour objectif d’indiquer des informations utiles sur les services disponibles avec un nom de domaine. Le format de l’enregistrement SVCB est composé d’une priorité, d’une cible et d’une liste de paramètres optionnelle. Par exemple, il permet d’indiquer que pour un service défini, un nom de domaine est en fait lié à un autre nom avec une configuration spécifique.

SVCB [SvcPriority] [TargetName] ([SvcParams]…)

Les enregistrements SVCB se différencient des SRV sur plusieurs points :

  • Les enregistrements SRV sont généralement obligatoires pour qu’un service fonctionne ; ce n’est pas le cas avec les SVCB.
  • Les enregistrements SVCB peuvent indiquer plus d’informations que les SRV, comme une version de protocole à utiliser.
  • Le type SVCB est extensible, contrairement aux SRV, ce qui ouvre la porte à diverses évolutions et usages futurs.

Type HTTPS

Le type HTTPS est un type dérivé de SVCB. Contrairement au type SVCB qui est générique, le type HTTPS est spécifique au protocole HTTPS.

Généralement, pour initier une connexion HTTPS, le client doit d’abord se connecter en HTTP afin de récupérer plusieurs informations, par exemple pour savoir quelle version utiliser ; cela génère de la latence.

L’enregistrement DNS de type HTTPS permet notamment d’indiquer au client, différents paramètres afin de faciliter la connexion au serveur, et ainsi réduire la latence. Il a la même forme qu’un enregistrement SVCB :

HTTPS [SvcPriority] [TargetName] ([SvcParams]…)

Mode alias

Les enregistrements SVCB/HTTPS proposent deux modes de fonctionnement. Un mode alias et un mode service.

Le mode alias est activé lorsque la priorité est positionnée à 0. Il permet de rediriger un nom de domaine vers un autre nom, et notamment de résoudre le fameux problème du CNAME à la racine (CNAME-at-apex).

L’enregistrement CNAME permet d’indiquer qu’un sous-domaine renvoie vers un autre nom de domaine. Il est très utile pour déléguer un service : par exemple pour faire pointer le nom www.exemple.fr vers le site web hébergé chez monsite.presta.fr.

www CNAME monsite.presta.fr

Le problème avec l’enregistrement CNAME, c’est qu’il ne peut pas être défini à la racine d’un nom. Pour contourner ce problème, des solutions non-standards sont proposées comme les enregistrements ALIAS ou ANAME, mais ces types ne sont pas supportés par tous les opérateurs DNS. Le mode alias des enregistrements SVCB/HTTPS est une solution à ce problème.

SVCB 0 nameshield.net.

HTTPS 0 nameshield.net.

Mode service

Le mode service des enregistrements SVCB/HTTPS permet d’indiquer quels services sont configurés derrière un nom de domaine. Lors de la découverte de service, cela fournit au client un certain nombre de paramètres condensés dans un seul enregistrement DNS. L’objectif est de faciliter l’utilisation de services et diminuer la latence.

Par exemple, nous pouvons avoir un enregistrement HTTPS indiquant que le client peut se connecter avec le protocole HTTP/2 ou HTTP/3 (alpn) aux adresses IPv4 et IPv6 définies (ipv4hint, ipv6hint), sur le port 8061 (port).

HTTPS 1 . alpn=”h3,h2” ipv4hint=”192.168.0.1” ipv6hint=”2001:db8::1” port=8061

Déploiement en cours

Les enregistrements SVCB/HTTPS apportent plusieurs fonctionnalités afin d’améliorer les performances du Web et répondre à la problématique du CNAME à la racine. Le fait qu’ils soient génériques et évolutifs permet d’élargir le périmètre des cas d’usage.

Bien qu’ils ne soient pas encore normés par une RFC, ces nouveaux types d’enregistrement sont déjà utilisés. Certains logiciels DNS et navigateurs Web supportent ces enregistrements, et des acteurs comme Apple, Google, Cloudflare et Nameshield les implémentent déjà.

Aujourd’hui, les services fonctionnant avec des enregistrements SVCB/HTTPS doivent également pouvoir s’en passer, car leur déploiement n’est pas encore généralisé. C’est une étape qui peut prendre plusieurs mois, le temps que la majorité des opérateurs se mettent à jour.

Source de l’image : TheDigitalArtist via Pixabay

[REPLAY WEBINAR] Cyberisque : anatomie des attaques sur le DNS et le nom de domaine, exemples et solutions à mettre en place

WEBINAR - Cyberisque : anatomie des attaques sur le DNS et le nom de domaine, exemples et solutions à mettre en place

Retrouvez sur le site de Nameshield et la plateforme Webikeo, le replay du webinar « Cyberisque : anatomie des attaques sur le DNS et le nom de domaine, exemples et solutions à mettre en place », animé par Christophe GERARD, Security Product Manager de Nameshield.

Dans un monde qui continue sa mue vers la digitalisation, les entreprises déjà bien au fait du cyberisque pesant sur les organisations, ont vu les menaces augmenter pendant la période COVID. La nécessité de sécuriser ses actifs numériques est plus que jamais au cœur des sujets IT.

Au programme de ce webinar :

  • L’importance stratégique du DNS et des noms de domaine
  • Les risques liés à la gestion administrative
  • Les risques de détournement d’accès
  • Les risques liés à la gestion technique
  • Les mesures indispensables à mettre en place
Visionner le replay

[WEBINAR] Cyberisque : anatomie des attaques sur le DNS et le nom de domaine, exemples et solutions à mettre en place – Le 31 mars à 14h

[WEBINAR] Cyberisque : anatomie des attaques sur le DNS et le nom de domaine, exemples et solutions à mettre en place

Rendez-vous le 31 mars 2022 à 14h pour assister au webinar « Cyberisque : anatomie des attaques sur le DNS et le nom de domaine, exemples et solutions à mettre en place », animé par Christophe GÉRARD, Security Product Manager de Nameshield group.

Dans un monde qui continue sa mue vers la digitalisation, les entreprises déjà bien au fait du cyberisque pesant sur les organisations, ont vu les menaces augmenter pendant la période COVID. La nécessité de sécuriser ses actifs numériques est plus que jamais au cœur des sujets IT.

Au cours de ce webinar, notre expert reviendra sur l’importance stratégique du DNS et des noms de domaine, et vous présentera les attaques potentielles et les solutions pour s’en prémunir.

Je m’inscris au webinar

Pour y assister, il faudra au préalable vous inscrire sur la plateforme Webikeo (inscription gratuite) puis réserver votre place pour ce webinar. Vous pourrez ainsi participer en live à cette web-conférence et poser vos questions en direct.

Vous ne serez pas disponible ? Pas d’inquiétude, ce webinar sera également disponible en replay.

Nouvelle fiche : 5 minutes pour comprendre l’empoisonnement du cache DNS

Fiche 5 minutes pour comprendre - Noms de domaine - Empoisonnement du cache DNS - DNS cache poisoning - Nameshield

Le DNS (Domain Name System) est un service clé de l’Internet. C’est un annuaire géant, hiérarchisé et distribué, qui associe des adresses IP à des noms de domaine qui sont plus faciles à identifier, mémoriser et transmettre. C’est la pierre angulaire de l’Internet dont l’infrastructure présente, par sa conception, des failles en faisant une cible idéale pour les attaques.

Le service DNS repose d’un côté sur les DNS dits autoritaires, qui détiennent l’information, et les DNS résolveurs qui opèrent la résolution pour les internautes.
L’attaque par empoisonnement du cache DNS vise les DNS résolveurs.

Découvrez dans cette fiche « 5 minutes pour comprendre », disponible en téléchargement sur le site de Nameshield, en quoi consiste cette attaque et comment s’en protéger.

Télécharger la fiche

[WEBINAR] Noms de domaine stratégiques : Des cibles de plus en plus exposées, comment les protéger ?

[WEBINAR] Noms de domaine stratégiques : Des cibles de plus en plus exposées, comment les protéger ?

Rendez-vous le 30 novembre prochain à 14h pour assister au webinar intitulé « Noms de domaine stratégiques : Des cibles de plus en plus exposées, comment les protéger ? », animé par Christophe GÉRARD, Security Product Manager de Nameshield group.

Au cours de ce webinar, notre expert abordera la notion de noms de domaine stratégiques, quels sont-ils, à quel point sont-ils vitaux pour l’entreprise et ses applications clés (web, mail, applications, VPN, SSO…), comment ils sont exposés à des menaces de plus en plus nombreuses et sophistiquées et comment se protéger pour garantir leur disponibilité 100% du temps.

Je m’inscris au webinar

Pour y assister, il faudra au préalable vous inscrire sur la plateforme Webikeo (inscription gratuite) puis réserver votre place pour ce webinar. Vous pourrez ainsi participer en live à cette web-conférence et poser vos questions en direct.

Vous ne serez pas disponible ? Pas d’inquiétude, ce webinar sera également disponible en replay.

Petit précis du DNS

Pour les non-initiés, l’informatique est un domaine assez magique où tout se résout plus ou moins tout seul. Quand ça ne fonctionne plus, c’est la catastrophe et on est perdu.

Certaines notions peuvent être un peu velues, mais le principe de fonctionnement est souvent assez simple. Il suffit de l’expliquer.

Parlons aujourd’hui du système de nom de domaine. C’est un système que tout le monde utilise au quotidien pour parcourir Internet et qui est très intéressant à explorer.

Les noms de domaine

Tous les services (site web, mail, jeux vidéo …) que vous utilisez sur Internet fonctionnent sur des serveurs. Pour avoir accès à un de ces services, il faut contacter le serveur correspondant et lui demander de livrer le service. Or le point de contact d’un serveur c’est son adresse IP.

On peut comparer ça à avoir la localisation (longitude et latitude) d’un endroit où l’on souhaite se rendre. Dans la théorie, on peut très bien se rendre n’importe où à partir de la longitude et latitude. Cependant, dans la réalité ce serait un enfer de se souvenir de chaque localisation. Et pour rendre ça viable, on utilise des adresses postales. Et bien pour l’informatique c’est pareil. Plutôt que de devoir se souvenir de chaque adresse IP, on a mis en place les noms de domaine.

Un nom de domaine c’est donc (en partie) ce que vous voyez inscrit dans la barre d’adresse en haut de votre navigateur quand vous arrivez sur un site. C’est « google.com », « linkedin.com » ou « nameshield.com ». On peut constater que le nom de domaine se compose d’une chaîne de caractères, qui correspond généralement au nom d’une marque, d’un produit ou d’un service, et d’une extension (« fr », « com », « net », …).

Si on reprend notre comparaison avec une localisation, une fois arrivé à destination, on peut encore affiner notre objectif en choisissant à quel étage on veut se rendre. De même, pour les noms de domaine, on peut préciser notre demande en ajoutant un « étage » à notre nom de domaine, qu’on appelle sous-domaine : « mail.google.com ». Ici, on a « mail » qui est le sous-domaine et « google.com » qui est le nom de domaine. À partir de là, on peut mettre autant de sous-domaines qu’on le souhaite : « sous-sous-domaine.sous-domaine.domaine.net », mais c’est assez peu utilisé.

Les extensions

Comme on a pu le voir juste avant, la partie la plus à droite du nom de domaine est ce qu’on appelle une extension. On peut également l’appeler domaine de premier niveau (Top Level Domain ou TLD). Contrairement au reste du nom de domaine qui peut être composé de n’importe quels caractères alphanumériques, le domaine de premier niveau est choisi dans une liste préexistante. La liste de ces extensions se découpe en quatre types :

·  Les ccTLD (country code Top Level Domain) : ce sont des extensions de deux lettres identifiant un pays ou territoire indépendant. Par exemple, on a le « fr » pour la France, le « us » pour les États-Unis, ou le « tv » pour le Tuvalu.

·  Les gTLD (generic Top Level Domain) : ce sont des extensions historiques de trois lettres ou plus prévues pour des utilisations générales. On retrouve par exemple le fameux « com » qui a été créé pour une utilisation commerciale, le « gov » pour le gouvernement ou le « org » pour les organisations.

·  Les new gTLD (new generic Top Level Domain) : devant la croissance d’Internet, l’autorité responsable des noms de domaine a décidé en 2012 d’introduire de nouvelles extensions. On retrouve le « xyz », le « bank » ou le « sport ».

·  Les corpTLD (corporate Top Level Domain) : c’est en fait une sous-catégorie de new gTLD. Elle est réservée aux organisations souhaitant posséder leur propre extension. On y retrouve  « hbo » ou « lego ».

Les serveurs de nom de domaine

Maintenant que l’on comprend un peu mieux à quoi correspond cette notion, on peut se demander de quelle manière notre ordinateur récupère l’adresse IP cachée derrière un nom de domaine. On appelle cette opération « résolution d’un nom de domaine ». En fait, en regardant la configuration réseau de notre ordinateur, on peut retrouver un champ DNS (Domain Name Server) où l’on indique une adresse IP d’un serveur de nom de domaine à qui on va faire les demandes de résolution à chaque fois qu’on utilise un nom de domaine. Ce serveur peut être appelé « résolveur DNS ». On peut noter que pour ce service, on est obligé de spécifier une adresse IP étant donné que si ce champ n’est pas configuré on n’a aucun moyen de résoudre un nom de domaine et donc on ne peut pas récupérer l’IP cachée derrière.

Vous vous dites surement « C’est bien beau, mais moi je l’ai jamais changé ce paramètre et pourtant mon ordinateur arrive quand même à résoudre les noms de domaine ! ». Et en fait, c’est très simple, parce que vous n’avez pas non plus configuré votre adresse IP sur votre ordinateur ; vous l’avez branché à votre box Internet et la magie s’est opérée. Et bien, c’est pareil, c’est votre router Internet qui a décidé quel DNS vous alliez utiliser. Donc par défaut vous utilisez le résolveur de votre fournisseur d’accès Internet.

Cependant, ce ne sont que des valeurs par défaut, et vous pouvez tout à fait choisir d’utiliser d’autres résolveurs DNS. Vous pouvez choisir d’utiliser ceux d’un autre fournisseur d’accès, mais aussi ceux d’un autre fournisseur de service.

Choisir son résolveur DNS est important, car de là dépend (en partie) la vitesse de livraison d’un service (si le serveur met du temps à vous renvoyer une IP, vous mettrez forcément plus de temps à récupérer la page web) ; mais aussi la confidentialité de vos données, car comme c’est lui qui résout tous vos noms de domaine, il connait tous les services que vous cherchez à joindre.

La résolution des noms de domaine

Un serveur de nom de domaine est donc une base de données de couple nom de domaine / adresse IP. Cependant, chaque serveur DNS ne contient pas la liste d’absolument tous les noms de domaine qui existent. Cela formerait des bases de données titanesques, ce serait un vrai calvaire à mettre à jour et ça serait des passoires en termes de sécurité.

Avant de rentrer dans le détail du cheminement d’une demande de résolution de nom de domaine, il va être indispensable, pour ne pas se perdre, de définir certaines notions relatives au DNS et notamment les différents types de serveurs DNS qui existent (parce que oui, il en existe différent, ce serait beaucoup trop simple sinon).

Notions importantes

ICANN : C’est l’Internet Corporation for Assigned Names and Numbers (Société pour l’attribution des noms de domaine et des numéros sur Internet). C’est une autorité de régulation d’Internet de droit privé et à but non lucratif. Elle a pour objectif l’administration des ressources numériques d’Internet telles que l’adressage IP et la gestion des domaines de premier niveau (vous vous souvenez, les TLDs).

Serveur récursif : Ce sont les serveurs que l’on imagine quand on parle de serveur DNS. Ce sont ceux qu’on configure dans le fameux champ DNS de notre configuration réseau et ce sont eux qui se débrouillent pour aller chercher l’adresse IP que l’on souhaite à partir d’un nom de domaine. Ces serveurs ont aussi une fonction de « cache », c’est-à-dire que lorsqu’on leur demande un nom de domaine qu’ils ne connaissent pas, ils font la recherche puis ils gardent l’information en mémoire au cas où on leur redemande. Il ne garde bien sûr cette information qu’un certain temps avant de devoir renouveler leur recherche (au cas où il y a eu une modification relative à ce nom de domaine).

Serveur Racine : Ce sont les treize serveurs gérés par l’ICANN qui ont pour objectif d’indiquer où se situent les serveurs responsables de chacun de domaine de premier niveau.

Serveur TLD : Ce sont les serveurs responsables de chacun des domaines de premier niveau. On retrouve un serveur pour le « fr », un serveur pour le « com », … (En vrai cela est plus complexe que « un serveur pour un TLD », mais l’idée globale est là). Et ces serveurs de noms de domaine répertorient le serveur faisant autorité pour chacun des noms de domaine qu’ils gèrent.

Serveur faisant autorité : Ce sont sur ces serveurs sur lesquels se retrouve l’information que l’on cherche, c’est-à-dire l’IP correspondant à un nom de domaine. Lorsqu’on modifie une information relative à un nom de domaine, c’est sur ces serveurs qu’elle est modifiée.

Le chemin de la résolution

Maintenant qu’on voit un peu plus clair dans les termes, on commence à distinguer un schéma qui se dessine ; schéma que je vais m’empresser de vous expliquer. D’après ce que je vous ai déjà dit, on sait que le serveur DNS configuré sur votre ordinateur (le serveur récursif) ne connait pas tous les noms de domaine qui existent, il doit donc trouver un moyen d’apprendre l’IP d’un nom de domaine qu’il ne connait pas. La recherche se fait de manière hiérarchique.

Pour comprendre comment ça marche, on va suivre le cheminement d’une demande de résolution d’un nom de domaine. Imaginons que l’on veut résoudre « www.nameshield.com ».

1. Notre ordinateur va commencer par faire une demande au serveur récursif qu’il a de configuré. On va dire qu’on est chez Orange, et on demande donc au serveur « 80.10.401.2 » : « Est-ce que tu connais l’adresse IP qui se trouve derrière le nom de domaine www.nameshield.com ? ». C’est une adresse que personne n’a jamais demandée au serveur DNS d’Orange (on va faire comme si c’était le cas) et du coup il ne connait pas la réponse.

2. Ne voulant pas rester dans l’ignorance, il va aller chercher cette information. Pour ce faire, il va aller interroger un des serveurs racines : « Dis-moi serveur racine, je dois résoudre www.nameshield.com, or je ne connais pas ce nom de domaine, peux-tu m’aider ? ». Ce à quoi le serveur racine va répondre « Hum… tu devrais demander à 192.134.4.1, c’est lui qui gère les .com ».

3. Le serveur récursif d’Orange va donc répéter sa question au serveur TLD du .com qui va lui répondre : « nameshield.com ? C’est un nom qui est enregistré chez Nameshield ça. Demande à 255.341.209.423 ».

4. Pour la troisième fois, notre serveur récursif pose la question au serveur faisant autorité qui lui répond « Bien sûr que je connais www.nameshield.com, c’est moi qui le gère ! Tu peux le trouver à 81.92.80.11 ».

5. Tout fier d’avoir enfin la réponse, notre serveur récursif nous la transmet et on peut alors contacter le serveur qui se cache derrière nameshield.com via son adresse IP.

Bien évidemment, on est en informatique et tous ces échanges ne prennent que quelques centièmes de secondes. Mais, on est toujours soucieux de gagner du temps, et donc le serveur récursif va garder l’information qu’on vient de lui demander en mémoire (au moins pendant quelques minutes), comme ça si on lui redemande 20 secondes plus tard, il ne va pas déranger les autres serveurs.

Résolution DNS -NAMESHIELD

Conclusion

En dehors du milieu technique, on entend assez peu parler du système de nom de domaine (DNS), or c’est une notion qui mérite d’être connue, car c’est un vecteur important pour toute organisation. En effet, l’influence des noms de domaine se retrouve à tous les niveaux :

·  Le nom de domaine représente une marque, un produit, une organisation, … il est donc important de le protéger. Il faut penser aux différentes possibilités lors de l’enregistrement pour pas que quelqu’un d’autre puisse le réserver et nuire à votre image.

·  La configuration du serveur récursif que l’on va mettre en place sur notre machine va jouer sur la vitesse de votre Internet, mais aussi la confidentialité de vos données.

·  La disponibilité de tout Internet dépend de la disponibilité du système de nom de domaine. Si les serveurs racine, TLD ou faisant autorité tombent, on n’a plus accès à aucun service.

Tout ça pour dire, que le DNS, c’est complexe, mais c’est crucial !

Source de l’image : storyset.com

Nouvelle fiche : 5 minutes pour comprendre la résolution DNS des noms de domaine

Fiche 5 minutes pour comprendre - Résolution DNS des noms de domaine - Nameshield

L’homme a une très mauvaise mémoire des suites de chiffres. Or les ordinateurs et serveurs communiquent entre eux en s’identifiant via une adresse IP, suite de nombres ou mix de chiffres et nombres sensiblement complexe à mémoriser et différencier.

Pour aider les hommes dans leurs communications sur les réseaux, le Système de Noms de Domaine (DNS) a été inventé. Ce service est un annuaire géant de l’Internet, hiérarchisé et distribué au plan mondial, qui fait correspondre des noms de domaine avec des adresses IP.

Lorsqu’un internaute saisit un nom de domaine dans son navigateur, celui-ci interroge un serveur DNS qui va rechercher la réponse à cette adresse humainement compréhensible, le plus souvent une adresse IP, menant au bon site web, ordinateur ou réseau. On appelle ce processus d’interrogation la «résolution DNS».

Découvrez dans cette fiche « 5 minutes pour comprendre », disponible en téléchargement sur le site de Nameshield, le fonctionnement de la résolution DNS.

Télécharger la fiche

L’importance du reverse DNS

DNS inversé - Reverse DNS
Source de l’image : Jonbonsilver via Pixabay

Le DNS inversé (ou reverse DNS) est souvent méconnu des gestionnaires de noms de domaine, en particulier quand les noms sont hébergés par de grandes sociétés d’hébergement. Le DNS inversé permet de faire une résolution depuis une adresse IP vers un FQDN. C’est l’exact opposé de l’utilisation classique du DNS qui fait correspondre des noms de domaine avec des adresses IP. Le reverse DNS permet de répondre à la question : j’ai une adresse IP, quel est le FQDN qui s’y rapporte ?

Le reverse DNS fonctionne via la création d’une zone DNS reverse dans laquelle des enregistrements DNS PTR (pour Pointer Record) vont être configurés.

  • DNS classique : Record A : on connaît le nom d’un site et on souhaite récupérer son adresse IP…
  • DNS inversé PTR : on connaît une adresse IP et on souhaite récupérer le nom du site.  

Le système de résolution se construit de manière similaire à la résolution classique. Pour opérer la résolution DNS, l’adresse IP à interroger est configurée dans la zone reverse avec le suffixe .arpa et pointe vers la destination requise. Le principe est le même pour les adresses IP v4 et v6 selon la construction suivante :

Ex: IPv4 : 11.80.92.81.in-addr.arpa. IN PTR capp.perf1.com.

Ex: IPv6 : 0.0.0.0.0.0.0.0.0.1.0.1.0.0.0.0.0.8.c.0.0.1.0.a.2.ip6.arpa. 4080 IN PTR capp.perf1.com.

Cette construction permet d’opérer une résolution DNS classique sur un nom de domaine avec une extension «.arpa».

Pourquoi est-ce si important ?

Le DNS inversé est principalement utilisé pour le suivi de la provenance d’un visiteur du site Web, de l’origine d’un message électronique, etc. Il n’est généralement pas aussi critique que le DNS classique, les visiteurs atteindront le site Web même sans la présence de DNS inversé pour l’IP du serveur Web ou l’IP du visiteur.

Cependant, le DNS inversé est important pour une application particulière : la messagerie.

De nombreux serveurs de messagerie sur Internet sont en effet configurés pour rejeter les e-mails entrants provenant de toute adresse IP qui n’a pas de DNS inversé. Pour celui qui gère son propre serveur de messagerie, le DNS inversé doit exister pour l’adresse IP à partir de laquelle le courrier électronique sortant est envoyé.

Peu importe l’adresse vers laquelle pointe l’enregistrement DNS inversé de l’adresse IP, un enregistrement reverse est attendu. Dans le cas d’hébergement de plusieurs domaines sur un même serveur de messagerie, il suffit de configurer le DNS inversé pour pointer vers le nom de domaine considéré comme principal (Les serveurs de messagerie vérifiant le DNS inversé reconnaissent qu’il est normal d’héberger de nombreux domaines sur une seule adresse IP et qu’il serait impossible de répertorier tous ces domaines dans le DNS inversé pour l’IP).

Nous vous recommandons de vérifier la possibilité de paramétrer un DNS inversé auprès de votre solution d’hébergement DNS.

[INFOGRAPHIE] Les vulnérabilités de l’architecture DNS

Le DNS est au cœur des services critiques de l’entreprise : Internet, e-mail, applications… Il doit rester disponible et avoir un niveau élevé de sécurité. En effet une interruption de services aurait de lourdes conséquences pour les entreprises victimes.

Pourtant, le DNS est bien souvent l’infrastructure la moins sécurisée d’une entreprise et est exposé à de nombreuses attaques potentielles.

Découvrez dans cette nouvelle infographie, disponible en téléchargement sur le site de Nameshield, quelles sont les vulnérabilités de l’architecture DNS, les différentes attaques et comment assurer la disponibilité et la protection des services en ligne.

Infographie Les vulnérabilités du DNS - Nameshield
DECOUVRIR