[REVIEW] dns-security: add AXFR, open recursion, and dynamic update hardening

[dannielmv]

Skill Being Reviewed

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

False Positive Analysis

Benign code that can be misclassified as unsafe if reviewed without context:

key "xfr-secondary" {
    algorithm hmac-sha256;
    secret "[redacted]";
};

acl "authorized-secondaries" {
    192.0.2.53;
    2001:db8::53;
};

zone "example.com" {
    type primary;
    file "/etc/bind/zones/example.com.signed";
    allow-transfer { key "xfr-secondary"; authorized-secondaries; };
    update-policy { grant ddns-updater zonesub ANY; };
};

Why this is a false positive:

Zone transfers and dynamic updates are not automatically findings. They are expected for secondary DNS, DNS provider migration, hidden-primary patterns, and controlled DDNS. The risk depends on evidence that transfers are restricted to authorized secondaries, protected with TSIG or equivalent provider IAM, and not reachable from arbitrary internet clients. A review that only greps allow-transfer or update-policy can over-report legitimate DNS operations.

Coverage Gaps

Missed variant 1: public AXFR exposes the full authoritative zone

zone "example.com" {
    type primary;
    file "/etc/bind/zones/example.com";
    allow-transfer { any; };
};

Why it should be caught:

The skill references NIST SP 800-81 Rev 2 Section 6 for securing DNS infrastructure, including TSIG and ACLs for zone transfers, but the process does not include an explicit AXFR/IXFR review step. Public zone transfers can disclose internal hostnames, service names, stale subdomains, delegated environments, and security-relevant records even when DNSSEC, RPZ, and DoH/DoT are configured correctly.

Missed variant 2: authoritative server also allows open recursion

options {
    recursion yes;
    allow-recursion { any; };
};

Why it should be caught:

Open recursion exposes infrastructure to abuse, cache poisoning surface, and reflection/amplification. The current skill separates authoritative and recursive categories during discovery, but it does not require a check that public authoritative servers have recursion disabled or that recursive resolvers restrict clients to trusted networks.

Missed variant 3: DNS dynamic updates lack TSIG/provider-IAM guardrails

zone "example.com" {
    type primary;
    allow-update { any; };
};

Why it should be caught:

Unauthorized zone data modification is one of the DNS threat classes called out in the skill context. Dynamic update paths (allow-update, update-policy, RFC 2136 clients, Terraform/cloud DNS service accounts) should be reviewed for TSIG keys, source restrictions, scoped IAM, audit logs, and rotation. The current process focuses on DNSSEC validation and DNS filtering, but DNSSEC does not prevent an authorized-or-misconfigured control plane from publishing malicious records.

Edge Cases

• Hidden-primary architectures may intentionally expose AXFR only to provider-operated secondaries; the finding should require evidence from ACLs, TSIG, provider IAM, and external transfer tests before rating severity.
• Some managed DNS providers do not expose BIND-style allow-transfer; reviewers should check provider-specific zone transfer settings, IAM, audit logs, and DNSSEC signing roles instead.
• Split-horizon DNS may have different transfer/update policies for internal and external views. Each view needs separate evidence.
• DNSSEC-signed zones can still be compromised through insecure dynamic update credentials or overbroad cloud DNS service accounts; signed malicious records will validate.
• Rate limiting (RRL or provider equivalent) should be evaluated separately from DNSSEC and RPZ because it addresses reflection/amplification and denial-of-service behavior.

Remediation Quality

• Fix resolves the vulnerability
• Fix doesn't introduce new security issues
• Fix doesn't break functionality
• Issues found: Add a DNS infrastructure hardening step covering AXFR/IXFR exposure, open recursion, dynamic update authorization, TSIG/provider-IAM controls, version disclosure, and response rate limiting. Add output fields so reviewers record whether each authoritative and recursive server is externally reachable, transfer-capable, recursion-capable, update-capable, and rate-limited.

Comparison to Other Tools

Tool	Catches this?	Notes
dig AXFR / delv	Partial	Can prove transfer exposure for a specific zone/server, but does not explain intended secondary topology or provider IAM.
Nmap DNS NSE scripts	Partial	Can flag open recursion, AXFR, and version.bind, but still needs configuration review to avoid false positives.
NIST SP 800-81 Rev 2	Yes	Section 6 covers infrastructure hardening such as restricting zone transfers and DNS transaction security.
CIS Benchmarks / provider checks	Partial	Managed DNS providers expose equivalent settings through IAM, zone transfer toggles, audit logs, and DNSSEC controls.

