DNS

Domain Name System est le protocole utilisé globalement pour permettre la traduction d'une chaîne de caractères en adresses IP et vice-versa.

Rôle

DNS

Domain Name System

Le protocole DNS permet la conversion de noms de domaines (ex. adresse d’un site web) en adresses IP. L’objectif principal de ce système est de faciliter l’accès aux services offerts sur un réseau, principalement aux services offerts publiquement sur Internet. 

Différents types d'enregistrement permettent l'identification de différents paramètres liés à un domaine. On peut ici penser à l'adresse du serveur responsable des entrées liées à un domaine spécifique, l'adresse du serveur de courriel auquel acheminer des messages destinés à un adresse de ce domaine et quels serveurs sont autorisés à envoyer des courriels en tant que ce domaine.

Structure

Un nom de domaine est composé de termes séparés par un point comme une adresse IP. Ces termes sont énumérés du plus spécifique au moins spécifique. Pensons par exemple à www.google.ca. Dans cet exemple, le www (World Wide Web) représente le service que l’on tente de contacter (un serveur web dans ce cas). La deuxième section représente l’organisation que l’on tente de contacter, Google dans cet exemple. La section suivante représente le domaine de tête ou “top level domain name” (TLD). L’ensemble de ces sections représente ce qu’on appelle un “Fully Qualified Domain Name” (FQDN) et représente généralement un hôte ou un serveur accessible par le réseau. 

image.png

Sections

Le rassemblement de ces 3 sections se nomme un FQDN ou "Fully Qualified Domain Name".

Domaine de tête (TLD)

Les domaines de têtes sont gérés par l'autorité d'assignation des numéros Internet (IANA/Internet Assigned Numbers Authority) et ce sont les serveurs racine (root-servers) qui dirigeront les requêtes DNS vers différents registraires en fonction du sous-domaine et du TLD consulté.

Génériques (gTLD)

Les domaines de tête génériques sont les plus répandus, on peut penser ici à .com, .org, .net, etc. En 2011, une panoplie d’autres domaines de têtes ont été ajoutés tels que .life, .cloud, .art, etc. 

Sponsorisés (sTLD)

Les domaines de tête sponsorisés sont des domaines appartenant à des organisations privées. On peut penser ici à .edu pour les universités, .gov pour les organismes gouvernementaux, .travel pour les agences de voyages, etc.

Code national (ccTLD)

