DNS

De Justine's wiki
Aller à la navigation Aller à la recherche

Introduction

Note : le site de Bortz Meyer (qui bosse à l'AFNIC) est une référence sur DNS  : https://www.bortzmeyer.org/

L'un des protocoles les plus répandus, cela dit c'est aussi un des plus difficiles à expliquer. Il est important de savoir l'expliquer simplement à un recruteur. De plus, il faut savoir l'expliquer à un débutant : lors d'un dépannage, si je peux expliquer simplement à la personne que je dépanne ce qu'est le DNS par exemple, elle aura plus confiance, une notion importante dans le travail d'admin S&R.

DNS signifie Domain Name System.

Le DNS est un:

  • Système
    • Hiérarchique
    • Distribué
  • A pour vocation de traduire des noms de domaine en adresse IP, pour que cela soit simple à lire pour un humain.

Les intérêts du DNS : le DNS travaille sur des noms de domaine, qui sont vecteurs d'identité sur le réseau (facebook, google, amazon...) : DNS permet de véhiculer une image de marque, les noms de domaine valent beaucoup d'argent. Il permet de se souvenir de notion complexes (@IPv4/6) et permet aussi d'éviter de devoir prévenir tout le monde lors d'un changement d'hébergeur (et donc d'adresse IP). 

Dans le passé, avant DNS, il existait un fichier HOSTS.txt, ancêtre de /etc/hosts qui contenait toutes les adresses IP et tous les noms d'hôte de tout le monde ! Il était distribué sur le réseau local par un point central.. Bien entendu, au moindre problème concernant les distributeurs de ce fichier prenait des proportions... De plus la gestion des droits sur ce fichier était compliquée. Cela prenait de plus du temps, et le versioning posait problème aussi.

DNS est défini dans les RFC882 et 882 en nov 1983. Il a par la suite été standardisé. BIND est créé en 1985. Le fichier HOSTS comptait 600 entrées en 1987, tandis que DNS en comptait 20000. DNS a pris 4 ans a être complètement déployé.

Les noms de domaine

Ne pas confondre nom de domaine et DNS:

  • Les noms de domaine peuvent exister sans DNS : DNS n'est qu'une des implémentations techniques des noms de domaines.

Un nom de domaine:

  • Est un identificateur sur le réseau (machine, équipement, société...)
  • Vecteur d'identité (Marques...)
  • Il y'a des règles d'obtention pour obtenir un nom de domaine : on ne peut pas avoir n'importe quel nom de domaine : il faut passer par un registrar, qui va nous louer un nom de domaine.

Un registrar est un organisme commercial ou non (eu.org). Il est habilité à délivrer des noms de domaine pour certains TLD et respecte les règles d'obtention. On peut citer : OVH, 1&1, Gandi, etc... Les règles d'obtention sont basées sur la loi du pays. 

Aspect juridique

L'AFNIC est une assoc 1901 qui gère le .fr; en cas de problème, c'est elle qu'il faut contacter (cyber-squatting, par exemple), et par là même par la justice française. 

Exemple de problème qui a existé : les iles Tuvalu ont le TLD .tv, et sont gérées par la reine Elizabeth 2. Le .tv est mal géré est passe pour de la télévision : ainsi TF1 avait acheté wat.tv. Ils ont perdu ce nom de domaine temporairement en 2009, à cause de la gestion moins performante du .tv, et ne pouvaient pas contacter l'AFNIC. Cela s'est reproduit par la suite.

Il faut s'assurer de relouer les domaines avant leur expiration pour éviter les problèmes !

De la même façon, un coréen avait acheté france2/3.com et en avait fait un site x; il a demandé des millions de $.

facebook.com a été acheté 200 000$. Etc...

Le nom de domaine étant un tel identificateur, il faut vraiment TOUT faire pour ne pas le perdre : surveiller les dates de dépassement et envoyer les mails adaptés aux responsables avant, au risque d'être face à des gens qui demandent des rançons.

Serveurs Racine

