Summary

  • AFRINIC's Africa IPv6 & DNSSEC Deployment Monitor says in its 18 August 2026 release notes that government and university operators can request monitoring for their domains, with a button on the home page and every country page.
  • Public files captured on 5 September contain those controls, but both begin with the hidden attribute. Their shared script sets FORM_URL to an empty string and removes the hidden state only after validating an absolute HTTPS destination.
  • The design fails closed, and other security changes from the same release are observable. The evidence therefore describes one unactivated feature inside a mixed release—not a broken monitor, an outage, or proof that no request channel exists elsewhere.

The missing value is only two quotation marks

The decisive line is short enough to miss in a release review:

const FORM_URL = '';

It sits in the public request-form.js used by AFRINIC's Africa IPv6 & DNSSEC Deployment Monitor. The script first collects every element marked data-request-form. It then tries to parse the configured value as a URL. Only an absolute address using HTTPS is accepted. If the value is empty, malformed or uses another protocol, execution returns before a destination is assigned and before any button is unhidden.

When the test passes, the rest of the branch is equally clear. The script writes the validated address into the link, asks the browser to open a new tab, adds noopener noreferrer external, and finally sets btn.hidden = false. In the version captured on 5 September 2026, that branch cannot be reached because the configured string is empty.

This is not a guess based on a missing visual element. The home page's HTML contains a hero-cta anchor with data-request-form, href="#" and the Boolean hidden attribute. Its nearby comment says the destination is set in the shared script and the control remains hidden until it is. The South Africa country page contains the same arrangement in its top navigation. The stylesheet maps both .hero-cta[hidden] and .topnav-cta[hidden] to display: none.

The landing-page and country-page application scripts do not contain another data-request-form activation path. Each page loads the dedicated request script. The released interface is therefore present in the deployed markup, while the deployed configuration deliberately leaves it unavailable.

What version 2.12.0 says

The monitor's public changelog labels version 2.12.0 as an 18 August 2026 release. Under “What's new”, it makes two linked statements: government and university operators can request monitoring for their domain, and the button appears on the home page and at the top of every country page.

The word “appears” is doing more work than the deployed state can support. The controls appear in source markup; they do not enter the usable interface under the script and configuration that were captured. An operator reading the release note would reasonably expect a route into the monitoring process. The public artifacts instead contain a dormant route whose one required destination is blank.

That gap should be described precisely. It does not establish that a request form was never built. It does not show why the address was left empty, whether the feature was enabled at another time, or whether AFRINIC accepts requests through email or private contacts. No request was submitted during this review. There is no evidence about acknowledgement, queueing or response time.

The observation is also time-bound. The HTML, JavaScript, CSS and response headers were fetched without using a cached copy on 5 September. The script and stylesheet advertised a public cache life of one hour. A later deployment can change the result. An accurate record says what bytes were served and when; it does not convert a capture into a permanent condition.

A quiet failure is the right immediate failure

The implementation deserves credit. A call to action pointing to #, an invalid URL or an unsafe scheme would be worse than no control. The script treats its manually supplied value as untrusted, accepts HTTPS only, and keeps the link hidden if validation fails. When enabled, it also prevents the new page from receiving an opener handle and suppresses a referrer beyond the site's policy.

That design contains the immediate risk. It does not reconcile the release statement. Fail-closed software and over-broad release text can coexist: the former protects a visitor from a dead or unsafe route, while the latter says the route is available. Treating the careful failure as proof that nothing is wrong would confuse application safety with record accuracy.

The distinction matters because the monitor is itself an evidence product. It measures whether public-sector and institutional domains expose IPv6 and DNSSEC-related capabilities. Its credibility does not depend on every measured domain succeeding. It does depend on keeping claims, observations and unavailable states separate. The same discipline should apply to the monitor's own intake feature.

The rest of the release did not disappear

Version 2.12.0 also lists security changes. Two leave visible traces in the captured deployment. The site's robots.txt disallows /data/ and explains that the underlying JSON is not meant for search indexing. A direct response for the South Africa JSON remained available to the site but carried X-Robots-Tag: noindex. The country-page script also defines an escaping function for third-party text and applies it to country names inserted into map-tooltip markup.

The changelog further says that build working files are no longer web-accessible. This review did not test unspecified working-file paths, so that statement remains a release claim rather than an independently reproduced observation.

These states prevent a sweeping verdict. At least some security work named in 2.12.0 is visible in production. The request interface's inactive configuration does not make those changes fictitious, just as those changes do not activate the request interface. “Released” is too large a Boolean for a package containing several independently deployable promises.

Feature-level question Evidence on 5 September
Does the release note promise domain-monitoring requests? Yes
Are request controls in home and country markup? Yes
Do they begin hidden? Yes
Does the shared script contain a destination? No; FORM_URL is empty
Does the script fail closed? Yes
Was an end-to-end request accepted? Not tested and not established
Are some same-release security changes observable? Yes

That table is more useful than calling the release either complete or failed. It preserves what is working, what is present but dormant, and what was not tested.

A request button cannot validate the cohort it would change

This evidence says nothing about the monitor's current percentages. No new domain was submitted, no domain was added, and no scan result was recomputed. It would be wrong to infer that the hidden control caused a particular country to have too few monitored sites or that a visible control would make the sample representative.

There is nevertheless a mechanism worth watching. If the published route is unavailable, operators who know a maintainer or an informal channel may still reach the team, while those relying on the public interface cannot use it. Over time, that could make admission depend more on prior relationships. It is a selection-risk hypothesis, not an observed bias. Testing it would require request records, admission decisions and changes to the monitored cohort—none of which are public in the captured files.

The useful response is not to decorate the monitor with another percentage. It is to preserve the intake states that precede a measurement: request received, acknowledged, accepted or rejected, domain added, first scan completed, and reason for any exclusion. Without that chain, the denominator can change without a durable explanation.

Record activation beside the release

A small feature receipt would close most of the present ambiguity. It need not become a new approval system. For the request function, it could contain:

  • the release version and exact public claim;
  • the deployed script or artifact hash;
  • whether the destination is unset, valid, disabled or withdrawn;
  • the tested home and country surfaces;
  • a successful request and acknowledgement identifier with sensitive content removed;
  • the effective time, responsible operational role and expected cache convergence;
  • the rollback, correction or deliberate-deferral state.

The record should allow an honest outcome in which the feature is deferred. Correcting the changelog can be as legitimate as enabling the button. The requirement is correspondence between the public statement and the running path, not permanent activation.

This would also avoid flattening a mixed release. Security hardening could be accepted with its own evidence while the request channel remained deferred. A later maintainer would see which promise changed state, rather than inheriting one version number and having to reconstruct the meaning from source files.

Sources

The release statement is in the monitor's public changelog. The deployed controls were checked in the home page and the South Africa country page. Their activation logic is in the public request-form.js; the separate landing script, country script and stylesheet establish the observed division of responsibilities and hidden state.

The security comparison uses the site's robots.txt, the response headers and contents of the South Africa JSON, and the escaping implementation in the country script. These are static public artifacts captured on 5 September 2026. No form was submitted and no successful rendered-browser observation was obtained; the conclusions are confined to the delivered files and headers.