CVE-2026-12490: DNS Server Auth Bypass Vulnerability

CVE-2026-12490 Overview

CVE-2026-12490 is an access control vulnerability in NLnet Labs NSD (Name Server Daemon) affecting how the provide-xfr directive enforces client certificate authentication for zone transfers. When provide-xfr is configured with a tls-auth-name, a secondary server requesting a zone transfer should present a client certificate matching that name. However, the certificate check is skipped when requests arrive over TLS on the standard tls-port instead of the dedicated tls-auth-port, or over plain TCP, if other provide-xfr rule conditions match. The flaw is classified under [CWE-284] Improper Access Control.

Critical Impact
Unauthorized clients can pull DNS zone data without presenting the required client certificate, exposing internal zone contents that the administrator intended to restrict.

Affected Products

NLnet Labs NSD authoritative DNS server
Deployments using provide-xfr with tls-auth-name for zone transfer authentication
Configurations exposing both tls-port and tls-auth-port listeners

Discovery Timeline

2026-06-25 - CVE-2026-12490 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-12490

Vulnerability Analysis

NSD supports authenticated zone transfers using TLS client certificates. Administrators bind a tls-auth-name to a provide-xfr rule so that only secondaries presenting a certificate matching that name can request the zone. The expected enforcement path requires the client to connect to the dedicated tls-auth-port where mutual TLS authentication occurs.

The vulnerability stems from inconsistent enforcement across listener ports. When a secondary connects to the regular tls-port over TLS, NSD does not require the client certificate even though the matching provide-xfr rule declares a tls-auth-name. The same bypass occurs when the request arrives over plain TCP on the standard DNS port. Any client meeting the remaining match conditions of the provide-xfr rule can retrieve the zone.

Root Cause

The provide-xfr rule evaluator treats tls-auth-name as a constraint that only activates on the tls-auth-port listener. The check is not propagated to other listener types, leaving the access control decision dependent on the port the client chooses rather than the rule the administrator wrote.

Attack Vector

An attacker on the network sends an AXFR or IXFR request to the NSD instance over the standard TLS port or TCP port. Because NSD skips the client certificate requirement on those listeners, the server processes the transfer against the provide-xfr rule using only the remaining match criteria. The attacker receives the full zone contents, exposing internal hostnames, infrastructure layout, and any records that were intended to be restricted to authenticated secondaries.

No exploitation code is required beyond a standard DNS client capable of issuing zone transfer queries. See the NLnet Labs CVE-2026-12490 advisory for vendor technical details.

Detection Methods for CVE-2026-12490

Indicators of Compromise

Successful AXFR or IXFR responses logged on the standard tls-port or TCP port from source addresses that do not correspond to authorized secondary nameservers.
NSD transfer logs showing zone retrievals without an associated client certificate subject when a tls-auth-name is configured for that zone.
Outbound DNS zone data observed in network captures destined to unexpected hosts following AXFR requests.

Detection Strategies

Audit NSD configuration for every provide-xfr statement that references a tls-auth-name and confirm only the tls-auth-port is reachable from untrusted networks.
Correlate zone transfer events with the listener port and TLS session metadata to identify transfers that bypassed certificate validation.
Run periodic AXFR probes from an unauthenticated test host against each listener port to verify enforcement.

Monitoring Recommendations

Forward NSD query and transfer logs to a centralized SIEM and alert on AXFR or IXFR queries from non-secondary source addresses.
Monitor firewall and network telemetry for connections to the standard DNS TCP and TLS ports originating outside the secondary nameserver subnet.
Track configuration drift on provide-xfr rules and TLS port bindings using configuration management tooling.

How to Mitigate CVE-2026-12490

Immediate Actions Required

Apply the NSD update from NLnet Labs that enforces tls-auth-name checks across all listener types as soon as it is available for your distribution.
Restrict the standard tls-port and TCP DNS port to permit AXFR and IXFR only from the IP addresses of authorized secondary nameservers using host or network ACLs.
Review zone transfer logs for prior unauthorized retrievals and rotate any sensitive records that may have been exposed.

Patch Information

Refer to the NLnet Labs CVE-2026-12490 advisory for the fixed NSD release and patch details. The fix enforces the tls-auth-name client certificate requirement regardless of which listener accepts the transfer request.

Workarounds

Block the standard tls-port and TCP DNS port at the firewall for any source that is not an explicitly trusted secondary nameserver.
Bind NSD only to the tls-auth-port for any zone where tls-auth-name is required, and remove other listener exposure for those zones.
Add IP-based provide-xfr constraints alongside tls-auth-name so that source address filtering acts as a compensating control until the patch is deployed.

bash

# Configuration example - restrict provide-xfr with source IP as a compensating control
# /etc/nsd/nsd.conf
server:
    tls-port: 853
    tls-auth-port: 854

pattern:
    name: "secured-xfr"
    provide-xfr: 192.0.2.10 secondary-cert tls-auth-name "secondary.example.net"
    # Until patched, also enforce at the firewall:
    #   allow TCP/853 and TCP/53 only from 192.0.2.10