Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Qui sommes nous ? Contact rédaction Contact site Forum
Flux RSS
GitHub Discord

À propos

Abonnez-vous

[Dossier] Internet, mode d’emploi : de l’URL à l’IP avec le DNS (partie 2)

« Les discussions portant sur le DNS sont difficiles »

[Dossier] Internet, mode d’emploi : de l’URL à l’IP avec le DNS (partie 2)

Dans la première partie de notre dossier, nous avons vu comment fonctionnent les URL. C’est bien, mais ce n’est que la première étape du long chemin de la quête de notre page sur Internet. Internet ne fonctionne en effet pas avec des noms de domaines, mais avec des adresses IP (v4 ou v6, vous en avez certainement entendu parler). Voyons comment on passe de l’une à l’autre.

Le 26 mars à 12h19

Le DNS, version simple (en vrai, c’est compliqué)

Il est bien plus facile de retenir Next.ink qu’une série de quatre nombres en IPv4 ou de huit champs alphanumériques en IPv6. Mais il n’y a pas le choix, pour accéder au serveur, il faut donc transformer le nom de domaines en adresse IP. C’est le rôle du serveur DNS (on parle plutôt de DNS resolver). Voici comment le présente Wikipédia : un service « qui associe les noms de domaine Internet avec leurs adresses IP ou d'autres types d'enregistrements ».

Le DNS est très vieux puisqu’il a plus de 40 ans : « la première norme, le RFC 882, date de 1983 », rappelle Stéphane Bortzmeyer, spécialiste des réseaux et du DNS. Durant toutes ces années, le DNS est aussi le théâtre de nombreuses batailles sur la terminologie : « chacun peut constater que les discussions portant sur le DNS sont difficiles : on manque de terminologie standard, et celle des RFC officiels ne suffit pas, loin de là. Souvent, le DNS a tellement changé que le RFC officiel est même trompeur : les mots ne veulent plus dire la même chose ». Si le sujet vous intéresse, son billet de blog DNS Terminology de début 2024 est à lire (en français).

Les puristes me pardonneront, mais nous allons simplifier à l’extrême les étapes. Lorsqu’un utilisateur veut joindre Next.ink, son navigateur va contacter un résolveur DNS pour voir s’il connait l’adresse IP correspondante (si elle est en cache par exemple). Si c’est le cas, il répond et le navigateur connait alors l’adresse IP du serveur.

Il reste 80% de l'article à découvrir.

Déjà abonné ? Se connecter

Cadenas en colère - Contenu premium

Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.

Accédez en illimité aux articles

Profitez d'un média expert et unique

Intégrez la communauté et prenez part aux débats

Partagez des articles premium à vos contacts

Abonnez-vous

Commentaires (28)

votre avatar
Entre l'adresse ip et le get http, il faut ouvrir une connexion TCP avant (ou QUIC), ça a son importance avec des serveurs sur des ports exotiques, où l'on doit le préciser dans l'url justement.
votre avatar
Ayant un p'tit réseau local et un NAS, j'ai découvert l'IPv6 lorsque j'ai changé d'opérateur et bien la transition est loiiiiiin d'être trivial !

D'une part en IPv6 on a pas besoin de cacher ses appareils locaux derrière un NAT, chaque appareil a son IPv6 publique... de chez publique.

Par ailleurs, un appareil en IPv6 ne peux pas nativement communiquer avec un autre appareil en IPv4, il faut passer par un autre serveur qui va s'occuper de traduire l'IP (encapsuler, généralement). Il faut donc un NAT64, qui est, si j'ai bien comprit, souvent géré par le FAI. Mais qui dit traduction dit aussi résolution d'IP, et donc DNS. Il faut aussi un DNS64.

On peux aussi vouloir garder de l'IPv4 pour ses vieux appareils, donc faire cohabiter ces 2 réseaux. Dédoubler les règles de par-feu au niveau du routeur. Est-ce qu'on fait quand même un NAT de mon réseau local, ce qui implique du routage au niveau Application ou Ports ?

Bien content d'utiliser mes cours de Réseau d'il y a 10 ans pour me débrouiller en IPv4, mais je vous vois bien, les 3 du font de chez Moji en trains de se moquer de moi et mon p'tit réseau de rookie. 😒
votre avatar
D'une part en IPv6 on a pas besoin de cacher ses appareils locaux derrière un NAT, chaque appareil a son IPv6 publique... de chez publique.
Le NAT ne sert pas à cacher un appareil mais à partager l'unique adresse IP v4 publique que t'attribues ton FAI. C'est un effet de bord, la protection.

En IP v6, ton appareil a plusieurs adresses IP dont certaines sont privées et non visibles de l'extérieur.

Je laisse des réponses pour les autres.
votre avatar
C'est un effet de bord, la protection.
Et c'est une protection relative. Pour se protéger : firewall.
votre avatar
Oui, on est d'accord.
votre avatar
Oui, c'était un raccourci :) Je voulais surtout exprimer ma galère d'utilisateur quand j'ai essayé de le mettre chez moi.
votre avatar
Le problème vient souvent du réflexe maladif de reproduire les bricolages de l'IPv4 en IPv6. Il faut apprendre à penser autrement.

IPv6 ne permet pas uniquement de corriger le problème de manque d'adresses, loin de là. C'est malheureusement le raccourci que font tous les grincheux qui prétendent ne pas avoir besoin d'IPv6 sur les forums (je ne parle pas de toi ici bien sûr).

Mais si tu nous fais part de tes galères, nul doute que tu trouveras ici des réponses.
votre avatar
Pour l'instant j'ai pu obtenir une ipv4 fixe chez mon opérateur donc je vais en rester là. Quand j'aurai un peu de déter plus tard je viendrais toquer a la porte du forum/discord

