Skip to content

Noms de domaine, DNS et HTTPS

Avant-propos

Lorsque vous saisissez www.google.com dans votre navigateur et appuyez sur Entrée, que se passe-t-il réellement ? Cette action en apparence simple implique une série de processus complexes : résolution de nom de domaine, requêtes DNS, négociation TLS, etc. Comprendre ces mécanismes est un prérequis indispensable pour tout développeur — cela détermine directement si votre site est accessible et si vos données sont protégées contre les interceptions.

Que allez-vous apprendre dans cet article ?

À l'issue de ce chapitre, vous maîtriserez :

  • Principes du DNS : comprendre le processus complet de traduction d'un nom de domaine en adresse IP
  • Types d'enregistrements : connaître les usages des enregistrements DNS courants (A, CNAME, MX, etc.)
  • Mécanisme HTTPS : comprendre comment la négociation TLS établit une connexion sécurisée
  • Chaîne de certificats : découvrir la chaîne de confiance des certificats numériques et le mécanisme de vérification
  • Conscience sécuritaire : comprendre pourquoi HTTPS est une exigence fondamentale du Web moderne
ChapitreContenuConcepts clés
Chapitre 1Résolution DNSRequête récursive, requête itérative
Chapitre 2Enregistrements DNSA, CNAME, MX, TXT
Chapitre 3HTTPS et TLSProcessus de négociation, communication chiffrée
Chapitre 4Chaîne de confiance des certificatsCA, certificat racine, certificat intermédiaire
Chapitre 5HTTP vs HTTPSTexte clair vs chiffré, comparaison de sécurité

0. Vue d'ensemble : du nom de domaine à la connexion sécurisée

Les communications sur Internet reposent sur des adresses IP (comme 142.250.80.46), mais les humains ne peuvent pas mémoriser ces nombres. C'est pourquoi le système de noms de domaine (DNS) a été inventé — l'« annuaire téléphonique » d'Internet, qui traduit les noms de domaine lisibles par l'homme en adresses IP lisibles par la machine.

Mais pouvoir trouver le serveur ne suffit pas. Si les communications transitent en clair, tout intermédiaire peut intercepter ou altérer vos données. HTTPS résout précisément ce problème — il ajoute une couche de chiffrement TLS au-dessus de HTTP, garantissant la confidentialité et l'intégrité des données pendant le transit.

Une visite web complète

  1. Résolution de nom de domaine : le navigateur demande au DNS « Quelle est l'IP de www.google.com ? », le DNS répond « 142.250.80.46 »
  2. Connexion TCP : le navigateur établit un triple handshake TCP avec le serveur
  3. Négociation TLS : les deux parties conviennent des algorithmes de chiffrement, vérifient le certificat et échangent les clés
  4. Communication chiffrée : toutes les données HTTP transitent par un canal chiffré

1. Résolution DNS : l'« annuaire téléphonique » d'Internet

