Qui peut m'expliquer les DNS, IP,...?

Bonjour,

Pour compléter cette réponse :

Lorsqu'un visiteur demande http(s)://example.com/, le navigateur extrait le nom (nom de domaine, sous-domaine ou tout autre nom valide comme "localhost" ou "example.lan") afin de procéder à la résolution DNS et obtient ainsi une adresse IP et peut alors établir la connexion TCP/IP avec l'IP et le port (80 ou 443, ou celui précisé).

À ce moment, le serveur n'a pas connaissance du fait que le visiteur a utilisé « example.com » pour accéder au serveur.
Cette information est transmise par le navigateur vers le serveur lors de la requête HTTP, via l'entête « Host ».

Exemple de requête HTTP pour cette page :

GET /forum/affich-36909805-qui-peut-m-expliquer-les-dns-ip HTTP/1.1
Host: forums.commentcamarche.net
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
DNT: 1
Referer: https://forums.commentcamarche.net/forum/affich-36909805-qui-peut-m-expliquer-les-dns-ip
...

Il est important de noter que cela se passe au niveau applicatif/protocole, et non au niveau réseau/DNS/IP.
Cela est donc spécifique au protocole.

D'autres protocoles permettent cette notion de « vhost » (comme FTP, voir RFC 7151), mais c'est plutôt l'exception que la règle.

Quant à la différenciation basée sur l'IP ou le port, elle est possible avec tous les protocoles, il suffit de spécifier l'IP et le port d'écoute dans la configuration du serveur, et si besoin, lancer des instances différentes.


À noter que dans le cas d'une connexion HTTPS, le serveur doit fournir le bon certificat avant la requête HTTP, donc alors qu'il n'a pas encore connaissance du nom utilisé pour la connexion.
C'est pour cette raison qu'autrefois, une IP dédiée était nécessaire pour configurer un certificat SSL, chaque site disposat de son propre point d'écoute SSL (combinaison IP/port) en faisant varier l'IP. On aurait pu se passer d'IP dédiées en faisant varier le port, mais tout le monde préfère garder le port 443.
Désormais, SSL/TLS prend en charge le « SNI » qui permet au navigateur de préciser le nom de domaine afin de recevoir le certificat adéquat. Lorsque la connexion SSL/TLS est établie, la requête HTTP peut suivre, et l'entête HTTP "Host" reste utilisée malgré que le nom soit déjà connu par SSL/TLS via le SNI, parce que ce sont souvent deux "composants" différent qui gèrent le point de terminaison SSL/TLS, et la requête HTTP.

« hackeur », c'est trop glorifiant pour ce genre de personnages sans morale. Ils ne hackent en réalité rien du tout, c'est juste du social engineering. Si tu lis attentivement ces emails menaçant, tu te rendras compte qu'en fait, le prétendu hacker ne montre jamais aucune preuve de quoi que ce soit, il joue uniquement sur le fait que le destinataire voit sa propre adresse comme expéditeur pour générer de la peur et ensuite manipuler la victime. Dans certains cas, l'arnaqueur peut joindre des informations personnelles qui se trouvent publiquement, voire des mots de passe de la victime qui ont été compromis et qui se trouvent dans des bases de données en ligne.

Les emails fonctionnent comme les courriers postaux : la personne qui composent le message et l'enveloppe peut indiquer ce qu'elle veut comme adresse expéditeur. Dans le cas des emails, il existe des protocoles (DKIM et SPF) qui permettent de vérifier si le serveur qui envoie l'email est bien autorisé par le propriétaire du domaine. Ces protocoles se basent sur les DNS (des entrées "TXT"), puisque seul le propriétaire du domaine peut configurer les entrées DNS pour son domaine.

Quant au transfert du nom de domaine, le changement de registraire n'impacte pas du tout le fonctionnement DNS. Temps que le domaine pointe sur les bons DNS et que l'entrée MX est bien configurée, tu peux alors recevoir les emails. Il faut bien-entendu configurer le serveur de messagerie, ce qui se traduit pour le client par « créer le compte de messagerie via le tableau de bord ».
À noter que tu peux tout à fait configurer un domaine et des comptes de messagerie sur un serveur, même si ce domaine ne t'appartient pas. Mais puisque le domaine ne pointe alors pas vers ton serveur, ça ne fonctionnera pas.

Mdns n'a qu'une portée sur le réseau local, aucun intérêt de le bloquer dans un parefeu, tous les routeurs le bloquent.