DNS¶

Définition¶

DNS ou Domain Name System (Système de nom de domaine) permet à un utilisateur de pouvoir visiter un site via un nom qui sert d'alias à une adresse IP, vous simplifiant la vie lorsque vous devez vous rendre sur plusieurs sites web et surtout pour vos grand-parents.

Un DNS en tant qu'administrateur système, vous permet de gérer vos domaines et sous-domaines lors de la configuration de site web, de serveur mail, de vpn et encore plein d'autres.

Historique¶

ARPANET¶

À l'époque d'ARPANET, la Stanford Research Institute (de nos jours, SRI International) utilisait le fichier hosts.txt pour définir une adresse mais cela devait se faire sur tous les ordinateurs et si une donnée devait être ajouté au fichier, il fallait modifier tous les ordinateurs.

Elizabeth Feinler a alors eu une idée, développé un outil nommé Assigned Number List qui était gérer par Jon Pastel à l'Information Science Institute de l'Université de Californie du Sud.

Le premier système WHOIS¶

Avant la mise en place du premier système WHOIS, les adresses étaient attribuées manuellement et on devait appeler le SRI Network Information Center ou SRI-NIC (qui était géré par Mme Feinler).

Un peu plus tard, Mme Feinler et son équipe on décidé de créer le premier système WHOIS pour la récupération d'informations sur les ressources, les contacts et les entités. Ils ont également développé le concept de nom de domaine et Mme Feinler à suggérer que cela soit basé sur l'adresse physique de l'ordinateur.

Dans les années 80¶

Paul Mockapetris, étant à l'Université de Californie du Sud, a créé un système de nom de domaine. L'équipe en charge des normes RFC a alors introduit la norme RFC 882 et 883 en novembre 1983 puis RFC 973 en janvier 1986.

Création du BIND¶

En 1984, quatre étudiants de l'université de Berkeley, Douglas Terry, Mark Painter, David Riggle et Songnian Zhou, ont écrit la première implémentation du serveur de noms Unix pour le Berkeley Internet Name Domain, communément appelé BIND.

Les versions 4.9.3 et suivantes de BIND ont été développées et maintenues par l'ISC, avec le soutien des sponsors de l'ISC. En tant que co-architectes/programmeurs, Bob Halley et Paul Vixie ont publié la première version prête à la production de BIND version 8 en mai 1997.

Fonctionnement¶

En tant qu'utilisateur¶

Imaginons que vous souhaitez aller sur youtube pour regarder une vidéo.

Vous allez dans votre navigateur et vous tapez www.youtube.com. Que se passe-t-il derrière ? Voici un schéma TRÈS SIMPLIFIÉ