Comme le suggère le nom, les domaines de tête de codes nationaux sont les .qc, .ca, .us, .cn, .ru, .fr et autres pays/régions de ce monde. Les domaines de tête composés de deux lettres sont généralement des domaines de code national. Ceci inclus des domaines tels que .gg (Guernsey), .io (territoires brittaniques de l'océan Indien), .tv (Tuvalu), .it (Italie) qui sont souvent utilisés à des fins autres que nationales dû à leur ressemblance à d'autres acronymes populaire en lien avec des thèmes associés à la télécommunication. Certains pays en font la location une grande partie de leur économie. En date de 2024, les domaines .tv génèrent environ 7 millions de dollars australiens (majoritairement dû au domaine twitch.tv) annuellement représentant près de 10% de leur produit intérieur brut. 

Locaux

Le domaine .local a été réservé pour utilisation au sein d'un réseau local par l'ITEF. Ce TLD est donc utilisé pour faire référence aux serveurs locaux, à vos imprimantes, à vos routeurs, etc.

Nom de domaine

Un nom de domaine est le nom attribué à un domaine. On peut penser ici à "google".com, "twitch".tv, "cegepat".qc.ca, etc. Il s'agit généralement du nom de l'organisation en étant responsable, du produit associé au site ou de l'administrateur du domaine. Si ce domaine est local, il est nécessaire de consulter le serveur DNS responsable du sous-domaine pour résourdre les adresses associées à ce domaine mais s'il s'agit d'un sous-domaine public, ce sous-domaine sera généralement loué à un registraire tel que GoDaddy, namecheap, le CIRA ou d'autres organisations enregistrées auprès de l'IANA pour la location de domaines publics et sera par conséquent connu de tous les serveurs DNS publics.

Sous-domaine

Un sous-domaine est une entrée associée à un domaine et fait généralement référence à un service offert tel que "www" dans le cas d'un site web, "mail" dans le cas d'un serveur de courriels, etc. Il peut aussi être associé à une machine résidant dans un réseau tel que le type d'appareil (on peut penser ici à une imprimante, un partage de fichiers réseau, etc.) ou au nom d'un appareil tel que votre téléphone cellulaire, votre ordinateur portatif, votre routeur, etc.

URL (Uniform Resource Locator)

Un URL ou "localisateur uniforme de ressource" est une combinaison d'un protocole, d'un domaine (ou une adresse IP) ainsi qu'un emplacement dans ce domaine où trouver une ressource particulière. Cette notation est utilisée prédominamment pour la navigation web.

Elle prend la structure suivante, le protocole suivi d'un séparateur tel que "://", ":/" ou encore tout simplement "/", le FQDN et le chemin vers la ressource à consulter.

image.png

 

 

Types d'enregistrements

Chaque type d'enregistrement DNS occupe un rôle différent en faisant référence à un type d'objet différent. Cette liste n'est pas exhaustive mais décrit les types d'enregistrement les plus répandus.

A

Un enregistrement de type A est un nom de domaine faisant référence à une adresse IPv4.

AAAA

Un enregistrement de type AAAA est un nom de domaine faisant référence à une adresse IPv6.

NS

Un enregistrement de type NS mentionne à quel serveur DNS se référer pour contacter les enregistrements liés à ce sous-domaine. Prenez pour exemple “cegepat.qc.ca”, leurs entrées NS indiquent aux systèmes tentant de rejoindre des enregistrements de ce domaine de se référer aux serveurs “ns1.zonerisq.ca” et “ns2.zonerisq.ca”.

CNAME

Un enregistrement de type CNAME est un alias pour un autre enregistrement de nom de domaine.

Ce type d’enregistrement est généralement utilisé pour faire abstraction du nom réel d’un serveur au profit du service offert par le serveur auquel l’enregistrement réfère. Par exemple, mon serveur de courriels pourrait porter un nom tel que “catmx01.cegepat.local” et l’enregistrement CNAME pourrait être “courrier.cegepat.local”. Il serait alors possible de remplacer le serveur de courrier par un nouveau serveur de courrier portant le nom “catmx02.cegepat.local” sans devoir configurer tous les appareils et logiciels utilisant ce serveur tout simplement en changeant le serveur auquel “courrier.cegepat.local” fait référence à.

Ceux-ci peuvent aussi être utilisés pour indiquer à un serveur web hébergeant plusieurs sites web celui qu’on désire visiter. Prenez comme exemple le domaine “renecollard.com”. L’entrée A réfère à l’adresse IP 72.10.160.242 tout comme l’entrée pour le serveur de courrier. Si vous accédez au serveur par l’adresse “mail.renecollard.com”, un site web différent vous sera présenté que si vous accédez au serveur par l’adresse “renecollard.com”. Ceci s’appelle un hôte virtuel.

PTR

Un enregistrement de type PTR est l’inverse d’un enregistrement de type A, il nous permet de trouver un nom de domaine par son adresse IP.

MX

Un enregistrement de type MX indique aux systèmes de courriel à quel serveur faire parvenir les courriels destinés à une adresse appartenant à un certain domaine. Prenez pour exemple “cegepat.qc.ca”, leur entrée MX indiquera aux autres systèmes de courriel que pour acheminer des courriels à des adresses email @cegepat.qc.ca, il faudra les faire parvenir à “cegepat-qc-ca.mail.protection.outlook.com”

TXT

Un enregistrement TXT présentera une chaîne de caractères plutôt que de référer à un autre domaine ou une adresse IP. Ce type d’entrée est généralement utilisé pour prouver qu’un domaine vous appartient ou pour spécifier des paramètres supplémentaires pour des systèmes comme des serveurs de courriels.

Fonctionnement

Démarche

DNS fonctionne principalement avec le protocole UDP au port 53. Une requête contenant ledomaine ou le FQDN ainsi que le type d’enregistrement demandé est envoyée à un serveur DNS. 

Si celui-ci est autoritaire du domaine en question (c’est-à-dire que ce domaine est géré par lui-même) nous répondra directement avec l’information correspondant à la requête, soit le domaine référé par un CNAME, l’adresse IP référée par une entrée A, le serveur de courriel correspondant à l’entrée MX, etc.

S’il n’est pas autoritaire du domaine demandé, il acheminera notre requête à un autre serveur DNS. Si vous utilisez votre routeur comme serveur DNS à la maison, tous les domaines mis à part votre domaine local seront acheminés à un serveur DNS public. Il vous mentionnera alors qu’il n’est pas autoritaire du domaine demandé en vous remettant l’information concernant le domaine demandé lorsque la réponse lui sera acheminée.

Un serveur DNS a généralement une mémoire temporaire pour éviter de questionner son serveur en amont ou “upstream” à chaque requête. Pour cette raison, lorsqu’on enregistre un nouveau domaine public, il est fort probable que notre domaine ne soit pas immédiatement accessible.

Les serveurs publics les plus populaires sont 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9) mais tous ces serveurs publics se réfèrent ultimement à “root-servers.org” qui est une organisation d’opérateurs indépendants connaissant l’ensemble des domaines publics. Ces “root-servers” sont essentiels au fonctionnement d’Internet tel qu’on le connaît. Sans ce service, il faudrait accéder aux différentes ressources par leur adresse IP.

