Principes de base

1. Indications de racines

Lorsque l’on demande à un serveur DNS (Domain Name System) de traduire un FQDN (Fully Qualified Domain Name) en adresse IP, deux cas de figure sont possibles : soit le serveur DNS connaît la réponse à la question posée, car il possède cette information dans un enregistrement DNS ou en cache dans sa mémoire RAM, soit il ne la connaît pas et il doit alors demander à un autre serveur DNS.

Dans le cas où il demande à un autre serveur, il peut, entre autres, envoyer sa demande a un des serveurs DNS racine, qui sont accessibles publiquement sur l’Internet.

Pour rappel, les serveurs DNS racine connaissent les adresses des serveurs TLD (Top Level Domain), qui gèrent la dernière partie d’une adresse, comme .com, .edu, .fr, ou encore .gouv.

Les serveurs TLD vont donner au serveur DNS l’adresse du serveur qui gère le domaine que l’on veut joindre, comme ecole.com ou eni.fr, et ce dernier nous renverra l’adresse IP du serveur qui gère le service que l’on veut joindre comme www.eni.fr.

Ce processus est connu sous le nom de recherche itérative. Les adresses IP des serveurs racine qui permettent de débuter ces recherches sont disponibles dans le système.

a. Visualiser les indications de racines

Dans un serveur DNS Windows, il est possible de repérer les indications de racines...

Le lab

Pour explorer ensemble le service DNS dans Windows Server, nous allons nous servir du lab suivant :

Un contrôleur de domaine, avec DHCP et DNS.
Deux serveurs DNS qui ne seront pas dans le domaine.
Une machine client qui ne sera pas dans le domaine au départ.
Un Windows Server avec le routage NAT, qui ne sera pas dans le domaine.

Le serveur NAT a deux cartes réseau, une qui le relie au réseau réel via votre logiciel de virtualisation, et une dans le même réseau que le reste des machines.

Sur DC-ecole, installez le rôle services de domaine Active Directory et choisissez d’installer le DNS lors de la promotion du serveur en contrôleur de domaine. Ensuite, installez le rôle DHCP et autorisez-le dans le domaine.

Sur le serveur DC-ecole, paramétrez l’étendue DHCP pour que les machines clients puissent avoir une adresse dans le réseau de votre NAT, que le NAT soit la passerelle, et le DC-ecole comme DNS.

Sur les serveurs DNS1 et DNS2 installez le rôle serveur DNS. Pour ce faire, vous pouvez utiliser la commande PowerShell :

Install-WindowsFeature -Name DNS -IncludeManagementTools

1. Configuration du NAT

a. Configuration des cartes réseau

La carte réseau qui se trouve dans le même segment que l’autre machine a les réglages suivants :

La deuxième carte réseau, qui est reliée...

Redirecteurs

Il est possible de dire à un serveur DNS où aller chercher les informations dont il a besoin pour répondre aux requêtes des clients. Nous l’avons vu par défaut si un serveur ne dispose pas des informations pour répondre à un client, il va demander aux serveurs DNS racine.

La résolution avec les indications de racine peut être trop lente, et occasionner des messages de time out.

Pour tester la résolution DNS, utilisez la commande nslookup.

Vous pouvez régler ce problème en lui spécifiant un autre serveur DNS ; cela se fait avec des redirecteurs. Il existe deux sortes de redirecteurs : globaux et conditionnels. Avec des redirecteurs, la résolution itérative vers les serveurs DNS racine n’est plus effectuée, le serveur va demander directement au service DNS qui est indiqué dans le redirecteur.

La commande nslookup ignore le cache DNS local de la machine où elle est exécutée et force la résolution par le serveur DNS.

1. Redirecteurs globaux

Les redirecteurs globaux vont indiquer une adresse de serveur DNS à consulter lorsque le serveur n’a pas les informations demandées.

Dans le service DNS de DC-ecole, pour créer un redirecteur global, allez dans le gestionnaire DNS, puis faites un clic droit sur le service Properties, puis dans...

Processus de résolution du serveur DNS

Nous allons maintenant étudier la manière de procéder des serveurs DNS pour tenter de résoudre la requête.

Lorsqu’une requête DNS arrive au serveur, un processus pour la résoudre s’engage, en tenant compte des données disponibles localement, du contenu du cache, des éventuels redirecteurs, et des indications de racines.

