# TP4 : Mise en place et sécurisation du DNS public

Noms des auteurs : DEUMENI TCHAMENI DERVAL, Jérémie MUCHEMBLED

1. Installation et configuration de Bind en tant que serveur autoritaire sur un VPS

Mise en place de l'environnement de travail.

Organisation du VPS

On aura un dossier dns dans notre ~, avec des dossiers etc et var qui seront montés sur les etc et var de bind.

Votre repository Github et son Wiki

On fera une page de wiki et un dossier dans le repo par TP. Les dossiers auront la meme structure que sur le VPS.

Méthode de configuration

On stockera les fichiers de configurations en local, qu'on montera dans le conteneur dans le docker-compose

Nom de domaine

l1-5.ephec-ti.be

1.2. Mise en place du serveur autoritaire

1.2.1 Premier test du container

On observe que la requete a été transmise au serveur DNS de google, puisque on obtient leur adresse IP, que nous ne possédions pas.

1.2.2. Configuration du mode autoritaire

Dans les options générales de bind :

• Interdiction de la récursion et de la mise en cache :

	allow-query-cache { none; };
	recursion no;

• Requêtes acceptées depuis tout l’Internet (nous souhaitons définir une zone publique) :

	allow-query { any; };

Dans les options de la zone :

• Définition du serveur en tant que maître de la zone :

	type master;

On interdit la récursion pour plusieurs raisons :

• Rôle spécifique du serveur : Le serveur DNS est configuré comme serveur autoritaire, pas comme résolveur. Il ne doit donc répondre qu’aux requêtes sur les noms qu’il gère.

• Sécurité : Éviter d'être utilisé comme amplificateur d’attaques DDoS. Les serveurs ouverts à la récursion sont souvent utilisés à cette fin.

• Performance : Éviter de gaspiller des ressources à résoudre des noms extérieurs non liés à la zone gérée.

On devrait idéalement configurer une zone inverse (reverse DNS), car cela permet de résoudre une adresse IP vers un nom de domaine.

Elle est utile pour :

• Les tests réseau (ex. : commandes ping, dig, nslookup qui montrent des noms symboliques).

• Les protocoles de messagerie (comme SMTP) qui peuvent vérifier l’inverse pour valider la légitimité du serveur.

• Le débogage et la surveillance réseau.

named.conf :

options {
  directory "/var/cache/bind";
  version "not currently available";
  allow-query { any; };
  allow-query-cache { none; };
  recursion no;
};

zone "l1-5.ephec-ti.be." {
  type master;
  file "/etc/bind/l1-5.zone";
  allow-transfer {
    none;
  };
};

Fichier de zone (l1-5.zone) :

$ORIGIN l1-5.ephec-ti.be.
$TTL 3600

@ IN SOA ns.l1-5.ephec-ti.be. admin.l1-5.ephec-ti.be. (
        2025052301  ; Augmente le numéro de série (YYYYMMDDXX)
        14400       ; Rafraîchissement
        3600        ; Tentatives en cas d'échec
        2419200     ; Expiration
        86400       ; TTL minimum
)

@ IN NS ns.l1-5.ephec-ti.be.
ns.l1-5.ephec-ti.be. IN A 54.36.181.37
www.l1-5.ephec-ti.be. IN A 54.36.181.37

Bilan de la validation :

On observe que la récursion est bien désactivée puisqu'on n'a plus de réponse

On en deduit que le DNS est fonctionnel puisque le port 53 est en écoute et qu'on a une réponse contenant l'adresse IP du VPS

On rajoute l'option -g dans la commande de lancement du conteneur pour que les logs sont accessibles :

1.2.3. Construction d'une image pour votre serveur autoritaire

On utilise comme Dockerfile :

FROM internetsystemsconsortium/bind9:9.18
CMD ["-c", "/etc/bind/named.conf", "-g"]

Il s'agit simplement de l'image de base dans laquelle on injecte une commande qui pointe bind vers le fichier de configuration, et qui active le flag -g dans le but décrit précédemment. Les fichiers de configuration et de zone sont rendu disponible au conteneur dans le docker-compose afin de pouvoir les modifier sans re-build l'image.

L'image ainsi crée est validée avec les mêmes test que précédemment.