Tout comme le protocole Telnet, les requêtes et réponses DNS sont visibles en texte clair dans une capture de paquets. Depuis peu, il est maintenant possible d’acheminer ces requêtes de façon encryptée par DNS-over-TLS et DNS-over-HTTPS aux serveurs le supportant tels que ceux de Google (dns.google) et cloudflare (one.one.one.one et cloudflare-dns.com).

Requête

Une requête contient généralement le type d'enregistrement demandé ainsi que le FQDN, sous-domaine ou domaine à résoudre.

Exemple d'une requête demandant l'adresse IP correspondant à "cegepat.qc.ca"

Domain Name System (query)
    Questions: 1
    Queries
        cegepat.qc.ca: type A, class IN
            Name: cegepat.qc.ca
            Type: A (1) (Host Address)
            Class: IN (0x0001)

Exemple d'une requête demandant l'adresse du serveur de courriels pour le domaine "cegepat.qc.ca"

Queries
    cegepat.qc.ca: type MX, class IN
        Name: cegepat.qc.ca
        Type: MX (15) (Mail eXchange)

Exemple d'une requête demandant tout type d'enregistrement correspondant au domaine "google.com"

Queries
    google.ca: type ANY, class IN
        Name: google.ca
        Type: ANY (255) (A request for all records the server/cache has available)
        Class: IN (0x0001)

Réponse

Lorsqu'interrogé, un serveur DNS vérifiera sa propre configuration pour vérifier s'il est autoritaire (responsable) du domaine questionné. Advenant le cas contraire, si le serveur est configuré en conséquence, il consultera un autre serveur DNS (généralement un serveur public comme 8.8.8.8, 1.1.1.1 ou un des serveurs racine/root-servers) et nous acheminera la réponse s'il trouve l'information demandée. Dans sa réponse, le serveur indiquera s'il est autoritaire du serveur.

Exemple d'une réponse à une requête demandant tout type d'enregistrement correspondant au domaine "google.com"

Answers
    google.ca: type A, class IN, addr 142.251.32.67
    google.ca: type AAAA, class IN, addr 2607:f8b0:400b:807::2003
    google.ca: type NS, class IN, ns ns2.google.com
    google.ca: type SOA, class IN, mname ns1.google.com
    google.ca: type TXT, class IN
    google.ca: type NS, class IN, ns ns4.google.com
    google.ca: type NS, class IN, ns ns3.google.com
    google.ca: type MX, class IN, preference 0, mx smtp.google.com
    google.ca: type NS, class IN, ns ns1.google.com
    google.ca: type CAA, class IN

Outils

Windows

nslookup (cmd)

La commande nslookup est un invite de commande interactif permettant d'interroger des serveurs DNS. Il est disponible par défaut sous Windows mais est aussi disponible sous Linux et MacOS.

L'invocation de la commande "nslookup" ouvrira la console nslookup et affichera ">". À cet endroit vous pourrez paramétrer votre requête. Vous pouvez mentionner le serveur à interroger avec "server [adresse du serveur]", le type d'enregistrement à demander avec "set type=[type d'enregistrement]" (par défaut, le type A sera sélectionné) et le domaine à chercher en mentionnant tout simplement l'adresse recherchée.

Exemple d'une requête en nslookup pour récupérer l'enregistrement "NS" du domaine "cegepat.qc.ca" :

❯ nslookup
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> set type=NS
> cegepat.qc.ca
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
cegepat.qc.ca	nameserver = ns2.zonerisq.ca.
cegepat.qc.ca	nameserver = ns1.zonerisq.ca.

Resolve-DNSName (powershell)

Resolve-HostName est la commande en Windows la plus près de la fameuse commande "dig". Il s'agit d'un applet de commande powershell qui permet d'interroger un serveur DNS en une seule ligne de commande ce qui permet d'utiliser la réponse dans un script.

