SRT2 DNS

Problématique ● Toutes machines accessibles sur le net ont une adresse IP publique – Numériques, non mémorisables par un n'êtrumin. – Même sur un réseau local, adresses IP privées, grand nombre de machines – Mécanisme pour associer un nom à une adresse IP – Trouver l'adresse IP correspondante à un nom : Résolution DNS – Trouver le nom correspond à une adresse : Résolution DNS inverse

Résolution locale ● Résolution statique locale : correspondances dans un fichier ● /etc/hosts ● correspondance entre une adresse IP et une nom ● [ ] – Permet à la machine une résolution locale – Bien évidemment, pas adapté à un grand nombre de machines ● Difficile à maintenir et à dupliquer ● Invention de DNS en 1983

Domain Name System ● Mécanisme Client / Serveur sur le client ● Adresses de serveurs DNS configurées sur le client : ● /etc/resolv.conf nameserver nameserver ● Le client envoie une requête DNS au premier serveur : « quelle est l'adresse IP de ? » ● Le serveur écoute sur port 53, renvoie une adresse IP. ● Si pas de réponse ou réponse négative, demande au deuxième serveur ● Possible de demander nom associé à une adresse IP.

Nom de domaine ● Un nom de domaine (domain name) est constitué de deux ou plusieurs parties (labels ou segments) séparés par des points. ● Au hasard : ●.fr est un TLD ●.fr est un TLD : Top-Level Domain : domain de niveau le plus élevé ● Chaque label à gauche est un sous-domaine ● Il peut y avoir jusqu'à 127 niveau, chaque label maximum 63 caractères, taille totale 255 caractères ●. à droite de.fr est un root domain, le point de départ de tous les domaines

Organisation hiérarchique ● L'espace de noms de domaines est organisé en arbre. ● L'arbre se divise en zones, servies par un serveur de référence (authoritative DNS nameserver) zone assemblage de sous-domaines, tant que cet assemblage est géré par un seul serveur DNS ● Une zone n'est pas seulement un sous-domaine, il peut s'agit d'un assemblage de sous-domaines, tant que cet assemblage est géré par un seul serveur DNS. ● Par exemple, pour le domaine bidule.classe1.admin.tellnet.fr ● Un serveur DNS s'occupe de.fr ● Un autre serveur DNS s'occupe de la zone admin.tellnet déléguer ● Un troisème se voit déléguer la gestion de la zone bidule.classe1

Organisation hiérarchique (suite) ● Ainsi, le Domain Name System est un ensemble de serveurs DNS ressource records ● Chaque domaine ou sous-domaine faisant partie d'une zone a un authoritative DNS server qui publie de l'information à propos de ce domaine : les ressource records déléguée – Il indique également qui s'occupe de la zone « en-dessous » déléguée à un autre serveur DNS haut de la hiérarchieroot nameservers, qui s'occupent du root domain et des TLD qui sont les serveurs s'occupant des sous-domaines des TLD ● En haut de la hiérarchie, on trouve les root nameservers, qui s'occupent du root domain et des TLD. Ils indiquent également qui sont les serveurs s'occupant des sous-domaines des TLD. ● Un serveur DNS peut s'occuper de plusieurs zones

Organisation hiérarchique (suite)

Root servers ● Répartis un peu partout sur la planète, surtout aux US

Fully Qualified Domain Name ● Un FQDN identifie de manière unique une machine : ● Il s'agit de l'assemblage d'un nom de machine (hostname) et d'un nom de domaine (qui comprend un ou plusieurs sous- domaines + un TLD + le root domain implicite) ● FQDN = host.domain.tld. ● Par exemple : ● Le point à la fin est implicite (rajouté par défaut) mais fait partie du FQDN. Nécessaire dans certaines configurations de DNS. ● Essayez dans un browser. ● En matière de sécurité, association entre un FQDN et un certificat

Mécanisme de résolution d'adresses logiciel client resolver local ● Pour obtenir l'adresse IP de le logiciel client (par exemple, le browser) client s'adresse au resolver local. au serveur DNS ● Ce resolver local s'adresse au serveur DNS (qui est lui-même un resolver) ● Le serveur possède la liste des root servers s'occupant de. un des root servers ● Il demande à un des root servers quel est le root servers s'occupant du TLD.fr au root server s'occupant de.fr serveur s'occupant du domaine tellnet ● Il s'adresse ensuite au root server s'occupant de.fr pour connaître l'adresse du serveur s'occupant du domaine tellnet l'adresse IP du host www ● Finalement, il demande à ce serveur l'adresse IP du host www ● Renvoie l'adresse IP obtenue au client

Mécanisme de résolution d'adresses

Requêtes récursives ● Par défaut, les serveurs DNS doivent accepter les requêtes itératives : – Le serveur peut fournir une réponse partielle, le resolver ayant fait la requête consulte les autres serveurs DNS pour obtenir une réponse complète ● Les requêtes récursives peuvent être acceptées : – Le serveur peut dans ce cas s'occuper lui-même de consulter les autres serveurs DNS pour fournir une réponse complète au resolver ayant fait la requête

Mise en cache ● En réalité, pour éviter un trafic important sur internet pour chaque requête DNS, ainsi qu'une surcharge des serveurs DNS s'occupant d'une zone (et surtout des root servers), les concepteurs ont mis en place la notion de mise en cache ● Le TTL (Time To Live) définit la durée de validité d'une réponse ● Les DNS des FAI mettent en cache les réponses DNS envoyées à leurs clients : non-authoritative answer (la réponse peut être périmée)

