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

Signaler
-
 mario -
Bonjour,
J'ai plusieurs hébergement chez OVH et plusieurs nom de domaines. Je finis toujours par m'en sortir, mais en fait je réalise que c'est en testant tout et n'importe quoi et même si ça marche en fait, j'aimerais comprendre de façon plus précise ce que je fais.
Je pense qu'il manque une pièce principale dans mon puzzle ou une case dans mon cerceau :D

Je ne comprends pas comment un nom de domaine peut pointer vers un hébergement avec une entrée A référençant une adresse IP alors qu'à ma grande surprise (server mutualisé oblige) plusieurs de mes noms de dom pointe vers la même IP alors que ce sont bien des hébergements différents avec un contenu différent.
En fait, je ne comprends pas comment le nom de domaine "comprends" vers quoi il doit pointer alors que la même IP pourrait signifier plusieurs contenu différent.

Qui peut m'expliquer?

3 réponses

Messages postés
30003
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
14 novembre 2020
6 953
Bonjour,

La demande issue d'internet est redirigée vers le bon site par le logiciel serveur web qui tourne sur la machine physique. Si tu avais une machine, et pas seulement des hébergements web, tu devrais te charger de ce paramétrage.

Ce logiciel serveur Web, c'est par exemple Apache. Dans ses fichiers de paramétrage, on configure des VirtualHost. A partir de ce paramétrage, Apache va étudier l'url entrante de la demande et l’exécuter en utilisant la racine des pages sources correspondant au domaine sollicité.

En gros on va avoir comme paramètres pour un VirtualHost :
- une ip entrante de la machine (éventuellement un port), sachant que sur une machine on peut avoir plusieurs cartes et donc plusieurs ip
- une racine de sources d'un site web
- un nom de domaine entrant

Ce paramétrage permet, en plus de l'utilisation pour "un site/un nom", de nombreuses combinaisons, par exemple rediriger plusieurs noms de domaines (nnnn.com et nnnn.net) vers le même site web. Avoir un site de production et un site de test (le premier sur le port standard 80, et d'utiliser par exemple le port 8080 pour le site de test).

voir : https://httpd.apache.org/docs/2.2/fr/vhosts/examples.html

Messages postés
18470
Date d'inscription
dimanche 17 février 2008
Statut
Contributeur
Dernière intervention
12 novembre 2020
4 225
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.
Ok, merci pour vos éclaircissements.
J'ai une question que je me pose en lien avec tout ceci :

En ce moment énormément de faux emails circulent et les malfrats ont réussi à créer des adresses mail avec le bon nom de domaine dont ils ne sont pourtant pas propriétaire.
Je trouve que c'est une faille de sécurité plutôt énorme, comme cela se fait-il?

Concrètement, voici l'exemple :
Je suis propriétaire du nom de domaine et de l'hébergement : contact arrobase commençamarche.net
Un hackeur parvient à m'envoyer un mail sur cette boite mail avec un adresse xxxxxx arrobase commençamarche.net
Comment cela est-il possible?

Récemment, j'ai également fait un transfert d'un nom de domaine et j'ai été surpris que j'aie pu immédiatement créer les adresses mails (avant même que le transfert soit validé), mais je pouvais uniquement recevoir les emails et pas en envoyer...
J'aimerais comprendre mieux tout cela en lien avec les DNS
Messages postés
18470
Date d'inscription
dimanche 17 février 2008
Statut
Contributeur
Dernière intervention
12 novembre 2020
4 225 > cnob
« Du coup, par rapport à ton deuxième paragraphe, comment se fait-il que les protocoles en place n'aient pas détecté que la personne qui tente de créer une nouvelle boite mail avec ce nom de dom ne soit pas propriétaire des entrées TXT du dom en question? »

Si le nom de domaine est nouveau, DKIM et SPF peuvent ne pas avoir été configuré et donc le serveur du destinataire ne peut pas procéder à la vérification. La vérification DKIM/SPF doit être configurée du côté du destinataire. L'email peut être rejeté ou classé parmi les spams. Si le propriétaire du domaine a bien configuré DKIM/SPF, le destinataire devrait voir, dans les entêtes, le résultat ("fail" ou "pass") pour DKIM et SPF.

