Avantages liés à la sécurité

Introduction: menaces et mesures d'atténuation pour la sécurité DNS

En raison de la conception ouverte et distribuée du système de noms de domaine, et de son utilisation du protocole UDP (User Datagram Protocol), le DNS est vulnérable à diverses formes d'attaque. Les résolveurs DNS publics ou "récurrents" sont particulièrement exposés au risque, car ils ne restreignent pas les paquets entrants à un ensemble d'adresses IP sources autorisées. Nous sommes principalement préoccupés par deux types d'attaques courants:

• Attaques par spoofing visant l'empoisonnement du cache de DNS Il existe différents types de spoofing et de falsification DNS qui visent à rediriger les utilisateurs de sites légitimes vers des sites Web malveillants. Il s'agit d'attaques Kaminsky, dans lesquelles des pirates informatiques prennent le contrôle d'une zone DNS entière.
• Attaques par déni de service (DoS). Les pirates informatiques peuvent lancer des attaques DDoS contre les résolveurs eux-mêmes ou des pirates informatiques pour lancer des attaques DoS sur d'autres systèmes. Les attaques qui utilisent des serveurs DNS pour lancer des attaques DoS sur d'autres systèmes en exploitant une taille d'enregistrement/réponse DNS élevée sont appelées attaques d'amplification.

Chaque classe d'attaque est abordée plus en détail ci-dessous.

Attaques par empoisonnement du cache

Plusieurs variantes des attaques par spoofing DNS peuvent entraîner un empoisonnement du cache, mais le scénario général est le suivant:

1. Le pirate envoie plusieurs requêtes à un résolveur DNS cible pour un nom de domaine dont il sait que le serveur n'est pas fiable et qu'il est peu probable qu'il se trouve dans le cache du serveur.
2. Le résolveur envoie des requêtes à d'autres serveurs de noms (dont les adresses IP peuvent également prédire).
3. En attendant, le pirate inonde le serveur victime de réponses falsifiées qui semblent provenir du serveur de noms délégué. Les réponses contiennent des enregistrements qui résolvent le domaine demandé en adresses IP contrôlées par le pirate informatique. Ils peuvent contenir des réponses pour le nom résolu ou, pire, déléguer l'autorité à un serveur de noms appartenant au pirate informatique afin qu'il prenne le contrôle d'une zone entière.
4. Si l'une des réponses falsifiées correspond à la requête du résolveur (par exemple, par nom, type, ID et port source du résolveur) et qu'elle est reçue avant une réponse du véritable serveur de noms, le résolveur accepte la réponse falsifiée, la met en cache et la supprime.
5. Les futures résolutions du domaine ou de la zone compromis sont résolues à l'aide de fausses résolutions DNS du cache. Si le pirate informatique a spécifié une durée de vie très longue pour la réponse falsifiée, les enregistrements falsifiés restent dans le cache le plus longtemps possible sans être actualisé.

Pour une excellente présentation des attaques de Kaminsky, consultez Anlustrated Guide to the Kaminsky DNS Vulnerability (Guide illustré sur la faille DNS de Kaminsky).

Attaques DoS et d'amplification