1. Vous allez demandé qu'elle l'IP du serveur qui a www.youtube.com a un serveur DNS, généralement, celui de votre FAI (Fournisseur d'Accès à Internet).

Si le serveur DNS de votre FAI n'a pas www.youtube.com chez lui, il va demandé à un autre serveur DNS pour l'avoir.

1. Il demande à un autre serveur DNS si il a www.youtube.com

Il se trouve comme par chance, l'autre serveur DNS à www.youtube.com

1. Il renvoie donc l'IP de www.youtube.com

Le serveur DNS de votre FAI s'empresse alors de vous renvoyez la bonne nouvelle.

1. Et il le fait donc

Vous avez maintenant l'IP associé au nom de domaine.

1. Vous demandez donc au serveur ayant l'adresse IP pour avoir www.youtube.com

2. Il vous renvoie www.youtube.com

Vous pouvez maintenant regarder des vidéos youtube.

Il est possible de choisir un serveur DNS que vous pouvez définir sur votre routeur pour des raisons de performences, de sécurité ou autres.

En tant qu'administrateur¶

En tant qu'administrateur de votre serveur DNS, vous avez beaucoup de chose qui s'offre à vous dans la configuration.

• Vous pouvez ajouter un enregistrement à votre serveur DNS de type A

• Sur cette enregistrement, vous mettez un TTL de 1 jour.

• Ou alors, vous voulez rediriger un sous-domaine à vous vers votre NAS héberger chez vous mais l'IP est dynamique ? Utilisez un DynDNS.

• Vous souhaitez obtenir des informations sur un nom de domaine ? Utilisez un outil

Tous ces points, on va y revenir.

De manière global¶

Dans le monde, il y a 13 serveurs DNS majeurs dit RootDNS qui pour résumé, sont les serveurs DNS principaux dans le monde.

Mais pas tous les serveurs DNS s'y réfère, cela dépend de si ils sont public ou privé.

Et aussi si il est coté client ou coté serveur.

Également, il y a des serveurs DNS dit esclave qui se réfère au maître de zone.

Il ne faut pas oublier les TLD qui gère certain domaine.

Mais tous cela, on y reviendra plus tard.

Cache et TTL¶

Lorsqu'un serveur DNS demande une valeur, pour ne pas avoir à redemander la valeur, il le met dans le cache. Cela permet d'accélérer le temps de réponse et de ne pas avoir à redemander au serveur DNS. Le temps qu'il passera en cache dépend du TTL.

Le TTL ou Time To Live définit le temps qu'une valeur passera dans le cache. Après ce temps, il faut redemander au serveur DNS.

Les enregistrements¶

Un serveur DNS contient plusieurs types d'enregistrement listés ci-dessous.

Liste des types de registre¶

Chaque enregistrement fonctionnent de la manière suivante :

Type, Source, Valeur, TTL

Si on prend l'exemple de youtube, sa donnerai sa :

Exemple de contenu dans un serveur DNS¶

; Domain: unrecon.ch
; Exported (y-m-d hh:mm:ss): 2025-10-14 14:24:45
; Actual version

$TTL 3600
@                           IN SOA   nsany1.infomaniak.com. hostmaster.infomaniak.ch. (2025100826 10800 3600 605800 3600)
*.gitlab               3600 IN A     75.119.138.86
                       300  IN A     185.125.27.14
                       300  IN AAAA  2001:1600:0:aaaa::80:b
                       3600 IN MX 5  mta-gw.infomaniak.ch.
                       3600 IN NS    nsany1.infomaniak.com.
                       3600 IN NS    nsany2.infomaniak.com.
                       3600 IN TXT   "v=spf1 include:spf.infomaniak.ch -all"
autoconfig             3600 IN CNAME infomaniak.com.
autodiscover           3600 IN CNAME infomaniak.com.
bot                    3600 IN CNAME host.unrecon.ch:3030.
contact                3600 IN MX 10 mail.contact.unrecon.ch.
dkim._domainkey.mail   3600 IN CNAME dkim._domainkey.alias.proton.me.
dkim02._domainkey.mail 3600 IN CNAME dkim02._domainkey.alias.proton.me.
dkim03._domainkey.mail 3600 IN CNAME dkim03._domainkey.alias.proton.me.
foundry                3600 IN A     100.42.184.82
gitlab                 3600 IN A     75.119.138.86
host                   60   IN A     213.136.79.151
mail                   3600 IN MX 10 mx1.alias.proton.me.
mail                   3600 IN MX 20 mx2.alias.proton.me.
mail                   3600 IN TXT   "pm-verification=oxkllbawdtxinqklihhehijapmdtaq"
mail                   3600 IN TXT   "v=spf1 include:alias.proton.me ~all"
mail.contact           3600 IN A     45.67.217.3
mermaid                3600 IN A     213.136.79.151
server                 60   IN A     213.136.79.151
www                    300  IN A     185.125.27.14
www                    300  IN AAAA  2001:1600:0:aaaa::80:b
_dmarc                 3600 IN TXT   "v=DMARC1; p=reject; pct=100;"
_dmarc.mail            3600 IN TXT   "v=DMARC1; p=quarantine; pct=100; adkim=s; aspf=s"
_domainkey             3600 IN NS    nsany1.infomaniak.com.
_domainkey             3600 IN NS    nsany2.infomaniak.com.

Dynamic DNS¶

un Dynamic DNS ou DynDNS vous permet de pointer un domaine ou sous-domaine à vous vers une adresse IP dynamique.

Exemple : Imaginez que vous héberger une instance de NextCloud et vous voulez qu'il soit accessible par des membres de votre famille et des amis facilement. Vous pouvez configurer un DynDNS et même si l'IP change, vous n'aurez pas à le découvrir et le changer manuellement.

Mise en place¶

Création de l'utilisateur¶

Il faut avoir les droits administrateurs sur votre serveur DNS.

Dans un premier temps, rendez-vous sur le panel ou vous avez votre nom de domaine. Allez ensuite dans la zone Dynamic DNS.

Vous allez dans : AJOUTER UN DYNAMIC DNS.

Vous devriez avoir un formulaire qui s'est affiché :

1. Laisser vide pour le domaine ou mettez le sous-domaine concerné (dans mon exemple: drive)
2. L'adresse IPv4 public de votre NAS
3. Le nom de l'identifiant pour le DynDNS
4. Le mot de passe

À FAIRE | Configuration de votre routeur¶

À FAIRE | Configuration sur Linux¶

Dans un premier temps, on va installer le logiciel pour la gestion du DynDNS sur Linux via la commande suivante :

sudo apt install ddclient -y

Configuration sur un NAS¶

Sur votre NAS, vous devez vous connectez avec un compte administrateur.

Ensuite, aller dans le Panneau de configuration, puis Accès externe et enfin dans DDNS.

Voici une image :

Cliquer sur Ajouter et vous devriez avoir cette pop-up :

Vous trouverez 4 champs à configurer :

• Le Fournisseur (votre SLD comme Infomaniak)

• Le nom d'hôte

• Votre adresse Mail

• Le mot de passe

Dans un premier temps on va faire le fournisseur. Le problème c'est que Infomaniak n'est pas dans la liste des fournisseurs par défaut, on doit le rajouter. Vous allez donc cliquer sur Personnaliser le fournisseur.

Ceci devrait apparaître :

Mettez le nom du fournisseur et le lien de mise-à-jour (Pour Infomaniak, voici le lien : infomaniak.com/nic/update). Cliquer sur Sauvegarder et vous n'avez plus qu'à sélectionner Infomaniak dans la liste des fournisseurs.

Ensuite, dans le nom d'hôte, mettez le sous-domaine que vous utilisez (dans mon cas, drive.benone.ch).

Pour le nom d'utilisateur, mettez le nom d'utilisateur que vous avez mis sur votre fournisseur (dans mon cas, drive-dyndns-user) et son mot de passe.

Vous n'avez plus qu'à tester via le bouton Test de connexion et cela devrait vous mettre Normal.

Aller maintenant sur le lien et vérifier que cela fonctionne !

Architecture DNS¶

Une architecture DNS se divise sur plusieurs niveaux.

Explication de chaque niveau¶

Niveau Racine (Root Level)¶

C'est le sommet de l'arbre DNS, où se trouvent les serveurs racines qui gèrent la zone racine. Ils dirigent les requêtes vers les serveurs des domaines de premier niveau (TLD) comme .ch, .fr, etc...

Domaines de premier niveau (TLD)¶

TLD ou Top Level Domain représentent les extensions de domaine, qui peuvent être génériques (.com, .org, etc...) ou géographiques (.fr, .ch, etc...). Les serveurs autoritaires des TLD gèrent les sous-domaines correspondant à leur niveau.

Domaine de second niveau (SLD)¶

SLD ou Second Level Domain sont généralement attribués à des organisations ou individus et sont administrés par eux via des registraires (exemple : Infomaniak).

Sous-Domaines¶

Ils permettent de subdiviser un domaine pour organiser des sections spécifiques (exemple : gitlab.unrecon.ch).

Exemple en image¶

Requête en image¶

Explication¶

Supposons que vous souhaitez visiter le site web de www.unrecon.ch.

1. Le client souhaite aller sur www.unrecon.ch

2. Le DNS du FAI demande au serveur DNS Racine pour l'IP de www.unrecon.ch

Le RootDNS ne contient pas l'IP mais uniquement les informations des TLD, qu'elle serveur gère le domaine de premier niveau.

1. Le RootDNS demande alors au TLD ch pour avoir l'IP de www.unrecon.ch.

Le TLD ne contient pas non plus l'IP mais il sait ou est enregistré l'IP de www.unrecon.ch.

1. Le TLD demande au SLD l'IP de www.unrecon.ch

Infomaniak est un des registraires dans le monde. Il y a aussi Contabo, Google, GoDaddy et plein d'autres.

Le SLD est celui qui contient tout votre registre DNS comme vos enregistrements de type A, AAAA, etc...

1. Le SLD renvoie donc au serveur DNS du FAI l'adresse IP de www.unrecon.ch.

2. Le DNS du FAI vous renvoie l'adresse IP de www.unrecon.ch.

Liste des serveurs RootDNS¶

Liste des serveurs TLD .ch et .fr¶

ch¶

Les serveurs DNS TLD .ch sont gérés par SWITCH.

fr¶

Serveur DNS privé et public¶

Privé¶

Un serveur DNS privé permet de gérer la résolution des noms de domaines en fonction de son registre mais peut aussi utiliser un serveur DNS public pour avoir accès à internet.

Public¶

Un serveur DNS public permet de gérer la résolution des noms de domaines au niveau mondial. Contrairement à un DNS privé, il n'est pas possible d'écraser un nom de domaine car elle suit les règles.

Exemple¶

Imaginez que vous travaillez dans une entreprise, on va la CPEG, la Caisse de Prévoyance de l'État de Genève.

La CPEG à un site public qui est sur les serveurs DNS public mais imaginons qu'elle a un site interne disponible à l'adresse www.cpeg.int. www.cpeg.int est enregistré sur le serveur DNS privé de l'entreprise et www.cpeg.ch est toujours accessible par les employés. Comment ça marche ?

Cas 1 : DNS Privé¶

L'employé souhaite accédé à www.cpeg.int. Le serveur DNS locale va alors voir si il a le nom de domaine dans son registre. Dans ce cas, il l'a, alors il va retourné l'IP du site web.

Cas 2 : DNS Public¶

L'employé souhaite accédé à www.cpeg.ch. Le serveur DNS locale va alors voir si il a le nom de domaine dans son registre. Dans ce cas, il ne l'a pas, alors il va demandé à un autre serveur DNS pour avoir l'IP et va le donner le renvoyer.

Comment ça marche¶

Le serveur DNS privé a enregistré le nom de domaine www.cpeg.int dans son registre, mais il n'a pas www.cpeg.ch. Pour continuer à avoir accès à l'Internet mondial, il faut dire au serveur DNS privé que si il n'a pas l'adresse, d'aller questionner un serveur DNS public.

Exemple d'architecture¶

Liste des serveurs DNS publics¶

Différence entre client et serveur¶

Pour comprendre la différence entre client et serveur, il faut savoir qu'il existe 3 types de serveur DNS.

Type de serveur¶

Autoritaire (Serveur)¶

Les serveurs dit Autoritaire, ils contiennent les informations de leur zone et ne s'occupe que de leur zone d'autorité.

Les RootDNS et les TLD sont des serveurs DNS autoritaires.

Récursif (Serveur)¶

Les serveurs dit Récursif, s'occupe de la résolution des noms de domaines, c'est eux qui contiennent les informations des noms de domaines ou qui vont faire le demande vers d'autres serveurs DNS récursif.

Les serveurs DNS récursifs font 2 types de requêtes, des requêtes récursives et non-récursives.

Si le serveur DNS à la donnée dans son cache ou la dans son registre, il va alors faire une requête non récursive, c'est à dire qu'il ne va pas faire d'autre requête externes et va juste renvoyer l'information.

Si le serveur DNS n'à pas la donnée dans son cache ou dans son registre, il va alors faire une requête récursive, c'est à dire qu'il va demander l'information à d'autres serveurs DNS jusqu'à avoir la réponse ou renvoyer une erreur.

Les SLD sont des serveurs DNS sont des serveurs DNS récursif.

Client¶

Le client DNS quant à lui, ne fait qu'une requête au serveur DNS qui le gère qui est OBLIGATOIREMENT un serveur DNS récursif. Le client DNS ne va jamais intérrogé un serveur DNS autoritaire car ce n'est pas son rôle.

Votre routeur est un client DNS.

Maître de zone et esclave¶

Le concepte de Maître de zone et d'esclave sert a déchargé le serveur DNS principale (ici, maître de zone) en plein de petit serveur DNS (ici, esclave).

L'esclave a les données via le maître de zone mais il n'a que des droits de lecture. C'est à dire que si vous consultez un site, il peut vous donnez la donnée mais elle ne peut pas la modifié, vous devez vous adressez au maître de zone.

L'esclave, pour obtenir les données, va faire ce qu'on appel un transfert de zone, il va demandé une copie au maître de zone pour se synchronisé avec lui.

Exemple¶

Les utilisateurs vont seulement intéragir avec les esclaves pour obtenir les informations.

Si ils doivent modifier des données, ils vont directement voir le maître de zone.

Logiciel de Serveur DNS¶

Windows¶

Si vous souhaitez utiliser windows pour héberger votre serveur DNS, je vous recommande fortement d'installer une version de Windows Server (2022, 2019, 2016) qui intègre l'outil DNS Windows Server.

Cliquez-ici pour aller voir un tutoriel.

Linux¶

Sur Linux, il existe un logiciel nommée BIND9 qui permet d'agir comme un serveur DNS.

Cliquez-ici pour aller voir un tutoriel.

MacOS¶

Vous pouvez aussi installer BIND9 sur MacOS via le gestionnaire de paquets.

Cliquez-ici pour aller voir un tutoriel.

Outils¶

Ils existent différent outils pour examiner les données d'un serveur DNS.

NSLookUp¶

C'est un outil installable ou une version en ligne existe via ce lien.

Il permet de tester la résolution des serveurs DNS.

Dig¶

C'est un outil de google pour vérifier les informations d'un serveur DNS disponible en ligne via ce lien.

WhoIs¶

WhoIs permet, comme Dig, de vérifier les informations d'un serveur DNS et même de faire un diagnostique.

C'est un site disponible via ce lien.

Source¶

• Wikipedia DNS
• Devopedia
• Infomaniak
• IBM
• CloudFlare
• AWS
• IANA RootDNS
• IANA ch
• IANA fr
• Root-Servers
• Wikipedia WHOIS

Normes RFC¶

• IETF RFC 1035
• IETF RFC 2782
• IETF RFC 3596
• IETF RFC 4034
• IETF RFC 4255
• IETF RFC 6376
• IETF RFC 6672
• IETF RFC 6698
• IETF RFC 7489
• IETF RFC 8162
• IETF RFC 8659

Liens des outils/tutoriels¶

• Tutoriel Serveur Windows DNS
• Tutoriel DNS Bind9 sur Linux
• Tutoriel DNS Bind9 sur MacOS
• Outil en ligne nslookup.
• Outil en ligne Dig
• Outil en ligne WhoIs