Overall Assessment

Strengths:

• Strong coverage of DNSSEC, DoH/DoT, RPZ/protective DNS, DNS tunneling indicators, and output formatting.
• Good separation between authoritative and recursive DNS during discovery.
• The common pitfalls already mention DS chain validation and TCP/53 visibility.

Needs improvement:

• Add an explicit NIST Section 6 infrastructure-hardening review step.
• Require AXFR/IXFR, recursion, and dynamic update evidence for every discovered DNS server or managed zone.
• Distinguish legitimate secondary DNS and DDNS from public transfer/update exposure.
• Add rate limiting and version disclosure checks as DNS infrastructure findings, not just DNSSEC/protective-DNS observations.

Priority recommendations:

1. Add a new process step for authoritative/recursive infrastructure hardening: allow-transfer, allow-recursion, allow-update, update-policy, TSIG keys, provider IAM, RRL, and version disclosure.
2. Add severity guidance: public AXFR or unauthenticated dynamic update should be High/Critical depending on exposure; open recursion on internet-facing resolvers should be High; missing RRL/version hiding should be Medium/Low based on context.
3. Extend the output template with per-server fields for transfer policy, recursion policy, update policy, TSIG/provider IAM, external reachability, and rate limiting.

Bounty Info

• I have read and agree to the CONTRIBUTING.md bounty terms
• Preferred payment method: To be provided privately after acceptance

[JamesJi79]

Review: dns-security - Add AXFR, Open Recursion, and Dynamic Update Hardening

Issue: #169
Skill: /private/tmp/SecuritySkills/skills/network/dns-security/SKILL.md
Current Version: 1.0.0
Reviewer: Hermes Agent
Date: 2026-06-03

---

Summary

This review evaluates whether the dns-security skill adequately covers three critical DNS hardening topics: Zone Transfer (AXFR) security, open recursion prevention, and dynamic update protection. These map to NIST SP 800-81 Rev 2 Section 3 (Securing DNS Transactions) and Section 6 (Securing DNS Infrastructure).

Verdict: GAP FOUND -- The current skill references these topics in the framework reference table and common pitfalls but has no dedicated process step to audit, detect, or remediate any of the three. All three need to be added.

---

Gap Analysis

1. AXFR / Zone Transfer Hardening

Current coverage:

• Line 362: Framework reference table mentions "TSIG for zone transfers" under NIST SP 800-81 Rev 2 Section 3.
• Line 365: Framework reference mentions "Restricting zone transfers" under Section 6.
• Line 385: Common Pitfall Enhance all 45 skills per 7-rule audit evaluation #4 mentions "DNS over TCP... required for zone transfers."

What's missing:

• No process step to check allow-transfer directives in named.conf / BIND configs.
• No detection of zones configured with allow-transfer { any; } or missing allow-transfer entirely.
• No verification of TSIG key configuration for authenticated zone transfers.
• No checks for primary/secondary server TSIG relationship.
• No checks for cloud DNS (Route53, Cloud DNS) zone transfer restrictions.
• No finding classification for open zone transfers.

Required additions: A new Step 6 (or a substep under Step 2) dedicated to zone transfer security, covering:

• allow-transfer ACL verification in BIND/named
• TSIG key presence and usage for inter-nameserver transfers
• Detection of zones allowing unrestricted AXFR
• Cloud provider zone transfer settings (Route53, Cloud DNS)
• Finding classification: unrestricted AXFR = High; missing TSIG = Medium

2. Open Recursion Detection and Hardening

Current coverage:

• Line 91: Discovery step mentions "Recursive resolvers: Unbound, BIND (recursion enabled)" -- but only as a categorization, not as a security check.
• Line 362: Framework reference mentions "ACLs on recursive queries" under Section 3.

What's missing:

• No process step to check allow-recursion or allow-query-cache ACLs.
• No detection of open resolvers (recursion allowed for any; or 0.0.0.0/0).
• No verification of recursion restrictions in Unbound (access-control view).
• No testing methodology for detecting open resolvers (e.g., dig +recursion desired from external IP).
• No mention of the DNS amplification DDoS attack vector that open recursion enables.
• No finding classification for open recursion.

Required additions: A new Step (or substep) covering:

