Attaque NXDOMAIN dans Cloud DNS : migration de zone

Trafic NXDOMAIN anormal dans Cloud DNS : Analyse, migration et enseignements

En mars 2026, une zone DNS publique dans Cloud DNS a connu un trafic anormal : les requêtes avec réponses NXDOMAIN ont bondi de 0,57 requêtes/sec à 2720 requêtes/sec. La charge totale a grimpé à 2951 requêtes/sec, entraînant une forte hausse de la facturation. Le support n'a pas fourni d'analyse technique en temps voulu, forçant une migration urgente de la zone vers un hébergement externe.

Les métriques ont montré que NXDOMAIN dominait les requêtes NOERROR. Le trafic a été jugé illégitime en raison de l'absence d'événements métier, de sa répétabilité et du manque d'explications du fournisseur.

Détails de l'anomalie

Niveau de base normal le 22 mars :

• A noerror : 9,38 requêtes/sec
• A nxdomain : 0,57 requêtes/sec
• Total : 9,96 requêtes/sec

Anomalie le 25 mars :

• A nxdomain : 2720,29 requêtes/sec
• A noerror : 231,14 requêtes/sec
• Total : 2951,43 requêtes/sec

La zone contenait des enregistrements standards : A, CNAME, MX, TXT, NS, et des enregistrements de service pour DKIM, DMARC, ACME. La première alerte est survenue du 7 au 10 mars, avec l'incident principal du 24 au 31 mars.

Le trafic a été classé comme anormal selon son profil : prédominance de NXDOMAIN sans raisons légitimes, récurrence de l'épisode et absence de réponse du support.

Réponse du support et impact financier

Contacter le support n'a donné aucun résultat : au lieu d'analyser le trafic, nous avons reçu une réponse générique sur l'attente de collègues. Les coûts ont augmenté proportionnellement aux requêtes pour des noms inexistants.

Solution : déposer une réclamation en parallèle tout en préparant la migration. Nous avons choisi un hébergement DNS externe avec importation de fichier de zone.

Étapes de migration

• Exporter les enregistrements :

yc dns zone list-records example-zone --format json > zone-records.json

Structure JSON :

{
  "record_sets": [
    {
      "name": "*.service.example-company.ru.",
      "type": "A",
      "ttl": "300",
      "data": [
        "203.0.113.10"
      ]
    },
    {
      "name": "_dmarc.example-company.ru.",
      "type": "TXT",
      "ttl": "300",
      "data": [
        "\"v=DMARC1; p=none; sp=none; rua=mailto:[email protected]\""
      ]
    }
  ]
}

• Convertir le JSON en fichier de zone BIND :
• Utiliser @ pour l'origine
• Supprimer les enregistrements NS de l'ancien fournisseur
• Dérouler les enregistrements TXT multiples
• Vérifier les enregistrements CNAME, ACME, DMARC
• Exclure SOA

Exemple de fichier de zone :

$TTL 1d
example-company.ru. IN SOA ns1.provider.example. hostmaster.ns1.provider.example. (
        1
        14400
        3600
        604800
        10800
)

@       A       203.0.113.10
app     A       203.0.113.20
www     CNAME   infra.example-company.ru.

Recommandations de surveillance et de préparation

Pour les DevOps et SRE intermédiaires/seniors :

• Surveiller les métriques par codes de réponse : noerror, nxdomain, pics de charge.
• Préparer un script pour l'export/conversion de zone.
• Examiner les enregistrements avant migration : NS, TXT (ACME/DKIM), IP privées.

Tickets séparés : analyse technique séparément des réclamations financières.

En cas d'anomalie sans réponse—activer le plan B : exporter, migrer, tout journaliser.

Principaux enseignements

• Surveiller NXDOMAIN évite les surprises de facturation.
• Exporter via yc dns zone list-records --format json est une étape clé de migration.
• Exclure les enregistrements NS du fournisseur du fichier de zone pour éviter les conflits.
• Examiner les enregistrements TXT/ACME : supprimer ceux obsolètes.
• Les tickets parallèles accélèrent la résolution.

— Editorial Team