{"id":945,"date":"2026-02-25T17:53:03","date_gmt":"2026-02-25T09:53:03","guid":{"rendered":"https:\/\/www.ddosgj.com\/?p=945"},"modified":"2026-02-25T17:53:03","modified_gmt":"2026-02-25T09:53:03","slug":"comment-empecher-le-detournement-de-dns-et-securiser-les-domaines-avec-un-dns-de-haute-defense-en-utilisant-dnssec-et-la-resolution-multiligne","status":"publish","type":"post","link":"https:\/\/www.ddosgj.com\/fr\/945-html","title":{"rendered":"Comment pr\u00e9venir le d\u00e9tournement de DNS et s\u00e9curiser la r\u00e9solution des noms de domaine avec DNSSEC et la r\u00e9solution multiligne dans un CDN de haute d\u00e9fense."},"content":{"rendered":"<p>R\u00e9cemment, j'ai aid\u00e9 un ami \u00e0 g\u00e9rer un incident de d\u00e9tournement de DNS et j'ai constat\u00e9 que beaucoup de gens utilisent encore un service de r\u00e9solution de noms de domaine rudimentaire. L'attaquant a dirig\u00e9 le trafic vers des sites d'hame\u00e7onnage et les plaintes des utilisateurs ont afflu\u00e9 comme des flocons de neige. De nos jours, m\u00eame les CDN doivent \u201cemp\u00eacher les co\u00e9quipiers\u201d, sans parler des DNS publics.<\/p>\n<p>Vous pouvez penser qu'avec un CDN \u00e0 haute d\u00e9fense tout ira bien, mais n'oubliez pas : le DNS est la premi\u00e8re porte d'entr\u00e9e du trafic. Si la porte est forc\u00e9e, le mur qui se trouve derri\u00e8re ne sert \u00e0 rien. J'ai test\u00e9 un certain nombre de cas, l\u201c\u201danomalie de trafic\" 90% n'est pas une attaque CC, mais le niveau DNS a \u00e9t\u00e9 perc\u00e9 depuis longtemps.<\/p>\n<p><strong>Le d\u00e9tournement de DNS est depuis longtemps plus qu'un simple changement de r\u00e9solution.<\/strong>Le \u201cman-in-the-middle package\u201d est aujourd'hui en vogue. Le \"paquet de l'homme du milieu\" est d\u00e9sormais en vogue : il s'agit d'abord de polluer le cache DNS local, puis d'alt\u00e9rer les r\u00e9ponses au niveau du fournisseur d'acc\u00e8s, et m\u00eame de lancer des attaques directement contre le bureau d'enregistrement. L'ann\u00e9e derni\u00e8re, le nom de domaine d'une soci\u00e9t\u00e9 de commerce \u00e9lectronique bien connue a \u00e9t\u00e9 point\u00e9 vers une adresse IP malveillante, la cause premi\u00e8re \u00e9tant les travailleurs sociaux du compte du bureau d'enregistrement, et le CDN n'a rien \u00e0 voir avec cela - mais les utilisateurs auront seulement l'impression que votre site s'est effondr\u00e9.<\/p>\n<p>Il est temps de ressortir le vieux cheval de bataille DNSSEC. Ne soyez pas effray\u00e9s par ce mot, pour dire les choses franchement, il s'agit de faire des signatures num\u00e9riques pour les enregistrements DNS. Comme si vous alliez \u00e0 la banque pour retirer de l'argent, le caissier v\u00e9rifie non seulement la carte d'identit\u00e9 (r\u00e9solution du nom de domaine), mais aussi les empreintes digitales (signature num\u00e9rique). Pour qu'il y ait falsification, il faudrait que la base cryptographique soit perc\u00e9e, le co\u00fbt de l'extraction directe est donc \u00e9lev\u00e9.<\/p>\n<p>Cependant, de nombreuses personnes marchent sur plus de nids-de-poule que de probl\u00e8mes lorsqu'elles configurent DNSSEC. Par exemple, ils utilisent des bureaux d'enregistrement \u00e9trangers mais oublient d'activer la synchronisation des enregistrements DS, ou bien le TTL est fix\u00e9 \u00e0 une longueur \u00e9norme, ce qui entra\u00eene un retour en arri\u00e8re lent comme un escargot en cas de d\u00e9faillance. La le\u00e7on la plus douloureuse que j'ai apprise a \u00e9t\u00e9 lorsque je l'ai d\u00e9ploy\u00e9 sur une plateforme financi\u00e8re, parce que le serveur NS ne prenait pas en charge EDNS0, ce qui a directement conduit au d\u00e9passement du d\u00e9lai de r\u00e9solution pour les utilisateurs d'Asie-Pacifique - l'histoire du sang et des larmes nous l'apprend :<strong>Testez avant de vous lancer et ne vous fiez pas \u00e0 la \u201ccompatibilit\u00e9 par d\u00e9faut\u201d des vendeurs.\u201d<\/strong>\u3002<\/p>\n<p>Voici pour poster un vrai test utilisable du script de v\u00e9rification DNSSEC (je ne peux pas courir pour me frapper) :<\/p>\n<p>Le protocole DNSSEC ne suffit pas. L'environnement du r\u00e9seau national est trop complexe, les utilisateurs de t\u00e9l\u00e9communications vont Unicom le retard de ligne a grimp\u00e9 \u00e0 300 ms est commun. Cette fois, nous devons proposer l'arme magique de la r\u00e9solution multiligne. Mais ne soyez pas stupide avec la division g\u00e9ographique - maintenant que les utilisateurs sont suspendus au VPN, votre routage de localisation g\u00e9ographique IP n'est pas aussi fiable que de lancer des fl\u00e9chettes.<\/p>\n<p>Mon programme actuel est le suivant<strong>strat\u00e9gie de d\u00e9tournement \u00e0 trois niveaux<\/strong>La premi\u00e8re \u00e9tape consiste \u00e0 identifier le r\u00e9seau dorsal de l'op\u00e9rateur par ASN (Autonomous System Number), puis \u00e0 ajuster dynamiquement le poids en fonction du d\u00e9lai en temps r\u00e9el, et enfin \u00e0 utiliser Anycast pour garantir le fond. En particulier, les fournisseurs de services utilisant BGP Anycast comme CDN07, ainsi que l'analyse multi-lignes, peuvent r\u00e9duire le temps de latence de l'analyse \u00e0 50 ms.<\/p>\n<p>Prenons le cas de notre migration vers 08Host l'ann\u00e9e derni\u00e8re : les utilisateurs t\u00e9l\u00e9coms d'origine sont toujours rout\u00e9s vers les n\u0153uds Unicom, puis au niveau DNS pour faire l'identification ASN + la d\u00e9tection de retard, ce qui permet directement d'augmenter le taux de r\u00e9solution de 40%. La configuration est longue comme ceci :<\/p>\n<p>L'empoisonnement du cache DNS, le DDoS du serveur NS et m\u00eame la falsification du journal de transparence du certificat...... attaquants jouent plus de tours que vous ne le pensez. Je suis tomb\u00e9 une fois sur une \u00e9quipe qui implantait un cheval de Troie ciblant sp\u00e9cifiquement l'empoisonnement r\u00e9cursif du DNS sur les petits op\u00e9rateurs parce que la version de leur logiciel DNS \u00e9tait encore bloqu\u00e9e en 2014.<\/p>\n<p><strong>La valeur r\u00e9elle d'un CDN de haute d\u00e9fense se trouve dans les poches<\/strong>. Les n\u0153uds tels que CDN5 v\u00e9rifieront deux fois les r\u00e9sultats de la r\u00e9solution DNS : si l'IP r\u00e9solue correspond \u00e0 la base de donn\u00e9es de renseignements sur les menaces, le processus de nettoyage est d\u00e9clench\u00e9 directement. Cela revient \u00e0 ajouter une double assurance au DNS - m\u00eame si la r\u00e9solution frontale est alt\u00e9r\u00e9e, le trafic vers le n\u0153ud p\u00e9riph\u00e9rique a une derni\u00e8re chance de corriger l'erreur.<\/p>\n<p>Ajoutez-y une derni\u00e8re th\u00e9orie de la temp\u00eate :<strong>Oser ne pas utiliser l'\u00e9quipe DNSSEC en 2024 \u00e9quivaut \u00e0 prendre l'autoroute dans un fourgon de transport de fonds sans coffre-fort !<\/strong>Mais n'en faites pas trop. Mais n'en faites pas trop - j'ai vu une entreprise tester des domaines internes \u00e9galement sur un ensemble complet de DNSSEC, chaque fois que vous changez l'enregistrement pour attendre la synchronisation de la signature, les d\u00e9veloppeurs ont presque sacrifi\u00e9 l'exploitation et la maintenance.<\/p>\n<p>La v\u00e9ritable architecture fiable doit \u00eatre imbriqu\u00e9e comme un oignon : tube d'authentification DNSSEC, tube d'analyse multi-lignes, tube d'optimisation des performances, tube de nettoyage du trafic CDN haute d\u00e9fense. D'ailleurs, Amway a r\u00e9alis\u00e9 une op\u00e9ration \u00e9meuti\u00e8re : l'aplatissement du CNAME, l'aplatissement de l'enregistrement alias du fournisseur CDN, \u00e0 la fois pour profiter de l'effet d'acc\u00e9l\u00e9ration du CDN, mais aussi pour \u00e9viter que la r\u00e9solution de la cha\u00eene ne soit trop longue et ne conduise \u00e0 des points d'\u00e9chec.<\/p>\n<p>Pour mettre les choses en perspective : de nombreuses organisations concentrent encore leurs investissements en mati\u00e8re de s\u00e9curit\u00e9 sur les pare-feu et les WAFs, et la s\u00e9curit\u00e9 DNS est laiss\u00e9e au hasard. Pourtant, si l'on consid\u00e8re les principaux incidents de s\u00e9curit\u00e9 de ces derni\u00e8res ann\u00e9es, du d\u00e9tournement de GitHub au crash de la banque br\u00e9silienne, quel est celui qui n'a pas \u00e9t\u00e9 pirat\u00e9 au niveau du DNS ?<strong>La r\u00e9solution des noms de domaine est la deuxi\u00e8me veine de l'internet. Si elle est pinc\u00e9e \u00e0 ce niveau, toutes les d\u00e9fenses ult\u00e9rieures ne sont que de la poudre aux yeux.<\/strong>\u3002<\/p>\n<p>D'ailleurs, si vous \u00eates en train de choisir un mod\u00e8le, n'oubliez pas de tester la compatibilit\u00e9 DNSSEC du fournisseur. Certains des anciens fournisseurs (pour ne pas les nommer) supportent l'EDNS comme une passoire, il serait pr\u00e9f\u00e9rable d'utiliser 08Host comme les fournisseurs de services \u00e9mergents - au moins \u00e0 partir du premier jour de sa naissance du support complet DoH\/DoT. donn\u00e9es mesur\u00e9es ici : le m\u00eame n\u0153ud pour ouvrir le DoH, les fluctuations de latence de r\u00e9solution de 200 ms \u00e0 moins de 30 ms ! La raison en est que la cha\u00eene de pollution DNS du FAI local est ignor\u00e9e.<\/p>\n<p>Cette technologie craint surtout les demi-mesures. Soit comme l'\u00e9quipe Wang d'\u00e0 c\u00f4t\u00e9 qui se couche compl\u00e8tement avec le DNS public, soit comme la suite compl\u00e8te DNSSEC + multi-ligne + CDN. Ce qui effraie le plus, c'est de d\u00e9penser des millions pour acheter une haute d\u00e9fense, le r\u00e9sultat \u00e9tant d'\u00e9conomiser quelques milliers d'euros sur la version professionnelle du service DNS - c'est la m\u00eame chose que d'installer des serrures \u00e0 iris dans une chambre forte, mais la cl\u00e9 est ins\u00e9r\u00e9e dans la porte.<\/p>\n<p>La prochaine fois que vous rencontrerez un \u00e9v\u00e9nement psychique du type \u201cle site ne peut pas \u00eatre ouvert mais le ping passe\u201d, sortez d'abord la main du diagnostic DNS \u00e0 trois axes : v\u00e9rifiez l'enregistrement DS, v\u00e9rifiez la signature RRSIG, mesurez le routage de la ligne. Il est garanti que 80 % du probl\u00e8me peut \u00eatre localis\u00e9 sur place - les 20 % restants ? C'est le r\u00e9seau dorsal de l'op\u00e9rateur qui a \u00e9t\u00e9 bombard\u00e9, il faut se d\u00e9p\u00eacher d'absorber les nouilles et autres r\u00e9parations.<\/p>","protected":false},"excerpt":{"rendered":"<p>R\u00e9cemment, j'ai aid\u00e9 un ami \u00e0 g\u00e9rer un incident de d\u00e9tournement de DNS et j'ai constat\u00e9 que beaucoup de gens utilisent encore un service de r\u00e9solution de noms de domaine rudimentaire. L'attaquant a dirig\u00e9 le trafic vers des sites d'hame\u00e7onnage et les plaintes des utilisateurs ont afflu\u00e9 comme des flocons de neige. De nos jours, m\u00eame le CDN doit \u201cemp\u00eacher les co\u00e9quipiers\u201d, sans parler du DNS public. Vous pensez peut-\u00eatre que tout ira bien si vous utilisez un CDN \u00e0 haute d\u00e9fense, mais n'oubliez pas : le DNS est la premi\u00e8re porte d'entr\u00e9e du trafic. Si la porte est forc\u00e9e, l'arri\u00e8re du mur ne sert \u00e0 rien pour construire encore plus haut. J'ai test\u00e9 un certain nombre de cas, l\u201c\u201danomalie de trafic\u201c 90% n'est pas une attaque CC, mais le niveau DNS a \u00e9t\u00e9 perc\u00e9 depuis longtemps. Le d\u00e9tournement de DNS va depuis longtemps au-del\u00e0 de la simple modification d'un r\u00e9sultat de r\u00e9solution si simple. Aujourd'hui, le \u201dpaquet de l'homme du milieu\" est tr\u00e8s r\u00e9pandu : il pollue d'abord le cache DNS local, puis la r\u00e9ponse du fournisseur d'acc\u00e8s \u00e0 l'alt\u00e9ration, et m\u00eame la r\u00e9ponse directe !<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"gallery","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","footnotes":""},"categories":[150],"tags":[],"collection":[],"class_list":["post-945","post","type-post","status-publish","format-gallery","hentry","category-updates","post_format-post-format-gallery"],"_links":{"self":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/945","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/comments?post=945"}],"version-history":[{"count":1,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/945\/revisions"}],"predecessor-version":[{"id":1180,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/945\/revisions\/1180"}],"wp:attachment":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/media?parent=945"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/categories?post=945"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/tags?post=945"},{"taxonomy":"collection","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/collection?post=945"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}