En DNS on a la racine : le . final d'un FQDN, juste au-dessus des TLD. C'est le plus haut domaine. On a alors la notion de serveurs racine : tous les serveurs racine connaissent tous les serveurs de TLD. C'est leur utilité.

Leur objectif est de relayer les demandes vers les serveurs TLD, on les contacte quand on ne sait pas qui contacter. On peut récupérer toutes ces infos par FTP, si on veut. Les résolveurs/serveurs récursifs connaissent les serveurs de racine et leurs adresses. Un résolveur peut interroger les serveurs racine si besoin.

On devrait en fait parler d'enregistrements racine ; on a 13 enregistrements de noms dans la racine, gérés par 12 structures indépendantes. Ils vont de A.ROOT-SERVERS.NET à M.ROOT-SERVERS.NET sur 24 @IP : 13 en ipv4 et 11 en IPv6. Ces enregistrements sont connus des resolvers. Leur but est (en gros) d'être SOA sur la racine et de transférer les demandes client aux TLD.

TLD : Top Level Domain

Les TLD sont souvent appellés "extensions"; c'est un abus de langage.

On a une hiérarchie dans DNS:

  • La racine tout en haut
  • Ensuite les TLD (1er niveau TLD) ou nom de domaine de premier niveau (mais la traduction est contestée).
  • Na pas dire extension : c'est du langage néophyte (un TLD n'étend rien...)

RTENOTITLE

On voit ici l'arborescence avec les TLD.

On a plusieurs types de TLD (l'aspect juridique change en fonction du pays):

  • Country-Code TLD ou ccTLD: Associé à un pays, un état souverain ou un territoire indépendant: .fr, .be, .de, etc... On en compte environ 260. Des règles existent pour les ccTLD : les .fr sont accessibles aux entreprises européennes et au particuliers dans l'UE et aussi Suède, Norvège, Islande, Liechtenstein... Valable 12 mois par tacite reconduction.
  • Internationalized ccTLD ou IDN ccTLD: c'est un TLD avec des caractères non latins ou latin accentué (d'autres alphabets) : mandarin, arabe, etc. En effet au début l'alphabet latin imposé posait des problèmes aux pays qui n'utilisent pas notre alphabet. Cela s'est fait suite à la menace d'une sission dans la racine de la part de la Chine.
  • Generic TLD : .com, net, .edu, etc... On en a environ 300, découpés en:
    • domaines génériques non commandités restreints
    • domaines génériques non commandités non restreints
    • domaines génériques parrainés : les STLD
  • Sponsored TLD ou STLD : .catholic, .coop, .frogans, .xxx, .paris, etc. L'ICANN a ouvert les TLD à ceux qui le souhaitaient pour faire évoluer les usages. Pour chacun de ces TLD, le sponsor qui le met en place doit définir une charte avec un but et des règles pour définir à quoi sert le TLD (par exemple, .museum est réservé aux musées). Cela passe par un appel d'offre et des frais de dossier élevés. Par exemple, pour .paris il faut prouver que:
    • On réside en RP
    • qu'on y exerce des activités professionelles, personnelles, commerciales ou culturelle ou que
    • l'on justifie de tout autre lien d'attachement direct ou indirect avec la région parisienne.
    • Et d'autrezs règles...
  • Reserved TLD ou RTLD :
    • Pas dans les serveurs racine, et donc impossibles à contacter
    • On a le .example, qui sert juste aux exemples pour documenter
    • .invalid
    • .localhost : éviter les conflits avec localhost
    • .test pour les tests
    • Non recommandés : .lan, .local, etc...
    • Il faut bien songer que les TLD qui n'existent pas encore pourront exister plus tard : si ils invente le .lan, on sera dans la panade si on l'as utilisé ! Il faut éviter les TLD qui n'existent pas : dans le lan, il faut créer un sous-domaine de notre domaine local.

Pour tester un TLD, on peut faire une requête sur nic.TLD : host nic.fr, host nic.xyz, etc.

Serveurs SOA et récursif

SOA

Cette partie est importante à maîtriser !

