La plupart des organisations passent des années à régler leur stratégie d'équilibrage de charge HTTP, à construire une protection WAAP profonde pour le trafic web, et pourtant traitent leur infrastructure DNS comme un serveur récursif unique avec une IP statique. Ce serveur unique devient à la fois un goulot d'étranglement de performance et une cible d'attaque de grande valeur.
Côté performance, une couche DNS lente injecte de la latence dans chaque transaction visible par l'utilisateur. Sans équilibrage de charge approprié, un résolveur saturé retarde chaque recherche en aval — et les clusters DNS anycast traditionnels sont difficiles à gérer dans les centres de données privés où le contrôle on-prem est requis.
Côté sécurité, les attaquants savent que le DNS est rarement inspecté. Les outils de tunneling DNS extraient des gigaoctets de données par des enregistrements TXT d'apparence anodine ; les logiciels malveillants pilotés par DGA tentent d'atteindre des milliers de domaines générés aléatoirement à la recherche de command-and-control ; les campagnes d'amplification DNS abusent des résolveurs ouverts comme vecteurs de réflexion ; et les clients stub sur les réseaux invités interrogent n'importe quel résolveur amont à leur guise, contournant tous les autres contrôles de sécurité que l'organisation a mis en place.
Le pare-feu DNS et l'équilibreur de charge TR7 traite le DNS comme un protocole applicatif de première classe qui mérite le même équilibrage de charge, la même gestion de santé, le même cache et la même application de politique de sécurité que reçoivent déjà les services HTTP.
TR7 traite le DNS comme un protocole applicatif de première classe : les requêtes obtiennent un équilibrage de charge complet et une diffusion consciente de la santé côté ADC, et elles passent par un moteur de politique côté WAAP — sans quitter la même passerelle.
Plusieurs algorithmes — round-robin, least-outstanding, hachage cohérent, aléatoire pondéré et hachage pondéré — distribuent les requêtes DNS entre les pools de résolveurs ou faisant autorité. Chaque algorithme est adapté à la charge : round-robin pour pools symétriques, least-outstanding pour temps de réponse variables, hachage cohérent pour scénarios d'affinité de cache.
Des health-checks configurables sondent les backends DNS en continu — checks de requête UDP, TCP, checks de résolution de nom personnalisés. Les serveurs malsains sortent de la rotation en quelques secondes ; la récupération les ramène automatiquement. Le même modèle de santé que le reste de TR7 utilise pour les pools HTTP s'applique aux pools DNS.
Correspondance par règle sur nom de requête, type de requête, IP source, options EDNS, expressions régulières et combinaisons de celles-ci. Les actions incluent bloquer, abandonner, refuser, tronquer, spoofer une réponse contrôlée, router vers un pool différent ou taguer la requête pour inspection en aval. La politique est évaluée avant que la requête ne soit envoyée à un backend.
Les limites de débit peuvent être appliquées par IP source, par nom de requête, par type de requête ou par dimension combinée. Les blocages dynamiques s'activent automatiquement lorsque les motifs de trafic franchissent les seuils définis par l'opérateur — une source unique inondant la passerelle de requêtes NXDOMAIN est étranglée ou temporairement bloquée sans intervention de l'opérateur.
Le pare-feu DNS et l'équilibreur de charge TR7 apporte la philosophie complète de gestion de trafic TR7 — équilibrage, health-checks, cache, politique et observabilité — au protocole DNS.
Round-robin pour pools uniformes, least-outstanding pour backends à temps de réponse variable, hachage cohérent et hachage pondéré pour scénarios d'affinité de cache où la même requête doit atteindre le même backend, et aléatoire pondéré pour les changements de trafic graduels. Chaque vService choisit son propre algorithme ; les algorithmes peuvent être modifiés en direct sans redémarrage.
Les domaines internes d'entreprise peuvent se résoudre via un pool, les domaines publics via un autre, les zones partenaires via un troisième. Les règles de routage par pool dirigent les requêtes selon les motifs QName, les plages d'IP source ou les tags de politique correspondants. La même passerelle sert plusieurs architectures DNS proprement.
Sondes de requête DNS TCP et UDP, sondes de résolution de nom personnalisées et checks de réponse basés sur le timing vérifient en continu la santé du backend. Les paramètres de seuil définissent combien de checks échoués déclenchent le retrait et combien de checks réussis réinstaurent un backend. Les backends lents peuvent être retirés même quand ils répondent — empêchant la latence visible par l'utilisateur.
Les enregistrements fréquemment demandés sont mis en cache à la passerelle avec invalidation consciente du TTL. Le cache respecte DNSSEC où applicable et peut être contourné sélectivement pour les zones sensibles. Le taux de hit du cache est exposé dans des métriques en temps réel afin que les opérateurs voient exactement combien de charge la passerelle absorbe.
Les règles de pare-feu correspondent à toute combinaison de nom de requête (exact, suffixe, regex), type de requête (A, AAAA, TXT, MX, ANY, etc.), IP source, EDNS Client Subnet, options EDNS et flags de requête. Les conditions peuvent être combinées avec une logique AND/OR. Les règles sont évaluées dans l'ordre défini par l'opérateur avec une sémantique allow/deny explicite.
Block renvoie une erreur contrôlée ; drop ignore silencieusement ; refuse renvoie REFUSED ; truncate force le fallback TCP (utile contre l'amplification) ; spoof renvoie une réponse contrôlée (block par NXDOMAIN, redirection vers un sinkhole, retour d'une alternative sûre) ; route envoie la requête vers un pool différent. Les actions tag marquent les requêtes pour inspection en aval sans altérer la réponse.
La détection basée sur des motifs et statistique identifie les requêtes vers des domaines générés algorithmiquement (C2 de malware DGA) et les charges TXT/CNAME inhabituelles caractéristiques de l'exfiltration de données basée sur DNS. Les requêtes détectées peuvent être bloquées, redirigées vers un sinkhole ou journalisées uniquement pour examen par analyste.
Les attaques par amplification DNS abusent des résolveurs ouverts pour inonder les cibles de trafic réfléchi. TR7 détecte les requêtes ANY, les motifs de réponse volumineux et les indicateurs de spoofing de source, appliquant le rate limiting de réponse et les actions de validation de source avant qu'aucune réflexion n'atteigne le fil. La passerelle ne devient jamais un vecteur d'amplification.
Les requêtes peuvent être évaluées par pays source, ASN, plage IP ou fenêtre temporelle. Les politiques de liste de blocage, liste d'autorisation et d'action conditionnelle s'appliquent au niveau DNS de la même manière qu'elles s'appliquent au niveau HTTP dans TR7 WAAP — en utilisant le même éditeur de politique et le même modèle d'application.
DNS over TLS (DoT, RFC 7858), DNS over HTTPS (DoH, RFC 8484) et DNS over QUIC (DoQ, RFC 9250) sont terminés à la passerelle. La gestion des certificats utilise le même magasin de certificats TR7 que les services HTTP. Les résolveurs stub modernes et les clients DoH navigateur se connectent nativement.
Les informations ECS transmises par les résolveurs en aval peuvent être honorées, surchargées, masquées vers un préfixe préservant la vie privée ou retirées entièrement. Le comportement est par politique, permettant la conformité de confidentialité pour certains flux tout en préservant la précision géographique pour d'autres.
Chaque requête, décision et action est écrite dans un flux de log structuré avec un formatage compatible SIEM. Les métriques en temps réel exposent le taux de requêtes, le temps de réponse, le taux de hit du cache, la santé du backend et les comptes de correspondance de règles. Les opérateurs voient le trafic DNS avec la même profondeur d'observabilité que le reste de TR7 fournit pour HTTP.
Le pare-feu DNS et l'équilibreur de charge est exploité conjointement avec l'ordre des règles, la topologie des pools, le réglage du cache, le choix du protocole de transport et la rétention d'audit.
Les règles de pare-feu sont évaluées de haut en bas avec first-match-wins par défaut. Les tags par règle permettent aux règles en aval d'agir différemment selon les correspondances antérieures. Les règles allow explicites en tête de chaîne épinglent le trafic connu-bon avant que les règles génériques de blocage ne s'appliquent, éliminant les faux positifs en production.
Les pools backend regroupent les résolveurs par objectif : interne corporate, récursion publique, zones partenaires, pool sinkhole. Les règles de routage par pool dirigent les requêtes selon QName, IP source ou tags correspondants. Les seuils de failover de pool empêchent un seul backend malsain d'absorber tout le trafic.
Taille du cache, comportement TTL, mise en cache consciente d'ECS et contournement sélectif pour zones sensibles sont tous contrôlés par l'opérateur. La mise en cache des réponses négatives (NXDOMAIN, NODATA) réduit la charge backend pour les charges à fort taux de NX typiques des réseaux infectés par DGA.
DNS UDP/TCP standard, DoT, DoH et DoQ peuvent être activés par listener vService. Les clients modernes négocient leur transport préféré ; les clients plus anciens reviennent à UDP. La politique de certificat et de chiffrement s'aligne avec le pool central de profils TLS TR7.
Les enregistrements d'audit par requête peuvent être conservés pour les fenêtres de conformité ; l'échantillonnage peut être appliqué pour les environnements à fort volume. Les logs JSON structurés streamment directement vers SIEM. Les opérateurs choisissent entre rétention complète, rétention échantillonnée et rétention par événement par pool.
Les sessions DNS sont sans état au niveau du protocole, donc le failover entre nœuds actifs est transparent pour la plupart des requêtes. Les sessions DNS TCP et les longues connexions DoH sont coordonnées à travers la paire HA pour minimiser la perturbation. L'état des health-checks et l'état du cache sont gérés indépendamment par nœud.
Les résolveurs corporate desservant le réseau interne gagnent rate limiting, filtrage de requêtes, journalisation d'audit et haute disponibilité. Les endpoints ne peuvent plus interroger des résolveurs externes arbitraires ; les hôtes infectés par DGA sont détectés et bloqués à la passerelle.
Les organisations exploitant des services DNS publics — FAI, hébergeurs, portails du secteur public — terminent les attaques par amplification à la passerelle. Rate limiting, validation de source et checks de motifs de réponse empêchent le résolveur d'être utilisé comme vecteur de réflexion.
Les réseaux santé, financiers et gouvernementaux ajoutent une couche de détection pour l'exfiltration basée sur les enregistrements TXT et les techniques de tunneling. Les flux suspects sont redirigés vers un sinkhole ou journalisés avec un contexte complet de session pour examen par analyste.
Lorsque TR7 GTM sert le DNS faisant autorité pour des applications multi-régions, le pare-feu DNS et l'équilibreur de charge se trouve devant GTM comme couche de rate limiting, cache et pare-feu. GTM reste focalisé sur l'intelligence de routage ; la passerelle absorbe le trafic hostile.
Équilibrage de charge intelligent, health-checks actifs, transports modernes et un moteur de règles de pare-feu complet — tout dans une seule passerelle. Laissez-nous vous présenter un déploiement en direct sur votre infrastructure DNS.