Guide Anti-DDoS DNSPublié le 6 mai 2026Lecture : 15 min
Mitigation DDoS amplification DNS : protéger l’infrastructure sans bloquer le DNS légitime
L’amplification DNS est l’un des schémas de réflexion UDP les plus fréquents, car DNS est très présent, les réponses peuvent être plus grosses que les requêtes et le trafic spoofé peut être dirigé vers une victime. Le défi de mitigation est précis : bloquer tout UDP/53 peut nettoyer un graphe, mais aussi casser des services qui dépendent du DNS. Un bon design sépare abus d’open resolver, flood réfléchi et trafic DNS légitime.
UDP/53 est sensible
Tout bloquer peut casser de vrais services DNS.
Les open resolvers amplifient
Des résolveurs récursifs mal configurés peuvent réfléchir de grosses réponses.
Le spoofing déclenche la réflexion
Les reflectors répondent à l’IP victime car elle est forgée comme source.
La relivraison compte
Le trafic DNS utile doit continuer à atteindre la bonne infrastructure.
La mitigation DDoS par amplification DNS demande plus de précision qu’un simple blocage UDP générique. DNS est un protocole critique : domaines, panels, APIs, launchers de jeux et services clients en dépendent. Pendant l’attaque, la victime reçoit de grosses réponses DNS générées par des résolveurs ouverts ou des infrastructures mal utilisées après l’envoi de requêtes spoofées ailleurs.
Le défi est de réduire le flood réfléchi sans casser le DNS légitime. Un bon design distingue DNS autoritatif, DNS récursif, requêtes clients, abus UDP/53 et trafic qui n’existe que parce que l’IP victime a été usurpée. Le transit protégé et le filtrage amont sont souvent nécessaires car le volume peut saturer le lien avant que l’infrastructure DNS locale ne réagisse.
Impact commercial
Mitigation DDoS amplification DNS
L’amplification DNS est l’un des schémas de réflexion UDP les plus fréquents, car DNS est très présent, les réponses peuvent être plus grosses que les requêtes et le trafic spoofé peut être dirigé vers une victime. Le défi de mitigation est précis : bloquer tout UDP/53 peut nettoyer un graphe, mais aussi casser des services qui dépendent du DNS. Un bon design sépare abus d’open resolver, flood réfléchi et trafic DNS légitime.
Le modèle technique est simple mais destructeur : des réponses UDP non sollicitées arrivent vers la victime alors que l’origine ne les a jamais demandées. Les règles placées uniquement sur le serveur voient le flood final, pas la chaîne de réflecteurs qui l’a produit.
Comme les paquets peuvent venir de vrais serveurs Internet, une liste de blocage naïve évolue lentement et crée du dégât collatéral. Le signal utile se trouve dans le comportement protocolaire, le sens du trafic, les ports attendus, le rythme, l’entropie et le fait que le service protégé ait réellement demandé ces réponses.
UDP/53 est sensible
Tout bloquer peut casser de vrais services DNS.
Les open resolvers amplifient
Des résolveurs récursifs mal configurés peuvent réfléchir de grosses réponses.
Le spoofing déclenche la réflexion
Les reflectors répondent à l’IP victime car elle est forgée comme source.
Pourquoi c’est important
C’est important commercialement, car la coupure est visible pour les clients avant que la cause soit claire. Un serveur dédié peut afficher peu de CPU alors que les joueurs, clients ou pairs BGP voient de la perte et des timeouts.
Pour un client en transit protégé, le mode de livraison compte aussi. GRE, IPIP, VXLAN, cross-connect et VM routeur doivent être dimensionnés et filtrés pour que le trafic réfléchi soit retiré avant de brûler le chemin propre.
Les solutions possibles
La première couche est la capacité : les transitaires et ports de filtrage doivent absorber l’attaque pendant que le moteur de décision classe le vecteur. La deuxième couche est le filtrage adapté au protocole, qui retire les réponses impossibles, les charges anormales et le trafic qui ne correspond pas au profil attendu.
FlowSpec, ACL et filtrage edge peuvent réduire le volume rapidement, mais les règles doivent rester précises et temporaires. Un firewall stateful sur l’origine n’est pas la bonne première ligne quand l’attaque consomme déjà la capacité ou les paquets par seconde.
Peeryx cherche à retirer le trafic sale avant qu’il arrive côté client. Pour les clients BGP, le préfixe protégé peut être annoncé via la couche de mitigation ; pour des serveurs existants, le trafic propre peut être livré par tunnel, cross-connect ou VM routeur.
Pour les services gaming, le même principe s’applique avec le reverse proxy : le chemin joueur reste joignable pendant que le trafic d’attaque est filtré sur l’edge Peeryx, au lieu d’être transféré aveuglément vers l’origine.
Cas concret d’utilisation
Imaginez une communauté de jeu hébergée sur un serveur dédié. Le serveur est en ligne, mais l’IP publique reçoit un flood UDP réfléchi. Les joueurs voient des timeouts, la voix devient instable et le panel hébergeur n’affiche parfois qu’une saturation de bande passante.
Avec une relivraison protégée, l’IP ou le service attaqué passe par un point de mitigation. La plateforme filtre le vecteur réfléchi, conserve les vraies sessions TCP/UDP et transmet uniquement le trafic propre vers la machine existante.
Erreurs fréquentes
La première erreur est de bloquer tout UDP. Cela peut casser les jeux, DNS, monitoring et flux d’infrastructure légitimes. La deuxième erreur est d’attendre du serveur d’origine qu’il règle un problème de saturation réseau.
Autre erreur fréquente : compter uniquement sur des limites de débit génériques. Elles peuvent réduire un graphe, mais aussi pénaliser les vrais utilisateurs quand le service a besoin de pics ou quand l’attaquant reste juste sous le seuil.
Pourquoi choisir Peeryx pour ce risque DDoS
Si votre infrastructure dépend de TCP, UDP, DNS ou de trafic de jeu, Peeryx peut placer une couche réseau protégée devant elle et relivrer le trafic propre par tunnel, cross-connect, VM routeur ou reverse proxy gaming.
Transit IP protégé pour les clients qui ont besoin de BGP, tunnels ou cross-connect.
Protection de serveur dédié pour les services qui doivent rester sur leurs machines actuelles.
Reverse proxy gaming pour FiveM, Minecraft et communautés fortement UDP.
Filtrage adapté au protocole plutôt que promesses vagues “DDoS illimité”.
FAQ
Peut-on être touché sans utiliser ce service ?
Oui. Une attaque réfléchie envoie les réponses vers l’IP victime, même si la cible n’héberge pas le protocole abusé.
Bloquer UDP suffit-il ?
Non. Certains services ont besoin d’UDP. La mitigation doit séparer le trafic réfléchi malveillant du trafic légitime.
Où faut-il filtrer ?
Le plus en amont possible, avant que l’attaque ne sature le lien client, le tunnel ou le firewall.
Peeryx peut-il protéger un serveur existant ?
Oui. Le trafic propre peut être livré à une infrastructure existante par tunnel, cross-connect, VM routeur ou reverse proxy selon le service.
Conclusion
Si votre infrastructure dépend de TCP, UDP, DNS ou de trafic de jeu, Peeryx peut placer une couche réseau protégée devant elle et relivrer le trafic propre par tunnel, cross-connect, VM routeur ou reverse proxy gaming.
Le bon objectif n’est pas seulement de survivre au graphe, mais de garder les utilisateurs légitimes joignables pendant que l’attaque est absorbée et filtrée.
Ressources
Lectures liées
Pour approfondir le sujet, voici d’autres pages et articles utiles.
Réduire ce vecteur avant qu’il atteigne votre serveur
Si votre infrastructure dépend de TCP, UDP, DNS ou de trafic de jeu, Peeryx peut placer une couche réseau protégée devant elle et relivrer le trafic propre par tunnel, cross-connect, VM routeur ou reverse proxy gaming.
