NEWRFC 10023 and the _for-sale TXT record: what it means for DNS security Sponsored by

NEWRFC 10023 and the _for-sale TXT record: what it means for DNS security

Zone Transfer Vulnerability

Critical DNS information disclosure weakness

Critical Security Issue

Information Disclosure

DNS Misconfiguration

Critical Security Risk

DNS zone transfer vulnerability allows attackers to download your entire DNS configuration, exposing all subdomains, internal systems, and network infrastructure details that should remain private.

Understanding Zone Transfer Attacks

DNS zone transfers (AXFR requests) are legitimate operations designed to synchronize DNS data between primary and secondary nameservers. However, when these transfers aren't properly restricted, they become a powerful reconnaissance tool for attackers.

When an attacker successfully performs an unauthorized zone transfer, they receive a complete inventory of your DNS infrastructure including all subdomains, IP addresses, mail servers, and other critical infrastructure details that would otherwise require extensive reconnaissance to discover.

What Attackers Can Discover

A successful zone transfer reveals sensitive information that attackers can use to plan targeted attacks against your organization's infrastructure.

With the reconnaissance risks clearly understood, implementing zone transfer restrictions becomes critical for protecting DNS infrastructure from unauthorized access. The following configurations provide comprehensive protection across DNS server platforms.

BIND DNS Server Security

Secure zone transfers in BIND (most common DNS server)

Configuration Steps

Implement comprehensive zone transfer security in BIND through precise access control lists and authentication mechanisms.

BIND's zone transfer security operates on a whitelist principle where only explicitly authorized servers can retrieve complete zone data. This configuration balances operational requirements for DNS redundancy with security needs to prevent reconnaissance attacks. The security model supports IP-based restrictions, TSIG authentication, and granular notification controls to ensure legitimate replication while blocking unauthorized access.

Basic Zone Transfer Restrictions

Configure zone-specific access controls in your named.conf file:

