Relation nom-@ip-type-ttl IP assure service sans connexion ICMP envoi de messages entre couches IP de nœuds IGMP gestion appartenance à un groupe Xcast TCP assure service fiable avec connexion FTP transfert fichiers SMTP messagerie électronique TELNET présentation d écran avant: fichier /etc/hosts diffusé vers autres machines depuis 1984: utilisation DNS qui évite: congestion serveur unique maintenance centralisée 3 Domain Name System Schéma hiérarchique par noms de domaines domaine: unité pour construction et gestion de noms (comme rép. dans SGF) hiérarchie de noms a une racine multiple : domaines de 1 niveau (TLD) domaines génériques domaines géographiques microsoft.com com org edu fr mc icann.org mit.edu unice.fr gouv.mc sun.com cs.mit.edu java.sun.com 4 deptinfo.unice.fr
TLD Domaines et zones domaines géographiques: fr, mc, it, jp... domaines d activité génériques: com, org, edu, net domaines génériques domaines géographiques com org edu fr mc icann.org mit.edu unice.fr gouv.mc microsoft.com sun.com cs.mit.edu deptinfo.unice.fr 5 java.sun.com Domaine: unité de désignation (espace de noms) Zone: unité de gestion administrative (serveur de noms propre à la zone) souvent, un domaine est une zone mais une zone peut regrouper plusieurs domaines administrés en commun 7 Attribution des noms Problème et principe dans chaque domaine, noms attribués par autorité responsable TLD par ISOC via groupe technique domaines publics (com, org, net...) une seule autorité centrale: ICANN domaines géographiques : autorité nationale: AFNIC en France, Namebay à Monaco pour les domaines inclus: autorités locales (entreprise, administration,...) Donnée: nom symbolique d une machine Sortie: @IP de la machine Principe: fonctionnement décentralisé hiérarchie de serveurs calquée sur hiérarchie de zone fonctionnement par caches (infos dupliquées) indicateurs (informations valides pdt tps donné) info accessible par voies et confirmée si nécessaire favorise tolérance aux fautes 6 8
Fonctionnement Fonctionnement 2 serveurs de nom par zone performances et tolérance aux pannes maintien table Resource Records (nom domaine-@ip) : (nom, valeur, type, durée de vie) recherche: soit serveur dns connaît l @IP, soit il a l adresse d un autre serveur qui peut la connaître. mode récursif mode itératif Accélération: serveurs mettent en cache (nom,@ip) récemment résolus; rare de contacter 1 serveur Autorités: tous les serveurs ne sont pas mis à jour en permanence. Seuls certains le sont et font autorité: authoritative answer non authoritative answer 9 11 Fonctionnement (1) le client envoie sa requête DNS à un serveur récursif choisi dans le fichier /etc/resolv.conf. Le client essaye au besoin plusieurs serveurs. (2) si le serveur a autorité sur la zone du domaine de la requête (authoritative),il répond directement avec les informations (gérées) localement (3) sinon il va rechercher le serveur cible du domaine de la requête, il relaye la requête vers ce serveur et relaye ensuite la réponse vers le client. Pour la recherche du serveur cible, on va : (a) choisir un parent (connu localement) du domaine recherché : c est ici soit la racine, soit le domaine que l on gère pour une requête concernant un descendant de ce domaine local. (b) interroger successivement les serveurs (informations NS) pour parcourir la branche entre le serveur parent et le serveur cible. Cet algorithme simplifié possède deux modes de résolution : récursif et itératif. Le premier consiste à demander à un serveur de résoudre complètement la requête et de renvoyer uniquement la réponse finale. Le mode itératif consiste à demander à un serveur la meilleure information dont il dispose par rapport à la question, c est-à-dire soit la réponse soit la référence à un serveur «plus proche» de la réponse. On itère ensuite de serveur en serveur. 10 client domaine D Fonctionnement smtp.unice.fr? 6 1 134.59.1.112 récursif ou Itératif? serveur local à D cache 12 5 smtp.unice.fr? 3 smtp.unice.fr? smtp.unice.fr, 134.59.1.112 134.59.1.112 2 taloa.unice.fr. 4 serveur racine serveur unice.fr *.unice.fr. le + proche taloa.unice.fr.
Serveur racine contient noms de domaine du second niveau et @IP correspondantes unice.fr. 86400 IN NS taloa.unice.fr. unice.fr. 86400 IN NS dns.inria.fr. unice.fr. 86400 IN NS samoa.unice.fr. serveur racine largement dupliqué. plus serveur est haut, + il a de copies et + TTL est grand // file db.admrx.test $TTL 3600 Contenu fichiers @ IN SOA ns1.admrx.test. root.admrx.test. ( 1 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600 ) ; Minimum @ IN NS ns1.admrx.test. ; Machine Names // nom et adresses des hotes selon l'exemple ci-dessous: ns1 IN A 192.168.1.1 et modifier le fichier resolv.conf: search admrx.test unice.fr nameserver 192.168.1.1 nameserver 134.59.130.1 // file db.1.168.192 $TTL 3600 @ IN SOA ns1.admrx.test. root.admrx.test. ( 20021111 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600 ) ; Minimum IN NS ns1.admrx.test. ; Machine Names 11 IN PTR host1.admrx.test. 12 IN PTR host2.admrx.test. 1 IN PTR ns1.admrx.test. PTR: pointeur vers une autre partie de l espace des noms de domaine 13 15 Serveur de zone Contenu tables et RR contient (noms,adresse) d hôtes des domaines de zone [(noms,adresse) de serveurs de sous-domaines] i3s.unice.fr. 86400 IN SOA taloa.unice.fr. SOA: start of authority (serveur racine) type: indique comment interpréter le champ valeur A(AAAA): valeur @IPv4 (@IPv6) NS: valeur nom de domaine d un serveur de nom CNAME: nom canonique (si alias) MX: mail... classe: IN (internet) CH (pour chaosnet LAN du MIT 70) durée de vie: TTL (pour rafraîchir) 14 16
Format des messages Les messages de requête et de réponse ont le même format. soit au-dessus d UDP soit au-dessus de TCP sur le port 53 dans les 2 cas, TCP si la taille du message dépasse 512 octets ethernet 0000 00 50 56 a7 4e d0 00 22 41 36 00 40 08 00 45 00.PV.N.." A6.@..E. 0010 00 3b 65 dc 00 00 40 11 f5 fe 86 3b 09 60 86 3b.;e...@....;.`.; 0020 09 01 cf e1 00 35 00 27 1f 10 54 3a 01 00 00 01...5.'..T:... 0030 00 00 00 00 00 00 04 73 6d 74 70 05 75 6e 69 63...s mtp.unic 0040 65 02 66 72 00 00 01 00 01 e.fr.... nb rép nb aut type A nb add UDP id flags (query) IPv4 class IN nb quest 04 73 6d 74 70 05 75 6e 69 63 65 02 66 72 00 s m t p u n i c e f r 4 5 2 0 17 19 id: nb de 16 bits pour requête, réponse utilise le même nb flags: query or reply récursion demandée récursion disponible réponse authoritative 18 identification nombre questions nombre de authority flags nombre de réponses nombre de additional questions (# variable) réponses (# variable) authority additional les 4 champs «nombre de» donnent le nombre d objets des 4 section suivantes questions: RR incomplets {nom-dns,type,classe} réponses, auth, add: RR complets: {nom-dns,type,classe,(rdata_length),rdata} 12 octets Résolution de nom tout hôte connaît @IP de serveurs de noms adresses fournies aux utilisateurs par FAI inscrites à la main dans les tables de configuration pour l accès à internet 20
Utilitaires unix Commande dig Plusieurs utilitaires pour faire une requête dns: host nslookup dig effectue requête (@IP à partir du nom; requête inverse avec option -x) dig example.com options +trace : effectue requêtes itératives +short : réponse courte + nssearch : cherche soa: start of authority +all : affiche tous les champs +nocomment : retire les champs commentaires mx : champ mail AAAA effectue une requête IPv6 serveur alternatif par dig @ns.alternatif.ex example.com 21 23 Commande host Fichiers unix correspondants effectue requête (@IP à partir du nom ou inverse) host example.com [ns.alternatif.ex] host -t type example.com l option -t à valeurs dans a : adresse mx : champ mail ns: serveur de noms cname: nom cannique soa: start of authority l option -a affiche tous les champs l option -6 effectue une requête IPv6 fichiers consultés lors de requêtes, pour trouver l adresse d une machine ou d un serveur dns /etc/hosts: donne la correspondance entre noms canoniques et adresses IP (locales) /etc/resolv.conf: fournit les adresses de serveurs dns (jusqu à 6): nameserver 134.59.1.7 # IP du serveur dns domain unice.fr # nom du domaine local Toute réponse dhcp écrase /etc/resolv.conf 22 24
Arpanet 1982 Mail conception système + élaboré (par étudiants) devenus des normes transmission dans RFC 821 format message RFC 822 (puis 2821 et 2822) vainqueur du X.400 CCITT (trop complexe) Le mail en 1980 Architecture protocole de transfert de fichier; première ligne = adresse destinataire limitations pas diffusion à un groupe pas de structuration interne peu d intégration Interface/transmission envoi autre chose que du texte impossible Mail composé des sous-systèmes: agent utilisateur (MUA): lecture et envoi; programmes locaux interagissant avec le système de messagerie par CLI ou GUI agent de transfert (MTA): acheminement; processus démons assurant le transport agent de dépôt (MDA): lien avec BAL utilisateur
Schéma général Enveloppe vs contenu En-tête Corps à: Bruno Martin Adresse Priorité Chiffrement de: Adresse Objet Texte Enveloppe Message Encapsulation Fonctions de base Format de message RFC 822 composition transfert: processus d acheminement automatique de l émetteur vers le destinataire notification: mail remis, rejeté ou perdu? affichage: lecture des messages disposition: traitement mail (lire, détruire, enregistrer...) En-tête To: Cc: Bcc: From: Sender: Received: Return-path: Description @DNS auteur @messagerie expéditeur info sur chaque MTA identifie chemin retour
Format de message RFC 822 MIME (RFC 1341 2045..2049) En-tête Date: Reply-To: Message-Id: In-Reply-To: References: Keywords: Subject: X-... Description n réf. unique mail id mail précédent autres ids pertinents pour usage privé Multipurpose Internet Mail Extension prend en charge caractères accentués ou non latins messages non textuels par ajout d une structure au corps du message et de règles de codage tout en utilisant le format RFC822 En-têtes En-tête Mime-version Content-Description Content-Id Content-Transfert-Encoding Content-type Description N version descr. contenu id. unique méthode encapsulation (5+1) type et format contenu
base64 6 bits 6 bits 6 bits 6 bits Schéma général chaque paquet de 6 bits= 1 caractère ASCII A=0..Z=25 a=26..z=51 0..9 +=52 /=63 == dernier groupe ne contient que 8 bits = dernier groupe ne contient que 16 bits b64(ex=101,120)= ZXg= =25,23,32,63 01100101,01111000 = ex 011001,010111,1000.00,- - - - - - = ZXg= Quoted-printable Transfert de messages format de codage de données sur 8 bits, qui utilise exclusivement les caractères alphanumériques ASCII (7 bits). QP remédie à ce problème, en procédant par: Un octet correspondant à un caractère imprimable de l'ascii est représenté tel quel Un octet qui ne correspond pas à un caractère imprimable de l'ascii est représenté par un signe égal, suivi de son numéro en hexadécimal. Exemple: "é" en latin-9 par 233 en QP "E9" MTA se charge de l acheminement des mails MUA construit message et le transmet au MTA qui utilise certains des champs d en-tête pour construire l enveloppe effective MTA = smtpd, serveur de mails, IP identifiée dans DNS par MX-record
Réception MTA Transfert en provenance de: MUA: FAI propose un service de MTA permettant au MUA d envoyer tous ses mails par son MTA MTA: la plupart des MTA servent à retransmettre dans un réseau les messages reçus en ajoutant un champ Received mails non rejetés sont transférés au MTA du destinataire par smtp si le MTA est le MTA traitant le mail, il est transféré à un MDA (ou traité directement) par protocole LMTP (local mail transfer proto) dépend du serveur; pour certains, MTA=MDA Mise à jour du Return-Path Rejet message par MTA smtp serveur non concerné: config MTA n accepte que les mails expédiés depuis le réseau du FAI non-respect des normes: si le mail est non conforme ou en cas de non respect du smtp expéditeur black-listé: serveur réputés utilisés par spammers sont black-listés et certains MTA rejettent les mails provenant de ces serveurs notification rejet n est plus systématique
Conversation (simplifiée) Codes de retour 2xx 3xx 4xx 5xx commande exécutée sans erreur demande en cours d exécution erreur temporaire; ré-essayer + tard demande invalide et non traitée http://www.greenend.org.uk/rjk/tech/smtpreplies.html Session SMTP Rôle du MX-record MTA expéditeur fait requête sur le champ MX du DNS de chaque destinataire En réponse, il obtient une liste ordonnée de serveurs de mails dans chaque domaine MTA établit session smtp avec un des serveurs Si pas de MX, MTA fait une requête sur le A- record (@IPv4)
Requête MX Indisponibilité MTA1 transfère vers MTA2 indisponible MTA1 met mail en file attente re-tente la transmission plusieurs fois Après un nb d essais infructueux (ou d un time out), le message est rejeté Serveur secondaire MTA classiques 2 MTA par réseau (primaire et secondaire) secondaire = store and forward prend le relai en cas de pb ne fournit pas tjs le service mise en attente message jusqu au redémarrage du primaire 85% des mails sont gérés par: sendmail postfix exim Microsoft exchange server tous implémentent un démon smtp
Spammers technique Remède utilisent les relais ouverts utilisent le MX-serveur secondaire pas les mêmes techniques anti spam SMTP normal= pas d authentification de l utilisateur ajout d une extension SMTP-AUTH ne réussit pas à s imposer; utilisation limitée recherches en cours, par groupe de travail Anti- Spam Research Group de l IRTF. Open relay Schéma général raisons historiques: pas authentification expéditeur (falsification possible) FAI limitent usage MTA aux machines de son seul domaine sinon= open relay qui accepte n importe qui
MDA Les plus classiques Post Office Protocol (tcp 110) Internet Message Access Protocol (tcp 143) [webmail] les utiliser dans leur version sécurisée (pop3s 995 et imaps 993) MDA POP IMAP single access multiple access Rôle: distribution courrier dans les BAL utilisateurs transfert sur client conservé sur serveur filtres différents anti-spam, anti-virus, personnalisés actions sur client folders sur client actions sur serveur folders sur serveur