Merci pour le support :D
votre avatar
Le nat au sens ipv4 (masquerade) est déconseillé en ipv6, vu les milliards de milliards d'adresses fournies pas une box (au lieu d'une seule), la seule traduction d'adresse à conseiller, un peu, sauf pour ipsec, c'est npt66 avec un réseau privé interne (adresses ula) et un ou plusieurs préfixes opérateurs pour faire du multihome, mais à ma connaissance aucune box opérateur ne fait ça, il faut monter en gamme de routeur
votre avatar
L'IPv6 only, nous ne sommes malheureusement pas prêt de pouvoir y passer.

j'ai voulu tester pour m'amuser il y a quelques mois, en montant un serveur IPv6 only, avec quelques services + mails.

Ce que j'en retiens :
- au niveau des mails, les grands (Google, Microsoft, etc.) s'en sortent très bien. Aucun problème.
- au niveau des mails, nos FAI nationaux, c'est juste une honte, l'IPv6 n'étant pas simplement supporté pour les plus grand acteurs, ou quand ils le sont, juste partiellement (par exemple, en envoi, mais pas en réception)
- des services plutôt orientié dev (comme Github) et donc plutôt sensibilisé à ce genre de problématique, ne sont pas accessible en IPv6. Donc si un service comme Github n'est pas accessible en IPv6 (alors qu'une bonne proportion sont sensibilisés aux enjeux), je vois mal la plupart des sites y passer.

Et pourtant, ça fait des décennies qu'on prépare l'après IPv4...
votre avatar
Et même au niveau des cours, ca reste limité aussi.
J'ai suivi une formation au CNAM (qui est quand même un organisme assez proche des entreprises et qui connaît à peu près les besoin) il n'y a pas longtemps, ca a parlé pas mal d'IPV4, et on a juste effleuré IPV6... Ca n'aide pas non plus.
votre avatar
Tiens, c'est rigolo ça. J'ai actuellement une stagiaire issue du CNAM, et les cours sont assez éloignés des besoin des entreprises je trouve. Sans doute une question de point de vue ;)
votre avatar
Ca doit dépendre des modules choisis.
Les miens étaient sur l'administration réseau, ca allait énormément en profondeur (je dirais presque trop, mais en même temps ca aide à comprendre ce qui se passe sous le capot et ne pas rester sur un "ca fonctionne tout seul, c'est magique"), et ca m'a donné pas mal de bases dans ce domaine. Je ne pourrai pas monter/gérer un réseau avec uniquement ce que j'y ai appris, mais ca va largement me faciliter la formation sur ce dont j'aurai besoin, que ce soit le montage physique comme la partie logicielle.
votre avatar
Je suis d'accord avec toi, j'avais, avant de passer "grâce" à mon FAI en NAT ipv4 et IPV6, plusieurs serveurs perso avec firewall, reverse proxy... Un peu pénible à mettre en place mais ça marchait de partout. Maintenant, avec IPV6, c'est plus simple, reverse proxy en moins, plus rapide et moins accessible, surtout sur les téléphones... Et pour les mails, c'est juste pas possible.
Vivement une vraie transition.
votre avatar
Petit commentaire avant de lire plus en détail : certaines images en texte noir sur fond gris foncé sont très difficiles à lire/voir ...
votre avatar
Petite rectification : certaines images à fond transparent avec le thème sombre sont difficiles à lire.

Mais sinon oui, je plussoie.
votre avatar
Exact !
:cap:
votre avatar
fixed :8 :chinois:
votre avatar
des RFC officiels
Marrant, j'ai toujours dit une RFC, et je viens de trouver ça :francais:
votre avatar
Ah non, on ne va pas recommencer sous cet article la discussion sur le sexe des choses (le ou la gameboy, etc...) :D

Le neutre a du bon, en fait. Raison de plus pour utiliser un (le masculin étant le neutre en français).
votre avatar
L'image :incline::love:

Je vais lire l'article.
votre avatar
Pour les IP privées, c'est 10.0.0.0/8 donc comme écrit 10.xx.yy.zz, 172.16.0.0/20 donc 172.16.xx.yy jusqu'à 172.31.xx.yy, et 192.168.0.0/16 donc 192.168.xx.yy (sur 192.xx.yy.zz, il y a d'autres adresses réservées, mais pas que)
votre avatar
172.16.0.0/12 plutôt :non:
On pourrait ajouter 100.64.0.0/10
votre avatar
'taing, comment j'ai réussi à taper 20 au lieu de 12 -_-'

Faut arrêter de faire des claviers où les touches sont les unes à côté des autres :D
votre avatar
Pour le DNS, parcourir le blog de Stéphane, une mine d'or ! Et les vidéos également sur la chaine de l'Afnic.
votre avatar
C'est ça, dis Stéphane ! Alors comme ça, on ne sait pas écrire son nom ? :D
votre avatar
Il manque aussi les adresses privées IPv6, nommées également ULA (unique local address), avec la plage fc00::/7
votre avatar
@127.0.0.1 pas de commentaire ? :D

[Dossier] Internet, mode d’emploi : de l’URL à l’IP avec le DNS (partie 2)

  • Le DNS, version simple (en vrai, c’est compliqué)

  • Changer son DNS c’est simple comme bonjour

  • Ok, mais c’est quoi une IPv4 et une v6 ?

  • Petit détour par les IPv4 locales

  • HTTP et GET pour finir

  • Au prochain numéro, le « maitre du jeu » : BGP !

Fermer