Le serveur regarde en premier si l’information demandée est disponible en cache. Si c’est le cas, il répond au client.
Si aucune donnée du cache ne permet de répondre, alors le serveur va consulter ses éventuelles zones DNS hébergées localement, à la recherche d’enregistrements DNS qui permettraient de répondre à la requête. S’il dispose d’enregistrement, alors il répond au client.
S’il n’y a pas non plus d’enregistrements qui permettent de résoudre la requête du client, le serveur va regarder s’il dispose de redirecteurs. Si c’est le cas, il va transmettre la requête à l’adresse spécifiée dans le redirecteur, sur le port 53 en UDP.

Si le serveur indiqué par le redirecteur lui répond, il transmet l’information au client.
Si le serveur indiqué dans le redirecteur ne répond pas, il cherche à joindre des serveurs racine....

Enregistrements DNS

Une zone DNS contient donc des enregistrements, certains sont créés automatiquement par le système, d’autres peuvent être créés à la main par les administrateurs. Il en existe de différents types qui remplissent différentes fonctions.

Il existe de nombreux types d’enregistrements DNS, voici une liste des plus couramment utilisés :

Enregistrements SOA (Start of Authority) : cet enregistrement est créé en même temps que la zone contenant des informations comme la liste des serveurs faisant autorité pour le domaine, le TTL qui indique combien de temps les enregistrements doivent être conservés en cache, les réglages de transfert de zones, les réglages de mise à jour dynamique, et d’autres encore.
Enregistrements NS : ce type d’enregistrement contient la liste des serveurs faisant autorité pour la zone. On y retrouve les mêmes informations que dans un enregistrement SOA, les TTL, les mises à jour, etc.
Enregistrements hôtes : ce sont eux qui contiennent les adresses IP des machines, et il y en a de deux sortes :

type A pour les adresses IPv4 ;
type AAAA pour les adresses IPv6.

Enregistrements CNAME : aussi appelés alias, ces enregistrements ne contiennent pas d’adresse IP, mais ils renvoient vers un enregistrement hôte....

Gestion des zones et des enregistrements

Lorsque l’on fait la promotion d’un serveur en contrôleur de domaine, la meilleure pratique recommandée par Microsoft est d’installer le service DNS en même temps sur la même machine.

Cette façon de procéder va donc installer le service DNS et y créer deux zones de recherche directes, qui seront liées à Active Directory et serviront à son fonctionnement.

La première, dont le nom commence par « _msdcs » suivi du nom de domaine de la forêt, est un sous-domaine du domaine racine. Elle sera répliquée sur tous les contrôleurs de domaine de la forêt.

Elle contient plusieurs sous-dossiers :

DC contient les informations sur les sites Active Directory ;
Domains, où se trouve la liste des contrôleurs de domaine de la forêt ;
GC, où se trouve la liste des contrôleurs de domaines qui ont le catalogue global ;
PDC, où se trouve la liste de contrôleurs de domaine qui sont émulateur PDC.

Concrètement, il y a peu d’administration à faire dans cette zone et les administrateurs interagissent rarement avec. Toutefois, il peut arriver qu’elle soit manquante, dans ce cas il est possible de la créer à la main en lui donnant le nom qui commence par _msdcs. Le système y crée alors les dossiers, sous-dossiers et enregistrements DNS. Ceci doit être considéré comme un dépannage temporaire pour gérer l’urgence, avant de réinstaller le service.

C’est dans la deuxième zone créée par le système que le plus important de l’administration va se faire, celle qui a le nom du domaine. Elle contient aussi des sous-dossiers utilisés par le système, la délégation DNS vers la zone _msdcs, et les enregistrements créés par Active Directory de toutes les machines du domaine. En effet, lorsque l’on met une machine dans le domaine...

Création de zones DNS dans Windows Server

Il existe plusieurs types de zones dans le DNS, nous allons voir comment les créer et les configurer dans Windows Server 2022.

Chaque zone DNS a un sens et un type. Pour le sens, elle peut être directe ou inversée, et pour le type, elle peut être principale, secondaire ou de stub. On peut donc avoir une zone principale inversée ou directe, et une zone secondaire inversée ou directe.

Un serveur DNS qui héberge une zone n’est plus un simple DNS resolver mais un serveur DNS dit hébergeur.

1. Zones principales

