[REVIEW] dns-security: add zone-transfer and dynamic-update transaction gates

[briefsmith-lab]

Skill Being Reviewed

Skill name: dns-security
Skill path: skills/network/dns-security/

False Positive Analysis

Benign code that triggers a false positive:

// Internal split-horizon zone, served only to corp VPN clients.
view "internal" {
  match-clients { 10.20.0.0/16; 10.30.0.0/16; };
  recursion no;

  zone "corp.internal" {
    type master;
    file "/etc/bind/zones/db.corp.internal";
    allow-transfer { key "corp-secondary-tsig"; 10.20.5.12; };
    also-notify { 10.20.5.12; };
  };
};

Why this is a false positive:
The current severity table says unsigned authoritative zones for public-facing domains are High, but the workflow does not force the reviewer to classify whether a zone is public authoritative, internal-only, split-horizon, delegated private namespace, or lab/test. If the reviewer applies the DNSSEC signing checklist uniformly, an internal-only non-public zone can be over-prioritized as a public DNSSEC gap. The risk should be classified after zone exposure and trust-boundary evidence is collected.

Coverage Gaps

Missed variant 1:

zone "example.com" {
  type master;
  file "/etc/bind/zones/db.example.com";
  allow-transfer { any; };          // full AXFR available to the internet
  allow-query { any; };
};

Why it should be caught:
The skill references NIST SP 800-81 Section 3 and Section 6 in the framework table, but the main process does not include a dedicated zone-transfer review. Open AXFR leaks complete host inventories, internal naming patterns, mail infrastructure, VPN hostnames, and takeover targets. The review should require checking allow-transfer, secondary nameserver ACLs, TSIG usage, and external AXFR test evidence.

Missed variant 2:

zone "example.com" {
  type master;
  file "/etc/bind/zones/db.example.com";
  allow-update { any; };            // unauthenticated dynamic DNS update
};

Why it should be caught:
Unauthorized dynamic DNS updates are a direct integrity failure: an attacker may add or replace records, redirect traffic, or poison service discovery. The current DNSSEC section focuses on signed data integrity, but it does not separately require transaction controls for zone modification paths. DNSSEC can authenticate data after signing, but it does not by itself prove that update authorization is safe. The skill should require allow-update/update-policy review, TSIG/SIG(0) evidence, and rejection of unauthenticated updates.

Edge Cases

• Some organizations intentionally permit AXFR only to secondary nameservers or managed DNS provider IP ranges. That is acceptable when restricted by explicit ACLs and TSIG, but the review should record the allowed secondary identities and test from an unauthorized source.
• Hidden primary architectures often have one non-public master and several public secondaries. The public zone may be secure while the hidden primary is still exposed to broad transfer or update traffic from internal networks.
• Cloud DNS services may hide BIND-style directives, so the equivalent evidence should be provider IAM policy, managed secondary configuration, zone transfer settings, audit logs, and registrar/DNS provider change approval records.

Remediation Quality

• Fix resolves the vulnerability
• Fix doesn't introduce new security issues
• Fix doesn't break functionality
• Issues found: Add a DNS transaction-security step before final severity classification.

Suggested additions:

DNS-TXN-01: Classify each zone as public authoritative, internal-only, split-horizon, delegated private, or lab/test before applying public DNSSEC severity.
DNS-TXN-02: For each authoritative zone, verify AXFR/IXFR is disabled or restricted to named secondary servers using ACLs and TSIG.
DNS-TXN-03: Verify unauthorized AXFR from an untrusted network fails, and document the tested source.
DNS-TXN-04: Review dynamic update controls: reject allow-update { any; }, require update-policy or TSIG/SIG(0), and log all accepted updates.
DNS-TXN-05: For cloud DNS, map the same checks to provider IAM, managed secondary settings, audit logs, and change-approval workflow.

Comparison to Other Tools

Tool	Catches this?	Notes
dig / drill	Partial	Can test unauthorized AXFR externally, but does not review intended secondary ACLs or update policy.
DNSViz	No/Partial	Strong for DNSSEC chain and delegation health, but not for BIND transaction ACLs or internal dynamic update policy.
Cloud DNS provider checks	Partial	May expose zone transfer and IAM settings, but findings must be normalized across AWS Route 53, Cloud DNS, Azure DNS, and BIND/PowerDNS.
SIEM DNS logs	Partial	Can show successful transfers or updates if logged, but missing logs are themselves a review gap.

Overall Assessment

Strengths:
The skill is practical and well grounded: it covers DNSSEC, encrypted DNS transport, RPZ/protective DNS, DNS tunneling indicators, NRD blocking, and clear severity mapping.

Needs improvement:
It should add explicit zone-transfer and dynamic-update transaction gates. These are classic DNS integrity and reconnaissance risks from NIST SP 800-81, but they are currently only implied in the framework reference rather than enforced in the review process.

Priority recommendations:

1. Add a Step 2.5 or separate step for authoritative DNS transaction security: AXFR/IXFR, TSIG, secondary ACLs, NOTIFY, and dynamic update policy.
2. Require zone exposure classification before applying public-zone DNSSEC severity to avoid false positives on internal split-horizon zones.
3. Add provider-specific evidence mapping for managed DNS platforms where BIND directives are not visible.

Bounty Info

• I have read and agree to the CONTRIBUTING.md bounty terms
• Preferred payment method: PayPal