• allow-recursion / allow-query-cache ACL checks in BIND
• access-control view restrictions in Unbound
• Testing for open resolver status
• Restricting recursion to trusted internal networks only
• Finding classification: open recursion = High (due to amplification DDoS risk)

3. Dynamic Update Hardening

Current coverage:

• No mention of allow-update, update-policy, or dynamic update security anywhere in the skill.

What's missing:

• No process step to check allow-update ACLs.
• No verification of update-policy (TSIG-authenticated, fine-grained update permissions).
• No checks for zones allowing unrestricted updates (allow-update { any; }).
• No TSIG key verification for authenticated updates.
• No mention of NIST SP 800-81 Rev 2 Section 3 guidance on securing dynamic updates.
• No finding classification for insecure dynamic update configuration.

Required additions: A new Step (or substep) covering:

• allow-update ACL verification
• update-policy configuration review (grant/deny rules with TSIG keys)
• Detection of zones permitting unauthorized dynamic updates
• TSIG key management for authenticated updates
• Finding classification: unrestricted dynamic updates = Critical; missing TSIG authentication = High

---

Proposed Structural Changes

Option A: Add a new "Step 7: DNS Transaction Security" section

Insert between existing Step 6 (Domain Categorization) and the Findings Classification section:

### Step 7: DNS Transaction Security (NIST SP 800-81 Rev 2, Section 3)

#### 7.1 Zone Transfer (AXFR) Restrictions

For each authoritative zone, verify:

- **allow-transfer is restricted:** Only authorized secondary nameservers should be permitted to initiate zone transfers.
  - BIND: `allow-transfer { 192.0.2.2; 2001:db8::2; };`
  - BAD: `allow-transfer { any; };` or missing directive (defaults to any)
- **TSIG authentication:** Zone transfers between primary and secondary should use TSIG for authenticity.
  - Verify `key` and `server` statements with TSIG keys.
  - Verify that both primary and secondary have matching key definitions.
- **Cloud DNS:** Route53, Cloud DNS managed zones restrict transfers by default, but verify IAM policies control zone access.

| File/Directive | Check | Secure | Insecure |
|---------------|-------|--------|----------|
| named.conf / allow-transfer | ACL scope | Specific IPs or TSIG key name | any; or missing |
| named.conf / also-notify | Notification list | Specific secondaries | Global notification |

**Patterns to search:**

allow-transfer { any; };
allow-transfer { 0.0.0.0/0; };
// Missing allow-transfer entirely (BIND defaults to any)

**Finding classification:** Unrestricted zone transfers (AXFR to any) are **High**. Missing TSIG authentication for zone transfers between authorized nameservers is **Medium**.

#### 7.2 Open Recursion Prevention

For each recursive resolver, verify:

- **Recursion is restricted to authorized clients:** Open resolvers are a primary vector for DNS amplification DDoS attacks.
  - BIND: `allow-recursion { 10.0.0.0/8; 192.168.0.0/16; };`
  - BAD: `allow-recursion { any; };` or recursion enabled without ACL
  - Unbound: `access-control: 10.0.0.0/8 allow` (not `allow_snoop`)
- **Split configuration:** Authoritative-only nameservers should have recursion disabled entirely.
  - BIND: `recursion no;`
- **External testing:** Verify that external hosts receive REFUSED (not NOERROR/NXDOMAIN) for recursive queries.
  - Test: `dig +recurse @<resolver-ip> example.com` from outside the trusted net

**Patterns to search:**

recursion yes;
allow-recursion { any; };
allow-query-cache { any; };
// Missing allow-recursion with recursion enabled

**Finding classification:** Open recursion (allowing recursive queries from any source) is **High**. Authoritative-only servers with recursion enabled is **Medium**.

#### 7.3 Dynamic Update Restrictions

For each authoritative zone, verify:

- **allow-update is strictly controlled:** Dynamic updates allow adding, removing, or modifying DNS records without manual zone file editing.
  - BIND: `allow-update { key "update-key"; };` or `update-policy { grant ... };`
  - BAD: `allow-update { any; };` allows anyone to modify zone data
- **update-policy is preferred** over allow-update for fine-grained, TSIG-authenticated control.
  - `update-policy { grant "dhcp-server" zonesub ANY; };`
- **TSIG keys** are used for authenticating update requests.
- **No unrestricted localhost updates:** Even `allow-update { 127.0.0.1; };` should be audited.

**Patterns to search:**