« Au sujet, des noms de domaine, c'est ça qui m'intrigue justement, c'est que ça fonctionne: ça marche à moitié, mais ça marche. Je peux ENVOYER, mais PAS recevoir. Ca a surement un lien avec ce que tu expliques plus haut: le fait qu'on puisse se prétendre expéditeur de quelque chose, sans l'être vraiment (sans être possesseur du nom de dom) »

Oui c'est exactement ça, n'importe qui peut envoyer un email en se faisant passer pour n'importe qui, c'est le destinataire qui doit procéder à la vérification, et pour cela, c'est le propriétaire du domaine qui doit annoncer (via les DNS) les serveurs légitimes pour envoyer des emails en utilisant son domaine.

Comme dit précédemment, tu peux tout à faire configurer un domaine quelconque sur ton hébergement / serveur, créer des comptes de messagerie, et donc envoyer des emails avec ce domaine qui n'est pas à toi ou qui ne pointe pas encore vers ton hébergement.

À l'inverse, la réception ne fonctionne pas puisque le domaine ne pointe pas vers ton serveur. Imagine le carnage s'il me suffisait de configurer « contact@google.com » sur mon serveur pour recevoir les emails de Google... Donc je peux envoyer des emails en me faisant passer pour contact@google.com, bien que tout antispam devrait détecter que mon serveur n'est pas autorisé par google.com (via SPF / DKIM). Je ne peux cependant pas recevoir les emails de contact@google.com.

« mais du coup... je trouve ça vraiment dingue en terme de sécurité. »

La même arnaque existe avec les courriers postaux. N'importe qui peut t'envoyer une facture en usurpant l'identité d'un de tes fournisseurs, et te demander de payer par virement vers le compte bancaire de l'arnaqueur.
C'est bien au destinataire de prendre ses dispositions afin de vérifier l'authenticité de l'expéditeur.
>
Messages postés
18470
Date d'inscription
dimanche 17 février 2008
Statut
Contributeur
Dernière intervention
12 novembre 2020

@avion-f16 "C'est bien au destinataire de prendre ses dispositions afin de vérifier l'authenticité de l'expéditeur."
--> je pensais naïvement que cette manipulation informatique comportait plus de restrictions que le courrier postal justement. J'ai donc appris quelque chose grâce à toi, merci :D
Notez quand même que je n'ai jamais été assez bête pour me faire piégé par quelconque fishing, je croise toujours les infos et relève les incohérences. C'est juste que parfois je trouve que ça sent le caca, que j'en suis sûr, mais que je ne comprends pas comment techniquement on a pu créer cette puanteur ^^
Messages postés
95157
Date d'inscription
lundi 16 juillet 2001
Statut
Modérateur
Dernière intervention
14 novembre 2020
10 938 > cnob
Salut,
quand tu crées un compte chez OVH, forcément tu le crées avec une adresse mail qui n'est pas dans le domaine que tu crées.
Le mail vient de postmaster@ton-nouveau-domaine ?
Après, tu peux enregistrer un domaine sans ouvrir d' hébergement donc dans boite mail non plus.
>
Messages postés
95157
Date d'inscription
lundi 16 juillet 2001
Statut
Modérateur
Dernière intervention
14 novembre 2020

Effectivement Brupala.
Mais là, je faisais bien référence à une adresse mail qui appartient au domaine crée. Quelque jour plus tard, tu reçois un mail se faisant passer pour OVH et dont l'expéditeur est en fait : tonnomdedomaine@tonnomdedomaine (paradoxalement forcément, mais pour des raisons de confusions psychologiques chez le destinataire, ça peut produire un certain effet)
Messages postés
95157
Date d'inscription
lundi 16 juillet 2001
Statut
Modérateur
Dernière intervention
14 novembre 2020
10 938 > cnob
bonjour, doit on bloquer le port 5353 en entrée dans le pare feu, de Mdns microsoft edge , merci
Messages postés
95157
Date d'inscription
lundi 16 juillet 2001
Statut
Modérateur
Dernière intervention
14 novembre 2020
10 938
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.
>
Messages postés
95157
Date d'inscription
lundi 16 juillet 2001
Statut
Modérateur
Dernière intervention
14 novembre 2020

merci de la réponse brupala