SOA:

  • Start Of Authority
  • Serveur faisant autorité sur un domaine : cela signifie que ce serveur contient la vérité sur un domaine.
  • C'est le serveur SOA qu'il faut contacter pour le domaine dont il est SOA.

Si je veux contacter trois serveurs dans un domaine coucou.fr, il faut s'adresser au(x) SOA de ce domaine. Si j'achète un domaine justine.fr et que je désigne trois SOA pour ce domaine, ces informations seront enregistrées directement dans le .fr, et tout le monde saura quels serveurs détiennent la vérité sur ce nom de domaine.

En effet on peut en avoir plusieurs:

  • Géré par les clients DNS
  • Géré par les serveurs DNS
  • Un domaine DEVRAIT avoir plusieurs SOA

On a en général un serveur primaire et un/des secondaires (Maître/esclave). Par exemple, le .fr a plusieurs soa :

  • f.ext.nic.fr
  • d.nic.fr
  • etc...

Le ext signifie que les serveurs sont à l'extérieur (pour éviter les pannes si ils sont tous dans le même site géo. / réseau). Ici, le d.nic.fr est dans le réseau et les autres sont à l'extérieur (hors du pays, en l'occurence). Il vaut mieux déclarer IPv4 et IPv6 pour chaque SOA.

Récursif

Il s'agit de serveurs résolveurs/serveurs récursifs (c'est pareil), qui interrogent les serveurs DNS pour tous les postes d'un réseau local : au lieu que chaque poste accède à tous les DNS à chaque fois en faisant la récursion lui-même, on passe par un résolveur (pour centraliser les demandes des clients) qui les résoudra. Ils sont généralement mis en place sur un LAN / réseau d'entreprise.

RTENOTITLEIci à gauche du schéma, derrière le resolver, j'aurais des clients.

Un LAN peut avoir plusieurs récursifs:

  • Répartition de charge
  • Failover (mais ralentissement en cas de panne).
  • Pas de synchro nécessaire.

Recommandations

Sur un réseau, avec un domaine:

  • Plusieurs serveurs SOA:
    • Sur plusieurs sites géographiques/plusieurs OS/plusieurs logiciels
  • Plusieurs resolveurs:
    • Au plus proche des utilisateurs
  • Resolveurs différents des SOA

Architecture du DNS : répartition

Les DNS est une base de données hiérarchique et répartie.

  • Hiérarchique : On a serveur root, serveur TLD, sous zone, etc...
  • Répartie : Plusieurs serveurs racine: les données sont découpées et réparties sur les serveurs dans la hiérarchie. Les données peuvent être synchronisées sur plusieurs serveurs.

Racine : Représentée par le point final final d'un nom de domaine, c'est le domaine de plus haut niveau, que l'on contacte quand on ne sait pas qui contacter.

Serveurs racine : Ce sont les serveurs qui connaissent tous les serveurs de niveau TLD. Les serveurs racine sont connus de tous les systèmes.

Les enregistrements racine sont répartis : on en a 13 dans la racine, qui sont gérés par 12 structures indépendantes (chacune pouvant gérer plusieurs serveurs pour un enregistrement, sur plusieurs sites géographiques). On en trouve sur presque tous les continents : grâce à l'anycast, on utilise le serveur le plus proche. Un même site peut avoir plusieurs instances (des dizaines !) pour la répartition de charge. Cela permet aussi de diminuer la probabilité de panne :

  • Matériels différents
  • De constructeurs différents
  • Avec différents OS
  • Et des logiciels de serveur DNS différents

Des attaques ont déjà eu lieu sur les serveurs racine : Le 21 oct 2002, on a eu une tentative de DDOS sur les 13 serveurs racine (à l'époque, on faisait ce qu'on voulait avec les serveurs au niveau redondance). 7 serveurs sur 13 ont été ralentis, pendant une heure; la charge était 40 fois supérieure à la normale ! Cependant le ralentissement n'as pas été ressenti grâce à la mise en cache. On a alors mis en place anycast.

