TTL DNS : enquêter sur un changement d’IP

Un domaine contacté pendant un incident résout aujourd’hui vers une autre adresse. Cette différence n’invalide pas vos journaux et ne prouve pas un déplacement malveillant. Pour l’expliquer, il faut replacer chaque réponse DNS dans son contexte : heure, résolveur, type de donnée, cache et point d’observation.

Le TTL DNS est utile dans cette reconstruction, à condition de lui poser la bonne question. Il renseigne le traitement du cache ; il ne date pas à lui seul une infrastructure. Voici une méthode pour conserver une chronologie exploitable quand les adresses changent pendant une investigation.

Ce que vous mesurez quand vous lisez un TTL

Le TTL est exprimé en secondes. Une réponse issue d’un résolveur récursif peut montrer la durée restante d’une donnée déjà en cache, tandis qu’une autorité peut présenter sa durée configurée. Comparer ces nombres sans identifier leur provenance crée des écarts artificiels.

La définition du TTL dans la RFC 1035 rattache cette valeur à la mise en cache d’un enregistrement. Elle ne décrit ni l’âge d’un domaine, ni la date de sa première utilisation, ni la durée de validité d’un indicateur de compromission.

L’exemple fictif suivant représente deux lectures du même résolveur :

10:00:00Z  api.service.example. A 192.0.2.20  TTL=240
10:01:00Z  api.service.example. A 192.0.2.20  TTL=180

Une baisse de soixante secondes est compatible avec un cache qui vieillit. Elle ne révèle pas une modification de zone. Pour qualifier un changement, comparez aussi le contenu des réponses et les conditions de collecte.

Construire un tableau de preuves datées

Créez une ligne par observation, sans écraser la précédente quand une nouvelle adresse apparaît. Enregistrez le nom complet, le type A ou AAAA, les éventuels CNAME, toutes les adresses renvoyées et les TTL correspondants. Ajoutez le résolveur, l’emplacement du capteur et l’heure UTC.

Dans votre dossier, gardez séparément la requête DNS et la connexion réellement observée. Un client peut recevoir plusieurs adresses et n’en utiliser qu’une. La réponse du résolveur décrit des destinations disponibles ; le journal réseau décrit celle qui a été tentée ou atteinte.

Ce tableau ne détermine pas l’instant exact du changement côté autorité. Celui-ci se situe quelque part dans une période encore à préciser. Évitez de remplacer cet intervalle par une heure inventée à partir de la dernière requête connue.

Examiner toute la chaîne, pas seulement la dernière IP

Un nom peut être un alias vers un service distribué. Conservez chaque CNAME avec sa propre observation. Une cible d’alias stable peut mener à des adresses variables ; un changement de CNAME peut aussi modifier l’opérateur sans que votre première vue le montre clairement.

Regardez séparément IPv4 et IPv6. L’application peut utiliser une réponse AAAA alors que votre enrichissement ne conserve que A. Un incident attribué à « la mauvaise IP » peut venir de cette collecte partielle, sans incohérence dans le DNS.

Des réponses différentes depuis deux réseaux peuvent correspondre à une répartition géographique ou à deux vues administrées. Comparez d’abord les noms, types et points d’observation. Pour un nom interne, restez dans les vues autorisées et ne l’envoyez pas à un service public pour simplifier le test.

Tenir compte des réponses anciennes encore servies

L’expiration d’un TTL n’assure pas que tous les clients recevront immédiatement la nouvelle adresse. Des couches applicatives, des résolveurs intermédiaires ou des politiques particulières peuvent prolonger l’écart constaté. Cherchez leur configuration et leurs journaux avant d’accuser la publication DNS.

La RFC 8767 décrit le service de données périmées lorsque leur rafraîchissement autoritatif échoue. Si cette fonction est activée, une ancienne réponse peut rester disponible au-delà de sa durée de cache ordinaire. Ce mécanisme doit être vérifié sur le résolveur concerné, pas supposé à partir du seul résultat.

Préservez donc la première réponse avant une purge. Notez les redémarrages, les changements de résolveur et les opérations de dépannage : ils modifient votre expérience. Un test qui fonctionne après une purge indique un effet du changement effectué, mais ne reconstitue pas automatiquement la situation antérieure.

Distinguer migration, distribution et activité suspecte

Demandez au propriétaire du service s’il existe une migration ou une modification de fournisseur correspondant à la période. Comparez cette déclaration avec les réponses conservées, les destinations réellement utilisées et les changements de configuration. Un ticket de migration apporte une explication à vérifier.

Si les adresses tournent rapidement, examinez leur diversité et l’activité associée. Le guide de détection du fast flux traite cette hypothèse spécifique. Dans une enquête sur un changement ponctuel, transformer toute rotation en fast flux ajouterait une conclusion sans preuve.

Consultez aussi le contexte de chaque IP à la date pertinente. Une adresse mutualisée peut héberger plusieurs services et changer d’usage. Ne transférez pas automatiquement la réputation de l’ancienne adresse à la nouvelle, ou celle d’un domaine à tous les voisins de son hébergement.

Choisir l’action avec la bonne durée

Si l’activité suspecte suit un nom précis, examinez une mesure portant sur ce nom lorsque vos contrôles le permettent. Si un confinement doit viser une IP, documentez la relation observée et prévoyez une révision. Le TTL DNS ne constitue pas une durée de blocage par défaut.

L’article sur l’expiration des IOC explique comment réévaluer une règle indépendamment du cache. Dans le dossier d’incident, terminez par les adresses démontrées, les périodes couvertes et les trous de collecte. Une observation historique externe peut compléter ces trous, sans établir ce qu’un poste précis a reçu.

Pour enrichir les adresses et domaines publics retenus, ouvrez un rapport IsMalicious. Joignez son heure de consultation à votre chronologie. La conclusion doit rester attachée aux événements conservés, même lorsque la résolution actuelle a déjà changé.