1.3. Délégation de la zone

On transmet les deux RRs suivants à la zone parent :

l1-5.ephec-ti.be. IN NS ns.l1-5.ephec-ti.be. 
ns.l1-5.ephec-ti.be. IN A 54.36.181.37

On vérifie avec les commandes dig et ping :

1.4. Validation du serveur autoritaire

On valide notre zone avec ZoneMaster :

Délégation : Vérifie si les serveurs de noms associés à la zone sont correctement déclarés et fonctionnent comme attendu.

Système : S’assure que les serveurs DNS respectent les bonnes pratiques techniques et ne présentent pas de défauts de configuration.

Basique : Contrôle la présence et la validité des enregistrements DNS essentiels.

Adresse : Vérifie que les adresses IP des serveurs DNS sont correctes, valides et joignables.

Connectivité : Teste si les serveurs DNS sont accessibles depuis plusieurs réseaux, en IPv4 et IPv6.

Cohérence : Vérifie que toutes les copies des enregistrements DNS sont identiques sur l’ensemble des serveurs de noms.

DNSSEC : Vérifie si la zone est protégée par DNSSEC et si la chaîne de confiance est complète.

Serveurs de noms : Vérifie que les serveurs de noms sont bien configurés, qu’ils répondent correctement et de manière fiable.

Syntaxe : Contrôle que les enregistrements DNS sont rédigés correctement et conformes aux normes du protocole DNS.

Zone : Analyse globale de la configuration de la zone pour détecter d’éventuelles erreurs ou incohérences.

A propos des avertissements :

Connectivité :

• ⚠️ Diversité des AS : Tous les serveurs de noms sont hébergés dans un seul et même système autonome (AS). Cela réduit la résilience du système face à des incidents de réseau affectant cet AS. Amélioration : Déployer au moins un serveur de noms dans un AS différent pour augmenter la tolérance aux pannes.

• ⚠️ Diversité des préfixes IP : Toutes les adresses IP (IPv4 et IPv6) utilisées partagent le même préfixe. Cela peut poser problème en cas de panne affectant ce bloc IP. Amélioration : Utiliser des adresses IP provenant de préfixes différents pour renforcer la disponibilité.

DNSSEC :

• ⚠️ Si un enregistrement DNSKEY est présent dans la zone enfant, la zone parente doit avoir un DS : Un enregistrement DNSKEY est présent dans la zone, mais aucun enregistrement DS correspondant n’est trouvé dans la zone parente. Cela signifie que la chaîne de confiance DNSSEC est rompue, ce qui empêche une validation correcte de la sécurité. Amélioration : Ajouter l’enregistrement DS dans la zone parente pour permettre une validation DNSSEC complète.

On a également une erreur dans Délégation :

• ❌ Nombre minimal de serveur de noms : Il faudrait un minimum de 2 serveurs DNS, donc en déployer un sur un deuxième VPS.

2. Sécurisation DNSSEC

2.1. Génération des clés et signature de la zone

On rajoute ces deux lignes dans la partie zone du named.conf :

  inline-signing yes;
  dnssec-policy default;

On observe que des fichiers on été crées :

Dans /etc/bind:

- l1-5.zone.jbk
- l1-5.zone.signed
- l1-5.zone.signed.jnl

Dans /var/cache/bind :

- Kl1-5.ephec-ti.be.+013+43528.key
- Kl1-5.ephec-ti.be.+013+43528.private
- Kl1-5.ephec-ti.be.+013+43528.state

Le reste était déjà là auparavant.

2.2. Validation de la clé publique via la zone parente

Il nous faut un RR DS à mettre dans la zone parent. Dans le dossier /var/cache/bind, on exécute la commande :

dnssec-dsfromkey -2 Kl1-5.ephec-ti.be.+013+43528.key

On obtient ceci :

l1-5.ephec-ti.be. IN DS 43528 13 2 160B704F23112C88C14ED1E6DB6B98F01B159B8D7895ED731FB7D4040ADB03DA

2.3. Tester la sécurisation d'une zone DNS

2.4. Configurer un résolveur pour valider le DNSSEC

On rajoute simplement cette ligne dans la partie options du named.conf :

dnssec-validation auto;