Le 6 février 2007, même chose pendant 24 heures sur F, G, L, et M. Un botnet de 5000 machines, pas de ralentissement ressenti par les utilisateurs. M a remercié la mise en place d'anycast.

Répartition des données

Les serveurs racine n'ont pas toutes les données : ils savent juste quel est le prochain serveur à contacter (les TLD). Les données sont réparties sur plusieurs niveaux.

Hiérarchie des données

Tout en haut, on a la racine. Juste en dessous, le 1er niveau : les TLD.

DNS1.png

On voit que cela ne s'arrête pas là : on a d'autres trucs en dessous. On pourrait en avoir encore plus : il serait possible d'avoir un nom de domaine en dessous de Wikipédia, théoriquement. Par exemple:

  • images.wikipedia.org
  • www.fr.wikipédia.org
  • ftp.fr.wikipédia.org

Si je prend un nom de domaine justine.org, je pourrais avoir une hiérarchie de sous niveaux : admin.justine.org, api.justine.org, etc. Il faut refléter la hiérarchie de l'entreprise suivant cette logique, cela permet d'être plus efficace.

Requête DNS

On va prendre un cas réel et simple:

  • Poste utilisateur sur un réseau configuré
  • Un récursif configuré
  • Le récursif vient tout juste de démarrer, donc n'as pas de cache
  • Tout ça dans le réseau RENATER