Une requête de base pour une entrée A aurait comme strucure "Resolve-DNSName -Name [nom de domaine]". Pour spécifier un autre type d'entrée DNS, il est possible d'utiliser l'option -Type dans une commande telle que "Resolve-DNSNae -Name [nom de domaine] -Type [type]". Il est aussi possible de mentionner le serveur à questionner en ajoutant l'option "-Server [adresse du server]".

Exemple d'une requête avec Resolve-DNSName demandant l'adresse du serveur de courriel pour le domaine "cegepat.qc.ca" au serveur DNS de Google :

PS C:\Windows\system32> Resolve-DnsName -Name cegepat.qc.ca -Server 8.8.8.8 -Type MX

Name                                     Type   TTL   Section    NameExchange                              Preference
----                                     ----   ---   -------    ------------                              ----------
cegepat.qc.ca                            MX     3600  Answer     cegepat-qc-ca.mail.protection.outlook.com 0

Unix (Linux/MacOS)

dig

La commande "dig" est probablement la commande la plus populaire et la plus bavarde pour interroger un serveur DNS. Cette commande fait partie du package nommé "bind-utils" ou "dnsutils" dans la majorité des distributions de Linux. Cette commande permet d'interroger des serveurs DNS avec une panoplie d'options ainsi que des serveurs DoH (DNS-over-HTTPS). La structure de cette requête est "dig @[adresse du serveur] [type d'enregistrement] [options supplémentaires] [domaine].

Exemple d'une requête demandant l'ensemble des types d'entrées DNS pour le domaine "bad.horse" :

❯ dig +noall +answer +multiline bad.horse any
bad.horse.		7200 IN	A 162.252.205.157
bad.horse.		7200 IN	CAA 0 issue "letsencrypt.org"
bad.horse.		7200 IN	CAA 0 issuewild ";"
bad.horse.		7200 IN	CAA 128 issuemail ";"
bad.horse.		7200 IN	CAA 0 iodef "mailto:abuse@sandwich.net"
bad.horse.		7200 IN	MX 10 mx.sandwich.net.
bad.horse.		7200 IN	NS a.sn1.zone.
bad.horse.		7200 IN	NS b.sn1.zone.
bad.horse.		7200 IN	SOA a.sn1.zone. n.sn1.zone. (
				2023040401 ; serial
				1200       ; refresh (20 minutes)
				180        ; retry (3 minutes)
				1209600    ; expire (2 weeks)
				60         ; minimum (1 minute)
				)

Exemple d'une requête encryptée demandant les entrées TXT du domaine "dns.google" auprès du serveur DNS de Cloudflare en DoH (DNS par HTTPS) :

❯ dig @one.one.one.one +https TXT dns.google

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2427
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;dns.google.			IN	TXT

;; ANSWER SECTION:
dns.google.		300	IN	TXT	"v=spf1 -all"
dns.google.		300	IN	TXT	"https://xkcd.com/1361/"

;; Query time: 63 msec
;; SERVER: 1.0.0.1#443(one.one.one.one) (HTTPS)

whois

La commande est un outil permettant d'interroger le registraire d'un domaine plutôt que le serveur de nom de domaine pour trouver les informations au sujet du locateur et du locataire du domaine. Certains outils en ligne permettent aussi de récupérer ces informations mais il s'agit d'un outil à la ligne de commande Linux. Cette commande interroge les registraires de domaines plutôt que les serveurs de noms de domaine.

Exemple des informations pertinentes d'une requête whois du domaine "cegepat.qc.ca"

whois cegepat.qc.ca

Domain Name: cegepat.qc.ca
Registry Domain ID: D270086-CIRA
Registrar WHOIS Server: whois.ca.fury.ca
Registrar URL: www.rebel.ca
Updated Date: 2024-04-29T12:40:57Z
Creation Date: 2000-11-02T18:22:55Z
Registry Expiry Date: 2025-06-14T04:00:00Z
Registrar: Rebel.ca Corp.
Registrar IANA ID: not applicable
Registrar Abuse Contact Email: abuse@rebel.com
Registrar Abuse Contact Phone: +1.6132252000
Registry Registrant ID: 91219630-CIRA
Registrant Name: Cegep AT
Registrant Organization:
Registrant Street: 425 Boulevard du Collège
Registrant City: Rouyn-Noranda
Registrant State/Province: QC
Registrant Postal Code: J9X5E5
Registrant Country: CA
Registrant Phone: +1.8197620931
Registrant Email: hostmaster@cegepat.qc.ca
Registry Admin ID: 91219635-CIRA
Admin Name: Dave St-Germain
Admin Organization: Cegep AT
Admin Street: 425 Boulevard du Collège
Admin City: Rouyn-Noranda
Admin State/Province: QC
Admin Postal Code: J9X5E5
Admin Country: CA
Admin Phone: +1.8197620931
Admin Email: hostmaster@cegepat.qc.ca
Registry Tech ID: 91219635-CIRA
Tech Name: Dave St-Germain
Tech Organization: Cegep AT
Tech Street: 425 Boulevard du Collège
Tech City: Rouyn-Noranda
Tech State/Province: QC
Tech Postal Code: J9X5E5
Tech Country: CA
Tech Phone: +1.8197620931
Tech Email: hostmaster@cegepat.qc.ca
Name Server: ns1.zonerisq.ca
Name Server: ns2.zonerisq.ca
DNSSEC: unsigned

