DNS, IP, routing, HTTPS — l'anatomie d'internet que tu dois maîtriser avant de déployer

Internet ne tombe jamais en panne par hasard. Il tombe en panne à l'endroit précis où tu ne regardes pas.

C'est un dimanche soir. Ton nouveau domaine est enregistré depuis deux heures. Tu as suivi le tuto Coolify, configuré Stripe, branché ton MX chez Google Workspace. Tout est censé marcher le lendemain matin pour le lancement.

À 6h30, tu constates que les emails de confirmation Stripe n'arrivent pas. Le site charge, mais les mails de bienvenue partent dans le vide. Tu regardes la console, tout est vert. Tu regardes Stripe, les webhooks passent. Tu ne sais pas où chercher — et pendant ce temps, tes premiers acheteurs pensent que ton site est cassé.

Le coupable : un enregistrement MX mal configuré et un TTL de 86 400 secondes que personne ne t'avait expliqué. Tes records DNS se propagent depuis les serveurs autoritaires jusqu'aux résolveurs du monde entier, et ce processus prend du temps — parfois 48 heures. Pendant toute cette fenêtre, une partie des serveurs mail du monde t'envoient dans l'espace.

Ce cas n'est pas rare. C'est le scénario médian du premier déploiement. Et il s'évite complètement si tu comprends les quatre briques fondamentales qui font fonctionner internet : DNS, IP, routing et HTTPS. Pas au niveau d'un ingénieur réseau — au niveau opérationnel d'un fondateur qui sait où chercher quand quelque chose ne tourne pas rond.

C'est exactement ce que cet article t'apporte.

DNS : le carnet d'adresses mondial que tu dois savoir lire

Ce que DNS fait réellement

Quand ton navigateur tape monprojet.fr, il ne sait pas où se trouve le serveur. Il connaît un nom — pas une adresse. Le Système de Noms de Domaine (DNS pour Domain Name System) est ce qui traduit monprojet.fr en 195.24.xx.xx, l'adresse IP réelle de ton serveur.

Cette traduction suit un chemin précis. Ton ordinateur interroge d'abord un résolveur récursif — souvent celui de ton FAI, de Cloudflare (1.1.1.1) ou de Google (8.8.8.8). Ce résolveur ne connaît pas forcément la réponse de tête, mais il sait à qui demander. Il remonte la chaîne : les serveurs racine (13 clusters planétaires qui connaissent la liste des TLD), puis les serveurs TLD (.fr, .com, etc.), puis finalement le serveur autoritaire de ton domaine — celui que ton registrar ou Cloudflare héberge pour toi. C'est ce serveur autoritaire qui possède la vérité sur tes records.

La réponse remonte dans l'autre sens, mise en cache à chaque étape, et ton navigateur peut enfin se connecter.

Les types de records que tu rencontres au quotidien

Le record TXT mérite une attention particulière. Il sert à la fois à l'authentification mail (SPF, DKIM, DMARC) et à la vérification de propriété du domaine (Google, Stripe, GitHub). Si ton record SPF est absent ou mal formé, tes mails Stripe finissent en spam — ou pire, sont rejetés avant d'atteindre la boîte.

TTL et propagation : le délai qui tue les lancements

Le TTL (Time To Live) est la durée en secondes pendant laquelle un résolveur peut mettre en cache ta réponse DNS avant de reposer la question. Un TTL de 86400 signifie 24 heures. Un TTL de 300 signifie 5 minutes.

La règle opérationnelle : 48 heures avant un changement DNS important, baisse ton TTL à 300. Quand le changement est fait et vérifié, remonte à une valeur haute (3600 ou davantage) pour réduire la charge sur ton serveur autoritaire. Si tu fais un changement de MX avec un TTL de 86400 laissé en place, tu attends potentiellement 24h que tous les résolveurs du monde invalident leur cache — et pendant ce temps, une partie de tes mails partent vers l'ancienne destination.

DNSSEC : la signature qui empêche l'empoisonnement

Le DNS classique n'est pas authentifié. Un attaquant qui contrôle un résolveur intermédiaire peut répondre à ta place et rediriger ton domaine vers son serveur. C'est ce qu'on appelle du DNS cache poisoning ou un DNS hijack — la tactique TA0001 du référentiel MITRE ATT&CK (Initial Access).

DNSSEC (DNS Security Extensions) ajoute une signature cryptographique à chaque réponse DNS. Le résolveur peut vérifier que la réponse vient bien du serveur autoritaire légitime. Cloudflare active DNSSEC en un clic dans le panneau DNS. Si ton registrar supporte la délégation DNSSEC et que tu utilises Cloudflare, le toolkit T-01-02 couvre exactement cette configuration.

