Summary

  • In an AFRINIC Whois domain object, mnt-domains references the maintainer authorized to create domain objects directly below the registered domain tree.
  • That authorization does not show that name servers are correctly configured, that a parent delegation is active, that authoritative queries succeed, or that useful PTR records exist.

A permission at the database layer

AFRINIC’s Database manual gives mnt-domains a precise scope. When the attribute appears in a domain object, it refers to the maintainer that can authorize creation of domain objects immediately below the registered domain tree. The field answers a change-control question: whose credentials may support a particular kind of database update?

That is important evidence. It helps an analyst identify the administrative gate around the reverse-domain hierarchy recorded by the registry. It may explain why a child object can be created, why an attempted update is rejected, or which maintainer reference should be examined during an authorization dispute.

But the attribute does not execute DNS. It carries no query result, serial number, response code, round-trip time, DNSSEC validation result or PTR value. It does not say that a server named elsewhere is online. Treating the maintainer reference as service proof would collapse a registry permission into an observation of a different system.

Reverse delegation has additional steps

AFRINIC’s reverse-DNS guidance makes the separation explicit. A resource holder first configures the reverse zone on its name servers. The holder then creates the corresponding domain object in the AFRINIC Database. AFRINIC checks the configuration before the delegation is propagated, and its guidance points operators to a lameness checker. The name servers themselves are listed through nserver values.

Each step supplies different evidence. The domain object records the reverse namespace and the proposed authoritative servers. mnt-domains records a maintainer relationship governing child object creation. Parent-zone data can show whether delegation is published. Direct DNS queries can show which servers respond and what they return. A lameness test can reveal that a delegated server is not authoritative for the zone.

These observations can agree, but they are not interchangeable. A perfectly valid maintainer reference can coexist with a missing domain object, stale name-server data, a lame delegation, an unreachable server or an empty reverse zone. Conversely, a functioning delegation does not prove that the current mnt-domains value expresses every operational or contractual responsibility behind it.

Reading the evidence without overreach

A reproducible review starts with the exact AFRINIC domain object, retrieval time and source interface. Record its key, its nserver values, its mnt-by and mnt-domains references, and the relevant parent. Keep the fields separate rather than turning them into a single label such as “DNS owner.”

Next, query the parent delegation and each authoritative server directly. Capture the queried name, record type, server address, response code, authority flags and time. For reverse service, test representative PTR names within the delegated range, while recognizing that absence of a PTR at one address does not by itself prove the whole zone is broken. Use a lameness check to distinguish delegation from authoritative service.

AFRINIC also exposes reverse-DNS registration information through the RDAP domain query class. That offers a structured registration view, not a substitute for DNS measurements. An RDAP response and a live DNS answer can be compared at the same timestamp, but neither should be silently promoted into the other.

Sources