Summary

  • LACNIC says nserver names the server expected to answer a reverse-DNS delegation, nsstat reports the delegation status, and nslastaa records the last date on which a correct configuration was observed.
  • nslastaa is therefore historical monitoring evidence. Current DNS behaviour requires a fresh, time-stamped query; BGP reachability requires a different evidence system altogether.

Analysis

A date that points backward

The most important word in the definition of nslastaa is “last”. LACNIC’s reverse-DNS FAQ does not describe the field as a health certificate with a validity interval. It describes the last date on which the registry’s monitoring observed a correct configuration on the server. The field preserves a useful event: at least one successful observation occurred on that date, under the monitoring conditions then in force.

That is materially different from saying that the delegation has remained correct ever since. The field reports the successful observation it names; it does not report what happened in every moment after it. A later result may differ without making the stored date false. That is why a dated observation must not be silently converted into a continuous claim.

The companion fields help keep the evidence in its proper lane. LACNIC explains that nserver identifies the server that should answer the delegation and nsstat reports the delegation’s status. nslastaa adds the time of the last successful configuration observation. Together they are a registry-operated view of reverse-DNS delegation and monitoring, not an all-purpose verdict on the operator or network.

Historical registry evidence and a fresh DNS test answer different questions

An investigator looking at an old incident should preserve the WHOIS response, its retrieval time, the nserver, nsstat and nslastaa values, and the queried block. That record can show what LACNIC’s directory and monitoring surface reported at a particular time. It may also reveal that a server had not been observed in a correct state for an unexpectedly long period.

An investigator asking whether the service works now needs a new observation. LACNIC recommends querying the delegated server for the relevant reverse-zone SOA record and distinguishes a successful NOERROR response from NXDOMAIN or SERVFAIL. The exact command is less important than the evidentiary discipline: record the query name, server, transport, vantage point, time, response code and returned authority data.

Even that fresh query has limits. One successful response proves that one observer obtained one response at one time. It does not establish universal reachability, continuous uptime or identical answers from every path. Repetition across time and vantage points can strengthen an operational conclusion, but the conclusion remains about DNS behaviour, not about every service run by the resource holder.

A failed check is a diagnostic signal, not a complete cause

LACNIC says a lame-delegation condition can arise when the server information registered for the IP block is inaccurate or when the registry’s monitoring system cannot access the server. Those are different mechanisms. The first points toward configuration or registration data; the second may involve reachability from the monitoring vantage point. A stored status alone does not select the cause.

That distinction matters during incident response. A non-success label does not select one cause, and an old successful date does not show that present behaviour is correct. In either direction, the responsible move is to keep the registry observation intact, state what it does not establish, and collect a current measurement before attributing cause.

Reverse DNS is not forward DNS, and neither is BGP

The LACNIC fields discussed here concern reverse resolution for an address block. They do not certify forward DNS. They also do not reveal whether the address block is being announced in BGP, which ASN originates it, where an announcement is observed, or whether traffic reaches a particular service.

Those questions use separate observations. A fresh DNS query can document the response obtained from a named server at a stated time and vantage point. A separate, time-aligned BGP observation is required for a routing claim. The source packet contains no such BGP observation, so nslastaa cannot supply one by implication.

The practical reading rule

Read nslastaa as a lower bound on recency, not as a warranty. It tells the reader when LACNIC last observed the listed server in a correct configuration according to the monitoring represented by the field. The older the date, the stronger the reason to perform a fresh test. A recent date can reduce uncertainty, but it cannot erase the time between the observation and now.

For audit work, preserve both the registry observation and any follow-up measurements. If they disagree, do not overwrite the older evidence. Record the divergence and investigate whether the difference comes from time, vantage point, delegation data, authoritative service behaviour or network reachability. That method keeps a small but valuable registry field intact without asking it to prove what it never observed.

Sources