DNS Server Dynamic Update Record Injection

Tenable plugin 35372 is not a software bug with a vendor patch; it is a live misconfiguration check. The scanner verified that the authoritative DNS server accepted an unauthenticated RFC 2136 dynamic update and allowed insertion of a record into a zone. In practice, that means any affected DNS zone on any server version is vulnerable as configured: BIND zones with permissive allow-update, Windows DNS zones set to nonsecure and secure updates, or any other authoritative implementation that accepts unsigned updates from arbitrary clients.

The original MEDIUM label undersells the operational risk. This is direct integrity compromise of the naming system, and DNS is upstream of web, mail, certificate issuance, service discovery, and AD-adjacent trust decisions. I am upgrading it to HIGH because exploitation is low-friction and unauthenticated once the attacker can reach the authoritative server; I am stopping short of CRITICAL because this is usually an internal-reachability problem, not Internet-scale wormable RCE, and modern defaults on major platforms are safer than the misconfig Tenable found.

Why this verdict

• Up from vendor MEDIUM: Tenable's 5.8 score models this as low-grade integrity impact, but in reality DNS is a trust root for web, mail, service routing, and certificate validation.
• Low attacker friction once reachable: the attacker needs only unauthenticated network access to port 53 and a standard tool like nsupdate; no creds, no user interaction, no exploit dev.
• But this is usually post-initial-access or limited-reach: many affected servers are internal AD/BIND authorities, which means the requirement often implies the attacker is already on-net or on a permitted segment.
• Population is narrow, impact is not: modern defaults are safer and the 2024 Internet-scale study found a small vulnerable fraction, but the specific hosts that *do* accept unsigned updates are dangerously exposed.
• No evidence-driven emergency override: there is no KEV/CVE linkage or verified active campaign forcing an 'immediate within hours' posture.

Why not higher?

I am not calling this CRITICAL because the main brake is exposure scope. In many enterprises, authoritative update paths are internal-only or limited to DHCP/DC infrastructure, which makes this more of a high-consequence reachable misconfiguration than a broadly reachable Internet kill chain starter. There is also no current KEV signal or widespread exploitation evidence tied to this exact Tenable item.

Why not lower?

I am not leaving this at MEDIUM because the scanner already proved the dangerous condition exists. This is not a soft hardening recommendation like 'tighten ciphers'; it is a direct unauthenticated modification path into your DNS data, and attackers can use it to redirect traffic, intercept mail, or mint shadow infrastructure with almost no tooling cost.

1. Set Windows zones to Secure only — For AD-integrated Microsoft DNS zones, switch any affected zone from Nonsecure and secure to Secure only and complete this within 30 days. This removes anonymous update capability while preserving legitimate Kerberos-backed dynamic registration.
2. Replace IP-based update trust with TSIG or update-policy — On BIND and similar servers, move away from permissive allow-update and use TSIG/SIG(0) or narrowly scoped update-policy rules within 30 days. IP-only trust is brittle and UDP source spoofing makes it a weak boundary.
3. Disable dynamic updates where not required — If a zone does not genuinely need RFC 2136, turn it off within 30 days. The cleanest control is removing the write surface entirely rather than trying to monitor bad writes forever.
4. Restrict who can reach authoritative update targets — Limit UDP/TCP 53 access to the exact DHCP servers, domain controllers, or management hosts that need it, and deploy that network control within 30 days. This does not replace secure updates, but it sharply cuts the reachable attacker population.
5. Turn on DNS update auditing and diff monitoring — Enable DNS server audit/debug logs and compare zone contents against an approved baseline within 30 days. You want evidence of unexpected UPDATE activity and ownership anomalies before the attacker quietly converts this into mail or web redirection.

Run this from an auditor workstation or jump host that can reach the target authoritative DNS server, not from the DNS server itself. Invoke it as ./check-ddns.sh example.com 192.0.2.53; it needs nsupdate and dig, no local admin privileges, but it will briefly add and then remove a test TXT record if the server is vulnerable.

#!/usr/bin/env bash
# check-ddns.sh
# Active test for unauthenticated RFC 2136 dynamic updates.
# Usage: ./check-ddns.sh <zone> <dns_server>
# Example: ./check-ddns.sh example.com 192.0.2.53
# Exit codes:
#   0 = PATCHED (or update refused)
#   1 = VULNERABLE
#   2 = UNKNOWN (tooling/network/problem determining state)

set -u

ZONE="${1:-}"
SERVER="${2:-}"

if [[ -z "$ZONE" || -z "$SERVER" ]]; then
  echo "UNKNOWN: usage: $0 <zone> <dns_server>"
  exit 2
fi

if ! command -v nsupdate >/dev/null 2>&1; then
  echo "UNKNOWN: nsupdate not found"
  exit 2
fi

if ! command -v dig >/dev/null 2>&1; then
  echo "UNKNOWN: dig not found"
  exit 2
fi

ZONE="${ZONE%.}"
STAMP="$(date +%s)"
LABEL="_noisgate-${STAMP}-$$"
FQDN="${LABEL}.${ZONE}."
VALUE="noisgate-probe-${STAMP}"
TMP_ADD="$(mktemp)"
TMP_DEL="$(mktemp)"
cleanup() {
  rm -f "$TMP_ADD" "$TMP_DEL"
}
trap cleanup EXIT

cat > "$TMP_ADD" <<EOF
server ${SERVER}
zone ${ZONE}
update add ${FQDN} 60 TXT \"${VALUE}\"
send
EOF

ADD_OUT="$(nsupdate -v "$TMP_ADD" 2>&1 || true)"

# Give the authoritative server a moment to commit/replicate locally.
sleep 2

DIG_OUT="$(dig +time=3 +tries=1 +short @${SERVER} ${FQDN} TXT 2>/dev/null || true)"

if printf '%s' "$DIG_OUT" | grep -Fq "${VALUE}"; then
  cat > "$TMP_DEL" <<EOF
server ${SERVER}
zone ${ZONE}
update delete ${FQDN} TXT
send
EOF
  nsupdate -v "$TMP_DEL" >/dev/null 2>&1 || true
  echo "VULNERABLE"
  exit 1
fi

if printf '%s' "$ADD_OUT" | grep -Eiq 'connection refused|timed out|no servers could be reached|network is unreachable|temporary failure'; then
  echo "UNKNOWN"
  exit 2
fi

# If the server did not publish the inserted record, treat refusal/non-acceptance as patched.
# Common safe responses include REFUSED, NOTAUTH, NOTZONE, or silent non-acceptance.
echo "PATCHED"
exit 0

Sources

1. Tenable Plugin 35372
2. Tenable IOE: Unsecure Dynamic DNS Zone Updates Allowed
3. Microsoft Learn: Dynamic DNS Update in Windows and Windows Server
4. IETF RFC 2136: Dynamic Updates in the Domain Name System
5. BIND 9 documentation: Advanced Configurations / Dynamic Update
6. Nosyk et al. 2024: Don't Get Hijacked
7. NetSPI: Exploiting Active Directory-Integrated DNS
8. CISA Known Exploited Vulnerabilities Catalog