Mise en cache ● Les resolver des clients mettent également les réponses dans un cache (pas sous Linux en standard) ● Sous Linux, pas de resolver faisant du cache. ● On peut installer un serveur DNS en tant que resolver exclusivement, pour mise en cache des enregistrements DNS ● On ne fait plus de résolution d'adresse pendant le caching time

Mise en cache (suite) ● L'administrateur d'une zone doit donc fixer un TTL pour cette zone – Bien souvent, quelques heures, voire quelques jours – Beaucoup plus court pour les noms de domaines dynamiques ● Bien souvent, les logiciels clients (browsers surtout) possèdent également un cache interne, leur évitant de demander à leur resolver local ● Mais opacifie un éventuel deboguage – Vider le cache du resolver local mais le browser continue de faire la résolution !!! GRRRR

Mise en cache (suite)

Resource Records ● Ce sont les informations stockées pour une zone ● Il y a plusieurs types d'informations ● Une des plus intéressante : l'enregistrement MX (Mail eXchange) – Quand vous voulez envoyer un mail à votre serveur SMTP ne connaît l'adresse du serveur SMTP de – Il doit donc effectuer une requête auprès du serveur DNS de tellnet.fr : «quelle est l'adresse du serveur de mail de tellnet.fr ? » – En fait, votre serveur SMTP demande les enregistrements MX de tellnet.fr.

Resource Records ● host -v -t MX tellnet.fr ● Trying "tellnet.fr" ● ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ● ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 8 ● ;; QUESTION SECTION: ● ;tellnet.fr. IN MX ● ;; ANSWER SECTION: ● tellnet.fr IN MX 10 mx00.1and1.fr. ● tellnet.fr IN MX 10 mx01.1and1.fr. ● ;; ADDITIONAL SECTION: ● mx00.1and1.fr IN A ● mx01.1and1.fr. 933 IN A ● Received 204 bytes from #53 in 73 ms

Resource Records ● A record ou address record qui fait correspondre un nom d'hôte à une adresse IPv4 de 32 bits. ● AAAA record ou IPv6 address record qui fait correspondre un nom d'hôte à une adresse IPv6 de 128 bits. ● CNAME record ou canonical name record qui permet de faire d'un domaine un alias vers un autre. Cet alias hérite de tous les sous-domaines de l'original. ● MX record ou mail exchange record qui définit les serveurs de mail pour ce domaine. ● PTR record ou pointer record qui associe une adresse IP à un enregistrement de nom de domaine.

Resource Records ● NS record ou name server record qui définit les serveurs DNS de ce domaine. ● SRV record qui généralise la notion de MX record, standardisé dans la RFC ● NAPTR record qui donne accès à des règles de réécriture de l'information, permettant des correspondances assez lâches entre un nom de domaine et une ressource. Il est spécifié dans la RFC ● TXT record permet à un administrateur d'insérer un texte quelconque dans un enregistrement DNS. Par exemple, cet enregistrement était utilisé pour implémenter la spécification Sender Policy Framework.

Resource Records ● SOA record ou Start Of Authority record qui donne les informations générales de la zone : serveur principal, de contact, différentes durées dont celle d'expiration, numéro de série de la zone. ● Le SOA doit être défini dans l'en-tête de la zone dans le serveur DNS

SOA Record ● Cet enregistrement permet d'indiquer le serveur de nom faisant autorité, un contact technique et des paramètres d'expiration. Ces paramètres sont dans l'ordre : ● Serial : indique un numéro de version pour la zone. Ce nombre doit être incrémenté à chaque modification du fichier zone. On utilise par convention une date au format yyyymmddhhmm ● Refresh : le nombre de secondes entre les demandes de mise à jour réalisées depuis le serveur secondaire ou les serveurs esclaves. ● Retry : le nombre de secondes que doivent attendre le serveur secondaire ou les serveurs esclaves lorsque leur précédente requête a échouée.

SOA record ● Expire : le nombre de secondes après laquelle la zone est considérée comme gelée si le secondaire ou les esclaves ne peuvent joindre le serveur primaire. ● Minimum : utilisé pour déterminer la durée de vie minimum du fichier de zone. ● Notez le point à la fin de la zone, après le TLD ● maboite.com. IN SOA serveur.example.com contact.example.com ( ● ;serial (version) ● 3600 ;refresh period ● 900 ;retry refresh this often ● ;expiration period ● 3600 ;minimum TTL ● )

Mise en oeuvre ● Implémentation la plus courante : BIND : un standard de fait ● Berkeley Internet Name Domain / Daemon ● Dernière version : 9 failles résolues et sécurité augmentée ● /etc/init.d/bind ● ou /etc/init.d/named

Configuration ● /etc/named.conf (RH) ● /etc/bind/named.conf (Debian) : ● Contient la configuration principale de bind ● Définit où sont stockés les fichiers de configuration des zones que vous possédez (Zone File) – En général, en deux parties : – Forward Zone File : correspondances noms vers adresses IP – Reverse Zone File : adresses IP vers noms – Ces fichiers sont des bases se trouvant dans /var/named/

Configuration /etc/named.conf ● section options { } – Configuration générale du serveur : sur quel port bind écoute-t'il ? ● sections logging { } – Configuration des logs du serveur ● Ensuite, on trouve des sections (« views ») définissant à quels clients on sert les requêtes – Par exemple, pour ne servir que les requêtes provenant des réseaux directement connectés au serveur. ● Pas nécessaire de définir des views, mais autant commencer à les utiliser dans le cas d'un rajout ultérieur.

Configuration /etc/named.conf ● view "localhost_resolver" { } – Cette section définit que bind est le propre serveur DNS de la machine, dans cette section on n'autorise la machine à ne répondre qu'à elle même ● La machine est son propre serveur DNS : il faut le définir dans /etc/resolv.conf nameserver localhost

Configuration /etc/named.conf