// BIND zone configuration with IP-based zone transfer restrictions
zone "example.com" IN {
    type master;                                     // Primary authoritative server role
    file "/etc/bind/zones/example.com.zone";        // Zone data file location (absolute path)
    
    allow-transfer {                                 // Whitelist of IPs allowed to request zone transfers
        192.168.1.2;                                // Secondary DNS server IP (backup/redundancy)
        192.168.1.3;                                // Another authorized server (monitoring/testing)
        localhost;                                  // Allow local admin zone transfers (dig @localhost)
        !192.168.1.99;                              // Explicitly deny this IP (compromised server)
    };
    
    // Zone transfer access control explanations:
    // - Only listed IP addresses can perform AXFR requests
    // - localhost allows local administrative transfers for testing
    // - Exclamation mark (!) creates explicit denials for specific IPs
    // - Unlisted IPs are automatically denied (default-deny policy)

IP-based restrictions provide the first line of defense against unauthorized zone transfers. The allow-transfer directive creates a strict whitelist where only specified servers can retrieve complete zone data.

Notification and Synchronization

Configure automatic zone change notifications for authorized secondary servers:

// Automated zone synchronization with security controls
zone "example.com" IN {
    also-notify { 192.168.1.2; 192.168.1.3; };     // Auto-notify these servers on zone changes
    notify yes;                                      // Enable automatic change notifications (SOA serial)
    notify-source 192.168.1.1;                      // Source IP for notifications (consistency)
    
    // Notification security benefits:
    // - also-notify ensures authorized secondaries receive immediate updates
    // - notify yes enables automatic SOA serial number change notifications
    // - notify-source provides consistent source IP for notification packets
    // - Prevents delays in DNS propagation across authorized server network
}

Notification controls ensure legitimate secondary servers stay synchronized while maintaining security restrictions. This prevents DNS propagation delays without compromising zone transfer security.

Additional Security Controls

Implement comprehensive zone-level security policies:

// Comprehensive zone-level security configuration
zone "example.com" IN {
    // Query and update security controls
    allow-query { any; };                           // Allow queries from anyone (public zone)
    allow-update { none; };                         // No dynamic updates (security)
    
    // Security rationale:
    // - allow-query permits normal DNS resolution from all clients
    // - allow-update prevents unauthorized dynamic DNS updates
    // - Zone transfers remain restricted by allow-transfer directive
    // - Queries (port 53 UDP/TCP) vs transfers (AXFR) have different permissions
}

Additional security controls separate query permissions from transfer permissions, allowing public DNS resolution while maintaining strict zone transfer restrictions.

TSIG Authentication (Advanced)

Implement cryptographic authentication for enhanced zone transfer security:

// TSIG (Transaction Signature) authentication for zone transfers
key "transfer-key" { 
    algorithm hmac-sha256; 
    secret "base64-encoded-shared-key-here"; 
};

zone "example.com" IN {
    allow-transfer { key "transfer-key"; };         // Require TSIG for transfers
    
    // TSIG authentication benefits:
    // - Cryptographic verification of transfer requests
    // - Shared secret authentication (not just IP-based)
    // - Protection against IP spoofing attacks
    // - Enhanced security for critical zones
    // - Both primary and secondary must have matching key
};

// Example TSIG key generation:
// dnssec-keygen -a HMAC-SHA256 -b 512 -n HOST transfer-key

TSIG authentication adds cryptographic security to zone transfers, protecting against IP spoofing and providing mutual authentication between primary and secondary servers.

Global Restrictions

Implement organization-wide security policies that establish secure defaults while allowing zone-specific overrides when necessary.

Global security options create a secure-by-default foundation for all zones managed by your BIND server. This approach implements defense-in-depth by establishing restrictive baseline policies that individual zones can selectively relax as needed. The configuration combines zone transfer restrictions with additional security hardening measures including information disclosure prevention, rate limiting, and network-level access controls.

Default-Deny Zone Transfer Policy

Establish organization-wide zone transfer restrictions as the security baseline:

// Global default-deny zone transfer policy (named.conf options section)
options {
    allow-transfer { none; };                       // Block all zone transfers by default (deny-by-default)
    notify no;                                      // Disable automatic notifications globally
    
    // Security benefits of global restrictions:
    // - deny-by-default prevents unauthorized transfers from misconfigured zones
    // - Global notify disable prevents information leakage through notifications
    // - Individual zones can override these settings when transfers are needed
    // - Reduces attack surface across entire DNS infrastructure
};

Global deny-by-default policies ensure that even misconfigured or forgotten zones cannot accidentally expose sensitive DNS information through unrestricted zone transfers.

Network-Level Security Controls

Implement network-level access controls and blacklisting for comprehensive protection:

// Network-level access controls and threat blocking
options {
    blackhole {                                     // Networks to completely ignore
        192.0.2.0/24;                              // TEST-NET-1 (RFC 5737 documentation range)
        198.51.100.0/24;                           // TEST-NET-2 (RFC 5737 documentation range)  
        203.0.113.0/24;                            // TEST-NET-3 (RFC 5737 documentation range)
        10.0.0.0/8 !10.0.1.0/24;                   // Block private range except trusted subnet
        // Add known malicious networks here based on threat intelligence
    };
    
    // Benefits of network blackholing:
    // - Completely drops packets from specified networks (no response)
    // - Reduces server load by ignoring traffic from known bad sources
    // - Can include threat intelligence feeds for dynamic protection
    // - Exclamation mark creates exceptions within blocked ranges
};

Network blackholing provides an additional security layer by completely ignoring traffic from known malicious or unwanted network ranges, reducing both security risks and server load.

Query and Recursion Controls

Configure global query policies that balance public DNS service with security:

// Global query and recursion security policies
options {
    allow-query { any; };                          // Allow queries from anyone (public DNS service)
    allow-recursion { 
        localhost;                                 // Local server can perform recursion
        192.168.1.0/24;                           // Trusted internal network
    };
    
    // Query vs recursion security model:
    // - allow-query: Who can ask about your authoritative zones (usually "any")
    // - allow-recursion: Who can use your server to resolve other domains (restrict!)
    // - Unrestricted recursion enables DNS amplification attacks
    // - Separate authoritative service from recursive resolver when possible
};

Query and recursion controls separate authoritative DNS service (answering for your zones) from recursive resolver service (looking up other domains), preventing DNS amplification abuse.

Information Disclosure Prevention

Hide system information that could assist attackers in reconnaissance:

// Information disclosure prevention and server hardening
options {
    version none;                                  // Hide BIND version from queries
    hostname none;                                 // Hide hostname from queries
    server-id none;                                // Hide server identifier
    
    // Rate limiting to prevent abuse and reconnaissance
    rate-limit {
        responses-per-second 20;                   // Max responses per client per second
        window 5;                                  // Rate calculation window (seconds)
        slip 2;                                    // Send truncated response every 2nd blocked query
        max-table-size 20000;                     // Maximum rate limit tracking entries
    };
    
    // Information hiding benefits:
    // - version hiding prevents version-specific exploit targeting
    // - hostname hiding reduces system information disclosure
    // - Rate limiting prevents DNS reconnaissance and DoS attacks
    // - slip parameter provides feedback to legitimate clients hitting limits
};

Information disclosure prevention reduces the attack surface by hiding system details while rate limiting protects against reconnaissance attempts and denial-of-service attacks.

Zone-Specific Override Example

Show how individual zones can override global restrictions when needed:

// Individual zones override global restrictions when transfers are needed
zone "public.example.com" {
    type master;
    file "/etc/bind/zones/public.example.com.zone";
    
    // Override global deny-by-default for this specific zone
    allow-transfer { 
        192.168.1.2;                              // Secondary server for this zone
        192.168.1.3;                              // Backup secondary server
    };
    notify yes;                                    // Override global notify disable
    also-notify { 192.168.1.2; 192.168.1.3; };   // Explicit notification targets
    
    // Zone-specific overrides provide:
    // - Selective transfer enabling for zones that need redundancy
    // - Granular control over each zone's security posture
    // - Flexibility within secure global defaults
    // - Clear documentation of exceptions to security policy
};

Zone-specific overrides allow individual zones to selectively relax global restrictions while maintaining the secure-by-default foundation for all other zones in your infrastructure.

Other DNS Servers

While BIND is widely used, other DNS platforms require different configuration approaches. These examples show how to secure zone transfers across popular DNS server software.

Microsoft DNS Server

Configure using DNS Manager:

• Right-click your zone → Properties
• Go to Zone Transfers tab
• Uncheck "Allow zone transfers"
• Or select "Only to servers listed on the Name Servers tab"

PowerDNS

Configure PowerDNS Authoritative Server with comprehensive zone transfer security using both configuration file settings and database-driven access controls.

PowerDNS implements zone transfer security through multiple complementary mechanisms: global configuration file settings, per-domain database metadata, and TSIG authentication support. This flexible architecture allows both simple IP-based restrictions and sophisticated per-zone access controls. The configuration supports both master and slave operational modes with granular security policies for each role.

Basic PowerDNS Zone Transfer Configuration

Configure fundamental zone transfer security in your pdns.conf file:

# PowerDNS Authoritative Server basic zone transfer security (pdns.conf)
allow-axfr-ips=192.168.1.2,192.168.1.3               # Comma-separated IPs allowed for AXFR requests
disable-axfr=yes                                      # Global AXFR disable (overridden by allow-axfr-ips)

# Configuration explanation:
# - allow-axfr-ips creates whitelist of authorized IP addresses
# - disable-axfr=yes provides deny-by-default security baseline
# - allow-axfr-ips overrides disable-axfr for specified addresses
# - Comma-separated format supports multiple authorized servers

PowerDNS zone transfer security operates on a deny-by-default principle with explicit allow-listing of authorized IP addresses. This ensures only specified servers can retrieve complete zone data.

Enhanced Security Configuration

Implement additional PowerDNS security hardening measures:

# PowerDNS security hardening and operational controls
master=yes                                            # Enable master (authoritative) mode
slave=no                                              # Disable slave mode if not needed
webserver=no                                          # Disable web interface (reduces attack surface)
guardian=yes                                          # Enable guardian process (auto-restart on crash)

# Security benefits of hardening settings:
# - master=yes enables authoritative DNS functionality
# - slave=no disables unnecessary slave/secondary functionality
# - webserver=no removes HTTP management interface attack vectors
# - guardian=yes provides automatic recovery from crashes or attacks

Security hardening reduces the attack surface by disabling unnecessary services and enabling protective mechanisms like automatic crash recovery.

Precise Network Access Controls

Configure precise network-level access controls using CIDR notation:

# Precise network access controls with CIDR notation
allow-axfr-ips=192.168.1.2/32,192.168.1.3/32        # Use CIDR notation for precision
only-notify=192.168.1.2,192.168.1.3                 # Only notify these IPs of zone changes
also-notify=192.168.1.2:5353                         # Notify on non-standard ports if needed

# Network precision benefits:
# - /32 CIDR ensures exact IP match (single host)
# - only-notify restricts zone change notifications
# - also-notify supports non-standard ports (security through obscurity)
# - Prevents network range abuse or IP spoofing attempts

CIDR notation provides precise network access control, ensuring that zone transfers are restricted to exact IP addresses rather than potentially vulnerable network ranges.

Database-Driven Access Control

Implement advanced per-domain access controls using PowerDNS database metadata:

# Advanced database-driven zone transfer access control
# PowerDNS supports per-domain AXFR policies via domainmetadata table

# Per-domain IP-based AXFR control
INSERT INTO domainmetadata (domain_id, kind, content) VALUES 
(1, 'ALLOW-AXFR-FROM', '192.168.1.2');               # Domain ID 1 allows AXFR from specific IP
(1, 'ALLOW-AXFR-FROM', '192.168.1.3');               # Multiple entries for multiple IPs
(2, 'ALLOW-AXFR-FROM', '192.168.2.0/24');            # Domain ID 2 allows entire subnet

# TSIG-based authentication for enhanced security
INSERT INTO domainmetadata (domain_id, kind, content) VALUES 
(1, 'TSIG-ALLOW-AXFR', 'transfer-key');              # Require TSIG key for domain 1
(2, 'TSIG-ALLOW-AXFR', 'domain2-key');               # Different key for domain 2

# Benefits of database-driven access control:
# - Per-domain granular access policies
# - Dynamic policy updates without server restart
# - TSIG authentication support for enhanced security
# - Scalable management for large zone inventories

Database-driven access control enables sophisticated per-domain policies with TSIG authentication support, providing enterprise-grade zone transfer security management.

NSD (Name Server Daemon)

Configure NSD with precise zone transfer controls using the minimalist yet secure nsd.conf syntax.

NSD (Name Server Daemon) implements zone transfer security through the provide-xfr directive, which creates explicit authorization for specific IP addresses to retrieve zone data. NSD's configuration philosophy emphasizes simplicity and security, requiring explicit authorization for each zone transfer relationship. The NOKEY parameter indicates IP-based authentication, while TSIG keys can be specified for enhanced security.

Basic NSD Zone Transfer Configuration

Configure zone-specific transfer authorization in your nsd.conf file:

# NSD zone configuration with IP-based zone transfer restrictions
zone:
    name: "example.com"
    zonefile: "example.com.zone"                    # Zone data file location
    
    # Zone transfer authorization (explicit whitelist)
    provide-xfr: 192.168.1.2 NOKEY                 # Allow AXFR from specific IP (no TSIG)
    provide-xfr: 192.168.1.3 NOKEY                 # Allow AXFR from another IP (no TSIG)
    
    # Configuration explanation:
    # - provide-xfr creates explicit transfer authorization
    # - NOKEY indicates IP-based authentication (no TSIG required)
    # - Only listed IPs can perform zone transfers
    # - Unlisted IPs are automatically denied (default-deny)

NSD's provide-xfr directive implements a strict whitelist approach where only explicitly authorized IP addresses can retrieve complete zone data, ensuring comprehensive zone transfer security.

TSIG Authentication Support

Enhanced zone transfer security using TSIG keys for cryptographic authentication:

# NSD zone transfer with TSIG authentication
key:
    name: "transfer-key"
    algorithm: hmac-sha256
    secret: "base64-encoded-shared-secret-here"

zone:
    name: "example.com"
    zonefile: "example.com.zone"
    
    # TSIG-authenticated zone transfers
    provide-xfr: 192.168.1.2 transfer-key          # Require TSIG key + IP match
    provide-xfr: 192.168.1.3 transfer-key          # Same key for multiple servers
    
    # TSIG authentication benefits:
    # - Cryptographic verification of transfer requests
    # - Protection against IP spoofing attacks
    # - Shared secret authentication between servers
    # - Enhanced security for sensitive zones

TSIG authentication adds cryptographic security to NSD zone transfers, requiring both IP address validation and shared secret verification for enhanced protection.

Testing and Verification

Verify your zone transfer restrictions are working properly

Manual Testing

Validate your zone transfer security configuration through comprehensive testing that verifies both authorized and unauthorized access attempts.

Testing zone transfer restrictions requires systematic validation from multiple perspectives: verifying that authorized servers can successfully retrieve zone data, confirming that unauthorized requests are properly denied, and ensuring that error responses don't leak sensitive information. This comprehensive testing approach validates both the security configuration and operational functionality.

Basic Zone Transfer Testing

Test zone transfer functionality using dig command-line tool:

# Basic zone transfer test from authorized location
dig @your-nameserver.com example.com AXFR
# Should return complete zone data if run from authorized IP
# AXFR query type requests full zone transfer
# Replace your-nameserver.com with your actual DNS server

# Expected success response includes:
# - SOA record (start of authority)
# - All A, AAAA, CNAME, MX records in the zone
# - Final SOA record (marking end of transfer)
# - Transfer successful message from dig

Successful zone transfer testing from authorized locations confirms that legitimate secondary servers can retrieve complete zone data for replication purposes.

Unauthorized Access Testing

Verify that unauthorized zone transfer requests are properly denied:

# Test zone transfer denial from unauthorized location
dig @your-nameserver.com example.com AXFR
# Should be denied if run from unauthorized IP
# Expected denial responses:
# - "Transfer failed" message
# - "REFUSED" status in dig output
# - No zone data returned

# Example of proper denial response:
# ;; Query time: 1 msec
# ;; SERVER: your-nameserver.com
# ;; WHEN: [timestamp]
# ;; XFR size: 0 records (messages 1, bytes 25)
# ;; MSG SIZE  rcvd: 25
# Status: REFUSED

Proper denial of unauthorized zone transfer requests confirms that your security configuration effectively blocks reconnaissance attempts while providing appropriate error responses.

Comprehensive Security Validation

Perform thorough testing across multiple scenarios and network locations:

# Comprehensive zone transfer security testing

# Test from different network locations
dig @your-nameserver.com example.com AXFR          # From current location
ssh user@remote-server "dig @your-nameserver.com example.com AXFR"  # From remote location

# Test with verbose output for detailed analysis
dig @your-nameserver.com example.com AXFR +trace +additional +authority
# +trace shows complete resolution path
# +additional includes additional section records
# +authority shows authoritative server responses

# Test TSIG authentication if configured
dig @your-nameserver.com -y transfer-key:base64-key example.com AXFR
# -y specifies TSIG key for authenticated transfer
# Should succeed only with correct key and authorized IP

# Automated testing script for multiple domains
for zone in example.com test.com prod.com; do
    echo "Testing $zone:"
    dig @your-nameserver.com $zone AXFR | head -5
done

Comprehensive testing validates zone transfer security across multiple domains, network locations, and authentication methods, ensuring robust protection against reconnaissance attacks.

Alternative Testing Methods

Additional tools for zone transfer validation using nslookup and monitoring approaches.

Using nslookup Command

Alternative zone transfer testing using the nslookup utility:

# nslookup interactive zone transfer test
nslookup
> server your-nameserver.com               # Set DNS server to query
> set type=AXFR                           # Set query type to zone transfer
> example.com                             # Request zone transfer for domain
> quit                                    # Exit nslookup

# Expected responses:
# - Success: Full zone listing with all records
# - Failure: "Query refused" or "Transfer failed" message
# - Timeout: No response (server may be blocking requests)

nslookup provides an alternative method for testing zone transfer restrictions with clear success/failure indicators.

Ongoing Security Monitoring

Implement continuous monitoring to detect unauthorized zone transfer attempts and maintain security posture.

Monitoring Recommendations

• Alert Configuration: Set up automated alerts for unexpected zone transfer requests from unauthorized IPs
• Regular Audits: Periodically review DNS server configurations to ensure zone transfer restrictions remain in place
• Log Analysis: Monitor DNS server access logs for AXFR request patterns and potential reconnaissance activities
• Change Management: Test zone transfer configurations after any DNS infrastructure changes or updates
• Security Validation: Include zone transfer testing in regular security assessments and penetration testing

Last updated: January 8, 2026