Les résolveurs DNS sont soumis aux menaces DoS courantes qui affectent tout système en réseau. Cependant, les attaques par amplification sont particulièrement préoccupantes, car les résolveurs DNS constituent des cibles intéressantes pour les pirates informatiques qui exploitent les ratios de réponse aux requêtes importants pour obtenir une bande passante offerte supplémentaire. Les résolveurs compatibles avec les EDNS0 (mécanismes d'extension pour DNS) sont particulièrement vulnérables en raison de la taille de paquet considérablement plus élevée qu'ils peuvent renvoyer.

En cas d'amplification, l'attaque se déroule comme suit:

1. Le pirate envoie des requêtes au serveur DNS victime à l'aide d'une adresse IP source falsifiée. Les requêtes peuvent être envoyées à partir d'un seul système ou d'un réseau de systèmes utilisant tous la même adresse IP falsifiée. Les requêtes sont destinées à des enregistrements dont le pirate informatique aura connaissance, ce qui se traduira par des réponses beaucoup plus volumineuses, jusqu'à plusieurs dizaines de fois¹, correspondant à la taille des requêtes d'origine (d'où l'attaque par "amplification").
2. Le serveur victime envoie les réponses volumineuses à l'adresse IP source transmise dans les requêtes falsifiées, submergeant le système et provoquant une situation DoS.

Atténuation

La solution standard pour les failles DNS est DNSSEC. Cependant, jusqu'à ce qu'ils soient implémentés universellement, les résolveurs DNS ouverts doivent prendre indépendamment des mesures pour atténuer les menaces connues. De nombreuses techniques ont été proposées. Pour en savoir plus sur la plupart d'entre elles, consultez la page RFC 5452: Mesures pour rendre le DNS plus résilient aux réponses falsifiées. Dans le DNS public de Google, nous avons implémenté et recommandé les approches suivantes:

• Sécuriser votre code contre les dépassements de mémoire tampon, en particulier le code responsable de l'analyse et de la sérialisation des messages DNS
• Surprovisionner les ressources de la machine pour vous protéger contre les attaques DoS directes sur les résolveurs eux-mêmes. Étant donné que les adresses IP sont faciles à falsifier pour les pirates informatiques, il est impossible de bloquer les requêtes basées sur l'adresse IP ou le sous-réseau. Le seul moyen efficace de gérer ce type d'attaques consiste simplement à absorber la charge.
• Implémentation de base de la validité des paquets de réponses et de la crédibilité du serveur de noms pour vous protéger d'une simple empoisonnement du cache. Il s'agit de mécanismes et de contrôles d'intégrité standards que tout résolveur de mise en cache conforme aux normes doit effectuer.
• Ajout de l'entropie aux requêtes de messages, afin de réduire la probabilité d'attaques plus sophistiquées par le spoofing ou le cache, telles que les attaques Kaminsky. Il existe de nombreuses techniques recommandées pour ajouter l'entropie. Vous trouverez ci-dessous un aperçu des avantages, des limites et des défis associés à chacune de ces techniques, ainsi que la manière dont nous les avons implémentées dans le DNS public de Google.
• Supprimer les requêtes en double, afin de lutter contre la probabilité d'attaques en date de naissance.
• Requêtes de limitation du débit, pour empêcher les attaques par déni de service (DoS) et les amplifications.
• Surveiller le service pour les adresses IP client utilisant le plus de bande passante et bénéficiant du ratio de réponse/requête le plus élevé

DNSSEC

La norme DNS (Domain Name Security Extensions) est spécifiée dans plusieurs RFC IETF : 4033, 4034, 4035 et 5155.

Les résolveurs qui implémentent des attaques par intoxication au cache DNSSEC en vérifiant l'authenticité des réponses reçues des serveurs de noms. Chaque zone DNS gère un ensemble de paires de clés privées/publiques et, pour chaque enregistrement DNS, une signature numérique unique est générée et chiffrée à l'aide de la clé privée. La clé publique correspondante est ensuite authentifiée via une chaîne de confiance par les clés appartenant aux zones parentes. Les résolveurs conformes à DNSSEC rejettent les réponses qui ne contiennent pas les bonnes signatures. DNSSEC empêche efficacement la manipulation des réponses, car en pratique, il est presque impossible de falsifier des signatures sans accéder à des clés privées.

Depuis janvier 2013, le DNS public de Google est entièrement compatible avec DNSSEC. Nous acceptons et transférons les messages au format DNSSEC, et validons les réponses pour une authentification correcte. Nous encourageons vivement les autres résolveurs à faire de même.

Nous mettons également en cache les réponses NSEC, comme spécifié dans la RFC 8198 de l'IETF: utilisation agressive du cache validé DNSSEC. Cela peut réduire le nombre de requêtes NXDOMAIN pour des serveurs de noms qui mettent en œuvre DNSSEC et utilisent NSEC pour les réponses négatives.

Transport chiffré côté client

Le DNS public de Google est compatible avec les protocoles de transport chiffrés, DNS sur HTTPS et DNS sur TLS. Ces protocoles empêchent la falsification, l'espionnage et le spoofing, ce qui améliore considérablement la confidentialité et la sécurité entre le client et le DNS public de Google. Ils complètent DNSSEC pour fournir des résolutions DNS authentifiées de bout en bout.

Implémenter la vérification de la validité de base

La corruption du cache DNS peut être due à des incohérences involontaires, et pas nécessairement malveillantes, entre les requêtes et les réponses (par exemple, en raison d'un serveur de noms mal configuré, d'un bug dans le logiciel DNS, etc.). Les résolveurs DNS doivent au moins effectuer des vérifications pour vérifier la crédibilité et la pertinence des réponses des serveurs de noms. Nous recommandons (et mettons en œuvre) toutes les protections suivantes:

• Ne définissez pas le bit récursif dans les requêtes sortantes et respectez toujours les chaînes de délégation de manière explicite. La désactivation du bit récursif garantit que votre résolveur fonctionne en mode itératif afin que vous puissiez interroger explicitement chaque serveur de noms de la chaîne de délégation, plutôt que d'autoriser un autre serveur de noms à effectuer ces requêtes en votre nom.
• Rejeter les messages de réponse suspects. Consultez la section ci-dessous pour plus d'informations sur ce que nous considérons comme & quot; suspect.
• Ne renvoyez pas d'enregistrements A aux clients en fonction des enregistrements Glue mis en cache à partir de requêtes précédentes. Par exemple, si vous recevez une requête client pour ns1.example.com, vous devez résoudre l'adresse plutôt que d'envoyer un enregistrement A basé sur les enregistrements Glue mis en cache et renvoyés par un serveur de noms de domaine de premier niveau.

Refus des réponses ne répondant pas aux critères requis

Le DNS public de Google refuse tous les éléments suivants:

• Réponses impossibles à analyser ou au format incorrect.
• Réponses dans lesquelles les champs de clé ne correspondent pas aux champs correspondants dans la requête. Cela inclut l'ID de requête, l'adresse IP source, le port source, l'adresse IP de destination ou le nom de la requête. Pour obtenir une description complète de ce comportement, consultez la section RFC 5452.
• Enregistrements qui ne sont pas pertinents pour la requête
• Enregistrements de réponse pour lesquels nous ne pouvons pas recréer la chaîne CNAME
• Enregistrements (dans la réponse, l'autorité ou les sections supplémentaires) pour lesquels le serveur de noms qui répond n'est pas crédible. Nous déterminons la crédibilité d'un serveur de noms en fonction de sa place dans la chaîne de délégation pour un domaine donné. Le DNS public de Google met en cache les informations de la chaîne de délégation, et nous vérifions chaque réponse entrante par rapport aux informations mises en cache afin de déterminer la crédibilité du serveur de noms qui répond à une requête particulière.

Ajouter l'entropie aux requêtes

Une fois qu'un résolveur applique des vérifications d'intégrité de base, un pirate informatique doit inonder le résolveur de victimes de réponses dans le but de faire correspondre l'ID de requête, le port UDP (de la requête), l'adresse IP (de la réponse) et le nom de la requête d'origine avant le serveur de noms légitime.

Malheureusement, cela n'est pas facile à réaliser, car le champ d'identification unique, l'ID de requête, ne fait que 16 bits (soit 1/65 536). Les autres champs sont également limités, ce qui fait que le nombre total de combinaisons uniques est relativement faible. Pour en savoir plus sur les fonctions combinatoires utilisées, consultez le document RFC 5452, section 7.

Par conséquent, le défi consiste à ajouter autant d'entropie que possible au paquet de requête, dans le format standard du message DNS, afin que les pirates informatiques aient plus de difficultés à faire correspondre une combinaison de champs valide dans la fenêtre d'opportunité. Nous recommandons et avons mis en œuvre toutes les techniques décrites dans les sections suivantes.

Nous avons présenté une révision mise à jour des techniques mentionnées ici lors de la conférence DNS OARC 38 en juillet 2022. La présentation comprend également des recommandations pour les opérateurs de serveurs de noms.

Rendre les ports sources aléatoires

En règle générale, ne laissez jamais les paquets de requête sortants utiliser le port UDP 53 par défaut, ni utiliser un algorithme prévisible pour attribuer plusieurs ports (par exemple, incrémentation simple). Utilisez une plage de ports aussi large que celle autorisée de 1024 à 65535, et utilisez un générateur de nombres aléatoires fiables pour attribuer les ports. Par exemple, le DNS public de Google utilise environ 15 bits pour autoriser environ 32 000 numéros de port différents.

Notez que si vos serveurs sont déployés derrière des pare-feu, des équilibreurs de charge ou d'autres appareils qui effectuent la traduction d'adresses réseau (NAT), ces appareils peuvent supprimer de manière aléatoire les ports sur les paquets sortants. Assurez-vous de configurer des appareils NAT pour désactiver la suppression aléatoire des ports.

Choix aléatoire des serveurs de noms

Certains résolveurs, lors de l'envoi de requêtes à un serveur de noms, un domaine de premier niveau ou un autre serveur de noms, sélectionne l'adresse IP du serveur de noms en fonction de la distance la plus courte (latence). Nous vous recommandons de randomiser les adresses IP de destination pour ajouter une entropie aux requêtes sortantes. Dans le DNS public de Google, il nous suffit de choisir un serveur de noms aléatoirement parmi les serveurs de noms configurés pour chaque zone, afin de favoriser des serveurs de noms rapides et fiables.

Si vous avez des inquiétudes concernant la latence, vous pouvez utiliser le bandeau aller-retour (DAR), qui consiste à randomiser la plage d'adresses en dessous d'un certain seuil de latence (par exemple, 30 ms, 300 ms, etc.).

Cookies DNS

La norme RFC 7873 définit une option EDNS0 pour l'ajout de cookies 64 bits aux messages DNS. Un cookie DNS prenant en charge un client inclut un cookie aléatoire de 64 bits et, éventuellement (si vous le connaissez), un cookie de serveur dans une requête. Si un serveur compatible trouve que l'option de cookie est valide dans une requête, il reflète le cookie client et le cookie de serveur correct dans la réponse. Le client associé peut ensuite vérifier que la réponse provient du serveur attendu en vérifiant le cookie client dans la réponse.

Si un serveur de noms n'est pas compatible avec les cookies DNS, vous pouvez utiliser les deux options suivantes pour ajouter l'entropie.

Ordre aléatoire dans le nom des requêtes

Les normes DNS exigent que les serveurs de noms traitent les noms avec insensibilité à la casse. Par exemple, les noms example.com et EXAMPLE.COM doivent être associés à la même adresse IP². De plus, tous les serveurs de noms, à l'exception d'une petite minorité, répercutent le nom dans la réponse, tel qu'il apparaît dans la requête, ce qui préserve le cas d'origine.

Par conséquent, pour augmenter l'entropie dans les requêtes, vous pouvez également modifier de manière aléatoire la casse des lettres dans les noms de domaine interrogés. Cette technique, également appelée "0x20", étant donné que le bit 0x20 est utilisé pour définir la casse des lettres US-ASCII, a d'abord été proposée dans le brouillon Internet IETF Use of Bit 0x20 in DNS Labels to Improve Transaction Identity (Utilisation du bit 0x20 dans les libellés DNS pour améliorer l'identité des transactions). Avec cette technique, la réponse du serveur de noms doit correspondre au nom de la requête, mais aussi à la casse de chaque lettre de la chaîne de nom (par exemple, wWw.eXaMpLe.CoM ou WwW.ExamPLe.COm). L'entropie des requêtes pour les domaines de premier niveau et racine peut s'avérer faible, voire inexistante, mais elle est efficace pour la plupart des noms d'hôte.

L'un des principaux défis que nous avons découverts lors de la mise en œuvre de cette technique est que certains serveurs de noms ne suivent pas le comportement de réponse attendu:

• Certains serveurs de noms répondent avec une insensibilité totale à la casse : ils renvoient correctement les mêmes résultats, quelle que soit la casse de la requête, mais la réponse ne correspond pas exactement à la casse du nom indiqué dans la requête.
• D'autres serveurs de noms répondent en respectant la casse (enfreignant les normes DNS) : ils traitent les noms équivalents différemment selon la casse de la requête, soit en n'y répondant pas du tout, soit en renvoyant des réponses NXDOMAIN incorrectes correspondant exactement à la casse du nom dans la requête.
• Certains serveurs de noms fonctionnent correctement, à l'exception des requêtes PTR de la zone arpa.

Pour ces deux types de serveurs de noms, la modification de la casse du nom de la requête générerait des résultats indésirables : pour le premier groupe, il serait impossible de distinguer une réponse d'une réponse fausse. Pour le deuxième groupe, la réponse (le cas échéant) pourrait être totalement incorrecte.

Notre solution actuelle consiste à utiliser la randomisation des cas uniquement pour les serveurs de noms qui, selon nous, appliquent correctement les normes. Nous listons également les sous-domaines d'exceptions appropriés pour chacun d'eux, en fonction de l'analyse de nos journaux. Si une réponse qui semble provenir de ces serveurs ne contient pas le bon cas, nous la refusons. Les serveurs de noms activés gèrent plus de 70% de notre trafic sortant.

Libellés nonce en avance sur les noms de requêtes

Si un résolveur ne peut pas résoudre directement un nom à partir du cache ou s'il ne peut pas interroger directement un serveur de noms faisant autorité, il doit suivre les sites référents d'un serveur de noms racine ou TLD. Dans la plupart des cas, les requêtes adressées aux serveurs de noms racines ou de domaines de premier niveau font référence à un autre serveur de noms au lieu d'essayer de résoudre le nom à une adresse IP. Pour de telles requêtes, vous devriez donc pouvoir attribuer un libellé aléatoire à un nom de requête afin d'augmenter l'entropie de la requête, sans risquer de résoudre un nom inexistant. En d'autres termes, l'envoi d'une requête à un serveur de noms référent pour un nom précédé d'un libellé nonce, tel que entriih-f10r3.www.google.com, doit renvoyer le même résultat qu'une requête pour www.google.com.

En pratique, ces requêtes représentent moins de 3% des requêtes sortantes. Toutefois, si le trafic est normal (la plupart des requêtes peuvent être reçues directement à partir du cache ou par une seule requête), il s'agit précisément des types de requêtes qu'un pirate tente de forcer un résolveur à émettre. Par conséquent, cette technique peut s'avérer très efficace pour empêcher les failles de style Kaminsky.

La mise en œuvre de cette technique nécessite que les étiquettes nonces ne soient utilisées que pour les requêtes qui sont forcément à l'origine de recommandations, c'est-à-dire de réponses qui ne contiennent pas d'enregistrements dans la section "Réponses". Cependant, nous avons rencontré plusieurs difficultés lors de la tentative de définition de l'ensemble de ces requêtes:

• Certains serveurs de noms de domaines de premier niveau nationaux (ccTLD) font autorité pour d'autres domaines de premier niveau secondaires. Bien qu'ils aient deux libellés, les 2LD se comportent comme les TLD. C'est pourquoi ils sont souvent gérés par les serveurs de noms ccTLD. Par exemple, les serveurs de noms .uk font également autorité pour les zones mod.uk et nic.uk, et donc les noms d'hôtes contenus dans ces zones, tels que www.nic.uk, www.mod.uk, etc. En d'autres termes, les requêtes adressées aux serveurs de noms ccTLD pour résoudre ces noms d'hôte n'entraînent pas de références, mais des réponses faisant autorité. L'ajout de libellés nonce à ces noms d'hôte rend les noms insolubles.
• Les serveurs de noms TLD (gTLD) génériques renvoient parfois des réponses qui ne font pas autorité pour les serveurs de noms. En d'autres termes, certains noms d'hôtes de serveurs de noms se trouvent dans une zone de domaine de premier niveau plutôt que dans celle de leur domaine. Un domaine de premier niveau générique affichera une réponse ne faisant pas autorité pour ces noms d'hôte, en utilisant l'enregistrement Glue qu'il possède dans sa base de données, plutôt que de renvoyer un site référent. Par exemple, le serveur de noms ns3.indexonlineserver.com se trouvait auparavant dans la zone gTLD .COM plutôt que dans la zone indexonlineserver.com. Lorsque nous avons envoyé une requête à un serveur de domaine de premier niveau générique pour n3.indexonlineserver.com, nous avons obtenu une adresse IP au lieu d'un site référent. Toutefois, si nous ajoutions un préfixe "nonce", nous avons reçu un lien vers indexonlineserver.com, qui n'a pas pu résoudre le nom d'hôte. Par conséquent, nous ne pouvons pas ajouter d'étiquettes "nonce" pour les serveurs de noms qui nécessitent une résolution d'un serveur de domaine de premier niveau générique.
• Les autorités associées aux zones et aux noms d'hôte évoluent au fil du temps. Cela peut entraîner l'indisponibilité d'un nom d'hôte non prédéfini qui était auparavant insoluble en cas de modification de la chaîne de délégation.

Pour résoudre ces problèmes, nous avons configuré des exceptions pour les noms d'hôtes pour lesquels nous ne pouvons pas ajouter d'étiquettes nonce. D'après les journaux de notre serveur, il s'agit de noms d'hôtes pour lesquels les serveurs de noms de domaine de premier niveau renvoient des réponses qui ne sont pas liées à un site référent. Nous examinons continuellement la liste des exceptions pour nous assurer qu'elle reste valide au fil du temps.

Suppression des requêtes en double

Les résolveurs DNS sont vulnérables aux attaques par "anniversaire" car ils exploitent le paradoxe mathématique "anniversaire" selon lequel la probabilité d'une correspondance ne nécessite pas un grand nombre d'entrées. Les attaques d'anniversaire impliquent d'inonder le serveur victime non seulement de réponses falsifiées, mais également de requêtes initiales, en comptant sur le résolveur pour l'émission de plusieurs requêtes pour une même résolution de nom. Plus le nombre de requêtes sortantes émises est élevé, plus il y a de chances que le pirate informatique mette en correspondance l'une de ces requêtes avec une réponse falsifiée : un pirate informatique n'a besoin que de l'ordre de 300 requêtes en cours pour que 50% des chances d'obtenir une réponse fausse aboutissent. 700 requêtes pour une réussite presque égale à 100 %.

Pour vous prémunir contre cette stratégie d'attaque, veillez à supprimer toutes les requêtes en double de la file d'attente sortante. Par exemple, le DNS public de Google n'autorise jamais plus d'une seule requête en attente pour les mêmes nom, type et adresse IP de destination.

Requêtes de limitation du débit

La prévention des attaques par déni de service (DDoS) pose plusieurs problèmes pour les outils de résolution DNS récursifs:

• Les résolveurs ouverts sont des cibles intéressantes pour lancer des attaques d'amplification. Ce sont des serveurs à haute capacité et une haute fiabilité et peuvent produire des réponses plus volumineuses qu'un serveur de noms faisant autorité, en particulier si un pirate informatique peut injecter une réponse volumineuse dans son cache. Il incombe à tout développeur d'un service DNS ouvert d'empêcher l'utilisation de ses serveurs pour lancer des attaques sur d'autres systèmes.
• Les attaques d'amplification peuvent être difficiles à détecter lorsqu'elles se produisent. Les pirates informatiques peuvent lancer une attaque via des milliers de résolveurs ouverts, afin que chaque résolveur ne voie qu'une petite partie du volume global de la requête et ne peut pas extraire un signal clair qu'il a été piraté.
• Le trafic malveillant doit être bloqué sans interruption ni dégradation du service DNS pour les utilisateurs normaux. Le DNS est un service réseau essentiel. Il n'est donc pas possible d'arrêter des serveurs pour couper une attaque et de le refuser à une adresse IP client donnée trop longtemps. Les résolveurs doivent pouvoir bloquer rapidement une attaque dès son démarrage et restaurer le service entièrement opérationnel dès la fin de l'attaque.

La meilleure approche pour lutter contre les attaques DoS consiste à imposer un mécanisme de limitation de la fréquence d'exposition. Le DNS public de Google met en œuvre deux types de contrôle du débit:

• Contrôle du débit des requêtes sortantes vers d'autres serveurs de noms. Pour protéger les autres serveurs de noms DNS contre les attaques DoS pouvant être lancées depuis nos serveurs de résolution, le DNS public de Google applique des limites de RPS aux requêtes sortantes de chaque cluster de diffusion pour chaque adresse IP du serveur de noms.

• Contrôle du débit des réponses sortantes envoyées aux clients. Pour protéger les autres systèmes contre l'amplification et les attaques DoS (botnet) distribuées traditionnelles pouvant être lancées par nos serveurs de résolution, le DNS public de Google effectue deux types de limitation du débit pour les requêtes client:

  • Pour se protéger contre les attaques traditionnelles basées sur le volume, chaque serveur impose des limites de RPS et une limite moyenne de bande passante par client.
  • Pour se prémunir contre les attaques par amplification, lors desquelles des réponses volumineuses à de petites requêtes sont exploitées, chaque serveur applique un facteur d'amplification maximal par client. Le facteur d'amplification moyen est un ratio configurable de la taille de la réponse à la requête, déterminé à partir des modèles de trafic historiques observés dans nos journaux de serveur.

  Si les requêtes DNS provenant d'une adresse IP source dépassent le débit maximal de RPS, les requêtes en excès sont supprimées. Si les requêtes DNS sur UDP à partir d'une adresse IP source dépassent la limite moyenne de bande passante ou d'amplification de manière cohérente (la réponse volumineuse occasionnelle peut être ignorée), les requêtes peuvent être supprimées ou seule une petite réponse peut être envoyée. Les petites réponses peuvent être des réponses d'erreur ou des réponses vides avec le bit de troncature défini (de sorte que la plupart des requêtes légitimes soient relancées via TCP et abouties). Les systèmes ou les programmes ne procèdent pas à une nouvelle tentative via TCP, et le DNS sur TCP peut être bloqué par les pare-feu côté client. Il est donc possible que certaines applications ne fonctionnent pas correctement lorsque les réponses sont tronquées. Néanmoins, la troncature permet aux clients conformes à la norme RFC de fonctionner correctement dans la plupart des cas.