Dans le lab, nous allons créer une zone de recherche directe et une zone inversée dans le contrôleur de domaine DC-ecole.

a. Création de zones principales directes

Dans le gestionnaire DNS, faites un clic droit sur Forward Lockup Zones et sélectionnez New Zone dans le menu déroulant.

Un assistant se lance, passez la première fenêtre.

Dans la deuxième fenêtre, sélectionnez Primary zone.

Lorsque l’on crée des zones dans un contrôleur de domaine, par défaut l’option pour stocker la zone dans Active Directory est cochée. Ainsi, les enregistrements contenus dans ces zones sont stockés dans des partitions de type application de la base de données Active Directory.

Si les zones ont été paramétrées pour se répliquer dans les contrôleurs de domaine du même domaine, ils sont dans la partition DomainDnsZones.
Si les zones ont été paramétrées pour se répliquer dans les contrôleurs de domaine de toute la forêt, leurs enregistrements sont stockés dans la partition ForestDnsZones.

Si l’option n’était pas cochée, le système proposerait alors de stocker la zone dans un fichier qui porte le nom de la zone et se trouve dans c:\windows\system32\dns par défaut.

Puis vient le réglage de la réplication, nous choisissons de répliquer dans tous les contrôleurs de domaine du même domaine.

Il faut ensuite donner un nom à la zone, choisissez editions56.com.

Vous devez ensuite décider de la politique de mise à jour dynamique. Vous allez désactiver la mise à jour dynamique des enregistrements....

Stratégies DNS

1. Présentation des stratégies DNS

Il est possible de faire des stratégies pour déterminer à quelles conditions un serveur DNS va accepter de répondre à une requête, ou donner des réponses différentes selon la stratégie. Ces stratégies peuvent s’implémenter au niveau de chaque zone, ou au niveau du serveur tout entier.

Si une stratégie est configurée au niveau du serveur, et une autre au niveau de la zone, et qu’elles entrent en conflit, alors c’est la stratégie du serveur qui sera prioritaire et appliquée.

Il y a un ordre d’application des stratégies, qui fonctionne comme une ACL (Access Control List). Le système va traiter les requêtes DNS et essayer de leur appliquer les stratégies en les prenant dans l’ordre d’exécution, en ordre séquentiel. Dès qu’une stratégie est applicable, le système arrête de les lire et ignore les stratégies suivantes.

Voici quelques exemples d’utilisation des stratégies DNS :

Équilibrage de charge : par exemple en ayant plusieurs enregistrements qui pointent vers différents serveurs qui hébergent la même application.
Gestion de lagéolocalisation : on autorisera le DNS à répondre ou pas selon la géolocalisation de la requête. C’est un des mécanismes employés pour interdire des sites dans certains pays.
Filtrage : il est possible de décider de répondre ou non à des requêtes suivant certains critères.
Fractionnement : le serveur DNS répondra différemment selon que la requête provient d’un réseau interne ou externe.

2. Concepts de base

a. Conditions et actions

Les conditions qui vont définir si et comment répond le serveur DNS peuvent être variées comme le réseau IP d’où provient la requête...

DNSSEC

1. Concepts généraux

DNSSEC est une fonctionnalité du DNS qui permet de renforcer la sécurité des infrastructures DNS, et de lutter contre les attaques « man in the middle » et l’empoisonnement du cache DNS. Elle peut s’appliquer aux zones incluses dans Active Directory :

Elle permet de garantir l’authenticité des réponses du serveur et d’assurer aux clients que c’est bien le serveur DNS voulu qui leur a donné la réponse à leur requête. Pour ce faire, les serveurs signent les réponses en utilisant une clé privée, que les clients peuvent vérifier avec la clé publique correspondante.
Elle permet aussi de garantir l’intégrité des réponses reçues et qu’elles n’ont pas été modifiées en chemin. Les réponses peuvent être cryptées avec le même mécanisme de clé privée et publique.
Les clients récupèrent la clé publique dans ce que Microsoft appelle une ancre d’approbation, qui sera créée dans le serveur DNS et répliquée dans les contrôleurs de domaine de la forêt. Cela remplace les certificats utilisés sur internet pour créer la chaîne de confiance et générer les clés.
Les clients sont forcés d’utiliser DNSSEC grâce à une stratégie de groupe configurée dans Active Directory et n’accepteront que des réponses signées avec les clés de l’ancre d’approbation. Les serveurs entre eux utiliseront DNSSEC, qui est activé par défaut dans Windows Server 2022.
Il y a deux paires de clés publiques/clés privées utilisées dans DNSSEC :

