Résumé

  • Selon LACNIC, nserver désigne le serveur censé répondre à la délégation inverse, nsstat en indique l’état et nslastaa consigne la dernière date à laquelle une configuration correcte a été observée.
  • nslastaa est donc une trace historique du suivi. Le comportement DNS actuel exige une requête récente et horodatée ; la visibilité BGP relève d’une observation distincte.

Analyse

Une date tournée vers le passé

Le mot décisif dans la définition de nslastaa est « dernière ». La FAQ de LACNIC ne présente pas ce champ comme un certificat de santé assorti d’une période de validité. Elle le décrit comme la date à laquelle le suivi de LACNIC a observé pour la dernière fois une configuration correcte sur le serveur. Le champ conserve donc un événement précis : dans les conditions de contrôle de ce jour-là, au moins une observation a réussi.

Cela ne signifie pas que la délégation soit restée correcte sans interruption. Le champ décrit le succès qu’il date, mais pas chaque instant qui suit. Un résultat ultérieur peut être différent sans rendre la date enregistrée fausse. Une observation datée ne doit donc pas devenir une affirmation continue.

Les champs voisins empêchent une lecture trop large. LACNIC explique que nserver indique le serveur qui doit répondre à la délégation et que nsstat indique l’état de celle-ci. nslastaa ajoute le moment du dernier succès constaté. L’ensemble décrit une vue de registre sur la délégation DNS inverse, non un jugement global sur l’organisation ou son réseau.

L’archive WHOIS et le test actuel ne répondent pas à la même question

Pour analyser un incident passé, il faut conserver la réponse WHOIS, l’heure de collecte, le bloc demandé et les valeurs nserver, nsstat et nslastaa. Cet ensemble montre ce que le répertoire et le suivi de LACNIC affichaient à cet instant. Il peut aussi signaler qu’aucun état correct n’avait été observé depuis longtemps.

Pour savoir si le service fonctionne maintenant, une nouvelle mesure est nécessaire. LACNIC recommande d’interroger le serveur délégué pour l’enregistrement SOA de la zone inverse et distingue une réponse NOERROR de NXDOMAIN ou SERVFAIL. La discipline probatoire impose d’enregistrer le nom interrogé, le serveur, le transport, le point d’observation, l’heure, le code de réponse et les données d’autorité reçues.

Même une réponse fraîche a des limites. Elle prouve qu’un observateur a obtenu une réponse à un instant donné. Elle ne démontre ni une accessibilité universelle, ni une disponibilité continue, ni l’identité des réponses depuis tous les chemins. Des répétitions dans le temps et depuis plusieurs réseaux renforcent l’analyse, sans la transformer en verdict sur tous les services du titulaire.

Un échec est un indice de diagnostic, pas une cause complète

LACNIC indique qu’une délégation boiteuse peut résulter d’informations de serveur inexactes dans la base ou de l’incapacité de son système de suivi à joindre le serveur. Ces mécanismes sont différents. Le premier oriente vers les données d’enregistrement ou la configuration ; le second peut concerner le chemin entre la sonde et le serveur. Le seul état enregistré ne suffit pas à choisir la cause.

Pendant un incident, considérer un échec comme une preuve de négligence peut masquer une perte transitoire, un filtrage, une maintenance ou un défaut de mesure. À l’inverse, une date de succès ancienne ne justifie pas d’écarter l’alerte. Dans les deux cas, le champ sert à formuler des hypothèses qui doivent être vérifiées.

DNS inverse, DNS direct et BGP restent séparés

Les champs étudiés concernent la résolution inverse d’un bloc d’adresses. Ils ne certifient pas les zones directes d’un site, d’une messagerie ou d’une API. Ils ne montrent pas non plus que le bloc est annoncé dans BGP, quel ASN l’origine, où il est accepté ou si le trafic atteint une application.

Ces questions exigent des observations distinctes. Une requête DNS récente documente la réponse obtenue auprès d’un serveur, à une heure et depuis un point donnés. Une affirmation de routage exige une observation BGP séparée et alignée dans le temps. Le dossier de sources n’en contient aucune : nslastaa ne peut pas la fournir implicitement.

Règle de lecture pratique

Il faut lire nslastaa comme une borne de récence, pas comme une garantie. Plus la date est ancienne, plus un contrôle frais s’impose. Une date récente réduit une partie de l’incertitude, mais n’efface jamais l’intervalle entre l’observation et le présent.

En audit, on conserve à la fois l’observation du registre et les mesures ultérieures. Si elles divergent, l’ancienne preuve ne doit pas être écrasée. Il faut documenter l’écart et déterminer s’il vient du temps, du point d’observation, des données de délégation, du serveur autoritaire ou de la connectivité. Ainsi, un petit champ reste utile sans devenir la preuve de phénomènes qu’il n’a jamais observés.

Sources