Le client interroge le resolver pour demander l'adresse de www.stg.navigart.fr. Le récursif va:

  • Interroger un des serveurs racine avec la MÊME requête (il demande l'adresse entière).
  • Le serveur racine va répondre : "Je sais pas, demande à .fr qui a pour adresse IP [adresse des servs .fr]"
  • Le récursif demande un des serveurs SOA de .fr sans tronquer la requête
  • Qui répond : "Je sais pas, demande à un des SOA de navigart.fr, voici leur noms NS ns.videomuseum.fr @IP"
  • Le resolver demande au SOA navigart.fr : "Qui est www.stg.navigart.fr?"
  • Qui lui répond directement : "Il a pour adresse IP..."
  • Le resolver répond au client.

À chaque fois les réponses sont mises en cache. Il pourra répondre plus vite à d'autre clients faisant ces requêtes. Le resolver est utile grâce à ça, par pour la volumétrie de données mais plutôt pour les temps de réponse. Et comme les résultats intermédiaires sont mis en cache, une requête sur www.navigart.fr serait envoyée directement à ns.videomuseum.fr.

Mise en cache

Ce sont les serveurs SOA (et donc les admins de la zone) qui décident de la durée de rétention dans le cache, à travers la directive TTL, parce que ce sont les plus à-même de savoir si les données changent souvent : un TTL petit provoquera plus de demandes, un TTL long provoquera moins de demandes mais sera moins adapté à un réseau qui change beaucoup.

Quand un récursif fait une requête, il recoit un TTL en plus de sa réponse.

Pour la mise à jour d'une donnée déjà en cache, prenons un exemple :

  • Processus :
    • 1e requête à 10h : stg.navigart.fr = 129.102.242.193; TTL : 1h
    • Changement d'adresse à 10h10 : stg.navigart.fr = 129.102.242.243; TTL : 1h
    • Même requête à 10h32 : que se passe-t'il?
    • La requête étant en cache, la réponse reçue à 10h est fournie aux clients qui la sollicitent. Lors d'un changement d'adresse, il faut prévoir une période de recoupement.
  • Erreurs récurentes :
    • La propagation DNS n'existe pas.
    • Il n'y a pas de délai de propagation.
    • Les SOA ne préviennent pas de leur mise à jour.
    • Les SOA préviennent leurs secondaires dans la réplication de données, mais pas les resolveurs !
  • On utilisera plutôt:
    • Délai de conservation dans le cache
    • Délai de mise à jour du cache

Méta-données sur une zone

Une zone DNS c'est un terme technique qui définit un fichier de configuration (généralement) concernant un nom de domaine.Par exemple, on a une zone videomuseum.fr qui est un fichier contenant toutes les informations concernant tout ce nom de domaine et ses sous-domaines. Pour chaque zone, on va mettre des méta-données :

  • Un serial number
  • Un refresh
  • Un retry
  • Un expire
  • Un min TTL (c'est le TTL normal)

Le serveur SOA primaire et les serveurs secondaires sont utilisés pour répartir la charge. Quand un serveur primaire est mis à jour, les serveurs secondaires recoivent une mise à jour des administrateurs. Pour une zone donnée, le primaire et les secondaires sont tous SOA (ils ont la vérité). Tous ces serveurs sont gérés par les responsables de la zone et sont différents des resolveurs !

  • Le Serial number: il prend souvent la forme d'une date suivie d'un numéro à deux chiffres d'incrément : 2015071802. Il est utilisé pour identifier la version d'une zone (c'est un numéro de version). Il est incrémenté (manuellement sur Bind9 !) en cas de mise à jour, et utilisé dans le cas primaire/secondaire. Il est à surveiller : une erreur va couper la synchronisation.
  • Le Refresh Time : temps en secondes entre 2 demandes de màj du Serial Number de la part des secondaires vers le primaire. Avec 3600, les secondaires demanderont une mise à jour toutes les heures : un Serial Number incrémenté entraînera un transfert de zone. Sinon, non.
  • Retry Time : temps en secondes du délai d'attente entre deux demandes de transfert de zone (si un transfert de zone échoue)
  • Expire Time : temps (en secondes) d'attente avant invalidation complète de la zone lorsqu'une màj échoue. Attention : si la zone est invalidée, aucune réponse n'est donnée aux requêtes.

Les types d'enregistrement

Les données sont stockées sous forme d'enregistrement, chaque enregistrement ayant son propre type.

Une fichier de zone DNS contient : Son nom, les méta-données, des relations nom-IP et IP-nom (reverse), la liste des serveurs de noms, et d'autres choses...

Les types

  • NS : Name Server:
    • Déclaration des servs SOA dans la zone
    • Une ligne par serveur : . IN NS ns1.justine.org.
    • Attention : on fait la différence entre si on met un point à la fin (ns1.justine.com) ou sans le point (ns2) : dans ce cas le système complètera de lui-même (et fera ici ns2.justine.com)
  • A : résoudre un nom en IPv4
  • AAAA : Pareil en IPv6
  • CNAME : alias sur un autre nom
    • Canonical Name Record
    • Utile dans le cas des de serveurs web hébergant plusieurs VHOSTS, ou dans le cas de migrations de serveurs.
  • MX : Mail eXchangeur : Déclaration du/des serveurs de mail.
    • Exemple : IN MX 10 mx1.justine.com.
    •                IN MX 20 mx2.justine.com.
    • La priorité va au serveur de poids le plus faible.
  • PTR : utilisé pour le reverse DNS. On va retrouver le nom associé à une @IP.
    • Le nommage de zone se fait en inversant l'adresse IPv4 et en ajoutant .in-addr.arpa
    • Par exemple : pour 192.102.242.0/24 : La zone sera 242.102.129.in-addr.arpa
    • On renverse pour avoir un ordre hiérarchique correct.
    • Exemple d'enregistrement PTR, qui serait fait une fois la zone reverse déclarée : 129 IN PTR ecureuil.justine.com.
    • Autre exemple : 139.242.102.129.in-addr.arpa IN PTR hibou.justine.com
  • PTR en IPv6
    • En IPv6 on inverse les nibbles (les groupes de 4 bits) et on ajoute .ip6.arpa
    • Exemple : 2001:660:3004:4000::10:53 devient 3.5.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.4.4.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa IN PTR renard.justine.com.
    • Quelle horreur !
    • Sous linux, la commande ipv6calc -- in ipv6addr --out revnibbles.arpa @IP/128 fait cette inversion pour nous. Ne pas oublier le /128.
    • ipv6calc, c'est cool ! Ça évite les erreurs.
  • SRV : pour identifier des services.
    • Par exemple, je peux identifier l'adresse de connexion à un serveur XMPP, à un serveur SIP, à un contrôleur de domaine... En rajoutant un port.
  • TXT : Pour stocker des informations textuelles.
    • Utilisé entre autre par SPF pour valider les adresses IP autorisées à envoyer des mails pour un domaine.

Commande host

Cette commande permet de faire les requêtes DNS que l'on souhaite.

Par exemple :

  • host videomuseum.fr nous renverra l'adresse du serveur web et de ses deux serveurs de mail.
  • On peut aussi faire une résolution inverse : host 192.102.1.10 renverra maelzel.ircam.fr.
  • On peut aussi demander les serveurs de nom d'un domaine en particulier : host -t NS videomuseum.fr renvoie les serveurs de nom de cette zone. Bien sûr ça ne fonctionnera pas sur www.videomuseum.fr : on ne fait pas de sous-domaine avec serveur de noms d'un www, en général, ça correspond au serveur de mail.
  • Je peux aussia voir des infos sur le SOA : host -t SOA videomuseum.fr. Il renvoie aussi l'adresse mail configurée dans le fichier de zone (avec le @ remplacé par un point).
  • On peut faire une requête de type any avec host -a videomuseum.fr, ce qui donnera plus d'informations.
  • On peut interroger un serv en particulier, par exemple pour du débug : host videomuseum.fr ns.videomuseum.fr interrogera le serveur DNS précisé à la fin.
  • Pour utiliser que IPv4 par exemple, on peut ajouter -4 (ou -6 pour IPv6).

 

DNSSEC

https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-20-fr

A VOIR

Présentation

Le protocole DNS, en lui-même, n'est pas sécurisé. Il date des années 80, alors qu'internet n'était pas ce qu'il est aujourd'hui. Quand un résolveur envoie une requête vers un serveur faisant autorité, il n'as aucun moyen de vérifier son identité ou l'authenticité de la réponse. De plus, il peut alors se retrouver à mettre une réponse erronnée en cache : l'attaquant aura alors empoisonné le cache de celui-ci.

Des extensions de sécurité ont alors créées par l'IETF à partir des années 90, appellées DNSSEC. Ce système renforce l'authentification du DNS en utilisant des signatures numériques, sur le principe de la cryptographie à clefs publiques.

Chaque zone DNS a une paire de clefs. L'admin de la zone utilise la clef privée de la zone pour signer les données DNS dans la zone et générer des signatures numériques. La clef publique est publiée dans la zone même afin de pouvoir être facilement extraite. Ensuite, tout client recevant des données d'un résolveur peut aller vérifier la légitimité des données en vérifiant la signature auprès de la zone d'origine.


Schéma d'explication (très) simpliste

On gagne deux fonctions avec DNSSEC :

  • L'authentification de l'origine des données : le résolveur peut vérifier que ses données sont les bonnes.
  • La protection de l'intégrité des données : on sait que les données n'ont pas été modifiées lors du transit puisqu'elles sont signées.

La clef publique d'une zone est publiée : mais comment lui faire confiance ? Celle-ci est signée numériquement, elle aussi; pas par elle-même, mais par la "zone mère", soit son TLD. icann.org a une clef publique signée par .org. Ainsi, la chaîne de confiance remonte jusqu'au TLD lui-même. Le mécanisme réel est un peu plus complexe, bien sûr, mais le principe reste le même.

Ce jeu de clefs se signant les unes les autres est appellé chaîne de confiance; la première clef de cette chaîne est appellée ancre de confiance. Généralement, un résolveur prend comme ancre de confiance la clef de la zone racine. Il peut alors construire une chaîne de confiance pour n'importe quel nom de domaine.

DNSSEC n'est pas automatique, mais il est conseillé de le déployer. C'est très facile pour un résolveur : on a juste à lui demander de vérifier les clefs. Le déploiement sur une zone est un peu plus complexe, sans que ce soit insurmontable.

Récupérée de « https://wiki.squi.fr/index.php?title=DNS&oldid=2166 »