Summary

  • NSD 4.15.2, released September 2, includes a fix that checks the client-certificate name together with the address and TSIG conditions of the same access-rule item.
  • The motivating report describes a valid transfer refused after a second certificate identity was configured. Upstream tests now exercise two legitimate identities, but do not reproduce every condition of that reported setup.

The first certificate matched. The second did not. That ought to be an unremarkable result when two different secondary servers have different identities. In the NSD test reported on July 24, it was enough to stop a zone transfer.

The public report describes NSD 4.14.0 from EPEL on RHEL 9.8, serving a primary zone to two non-NSD secondaries. Each secondary had its own certificate name and its own address in a transfer-access rule; the two rules used a shared TSIG key. Logs showed a successful TLS client handshake, accepted TSIG authentication and a matching first certificate name. A mismatch against the other name then preceded the refusal. With only one rule present, the transfer worked.

This was a reported test configuration, not evidence of an industry-wide outage. Its private addresses and nonstandard ports should not be mistaken for a public deployment map. On August 28, a maintainer said the issue had been reproduced and fixed. The September 2 release announcement explicitly includes the same-rule correction; the download page listed 4.15.2 as current when checked on September 8.

Matching an alternative, not every identity

The implementation change puts address matching, TSIG-key matching and certificate-name matching into the evaluation of the same access-rule item. The former separate certificate-name loop could reject the request because another configured name differed.

The correction does not make a wrong certificate name acceptable. It makes that name a nonmatch for the rule being considered, instead of allowing an unrelated identity to veto another valid match. Explicit blocking rules still matter; this is not a claim that every aspect of NSD access control has become a simple “any match wins” policy.

That distinction matters during certificate changes or the addition of a secondary. A longer list of legitimate identities should express additional intended alternatives. It should not accidentally demand that one client satisfy all their names. The resulting operational risk is not visible from a green TLS-handshake indicator alone: the channel can exist while the requested zone data never arrives.

The test is useful because its limits are visible

The regression change adds a second certificate identity and an access row for it. The complete release-pinned test checks that both legitimate certificate cases return a marker from the transferred zone. It also retains rejection checks for a wrong name, an unknown certificate authority and requests without a client certificate.

The configuration behind those assertions is not identical to the original report. Its two certificate rows accept any IPv4 source address and use NOKEY; the reporter used distinct addresses and a shared TSIG key. The test therefore demonstrates the intended multiple-certificate assertion, not exhaustive coverage of every address, key and identity combination. This article inspected the source and assertions; it did not run NSD or independently reproduce the failure.

A separate TSIG-authorised rule in the test permits transfers over ordinary TLS and TCP. That is a configured alternative, not proof of a new bypass. RFC 9103 distinguishes authentication from confidentiality: TSIG does not itself encrypt zone contents. Whether such an alternative is appropriate depends on the operator’s explicit policy and the protection required across the transfer group.

The same-row fix also should not inherit the label of an earlier vulnerability. NLnet Labs’ security advisories describe a distinct June client-certificate bypass, CVE-2026-12490, fixed in 4.14.3. The September correction examined here concerns the multiple-identity refusal. The reviewed evidence establishes neither a new exploit nor a complete affected-version range, customer count or post-release recovery report from the original reporter.

The narrow lesson fits Lu Heng’s argument for precise, locally verifiable security invariants. Applied here, that means saying which complete rule should permit a transfer and which should not, without silently relaxing identity checks. This is an editorial application, not an endorsement of NSD attributed to Lu Heng.