IP et routing : comprendre comment les paquets voyagent

IPv4, IPv6 et le problème de la rareté

Une adresse IP (Internet Protocol) est le numéro de voirie d'une machine sur internet. IPv4 encode l'adresse sur 32 bits, ce qui donne environ 4,3 milliards d'adresses uniques — un chiffre qui semblait astronomique en 1981 et qui s'est révélé dramatiquement insuffisant. Le pool d'adresses IPv4 publiques est épuisé depuis 2011 chez IANA (l'autorité mondiale d'allocation).

IPv6 encode l'adresse sur 128 bits. Le nombre d'adresses disponibles est si grand que chaque grain de sable de la planète pourrait en avoir plusieurs. La migration tarde parce que les deux protocoles ne sont pas directement compatibles, mais une infrastructure moderne doit supporter les deux (ce qu'on appelle le dual-stack). Si ton VPS n'a pas d'adresse IPv6, une partie de ta résilience réseau est manquante.

NAT : pourquoi ton adresse locale n'est pas ton adresse internet

Chez toi, ton ordinateur a une adresse comme 192.168.1.24. C'est une adresse privée, non routable sur internet public. Ton routeur FAI fait de la NAT (Network Address Translation) : il traduit cette adresse privée en l'adresse publique de ta connexion (par exemple 82.64.xx.xx) quand il envoie un paquet, et fait le chemin inverse quand il reçoit une réponse.

En production, ton VPS, lui, a directement une adresse publique. Il n'y a pas de NAT entre lui et internet — ce qui veut dire que chaque port ouvert est directement accessible depuis n'importe où dans le monde. C'est pour ça qu'un firewall configuré dès le premier jour n'est pas optionnel.

BGP en trois lignes : pourquoi internet peut disparaître pendant quelques heures

Internet n'est pas un réseau unique. C'est une collection de milliers de réseaux autonomes (AS pour Autonomous System) — Orange, Cloudflare, Amazon, OVH — qui échangent des informations de routage via le protocole BGP (Border Gateway Protocol). BGP dit à chaque réseau quels préfixes IP sont accessibles via quel voisin.

Le problème : BGP est un protocole basé sur la confiance. N'importe quel AS peut annoncer qu'il possède un préfixe IP qu'il ne possède pas — une erreur de configuration ou une manipulation délibérée qui s'appelle un BGP hijack. Le résultat : le trafic destiné à ta plateforme est redirigé vers un AS tiers, parfois pendant plusieurs heures, avant que les opérateurs corrigent manuellement les tables de routage. Les incidents BGP ayant affecté des services majeurs (Facebook en 2021, Cloudflare en 2020) ont duré de quelques minutes à plusieurs heures et sont documentés publiquement.

Tu ne contrôles pas BGP. Mais tu dois en connaître l'existence pour comprendre pourquoi un service peut être inaccessible sans que ni ton serveur ni ton DNS soient en cause.

Géolocalisation IP : ce que tes utilisateurs et tes attaquants voient

Les bases de données de géolocalisation IP (MaxMind, IPinfo) font correspondre une plage d'adresses à un pays ou une ville. Ces données sont imprécises — souvent au niveau régional, parfois complètement fausses pour les VPN et les Tor exit nodes. Mais elles servent à deux choses en pratique : configurer des règles de rate-limiting géographiques dans ton WAF (Web Application Firewall), et comprendre d'où viennent les tentatives d'authentification suspectes dans tes logs.

HTTPS et TLS : le cadenas que tout le monde croit comprendre

Le handshake TLS simplifié

HTTPS n'est pas un protocole distinct d'HTTP. C'est HTTP transporté sur une couche TLS (Transport Layer Security). TLS s'intercale entre la couche réseau et ton application pour chiffrer les données en transit.

Quand ton navigateur contacte un serveur HTTPS, les deux parties négocient un canal sécurisé en quelques allers-retours — le TLS handshake :

1. Le client annonce les algorithmes de chiffrement qu'il supporte et génère un nombre aléatoire.
2. Le serveur choisit un algorithme, présente son certificat X.509, et génère son propre nombre aléatoire.
3. Les deux parties s'accordent sur une clé de session symétrique (via ECDHE — échange de clés Diffie-Hellman sur courbe elliptique — dans TLS 1.3) sans jamais la transmettre en clair.
4. Tout le trafic qui suit est chiffré avec cette clé de session.

TLS 1.3 (le standard actuel) simplifie et accélère ce processus. Si ton serveur Nginx ou Traefik n'a pas été configuré pour refuser TLS 1.0 et 1.1, tu exposes encore des utilisateurs à des protocoles dépréciés avec des vulnérabilités connues.

Certificats X.509 : ce que le cadenas vert veut dire

Un certificat X.509 est un document signé cryptographiquement qui dit : "Ce serveur s'appelle monprojet.fr, et l'autorité de certification Untel l'atteste." Il contient la clé publique du serveur, le nom du domaine (ou les domaines couverts par un certificat wildcard *.monprojet.fr), la date d'expiration, et la signature de l'autorité.

Ton navigateur maintient une liste d'autorités de certification (CA) de confiance. Quand il reçoit un certificat, il vérifie que la signature remonte à l'une de ces CA via une chaîne de confiance. Si la CA n'est pas dans la liste, ou si le certificat a expiré, tu vois l'avertissement rouge "Connexion non sécurisée" — et selon les études de conversion, 50 à 80% des visiteurs ne cliquent pas sur "continuer".

Let's Encrypt vs certificats payants

Pour 99% des projets indépendants, Let's Encrypt suffit largement. Le renouvellement automatique via Certbot ou Traefik élimine le risque d'expiration — à condition que l'automatisation tourne réellement. Un certificat qui expire la nuit de ton lancement parce que le cron ne s'est pas exécuté, c'est un incident P1 évitable.

HSTS, SNI et OCSP : les trois détails qui font la différence

HSTS (HTTP Strict Transport Security) est un header de réponse qui dit au navigateur : "Pour ce domaine, utilise uniquement HTTPS pendant N secondes, même si l'utilisateur tape http://." Le préchargement HSTS (includeSubDomains; preload) va plus loin : ton domaine est inscrit dans une liste compilée dans le navigateur lui-même, ce qui élimine le premier aller-retour HTTP avant la redirection. Résultat : aucune possibilité de downgrade vers HTTP même sur une première visite.

SNI (Server Name Indication) est l'extension TLS qui permet à un serveur de présenter plusieurs certificats sur une seule adresse IP. Sans SNI, il faudrait une adresse IP dédiée par domaine — ce qui était le cas avant TLS 1.0 et reste la contrainte sur certains équipements réseau anciens. Avec SNI, ton Traefik peut servir des dizaines de domaines avec des certificats différents sur le même port 443.

OCSP (Online Certificate Status Protocol) est le mécanisme qui permet de vérifier en temps réel si un certificat n'a pas été révoqué. En pratique, les navigateurs implémentent aujourd'hui l'OCSP stapling : c'est le serveur qui récupère et met en cache la réponse OCSP, évitant à chaque client de faire une requête directe à la CA. Si l'OCSP stapling n'est pas configuré, un navigateur qui ne peut pas joindre la CA peut échouer à valider ton certificat dans certains modes stricts.

La surface d'attaque que tout ça crée

Comprendre l'anatomie d'internet, c'est aussi comprendre où les attaquants pointent leur attention.

DNS hijack et détournement de domaine

La tactique TA0001 du référentiel MITRE ATT&CK inclut le détournement DNS comme vecteur d'accès initial. L'attaquant n'a pas besoin de compromettre ton serveur. Il lui suffit de prendre le contrôle de ton registrar (via credential stuffing sur le compte sans MFA) ou de corrompre un résolveur intermédiaire. Une fois le DNS sous son contrôle, il redirige ton domaine vers son infrastructure, obtient un certificat valide via Let's Encrypt (qui ne vérifie que le contrôle DNS), et intercepte tout ton trafic sans que tes utilisateurs voient aucun avertissement.

La défense : MFA sur ton registrar, DNSSEC activé, et Certificate Transparency — un registre public de tous les certificats émis pour ton domaine. Tu peux le consulter sur crt.sh et être alerté en temps réel si un certificat est émis à ton insu.

DNS comme canal C2 et exfiltration de données

La tactique TA0011 (Command and Control) et TA0040 (Impact) du MITRE ATT&CK incluent l'utilisation du DNS pour des communications malveillantes. Un malware installé sur un serveur peut encoder des données dans des requêtes DNS valides et les exfiltrer vers un domaine contrôlé par l'attaquant — une technique qui traverse la plupart des firewalls parce que le port 53 (DNS) est rarement filtré en sortie. DNS over HTTPS (DoH), censé améliorer la confidentialité des requêtes DNS, est également utilisé comme canal d'évasion par des outils d'attaque modernes pour contourner les détections basées sur le monitoring du port 53.

Ce n'est pas un scénario réservé aux grandes entreprises. Dès que tu déploies une application avec des dépendances npm ou des webhooks entrants non validés, une chaîne de compromission est possible.

MITM sur réseau non chiffré

L'attaque Man-In-The-Middle (MITM) sur un réseau wifi public reste triviale quand HTTPS n'est pas correctement configuré ou forcé. Si ton application a une page accessible en HTTP (sans redirection HTTPS), un attaquant sur le même réseau peut intercepter les cookies de session ou injecter du code malveillant dans les réponses. HSTS preload et la redirection forcée au niveau Traefik suppriment ce vecteur.

Ce que tu peux vérifier toi-même demain matin

La meilleure façon d'ancrer ces notions, c'est de les observer sur ton propre domaine. Voici les six outils que j'utilise systématiquement avant et après un changement DNS ou TLS.

dig est ton premier réflexe en ligne de commande. dig monprojet.fr A te donne l'adresse IP associée. dig monprojet.fr MX liste tes serveurs de messagerie. dig monprojet.fr TXT montre ton SPF, DKIM et toute vérification de propriété. dig +trace monprojet.fr rejoue le chemin complet depuis les serveurs racine jusqu'au serveur autoritaire — indispensable pour diagnostiquer une délégation NS cassée.

whois (whois monprojet.fr) te donne les informations d'enregistrement du domaine : registrar, dates de création et d'expiration, et surtout le statut du domaine. Un statut clientTransferProhibited signifie que le transfert chez un autre registrar est verrouillé — une protection minimale contre le vol de domaine.

crt.sh est l'interface de recherche dans les logs Certificate Transparency. En cherchant ton domaine, tu vois tous les certificats jamais émis — y compris ceux que tu n'as pas demandés. Si tu vois un certificat wildcard *.monprojet.fr émis par une CA que tu ne reconnais pas, c'est un signal d'alerte immédiat.

hardenize.com analyse ton domaine sur une vingtaine de critères : HSTS, DNSSEC, SPF, DMARC, DKIM, certificat, OCSP stapling, etc. Le rapport est lisible en 5 minutes et t'indique exactement quoi corriger.

securityheaders.com se concentre sur les headers HTTP de sécurité : Content-Security-Policy, X-Frame-Options, Referrer-Policy, Permissions-Policy. Ces headers sont souvent oubliés dans les configurations Nginx ou Traefik par défaut.

dnsviz.net visualise graphiquement ta chaîne DNS et DNSSEC. Quand une délégation est cassée ou qu'une signature DNSSEC est invalide, dnsviz le montre en rouge avec l'explication exacte.

En résumé

Internet fonctionne sur quatre briques que tu dois maîtriser au niveau opérationnel — pas pour impressionner ton CTO, mais pour ne pas être démuni le jour où quelque chose casse.

Le DNS traduit tes noms de domaine en adresses IP via une chaîne résolveur-racine-TLD-autoritaire. Chaque record a un TTL qui conditionne la vitesse de propagation de tes changements. DNSSEC signe ces réponses pour empêcher leur falsification.

L'IP et le routing définissent comment les paquets voyagent de ta machine à tes utilisateurs. IPv4 est saturé, IPv6 est l'avenir, et BGP est la colle qui tient tout ça ensemble — une colle qui peut se décoller pendant quelques heures, indépendamment de ce que tu contrôles.

HTTPS et TLS chiffrent le transport et authentifient ton serveur via des certificats X.509 signés par des CA de confiance. Let's Encrypt couvre 99% des besoins si le renouvellement est automatisé. HSTS, SNI et OCSP stapling complètent la configuration pour éliminer les vecteurs d'attaque résiduels.

La surface d'attaque induite concerne en priorité le DNS (hijack via registrar compromis, empoisonnement de cache) et HTTPS (certificats frauduleux détectables via Certificate Transparency). Ces deux vecteurs sont documentés dans MITRE ATT&CK et touchent des projets de toutes tailles.

Les outils dig, whois, crt.sh, hardenize.com, securityheaders.com et dnsviz.net te donnent une vue complète de ton exposition en moins de dix minutes.

Suite logique : P-01-02 — Se défendre contre quoi ? Construire ta matrice de risque →

Passer à l'action : T-01-02 — DNS + TLS (Cloudflare + Let's Encrypt + DNSSEC) (47 €) — le toolkit qui configure DNSSEC, les records SPF/DKIM/DMARC, le certificat Let's Encrypt avec renouvellement automatique et les headers HSTS sur ton VPS Coolify. Pour comprendre ce qu'il y a exactement dans le bundle avant d'acheter, lis la présentation détaillée du toolkit T-01-02 →.

La fondation complète : Bundle B01 Foundation — 97 € (5 toolkits, du VPS vide au site déployé sécurisé, dont T-01-02 DNS+TLS)

Cet article fait partie de la phase 01 du parcours Cyberviseur, accessible dans le bundle B01. Si tu veux être prévenu·e quand les prochains modules sortent, inscris-toi à la newsletter — un email tous les 15 jours, jamais de spam, désinscription en un clic.