TP4
Noms des auteurs : Thomas Ciserane, Nathan Colson, WILLEMS Julien
Date de réalisation : 14/03/2025
Pour pouvoir disposer d'un DNS public, il faut avant tout disposer d'un nom de domaine. Nous utiliserons comme domaine parent le domaine ephec-ti.be, et chacun de votre groupe disposera de son propre sous-domaine, nommé selon le pattern suivant : l[1|2]-[#groupe].ephec-ti.be. Par exemple, le groupe 2TL1-1 disposera du nom de domaine l1-1.ephec-ti.be.
Organisation du VPS
On a créé un utilisateur commun dans le groupe docker pour tout le groupe avec un accès via clés SSH.
Quelle sera votre hiérarchie de répertoires?
On a un dossier tps à la racine avec un dossier par TP (tp1, tp2, etc.) contenant les fichiers du projet.
~/tps/
├── tp4/
│ └── dns/
│ ├── Dockerfile
│ ├── docker-compose.yml
│ └── config/
│ └── ...
├── tp5/
│ └── ...
└── tpN/
└── ...
Votre repository Github et son Wiki
Quelle structure allez-vous donner au repository et au wiki ?
Pour centraliser le travail du groupe, nous utilisons un repository GitHub commun. Il contient :
- Les fichiers de configuration de chaque TP, organisés par dossier.
- Un Wiki attaché au repository, utilisé pour documenter les étapes de mise en place, les choix techniques et les explications demandées dans les énoncés.
.
├── dns/
│ ├── named.conf
│ ├── l1-7.zone
│ └── ...
├── web/
│ └── ...
└── README.md
Méthode de configuration
Quelle procédure de gestion des configurations votre groupe a-t'il choisi ?
Dans un premier temps, nous avons rapidement testé Bind via des commandes docker run avec quelques options manuelles pour valider les premières configurations, cette approche nous a permis de lancer rapidement un container et de faire nos premiers essais.
Très vite, nous avons basculé vers une solution plus structurée avec un Dockerfile personnalisé et un docker-compose.yml, ce qui nous permettait de mieux organiser les fichiers, reproduire l’environnement plus facilement, et éviter les erreurs manuelles.
Plutôt que de monter tout le dossier /etc/bind (ce qui aurait pu poser des problèmes de permissions ou écraser les fichiers internes), nous avons uniquement utilisé un Bind Mount sur /var/cache/bind, afin de conserver les fichiers générés dynamiquement par Bind (comme les clés DNSSEC ou les fichiers .signed).
l1-7.ephec-ti.be
Qu'observez-vous comme comportement pré-défini dans ce serveur Bind? Indiquez vos observations et vos conclusions.
Sur l'image ci-dessus, on peut voir:
-
Le
status: NOERRORdans le HEADER de la requête, indiquant que la requête a fonctionnée sans aucune erreur. -
;; ANSWER SECTION: www.google.com. 300 IN A 142.250.74.228, indiqaunt le TTL (Time To Live, ici = 300s), le type de classe IN (Internet), le type d'enregistrement A (Adresse IPv4) et la valeur de l'adresse IP du serveur web de Google.
Mais également le temps de réponse du serveur, la date et l'heure de la requête.
En conclusion, le serveur Bind fonctionne comme attendu.
- Pour chacune des trois fonctionnalités listées plus haut, quelle(s) instruction(s) permet sa mise en oeuvre?
A. Interdiction de la récursion et de la mise en cache:
recursion no;
allow-query-cache { none; };
B. Requêtes acceptées depuis tout l’Internet (zone publique):
allow-query { any; };
C. Définition du serveur en tant que maître + fichier de zone + désactivation du transfert:
zone "l1-7.ephec-ti.be." {
type master;
file "/etc/bind/l1-7.zone";
allow-transfer { none; };
};
-
Pourquoi interdit-on la récursion ?
Cela protège contre certaines attaques et évite une surcharge du serveur.
-
Devez-vous configurer une zone inverse pour votre sous-domaine ? Pourquoi ?
Ici, on ne gère pas notre propre plage IP publique, donc on n’a pas l’autorité pour créer la zone inverse.
Reproduisez ici votre fichier named.conf ainsi que votre fichier de zone. Indiquez également pour chacun le lien vers la version courante sur le repository.
Fichier named.conf :
Voir sur GitHub
Fichier l1-7.zone:
Voir sur GitHub
Faites le bilan de la validation :
- Quelles commandes avez-vous utilisées?
Les commandes suivantes :
docker run -d --name=dns2 -p 53:53/udp -p 53:53/tcp --mount type=bind,source=/home/user/dns/named.conf,target=/etc/bind/named.conf --mount type=bind,source=/home/user/dns/l1-7.zone,target=/etc/bind/l1-7.zone --mount type=bind,source=/home/user/dns/cache,target=/var/cache/bind internetsystemsconsortium/bind9:9.20
(Il y avait un problème de permission du container pour l'écriture dnas '/var/cache/bind' alors j'ai fais un bind mount de plus pour contouner le problème)
docker exec -it dns2 /bin/sh puis named -g pour voir les logs
- Quels résultats avez-vous obtenus, et quelles conclusions pouvez-vous en tirer sur le fonctionnement de votre serveur DNS ?
Pour rappel, notre serveur DNS se doit de répondre aux exigences suivantes :
- Interdiction de la récursion et de la mise en cache ;
- Requêtes acceptées depuis tout l’Internet ;
- Définition du serveur en tant que maître de la zone;
- Désactiver le transfert de zone.
Tout d'abord, l'interdiction de la récursion peut être validée en effectuant des tests avec la commande dig. Lorsque la récursion était active, en effectuant la commande dig @localhost www.google.com, on obtenait dans sa réponse l'adresse IP de la machine correspondant à "www.google.com". Or, maintenant que ce n'est plus le cas, en entrant cette commande, nous obtenons cette réponse-ci :
On constate qu'un avertissement apparait indiquant que les requêtes récursives ne sont pas disponibles (1) et enfin que l'adresse IP de Google n'est plus fournie (2). Cela valide le fait que la récursion a été désactivée sur notre serveur DNS.
Ensuite, cette même opération mais cette fois avec "l1-7.ephec-ti.be" comme cible permet de valider la définition du serveur en tant que maître de la zone car dans la réponse reçue, une adresse IP est fournie :
On constate sur l'image attachée que la réponse à la commande dig @localhost l1-7.ephec-ti.be fournit l'IP de la machine "www" (1), confirmant donc la définition du serveur en tant que maître de la zone.
Pour ce qui des requêtes acceptées depuis tout l'internet, rien de plus simple. Il suffit de refaire un dig depuis une machine externe au VPS via la commande dig ns.l1-7.ephec-ti.be www.l1-7.ephec-ti.be, ce qui donnera une réponse similaire à celle-ci :
Dans la réponse, on peut premièrement observer l'adresse IP du serveur de nom (1) (cela confirme qu'il est joignable depuis n'importe où) et secondement celle de la machine "www.l1-7.ephec-ti.be" (2) (tandis que ceci valide qu'il dessert bien la zone dont il est le maître).
Finalement, la désactivation du transfert de zone peut être confirmé par l'absence de records NS ou SOA dans la réponse car ce sont des records que l'on y retrouverait typiquement si le transfert de zone était actif.
Conclusion, nous pouvons affirmer que notre serveur de noms répond aux exigences attendues de sa part.
- Comment avez-vous configuré les logs ? Y avez-vous bien accès ?
Je n’ai pas configuré explicitement de fichiers de logs dans named.conf.
Cependant, en lançant named avec l’option -g dans le conteneur (named -g), les logs s’affichent directement dans le terminal (stdout/stderr), ce qui permet de les consulter facilement.
Les messages affichés concernent principalement la gestion des clés DNSSEC, qui n’a pas encore été configurée. À ce stade, c'est normal.
- Documentez votre Dockerfile.
FROM internetsystemsconsortium/bind9:9.20
ADD named.conf /etc/bind/named.conf
ADD l1-7.zone /etc/bind/l1-7.zone
RUN chown -R bind:bind /etc/bind/
ENTRYPOINT ["/usr/sbin/named", "-g", "-c", "/etc/bind/named.conf", "-u", "bind"]
J'ai repris l'exemple donné en remplaçant CMD par ENTRYPOINT car le container plantait au démarrage. Je pense que c’est dû au fait que l’image internetsystemsconsortium/bind9:9.20 lance déjà named automatiquement. En mettant ENTRYPOINT, ça remplace complètement la commande par défaut, ce qui évite les conflits.
- Comment avez-vous validé votre image ?
Afin de valider le bon fonctionnement de l'image, les même tests avec la commande dig que ceux effectuées à la validation du point 1.2.2. ont été réalisés après la création des fichiers named.conf et l1-7.zone et toutes les exigences du serveur DNS ont été satisfaites.
- Indiquez ici les deux Resource Records à transférer à la zone parente
l1-7 IN NS ns.l1-7.ephec-ti.be.
ns.l1-7 IN A 54.36.181.82
- Montrez via des screenshots que la délégation fonctionne.
Résultat de la commande dig @ns110.ovh.net www.l1-7.ephec-ti.be, où l’on voit dans la Authority Section que les requêtes sont bien déléguées à ns.l1-7.ephec-ti.be., preuve que le domaine parent redirige correctement vers notre serveur DNS.
Résultat d’un ping de www.l1-7.ephec-ti.be, qui prouve que le nom de domaine est bien résolu en une adresse IP, ce qui confirme que notre serveur DNS fournit les bonnes informations.
- Indiquez le screenshot avec l'état de validation Zonemaster
- Expliquez avec vos mots ce que signifie chaque test
| Catégorie | Test | Résultat | Explication |
|---|---|---|---|
| System | Version du moteur Zonemaster | ✅ | Le test confirme que la version 7.1.0 de Zonemaster est utilisée, ce qui permet une exécution correcte de la suite de tests. |
| Basic | Présence d’un domaine parent et d’un serveur de noms fonctionnel | ✅ | La zone testée dispose bien d’un domaine parent et d’au moins un serveur de noms opérationnel. |
| Address | Correspondance de l’entrée DNS inverse avec le nom du serveur | Le nom associé à l’adresse IP du serveur de noms ne correspond pas exactement à celui configuré dans la zone. | |
| Accessibilité globale et présence de l’entrée reverse DNS | ✅ | L’adresse IP du serveur de noms est publique et une entrée de type PTR (reverse DNS) est bien configurée. | |
| Connectivity | Diversité des systèmes autonomes (AS) et des préfixes IP | Tous les serveurs de noms sont situés dans le même réseau et utilisent le même AS, ce qui limite la tolérance aux pannes réseau. | |
| Consistency | Cohérence des enregistrements SOA et NS, ainsi que des glue records | ✅ | L’ensemble des enregistrements liés à la zone (SOA, NS, glue records) est cohérent entre les différents serveurs. |
| DNSSEC | Signature de la zone avec DNSSEC et présence d’un enregistrement DS | La zone n’est pas signée avec DNSSEC et aucun enregistrement DS n’est présent au niveau de la zone parente. | |
| Delegation | Nombre minimal de serveurs de noms et configuration correcte des enregistrements | ❌ / ✅ | La zone ne dispose que d’un seul serveur de noms, ce qui est insuffisant. Les autres paramètres liés à la délégation sont correctement configurés. |
| Nameserver | Sécurité et compatibilité du serveur de noms | Le serveur de noms divulgue sa version logicielle. Tous les autres tests (non-récursivité, support EDNS0, transfert AXFR, etc.) sont concluants. | |
| Syntax | Validité syntaxique des champs SOA et des noms de domaine | L’adresse de contact dans le champ RNAME du SOA pourrait être améliorée. Aucune erreur syntaxique bloquante n’est relevée. | |
| Zone | Présence de champs liés aux services mail (MX, SPF) | La zone ne contient pas d’enregistrements MX ni de politique SPF, ce qui peut poser problème pour l’envoi de mails depuis le domaine. |
- Faites le bilan de cette validation sur votre zone : quels sont les points d'amélioration ? Si vous pouvez les réalisez, documentez les changements réalisés et montrez bien les screenshots du test de validation Zonemaster avant et après les modifications.
Globalement, la validation Zonemaster est plutôt positive. La zone est bien déléguée, le serveur répond correctement et les enregistrements sont cohérents. Quelques remarques sont présentes mais rien de bloquant pour le bon fonctionnement du DNS.
Les points à améliorer concernent surtout :
- Le manque de diversité réseau (un seul serveur de noms, dans un seul AS),
- L’absence de DNSSEC (signature de la zone),
- Et des avertissements mineurs comme l’absence d’enregistrements mail (MX, SPF).
Si vous avez mis en place un des bonus proposés, documentez votre travail ici.
- Documentez les modifications effectuées
Après l'ajout de
inline-signing yes;
dnssec-policy default;
Le fichier named.conf devient
options {
directory "/var/cache/bind/";
version "not currently available";
allow-query { any;
};
allow-query-cache { none;
};
recursion no;
};
zone "l1-7.ephec-ti.be." {
type master;
file "/etc/bind/l1-7.zone";
allow-transfer { none;
};
inline-signing yes;
dnssec-policy default;
};
- Après redémarrage de votre serveur, quels changements observez-vous?
Après avoir exécuté la commande dig www.l1-7.ephec-ti.be +dnssec sur un poste autre que VPS, on peut constater que la zone est signée car elle renvoit un enregistrement de type RRSIG et donc que le serveur applique le protocole DNSSEC correctement.
; <<>> `DiG 9.18.30-0ubuntu0.22.04.2-Ubuntu` (Ubuntu et non Debian [VPS]) <<>> www.l1-7.ephec-ti.be +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25835
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;www.l1-7.ephec-ti.be. IN A
;; ANSWER SECTION:
www.l1-7.ephec-ti.be. 916 IN A 54.36.181.82
www.l1-7.ephec-ti.be. 916 IN RRSIG A 13 4 3600 20250414060428 20250331121945 22815 l1-7.ephec-ti.be. ooGrwKfauAC3z0ZltUNgHcrfe1u/uSrGz2f/+GbrIyWjp81+QzGWu6SW vdV2XMU8VFnlCXPFxQGCLeglnLMtIQ==
;; Query time: 219 msec
;; SERVER: 10.255.255.254#53(10.255.255.254) (UDP)
;; WHEN: Mon Mar 31 22:20:31 CEST 2025
;; MSG SIZE rcvd: 177
- Documentez la procédure de création du record DS
Une fois dans le container grâce à la commande docker exec -it dns-l1-7 sh et en utilisant la commande cd /var/cache/bind/, le record DS a été genéré avec dnssec-dsfromkey Kl1-7.ephec-ti.be.+yyy+XXXX.key:
- Reproduisez ici votre record DS.
Voici le Resource Record DS généré à partir de la clé KSK de ma zone :
l1-7.ephec-ti.be. IN DS 19642 13 2 04E754A4DBE5ADDFA36DEADE04AB6125389770FC59A6304AFF842B4CC93C15F0
- Documentez et commentez ici les résultats obtenus en validant votre configuration avec les trois outils mentionnés.
-
https://dnssec-analyzer.verisignlabs.com/ :
Avec cet outils on vérifie bien que tous les champs sont OK à l'execption du RR DS dans la zone parente.
-
En utilisant dig :
- Après avoir exécuté la commande
dig @1.1.1.1 +dnssec www.l1-7.ephec-ti.bedepuis le VPS, on peut voir le record de type RRSIG avec le record A.
; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> @1.1.1.1 +dnssec www.l1-7.ephec-ti.be ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61866 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;www.l1-7.ephec-ti.be. IN A ;; ANSWER SECTION: www.l1-7.ephec-ti.be. 3600 IN A 54.36.181.82 www.l1-7.ephec-ti.be. 3600 IN RRSIG A 13 4 3600 20250414060428 20250331121945 22815 l1-7.ephec-ti.be. ooGrwKfauAC3z0ZltUNgHcrfe1u/uSrGz2f/+GbrIyWjp81+QzGWu6SW vdV2XMU8VFnlCXPFxQGCLeglnLMtIQ== ;; Query time: 35 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP) ;; WHEN: Mon Mar 31 14:47:25 UTC 2025 ;; MSG SIZE rcvd: 177- Après avoir exécuté la commande
dig @1.1.1.1 +dnssec dnskey l1-7.ephec-ti.bedepuis le VPS, on récupère le record de type DNSKEY et le record de type RRSIG du DNSKEY.
; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> @1.1.1.1 +dnssec dnskey l1-7.ephec-ti.be ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9174 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;l1-7.ephec-ti.be. IN DNSKEY ;; ANSWER SECTION: l1-7.ephec-ti.be. 3600 IN DNSKEY 257 3 13 +lIGE+oantKL2IKTPH4pGh5ZJMh9Y0aXz508Gg3Heqw07x8dVzb95HE6 /fkQRa46RBUDEAGbew0VfEIRNkGT+Q== l1-7.ephec-ti.be. 3600 IN RRSIG DNSKEY 13 3 3600 20250414131945 20250331121945 22815 l1-7.ephec-ti.be. alJmvG2VJdjxZ582VRfLr8fJJeKJ9ZYJG3R5+CplfYNyAUULEoUeJJH/ nRv6Se0xwekVKR2t7TDVPAm+AUT4jg== ;; Query time: 35 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP) ;; WHEN: Mon Mar 31 14:53:43 UTC 2025 ;; MSG SIZE rcvd: 237- Après avoir exécuté la commande
dig @1.1.1.1 +dnssec ds l1-7.ephec-ti.beon récupère le record de type DS, on remarquera que la la zone parenteephec-ti.bea été intérogée.
; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> @1.1.1.1 +dnssec ds l1-7.ephec-ti.be ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64063 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;l1-7.ephec-ti.be. IN DS ;; AUTHORITY SECTION: ephec-ti.be. 60 IN SOA dns110.ovh.net. tech.ovh.net. 2025032801 86400 3600 3600000 60 ephec-ti.be. 60 IN RRSIG SOA 8 2 3600 20250427090609 20250328090609 591 ephec-ti.be. VFCzmUMVIie+TMcaMDeoYSWRr5RLHw7SKOFTGnPiON2BMA9I9czbBT5N 2NOxnFL38Q1QdAMnf99njBPksPwlRcgzuwMIo6KcLXnOLVd6aVWk9zgp fKnltYfsI8oBg2nQJblGs7H5uWoxjEos9YJn4sHfnOufilkcwIAQOAgk aoc= RBLV28NGD7EK4DTIVSU1MQCJ4BLRJ8G9.ephec-ti.be. 60 IN NSEC3 1 0 0 - S8V06F5U52AMDSNQ3F6M218J4GDGS1CE NS RBLV28NGD7EK4DTIVSU1MQCJ4BLRJ8G9.ephec-ti.be. 60 IN RRSIG NSEC3 8 3 60 20250427090609 20250328090609 591 ephec-ti.be. bxuWHIA4B2B8jHCcy2agUM6+NcKBKTeoipJDA0UnrFmxIzhDUsJq2YFo dklQZ8yo37esy+jTWNzCS1o/qbr/EtF0rgiZGBzMhCfe7anDfD/zm+Oo zb+mSGToImubfQtzfR47DLPklVF5UCHxcQ/Nz/zwqCr5hf3vZ79qNX4+ XbA= ;; Query time: 27 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP) ;; WHEN: Mon Mar 31 14:55:34 UTC 2025 ;; MSG SIZE rcvd: 516 - Après avoir exécuté la commande
-
En utilisant delv :n
Après avoir exécuté la commande
delv www.l1-7.ephec-ti.beon récupère le record de type A ainsi que le record de type RRSIG.;; validating www.l1-7.ephec-ti.be/A: no valid signature found ; unsigned answer www.l1-7.ephec-ti.be. 3600 IN A 54.36.181.82 www.l1-7.ephec-ti.be. 3600 IN RRSIG A 13 4 3600 20250414060428 20250331121945 22815 l1-7.ephec-ti.be. ooGrwKfauAC3z0ZltUNgHcrfe1u/uSrGz2f/+GbrIyWjp81+QzGWu6SW vdV2XMU8VFnlCXPFxQGCLeglnLMtIQ==Chose intéressante, sur un session Ubunto soit pas sur le VPS, on a ce résulat:
delv www.l1-7.ephec-ti.be ;; broken trust chain resolving 'ephec-ti.be/DS/IN': 10.255.255.254#53 ;; broken trust chain resolving 'ephec-ti.be/DNSKEY/IN': 10.255.255.254#53 ;; shut down hung fetch while resolving 'www.l1-7.ephec-ti.be/A' ;; resolution failed: operation canceledIci la vérification n'a pas pu se faire car effectivement la zone parente ne possède pas le resource record DS de notre zone alors, la chaîne de confiance n'est pas respectée d
- Quelle(s) instruction(s) Bind permettent de contrôler si un résolveur effectue une validation DNSSEC ou non?
Bind utilise l’instruction dnssec-validation yes; pour activer la validation DNSSEC. C’est d’ailleurs activé par défaut dans les versions récentes.
Si vous avez réalisé des bonus, documentez-les ici.