Summary

  • The reverse-DNS object reported with two identical nserver: values in February now names ns1.ibits.xyz and ns2.ibits.xyz. A September snapshot also found both targets in the parent referral and an authoritative SOA answer from the first server. The original example must not be described as still broken.
  • A raw attribute count, a count of distinct DNS targets, an observed authoritative response and evidence of independent failure domains are different claims. Narrow duplicate-input safeguards can improve the first two without certifying the others or authorising broader registry sanctions.

Start with the correction

At 04:12 UTC on 2026-09-14, a read-only check of 8.c.4.f.f.0.c.2.ip6.arpa returned two different names. AFRINIC’s WHOIS object listed ns1.ibits.xyz and ns2.ibits.xyz; an NS query to ns1.afrinic.net referred the zone to both. A SOA query directed to the first listed server returned NOERROR with the authoritative-answer flag and an SOA record. That is a materially better result than the example that started a database working-group discussion in February. It is also considerably less than a resilience certificate.

The check covered one object, one vantage point and one moment. It did not test the second server’s SOA response, individual PTR answers, different client locations, network-path separation or failover. Nor does it identify who corrected the object, when the correction occurred, or whether any general input validator changed. The public WHOIS service makes the underlying registration object discoverable; the observation’s scope is the particular WHOIS and DNS queries just described.

Starting here matters. An old, precise report can become a new, imprecise allegation when its reproduction steps are treated as current findings. In this case the named duplicate is gone, the parent supplies two distinct targets, and the sampled first server no longer returns the refusal included in the old discussion. These observations should narrow the story, not be explained away so that the original criticism survives intact.

How two lines became one target

On 2026-02-19, Frank Habicht asked whether creation of a domain object should be rejected when two nameserver attributes contained exactly the same value. He explicitly said that he was not speaking as chair. His message showed the named IPv6 reverse zone with ns1.ibits.xyz entered twice. It asked staff to explain the existing checks and invited discussion of a possible additional one. It did not announce an adopted rule.

His follow-up on 20 February acknowledged that the existing documented wording allowed the entry. The concern was instead a likely human mistake followed by a likely human misunderstanding: a reader scanning two lines might believe two authoritative servers had been configured. The follow-up included a parent answer containing one NS target and a separate SOA query to that target returning REFUSED. Those were distinct observations. Repetition explained the inflated visual count; refusal concerned whether the target would serve that particular zone.

The distinction is built into DNS rather than invented for this incident. RFC 2181, section 5, defines a resource-record set through a common owner name, class and type with differing record data. Two records with all those components, including their data, identical do not create two useful members of the set; servers should suppress duplicates. Repeating the same NS target therefore cannot, by itself, manufacture a second DNS target. It can nevertheless manufacture a reassuring second line in a registration display.

That is the mechanism worth retaining after the particular object has improved. One system preserves submitted attributes for editing and lookup. Another presents the distinct DNS data relevant to a referral. A person may count the former while trying to reason about the latter. The protocol can handle identical data correctly while the operator-facing view leaves a misleading impression. Calling this a DNS duplication attack or a current service outage would add claims the evidence does not support.

Multiple is not a minimum of two

The exchange also exposed an easily missed reading error. In the domain template, nserver: is marked mandatory and multiple. Mandatory means the attribute must be present; multiple permits it to occur more than once. Those markings do not themselves say that every object must contain at least two rows, much less two distinct authoritative services.

In a 20 February reply, Habicht explained that distinction using a quotation from the then-linked getting-started manual. On 2026-03-23, Sylvain BAYA accepted the clarification after initially reading multiple as requiring at least two. He nevertheless argued for a wider discussion: restrictions on single-server entries, duplicate comparison, lameness handling and a best-practice document. These were a participant’s suggestions, not evidence of consensus or deployment.

The current read-only template query still returns mandatory, multiple and inverse key. The verbose public description addresses valid names, optional trailing dots and limited use of glue addresses. We did not attempt to create or update an object to discover which submissions every production interface accepts. A template is evidence about the advertised structure, not a comprehensive behavioural test of a portal, email update path or WHOIS server.

AFRINIC’s published reverse-DNS guidance recommends at least two nameservers for redundancy. That operational recommendation is sensible, but it is not interchangeable with the multiplicity notation. Converting a recommendation into a new acceptance condition would be a separate change requiring its own rationale and transition arrangements. A validator that catches an exact duplicate need not first refuse every legitimate edit to an existing single-target object.

Four tests, not a rising certainty score

The evidence is clearer when four questions are kept separate. How many attributes are displayed? How many distinct canonical NS target names do they represent? Which targets answered authoritatively for the zone in the stated observation? What dependencies would have to fail together to make all useful service unavailable? Each question measures something the previous answer cannot establish.

The September check answers the first two for the named object and part of the third. It does not answer the fourth. Even successful responses from both names would not reveal whether they share a site, routing dependency, power source, administrative account or deployment control plane. Conversely, a single name can front distributed infrastructure. Neither topology was measured here, so neither should be assigned to these operators by inference from their naming convention.

RFC 2182 explains secondary-server selection through likely failures and geographical as well as topological dispersion. Its practical concern is whether a plausible link, building or provider failure disables every server, not whether a configuration looks plural. Two machines in one room may survive the failure of one machine while remaining exposed to the same power loss. Two distant services may still have a common operational dependency. These are reasons to investigate failure modes, not findings about the named zone.

Nor is redundancy a simple score that increases with each successful probe. Authority for a SOA response, availability from a second vantage and survival during a controlled failure have different evidential shapes. A successful query is real counterevidence to an assertion that the sampled server currently refuses that query. It is not a sample of every condition in which a user will depend on the service. Accurate reporting should retain the success and its limits together.

A narrow safeguard can remain narrow

There is still a reasonable case for catching wholly repeated input. A warning can show an editor that two identical attributes produce only one distinct target; a proposed creation-time rejection could require the editor to remove the accidental repetition. Either measure addresses an inexpensive, foreseeable misunderstanding without promising a second working service. It should be described as a proposed safeguard, not something this investigation has proved AFRINIC already deployed.

Implementation would need more care than comparing complete lines or deleting every repeated hostname. DNS names can differ in letter case or an optional final dot without identifying different targets. The current verbose description also permits an in-bailiwick nameserver name to be followed by an IPv4 or IPv6 glue address. Two attributes that provide different legitimate glue data must not be erased merely because their target name is the same. The right distinction is between redundant identical input, distinct target names and distinct address data.

A display could therefore expose both raw attribute count and distinct canonical target count, while keeping glue information intact. Such a view would make the February ambiguity harder to miss. It would not claim that two distinct targets were independently reachable or that their failures were independent. A separate operational assessment could supply that evidence where it matters, with a timestamp and stated scope rather than a permanent green badge.

The broader March counterargument deserves its strongest reading. A duplicate check alone cannot cure a non-authoritative target or provide a secondary service that an operator has not provisioned. Best-practice guidance and practical deployment assistance can be more valuable than another rejection message. But that observation does not make a narrowly truthful display useless, and it does not establish that mandatory minimum-two enforcement is the best remedy. Avoiding an input ambiguity and procuring resilient DNS are complementary tasks with different owners and costs.

Sources