Le fonctionnement du DNS (Domain Name System) s'apparente à la consultation d'un annuaire téléphonique : vous connaissez le nom de votre correspondant (le nom de domaine) et vous devez trouver son numéro de téléphone (l'adresse IP). Mais l'« annuaire » d'Internet n'est pas un seul livre — c'est un système distribué et hiérarchique.

🔍 DNS Resolution Simulator

🌐
Browser cache
💻
OS cache
🔄
Recursive resolver
🌍
Root name server
📂
TLD server
🏠
Authoritative DNS server
Resolution flow: When the browser visits a website, it first translates the domain name into an IP address. This process checks multiple caches and servers until the matching IP is found.

Les quatre étapes de la résolution DNS

  1. Cache du navigateur : on consulte d'abord le cache local ; si ce domaine a déjà été visité, on utilise l'IP en cache
  2. Résolveur récursif : en cas d'absence dans le cache, la requête est envoyée au résolveur récursif du FAI (par exemple 8.8.8.8)
  3. Requête hiérarchique : le résolveur interroge successivement le serveur racine → le serveur de domaine de premier niveau (.com) → le serveur de nom faisant autorité (google.com)
  4. Retour du résultat : le serveur faisant autorité retourne l'IP finale, le résolveur met en cache le résultat et le transmet au navigateur
NiveauServeurRôleNombre
RacineRoot ServerConnaît les adresses de tous les TLD13 groupes dans le monde
TLDTLD ServerGère .com, .cn, .org, etc.Un groupe par suffixe
Faisant autoritéAuthoritativeStocke les enregistrements DNS des domaines spécifiquesAu moins 2 par domaine
Résolveur récursifResolverEffectue l'ensemble de la requête pour l'utilisateurFAI ou DNS public

2. Types d'enregistrements DNS : la « table de configuration » derrière les noms de domaine

Le DNS ne se contente pas de traduire les noms de domaine en adresses IP. Grâce aux différents types d'enregistrements DNS, vous pouvez contrôler la livraison des e-mails, les redirections de domaine, la découverte de services et bien plus encore. Comprendre ces types d'enregistrements est la base de la configuration de domaines et du dépannage réseau.

📋 DNS Record Type Cheatsheet

AAddress record

Maps a domain name to an IPv4 address. This is the most common DNS record type and is ultimately what browsers need when visiting a site.

Example record
example.com. IN A 93.184.216.34
Common uses
  • Point a website domain to a server IP
  • Point subdomains to different servers
  • Return multiple IPs for load balancing
Tip: DNS does more than translate domains into IP addresses. It also supports mail routing, domain verification, load balancing, and other features through different record types.
Type d'enregistrementUsageExemple
ANom de domaine → adresse IPv4example.com → 93.184.216.34
AAAANom de domaine → adresse IPv6example.com → 2606:2800:220:1:...
CNAMENom de domaine → un autre nom de domaine (alias)www.example.com → example.com
MXDésigne le serveur de messagerieexample.com → mail.example.com
TXTStocke des informations textuellesVérification SPF, preuve de propriété du domaine
NSDésigne le serveur de nom faisant autoritéexample.com → ns1.example.com

Configuration DNS en situation réelle

  • Déployer un site web : ajouter un enregistrement A pointant vers l'IP du serveur, ou un CNAME pointant vers le domaine CDN
  • Configurer la messagerie : ajouter un enregistrement MX pointant vers le serveur de messagerie, un enregistrement TXT pour configurer SPF/DKIM anti-spam
  • Vérifier la propriété d'un domaine : le fournisseur cloud vous demande d'ajouter un enregistrement TXT spécifique pour prouver que vous possédez ce domaine
  • Équilibrage de charge : configurer plusieurs enregistrements A pour un même domaine, le DNS distribue le trafic par rotation

3. HTTPS et TLS : mettre un « gilet pare-balles » aux données

Le protocole HTTP transmet les données en clair — comme envoyer une carte postale que le facteur (l'intermédiaire) peut lire à sa guise. HTTPS ajoute une couche de chiffrement TLS (Transport Layer Security) au-dessus de HTTP, ce qui revient à glisser la carte postale dans une enveloppe scellée.

La négociation TLS est l'étape clé pour établir une connexion sécurisée. Avant de transmettre des données, elle effectue l'authentification et la négociation des clés.

🤝 TLS Handshake Demo

💻
Client (browser)
Client Hello
Send supported TLS versions, cipher suites, and random number
Server Hello
Choose TLS version, cipher suite, and server random number
Certificate
Server sends its digital certificate with public key
Key Exchange
Both sides negotiate and generate a session key
Finished
Both sides confirm the handshake and start encrypted communication
🖥️
Server

Étapes clés de la négociation TLS 1.3

  1. Client Hello : le client envoie la liste des algorithmes de chiffrement pris en charge et un nombre aléatoire
  2. Server Hello : le serveur sélectionne l'algorithme de chiffrement, retourne le certificat numérique et un nombre aléatoire
  3. Vérification du certificat : le client vérifie la fiabilité du certificat serveur (vérifie la signature CA, la date de validité, la correspondance du domaine)
  4. Échange de clés : les deux parties négocient une clé partagée via l'algorithme ECDHE (la clé elle-même n'est pas transmise sur le réseau)
  5. Communication chiffrée : toutes les données ultérieures sont chiffrées avec la clé symétrique négociée
CaractéristiqueTLS 1.2TLS 1.3
Allers-retours de négociation2-RTT1-RTT (première fois) / 0-RTT (reprise)
Échange de clésRSA ou ECDHEUniquement ECDHE (sécurité anticipée)
Algorithmes de chiffrementPrend en charge de nombreux anciens algorithmesUniquement les algorithmes sécurisés
PerformancePlus lentPlus rapide

4. Chaîne de confiance des certificats : pourquoi faire confiance à ce site ?

L'étape la plus critique de la négociation TLS est la « vérification du certificat ». Comment le navigateur détermine-t-il qu'un certificat de site est authentique et non forgé par un attaquant ? La réponse réside dans la chaîne de confiance des certificats — un système de confiance reposant sur des niveaux de cautionnement successifs.

🔗 Certificate Trust Chain

Click each certificate layer to inspect its details and role in the trust chain.

🏛️
Root Certificate (Root CA)
Starting point of trust
issues
🏢
Intermediate Certificate (Intermediate CA)
Bridge of trust
issues
🌐
Server Certificate
Website identity card
🏛️Root Certificate (Root CA)
IssuerDigiCert Global Root G2 (self-signed)
Validity25 years (2013 - 2038)
Key lengthRSA 2048-bit
StorageOS/browser built-in trust store
ScaleAbout 150 trusted root certificates globally
The root certificate is the anchor of the whole trust chain. It is self-signed by a root certificate authority and preinstalled in operating systems and browsers. Only a small number of root CAs exist globally, protected by strict audits and physical security. Root CA private keys are usually stored offline in hardware security modules.
🔍 Browser Verification Flow
1Browser receives the server certificate and reads issuer information.
2It finds the intermediate certificate and verifies the server certificate signature with the intermediate CA public key.
3It then verifies the intermediate certificate signature with the root CA public key.
4It confirms the root certificate exists in the local trust store, so the whole chain is valid.

La structure à trois niveaux de la chaîne de confiance

  1. Certificat racine (Root CA) : émis par une autorité de certification de confiance, préinstallé dans les systèmes d'exploitation et les navigateurs. C'est l'« ancre » de la confiance.
  2. Certificat intermédiaire (Intermediate CA) : émis par le CA racine, utilisé pour émettre les certificats finaux. Le CA racine n'émet pas directement les certificats de site web, par isolation de sécurité.
  3. Certificat terminal (Leaf Certificate) : le certificat effectivement utilisé par votre site web, émis par le CA intermédiaire, contenant le domaine, la clé publique, la date de validité, etc.
Type de certificatNiveau de vérificationDélai d'émissionCas d'utilisation
DV (Validation de domaine)Vérifie uniquement la propriété du domaineEn quelques minutesSites personnels, blogs
OV (Validation d'organisation)Vérifie l'identité de l'organisationQuelques joursSites d'entreprise
EV (Validation étendue)Vérification stricte de l'organisationQuelques semainesBanques, institutions financières
Certificat génériqueCouvre tous les sous-domainesSelon le typeScénarios multi-sous-domaines

5. HTTP vs HTTPS : pourquoi le chiffrement est un minimum absolu ?

En 2024, plus de 95 % du trafic web mondial transitait déjà via HTTPS. Le navigateur Chrome affiche un avertissement « Non sécurisé » pour les sites HTTP, et les moteurs de recherche pénalisent le classement des sites HTTP. HTTPS n'est plus une « option », mais une exigence fondamentale du Web moderne.

🔐 HTTP vs HTTPS Data Transfer

💻
Browser
Original data
password=MySecret123&user=zhangsan
🔓 Plaintext transfer
🕵️
A man-in-the-middle can eavesdrop
🖥️
Server
ItemHTTPHTTPS
Port80443
Data encryptionNone (plaintext)TLS symmetric encryption
Identity verificationNoneCA certificate verifies server identity
Data integrityNo guaranteeMAC check prevents tampering
SEO impactSearch engines may rank it lowerPreferred by search engines
Performance costNo extra overheadTLS handshake adds about 1-2 RTT
DimensionHTTPHTTPS
Transmission des donnéesEn clair, pouvant être interceptéeChiffrée, indéchiffrable
AuthentificationAucune, impossible de confirmer l'identité du serveurOui, vérification du serveur via certificat
Intégrité des donnéesNon protégée, pouvant être altéréeProtégée, toute altération est détectée
Port80443
Impact SEOClassement réduitBonus de classement
Comportement du navigateurAffiche l'avertissement « Non sécurisé »Affiche l'icône de cadenas

Obtenir gratuitement un certificat HTTPS

Let's Encrypt est une autorité de certification gratuite et automatisée qui permet à tout site web d'activer HTTPS sans aucun coût. Associé à l'outil Certbot, vous pouvez demander et renouveler automatiquement les certificats en une seule commande. La plupart des plateformes cloud et des fournisseurs CDN proposent également des certificats SSL gratuits.


Résumé

Les noms de domaine, le DNS et HTTPS sont les trois piliers de l'infrastructure Internet. Le DNS nous permet d'accéder aux sites web via des noms lisibles par l'homme, et HTTPS garantit que les communications sont sécurisées et fiables.

Passons en revue les points clés de ce chapitre :

  1. Le DNS est un système hiérarchique : racine → TLD → faisant autorité, requête niveau par niveau, accélérée par le cache
  2. Les types d'enregistrements ont chacun leur usage : l'enregistrement A pointe vers une IP, le CNAME crée un alias, le MX gère la messagerie, le TXT sert à la vérification
  3. La négociation TLS établit la confiance : vérification de certificat + négociation de clés, TLS 1.3 ne nécessite qu'un 1-RTT
  4. La chaîne de confiance des certificats : CA racine → CA intermédiaire → certificat terminal, cautionnement niveau par niveau
  5. HTTPS est un minimum absolu : les certificats gratuits (Let's Encrypt) rendent le chiffrement accessible à tous

Pour aller plus loin