% (c) 2024 Canadian Internet Registration Authority, (http://www.cira.ca/)

Encryption de requêtes

DNS est un protocole UDP opérant au port 53. Ceci implique que la requête est en texte clair, sans encryption et que n'importe qui interceptant la requête peut identifier l'ensemble des services auxquels vous accédez. On peut penser ici à l'administration informatique du cégep, d'un café internet ou encore d'un aéroport. Une requête a généralement la structure suivante : 

Domain Name System (query)
    Questions: 1
    Queries
        tiktok.com: type A, class IN
            Name: tiktok.com
            Type: A (1) (Host Address)
            Class: IN (0x0001)

Dans cette requête, un serveur DNS est interrogé pour l'entrée de type A (correspondant à l'adresse IPv4 du domaine) pour tiktok.com. On peut observer avec la section "Questions: 1" que je demande ici uniquement une information (l'entrée de type A).

La réponse à cette demande serait la suivante : 

Domain Name System (response)
    Questions: 1
    Queries
        tiktok.com: type A, class IN
            Name: tiktok.com
            Type: A (1) (Host Address)
            Class: IN (0x0001)
    Answers
        tiktok.com: type A, class IN, addr 23.222.17.15
            Name: tiktok.com
            Type: A (1) (Host Address)
            Class: IN (0x0001)
            Address: 23.222.17.15
        tiktok.com: type A, class IN, addr 23.222.17.8
            Name: tiktok.com
            Type: A (1) (Host Address)
            Class: IN (0x0001)
            Address: 23.222.17.8

On observe ici que la réponse à l'entrée "tiktok.com" est 23.222.17.8. On peut donc assumer que l'appareil ayant effectué la requête a contacté TikTok.

Il est donc facile de déterminer avec ces informations facilement capturables à quels services un appareils se réfère que ce soit par une attaque de type "Man In The Middle" (MITM) ou en étant tout simplement l'administrateur d'un réseau.

Pour améliorer la sécurité de ce mécanisme, il est dorénavant possible d'effectuer des requêtes par "HTTPS" ou "Hypertext Protocol Secure" ou encore par "TLS" ou "Transport Layer Security" permettant l'encryption de ces requêtes entre un client et un serveur DNS. Ce faisant, les requêtes DNS sont encryptées et acheminées en TCP par le port 443 (DoH) ou 853 (DoT) au serveur DNS.

On peut observer ici qu'une requête DNS pour tiktok.com est beaucoup plus complexe et encryptée en TLS.

image.png

Ceci est le trafic qu'un administrateur réseau ou un une personne au milieu pourrait observer pour une telle requête/réponse :

Transport Layer Security
    [Stream index: 0]
    TLSv1.3 Record Layer: Application Data Protocol: Domain Name System
        Opaque Type: Application Data (23)
        Version: TLS 1.2 (0x0303)
        Length: 445
        Encrypted Application Data […]: 45b4de58ddc0edd64aeea19a460b8c70dbff0494487d7f653a30c69b88cafd0301991a8b516080abf3997d8543d6cfa129759689dece0caf937e7e43b0b7ca3b32cee01d283ad6167f22d6d0e7c7d62b1207bd79d4ed343b0051ae5bff729e2cae97e83fced64
        [Application Data Protocol: Domain Name System]
    TLSv1.3 Record Layer: Application Data Protocol: Domain Name System
        Opaque Type: Application Data (23)
        Version: TLS 1.2 (0x0303)
        Length: 487
        Encrypted Application Data […]: 3e4547e09af20c69527369f8f2dd96da903012c63afad1295cac5263e51d1e0c829d3b3ff4d5bc5b108f364581231f9b76518c414fb4a0c977896866c9aeb01aab9b80cdbcac5e29721e997fbdcce4f9c443de6683632b6937eb14d341ec84bb67ad2a7d8ce12
        [Application Data Protocol: Domain Name System]