Les ZSK (Zone Signing Key) sont utilisées pour signer la zone DNS avec la clé privée, et le client vérifie la signature avec la clé publique.
Les KSK (Key Signing Key) sont une autre paire de clés, utilisées pour signer les clés ZSK avec...

Délégation DNS et sous-domaine

Si nous créons une zone DNS direction.ecole.com, alors nous créons un sous-domaine direction du domaine ecole.com dans le cadre d’Active Directory. C’est le cas dans cet exemple et ce procédé est automatique pour le DNS quand on crée le sous-domaine Active Directory.

On peut vouloir créer des sous-domaines pour la flexibilité qu’ils apportent en créant des segmentations dans le domaine DNS principal pour, par exemple, classer des services comme la messagerie ou les sites intranet. Les sous-domaines peuvent également être utilisés pour renforcer la sécurité en isolant des parties sensibles de l’entreprise, ou implémenter des politiques de sécurité différentes. Ils peuvent aussi permettre de répondre plus facilement à des exigences de conformité, qui exigent de segmenter les services.

Une délégation DNS est créée pour indiquer au serveur de la zone parente où sont les serveurs du sous-domaine qui font autorité pour ce sous-domaine, et pour déléguer l’autorité pour le sous-domaine lui-même.

Pour une zone hors Active Directory, ce processus doit être fait « à la main » par les administrateurs.

Pour mettre en pratique la délégation DNS et la création...

Réglages supplémentaires du service DNS

1. Round robin

Le round robin est une fonctionnalité supplémentaire dans le DNS pour faire de l’équilibrage de charge. Si l’on crée deux enregistrements DNS pour le même FQDN qui pointent vers des adresses IP différentes, alors le service répondra les deux enregistrements à une requête pour ce FQDN.

Le round robin fera en sorte que l’ordre des réponses change et le client ne mettra en cache que le premier des enregistrements contenus dans la réponse.

Le round robin est activé par défaut, comme on peut le constater en se rendant dans les propriétés du serveur et dans l’onglet Advanced.

Pour tester ce mécanisme du round robin, nous avons créé deux enregistrements avec le même FQDN qui renseignent des adresses IP différentes.

Testez la résolution de ce FQDN avec la commande nslookup.

Comme vous pouvez le constater, l’ordre des enregistrements dans la réponse est inversé dans la deuxième requête.

La commande nslookup force la résolution d’un FQDN même si celui-ci est déjà contenu en cache.

2. Limitation du taux de réponse

La limitation du taux de réponse consiste à définir un nombre de réponses maximal que le service DNS fournira à une même machine, afin d’éviter la surcharge du système. Cela aide aussi à se prémunir des attaques DDOS de type amplification DNS.

La commande suivante permet de visualiser le paramétrage :

Get-DnsServerResponseRateLimiting

Ce qui nous donne le résultat suivant. Nous pouvons constater...

Surveillance du service DNS

Il existe de nombreux endroits dans le système qui nous permettent de surveiller le service DNS et de vérifier sa bonne santé. Il est possible de voir les évènements, les alertes et les performances globales de la machine.

1. Propriétés du serveur

Le premier endroit où nous allons nous rendre pour tester le bon fonctionnement du service DNS est dans les propriétés du serveur DNS.

a. Onglet Monitoring

Allez dans le gestionnaire DNS, faites un clic droit sur le serveur, puis choisissez Properties et rendez-vous dans l’onglet Monitoring.

Nous allons ici pouvoir effectuer des tests de fonctionnement du DNS, pour des résolutions locales et récursives. De plus, il sera possible de programmer ces tests à intervalles réguliers et ainsi de venir vérifier s’il y a d’éventuels dysfonctionnements, par exemple lorsque des services qui utilisent le DNS ne fonctionnent pas normalement.

b. Onglet Event Logging

Un autre onglet des propriétés du serveur concerne la surveillance du système, c’est l’onglet Event Logging.

Il permet de déterminer les types d’évènements que l’on veut enregistrer dans les journaux d’évènements. Par défaut, il est réglé sur All events, mais on peut vouloir réduire cette sélection pour alléger le système....

Le service DNS