allow-update { any; };
allow-update { 0.0.0.0/0; };
// Missing allow-update (defaults to none -- check if intended)
update-policy { grant * * *; }; // Overly permissive policy

**Finding classification:** Unrestricted dynamic updates (`allow-update { any; }`) are **Critical**. Dynamic updates without TSIG authentication are **High**. Overly permissive `update-policy` rules are **Medium**.

Option B: Integrate into existing Step 2 (DNSSEC Deployment Review)

This could work for AXFR since it's authoritative-server-focused, but open recursion and dynamic updates are distinct enough to warrant their own step. Option A is recommended.

---

Additional Recommendations

Update the Framework Reference Table

The NIST SP 800-81 Rev 2 Section 3 reference is already in the table (good), but consider adding detail for Section 6 to cover all three topics:

Section	Topic	Key Requirements
3	Securing DNS Transactions	TSIG for zone transfers, ACLs on recursive queries, TSIG for dynamic updates
6	Securing DNS Infrastructure	Restricting zone transfers, hiding version strings, rate limiting, disabling recursion on auth-only servers

Update Common Pitfalls

Add a new pitfall:

5. **Allowing unrestricted zone transfers or dynamic updates.** Zone transfers (AXFR) expose the entire DNS zone to an attacker, enabling reconnaissance. Dynamic updates without TSIG authentication allow unauthorized record modification. Both are frequently overlooked in initial DNS deployments. Always verify allow-transfer, allow-recursion, and allow-update ACLs are scoped to the minimum necessary set of IP addresses or TSIG keys.

Update Findings Classification Table

Add entries for the new findings:

Severity	Definition
Critical	Unrestricted dynamic updates (allow-update { any; }); broken DNSSEC chain of trust
High	Open recursion (recursion allowed from any source); unrestricted zone transfers (AXFR to any); DNSSEC validation disabled

Update Output Format

Expand the assessment report template to include new tables:

### DNS Transaction Security
| Zone | allow-transfer | TSIG for AXFR | allow-recursion | allow-update | Status |
|------|---------------|---------------|----------------|-------------|--------|
| example.com | 192.0.2.0/24 | Yes/No | Restricted/Open | Key-only | Pass/Fail |

---

Implementation Impact

Aspect	Details
Lines added	~150-200 lines (new Step 7 with 3 subsections)
Tags	No change needed (existing tags cover this adequately)
Frameworks	No change needed (NIST SP 800-81 Rev 2 already listed)
Time estimate	Should increase from "20-40min" to "30-60min" to account for the additional checks
Allowed tools	No change needed (Read, Grep, Glob sufficient)
Version bump	Recommend 1.1.0 (feature addition)
Prompt injection hardening	No change needed (existing guard covers config file safety)

---

Conclusion

The dns-security skill v1.0.0 has solid coverage of DNSSEC, encrypted DNS transport, RPZ/protective DNS, and exfiltration detection. However, it has a substantial gap in NIST SP 800-81 Rev 2 Section 3 coverage regarding DNS transaction security.

All three proposed topics -- AXFR hardening, open recursion prevention, and dynamic update protection -- are:

1. Directly mapped to the frameworks already declared in the skill metadata
2. Non-overlapping with existing content (no duplication risk)
3. High-severity issues when misconfigured (amplification DDoS, data exfiltration via AXFR, zone data compromise via dynamic updates)
4. Common real-world findings in DNS security assessments

Recommendation: Accept and implement with Option A (new Step 7 as a three-part section). Consider bumping version to 1.1.0 and updating the time estimate to "30-60min".

---

End of review.

[modelsbridgeaicom-ship-it]

Submitted implementation PR: #964

Bounty requested: Improver moderate / if accepted.

Summary:

• Added Step 7 DNS Transaction Security for AXFR/IXFR restrictions, open recursion prevention, and dynamic update hardening.
• Added search patterns and evidence tables for allow-transfer, TSIG, allow-recursion, allow-query-cache, allow-update, update-policy, broad ACLs, and external validation.
• Added severity guidance for unrestricted dynamic updates, open recursion, unrestricted zone transfer, missing TSIG, and broad update-policy grants.
• Added DNS Transaction Security output matrix and updated NIST mapping/common pitfalls/references.
• Replaced the stale Rev 2 PDF link with current NIST source references including Rev 3 superseding page.

Validation performed:

• git diff --check
• required-string assertions
• markdown fence balance check
• official NIST/RFC/CIS source URLs returned HTTP 200