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

Private IP Resolution

DNS rebinding vulnerability through private network exposure

Critical Security Issue

DNS Rebinding

Private Network Access

Critical Security Risk

Your domain resolves to private IP addresses, creating potential for DNS rebinding attacks. This allows malicious websites to bypass same-origin policy and access internal network resources that should be protected from external access.

Understanding Private IP Resolution

Private IP resolution occurs when a public domain name resolves to private IP address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). This creates a serious security vulnerability known as DNS rebinding, where attackers can use malicious websites to bypass browser security protections and access internal network services.

The vulnerability exploits browser same-origin policy limitations, allowing attackers to circumvent network firewalls and access internal devices, services, and administrative interfaces that should remain isolated from the public internet.

Private IP Address Ranges:

10.0.0.0/8 (10.0.0.0 - 10.255.255.255)
172.16.0.0/12 (172.16.0.0 - 172.31.255.255)
192.168.0.0/16 (192.168.0.0 - 192.168.255.255)

Comprehensive Private IP Resolution Remediation

Fixing private IP resolution requires a systematic approach to identify all instances where your domain resolves to internal network addresses, understand the security implications, and implement proper public IP addressing. This process is critical for preventing DNS rebinding attacks that could compromise your internal infrastructure.

Step 1: Comprehensive Private IP Discovery

The first step requires systematically checking all DNS record types that could contain IP addresses. Private IPs can hide in unexpected places beyond just A records, including mail server configurations, nameserver definitions, and service records that attackers could exploit.

Basic IP Address Discovery

Start with the fundamental DNS records that directly contain IP addresses. These commands reveal the most common locations where private IPs appear:

Check Primary A Records (IPv4)

This command reveals the main IPv4 addresses your domain resolves to. Look specifically for RFC 1918 private address ranges.

# Check primary A records (IPv4 addresses)
dig yourdomain.com A

What to look for: Any IP addresses starting with 10.x.x.x, 172.16-31.x.x, or 192.168.x.x indicate private IP exposure that needs immediate remediation.

Check IPv6 Addresses (AAAA Records)

IPv6 also has private address ranges that can create similar DNS rebinding vulnerabilities through unique local addresses.

# Check IPv6 addresses (AAAA records)  
dig yourdomain.com AAAA

IPv6 private ranges to identify: fc00::/7 (unique local addresses) and fe80::/10 (link-local addresses) create the same DNS rebinding risks as IPv4 private ranges.

Alternative Resolution Testing

Different DNS resolvers may return different results based on network configuration, split DNS, or resolver-specific behavior.

# Alternative lookup using nslookup (different resolver behavior)
nslookup yourdomain.com

Why this matters: Some networks have different DNS views (split-horizon DNS) that may expose different IP addresses to internal vs external queries, potentially hiding private IP exposure from standard testing.

Comprehensive Record Type Analysis

Private IPs can appear in various DNS record types. Mail exchangers might point to internal mail servers, nameservers could be internal infrastructure, and service records often reference internal services by IP address:

Complete Record Type Scan

The ANY query returns all configured DNS records for comprehensive analysis. This reveals hidden private IP addresses in unexpected record types.

# Check ALL record types for comprehensive analysis
dig yourdomain.com ANY

What this reveals: Returns all configured DNS records including A, AAAA, MX, NS, TXT, CNAME, and SRV records. Scan the entire output for any IP addresses that fall within private ranges.

Mail Exchanger (MX) Record Analysis

Mail servers frequently reside on internal networks and may expose private IP addresses through MX record targets.

# Specifically check mail exchanger records
dig yourdomain.com MX

Security risk: MX records pointing to private IP addresses allow attackers to discover internal mail server infrastructure and potentially exploit mail services through DNS rebinding.

Nameserver (NS) Record Verification

Authoritative nameservers using private IP addresses create direct DNS rebinding vulnerabilities and make domains unreliable from external networks.

# Check nameserver records
dig yourdomain.com NS

Critical issue: Private IP addresses in NS records prevent external DNS resolution and create opportunities for DNS rebinding attacks against your authoritative DNS infrastructure.

Service Discovery (SRV) Record Analysis

Service records often contain private IP addresses for internal service discovery, creating additional attack vectors for DNS rebinding.

# Check service discovery records
dig _http._tcp.yourdomain.com SRV
dig _https._tcp.yourdomain.com SRV

Service exposure risk: SRV records can reveal internal service locations and ports, allowing attackers to map your internal infrastructure and identify specific services running on private networks.

Automated Private IP Detection

This command automatically filters DNS responses to identify private IP addresses across all the standard private address ranges. It's essential for quickly spotting problematic configurations:

RFC 1918 Private Range Detection

This command uses regex pattern matching to automatically identify all RFC 1918 private IP addresses in DNS responses.

# Automated private IP detection with comprehensive pattern matching
dig +short yourdomain.com A | grep -E '^10.|^172.(1[6-9]|2[0-9]|3[01]).|^192.168.'

Regex breakdown: ^10\. matches Class A (10.x.x.x), ^172\.(1[6-9]|2[0-9]|3[01])\. matches Class B (172.16-31.x.x), and ^192\.168\. matches Class C (192.168.x.x) private networks.

Extended Problematic Range Detection

Beyond RFC 1918, other IP ranges can also create DNS rebinding vulnerabilities including loopback and link-local addresses.

# Extended check for additional problematic ranges
dig +short yourdomain.com A | grep -E '^10.|^172.(1[6-9]|2[0-9]|3[01]).|^192.168.|^169.254.|^127.'

Additional ranges detected: 169.254.x.x (APIPA/link-local addresses used for automatic addressing) and 127.x.x.x (loopback addresses) can also be exploited in DNS rebinding attacks.

Understanding Detection Results

When the grep command returns matches, it indicates DNS rebinding vulnerabilities that require immediate remediation.

Why this matters: The grep command uses regular expressions to match the specific IP address ranges defined in RFC 1918 as private. Finding any matches indicates a DNS rebinding vulnerability that needs immediate attention to prevent attackers from accessing your internal network infrastructure.

Step 2: Understanding the Security Impact

Before making changes, it's crucial to understand why your domain currently resolves to private IPs and what services might be affected. This analysis helps you plan the transition without breaking legitimate internal services.

Analyzing Current Configuration Purpose

Determine whether the private IP configuration serves a legitimate purpose or represents a misconfiguration:

External Connectivity Testing

Test if the private IP addresses are actually reachable from external networks. Run these commands from outside your internal network.

# Test connectivity to the private IP addresses from external networks
curl -I --connect-timeout 5 http://10.x.x.x
ping -c 3 192.168.x.x

Expected result: These commands should timeout or fail from external networks, confirming the IPs are truly private. If they succeed, you may have a different networking issue.

Service Discovery Scan

Identify what services are running on the private IP addresses to understand their purpose and business impact.

# Check if services are actually running on these addresses
nmap -p 80,443,22,3389 10.x.x.x

Common ports: 80(HTTP), 443(HTTPS), 22(SSH), 3389(RDP). Open ports indicate active services that need proper migration planning before DNS changes.

DNS Resolution Path Analysis

Trace the complete DNS resolution path to identify where private IPs are being introduced into the resolution chain.

# Verify if these are intentional internal services or misconfigurations
dig +trace yourdomain.com

What to analyze: The trace shows the complete DNS resolution path from root servers to authoritative servers. Look for where private IPs first appear to identify the misconfigured component.

Identifying Attack Vectors

Understanding how attackers could exploit your private IP resolution helps prioritize fixes and implement additional protections:

DNS Rebinding Attack Simulation

⚠️ WARNING: Only run these tests in controlled environments with proper authorization. These simulate actual attack methods.

# Check if internal services are accessible via domain name
curl -H "Host: yourdomain.com" http://192.168.x.x

Attack method: This simulates how attackers bypass same-origin policy by using your public domain name to access private IP addresses, effectively tunneling external requests to internal services.

Internal Infrastructure Discovery

Attackers often target common internal infrastructure endpoints to gain administrative access to network devices and services.

# Check for admin interfaces on private IPs
curl -I http://192.168.1.1/admin
curl -I http://10.0.0.1/management

Common targets: Router administration interfaces, network device management panels, and internal system dashboards that typically use default credentials or weak authentication.

Internal API Exploitation

Internal APIs and microservices often lack the same security controls as public-facing services, making them attractive targets.

# Verify if internal APIs are exposed
curl http://internal-service.yourdomain.com/api/status

Security insight: Attackers use JavaScript in malicious websites to make requests to your domain, which then resolves to private IPs, effectively allowing external websites to probe and interact with your internal network infrastructure through DNS rebinding attacks.

Step 3: Implementing Secure DNS Configuration

Replacing private IPs with public addresses requires careful planning to ensure all services remain accessible while eliminating security vulnerabilities. The approach depends on whether you need external access to the services or if they should remain internal-only.

Public IP Address Implementation

For services that need external access, configure proper public IP addresses with appropriate security controls:

DNS Zone File Structure

Create a properly formatted DNS zone file with public IP addresses. The SOA record defines authoritative information for your domain.

# Standard DNS zone file format
$TTL 300                                      ; Default TTL (5 minutes for initial testing)
yourdomain.com.    IN    SOA   ns1.yourdomain.com. admin.yourdomain.com. (
                           2023120501         ; Serial number (update when making changes)
                           3600               ; Refresh interval  
                           1800               ; Retry interval
                           604800             ; Expire time
                           300                ; Negative TTL
)

SOA components: Serial number must increment with each change, refresh/retry intervals control secondary server behavior, and negative TTL caches failed lookups to reduce server load.

Nameserver Configuration

Nameserver records must point to public IP addresses for external DNS resolution to work correctly.

; Nameserver records (must use public IPs)
yourdomain.com.    IN    NS     ns1.yourdomain.com.
yourdomain.com.    IN    NS     ns2.yourdomain.com.

Critical requirement: NS records pointing to private IPs will break external DNS resolution entirely. Ensure all nameservers use public addresses.

IPv4 Address Records

Replace all private IP addresses with your actual public IPv4 addresses. Use documentation IPs for examples only.

; Main domain A record - CRITICAL: Use your actual public IP
yourdomain.com.    300   IN    A     203.0.113.1

Important note: 203.0.113.1 is a documentation IP address (RFC 5737). Replace this with your real public IPv4 address obtained from your hosting provider or ISP.

IPv6 Support Configuration

Modern networks increasingly require IPv6 support for optimal connectivity and future compatibility.

; IPv6 support (recommended for modern networks)
yourdomain.com.    300   IN    AAAA  2001:db8::1
; Web services CNAME for easier management
www.yourdomain.com.  300  IN   CNAME  yourdomain.com.

IPv6 benefits: 2001:db8::1 is a documentation IPv6 address. Replace with your real IPv6 address. CNAME records allow easier IP address changes since you only need to update the main A/AAAA records.

Securing Transitional Configurations

During the transition, implement security measures to prevent exploitation while you migrate services:

Reverse Proxy Configuration

Use a reverse proxy to control access while gradually transitioning services from private to public addressing.

# nginx configuration for controlled access
server {
    listen 80;
    server_name yourdomain.com;
    
    # Restrict access during transition
    location / {
        allow 203.0.113.0/24;     # Your organization's public IP range
        deny all;

Access control: This configuration allows only your organization's IP range during migration, preventing public exposure while testing.

Proxy Headers and Security

Configure proper proxy headers and security measures to protect against DNS rebinding during the transition.

        # Proxy to internal service with security headers
        proxy_pass http://10.0.0.100:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        # Security headers to prevent DNS rebinding
        add_header X-Frame-Options DENY;
        add_header X-Content-Type-Options nosniff;
        add_header Referrer-Policy strict-origin-when-cross-origin;
    }
}

Security headers: These headers prevent iframe embedding, MIME type sniffing, and control referrer information to mitigate DNS rebinding attack vectors.

Complete Private Range Elimination

Systematically remove all problematic IP address ranges from your DNS configuration. This comprehensive cleanup prevents any remaining DNS rebinding attack vectors:

RFC 1918 Private Address Ranges

These are the primary private IP ranges that must be completely removed from all public DNS records.

# RFC 1918 Private Address Ranges (CRITICAL to remove)
# 10.0.0.0/8        - Class A private network (10.0.0.0 to 10.255.255.255)
# 172.16.0.0/12     - Class B private networks (172.16.0.0 to 172.31.255.255)  
# 192.168.0.0/16    - Class C private networks (192.168.0.0 to 192.168.255.255)

Critical requirement: These ranges are reserved for private networks and create DNS rebinding vulnerabilities when present in public DNS.

Additional Problematic Ranges

Beyond RFC 1918, several other IP ranges also create security vulnerabilities and should be removed.

# Additional problematic ranges to remove:
# 127.0.0.0/8       - Loopback addresses (127.0.0.0 to 127.255.255.255)
# 169.254.0.0/16    - Link-local addresses (169.254.0.0 to 169.254.255.255)
# 224.0.0.0/4       - Multicast addresses (224.0.0.0 to 239.255.255.255)
# 0.0.0.0/8         - Reserved addresses (0.0.0.0 to 0.255.255.255)

Extended risks: Loopback addresses allow localhost access, link-local addresses enable local network discovery, and multicast addresses can expose internal network topology.

Automated Validation Script

Use this script to systematically check for remaining private IP addresses across all DNS record types.

#!/bin/bash
echo "Scanning for remaining private IP addresses..."
for record_type in A AAAA MX NS; do
    echo "Checking $record_type records:"
    dig +short yourdomain.com $record_type | grep -E '^(10.|172.(1[6-9]|2[0-9]|3[01]).|192.168.|127.|169.254.)'
done

echo "If any IPs appear above, they need to be removed from DNS records"

Implementation note: This validation script checks A, AAAA, MX, and NS records for any remaining private IP addresses. Run this after making changes to ensure complete remediation.

Step 4: Validation and Ongoing Security

After implementing changes, thorough testing ensures that you've eliminated the DNS rebinding vulnerability while maintaining service functionality. Ongoing monitoring prevents future misconfigurations.

Comprehensive Validation Testing

Test your changes from multiple perspectives to ensure complete remediation and verify that services work correctly with public IP addressing:

Multi-Resolver DNS Testing

Test DNS resolution using multiple public DNS resolvers to ensure consistent results across different providers.

# Test from multiple public DNS resolvers
for dns_server in 8.8.8.8 1.1.1.1 208.67.222.222 9.9.9.9; do
    echo "Testing via $dns_server:"
    dig @$dns_server +short yourdomain.com A
done

DNS resolvers tested: Google (8.8.8.8), Cloudflare (1.1.1.1), OpenDNS (208.67.222.222), and Quad9 (9.9.9.9). Results should show only public IP addresses across all resolvers.

Geographic Distribution Testing

Verify DNS resolution works correctly from different geographic regions to ensure global accessibility.

# Test geographic distribution
dig @4.2.2.1 yourdomain.com A        # US resolver
dig @213.73.91.35 yourdomain.com A   # European resolver

Geographic validation: Tests DNS resolution from US and European resolvers to ensure your domain is accessible globally without private IP exposure.

Comprehensive Record Type Scan

Systematically check all DNS record types for any remaining private IP addresses.

# Verify no private IPs in any record type
for type in A AAAA MX NS CNAME TXT SRV; do
    result=$(dig +short yourdomain.com $type | grep -E '^(10.|172.(1[6-9]|2[0-9]|3[01]).|192.168.)')
    if [ -n "$result" ]; then
        echo "WARNING: Private IP found in $type record: $result"
    else
        echo "$type records clean"
    fi
done

Validation results: This script checks A, AAAA, MX, NS, CNAME, TXT, and SRV records. Any warnings indicate remaining private IPs that need remediation.

Ongoing Security Monitoring

Implement continuous monitoring to detect if private IPs accidentally reappear in your DNS configuration through automated deployments or configuration changes:

Automated Monitoring Script

Create a monitoring script that regularly checks your DNS configuration for private IP address exposure.

#!/bin/bash
# Save as: /usr/local/bin/dns-private-ip-monitor.sh

DOMAIN="yourdomain.com"
ALERT_EMAIL="security@yourdomain.com"
LOG_FILE="/var/log/dns-security-monitor.log"

Configuration variables: Set your domain name, security team email, and log file location for centralized monitoring.

Detection and Alerting Logic

The script checks DNS records and sends alerts when private IP addresses are detected.

# Check for private IPs in DNS
PRIVATE_IPS=$(dig +short $DOMAIN A | grep -E '^(10.|172.(1[6-9]|2[0-9]|3[01]).|192.168.)')

if [ -n "$PRIVATE_IPS" ]; then
    echo "$(date): ALERT - Private IP detected: $PRIVATE_IPS" >> $LOG_FILE
    echo "Private IP detected in DNS for $DOMAIN: $PRIVATE_IPS" | mail -s "DNS Security Alert" $ALERT_EMAIL
else
    echo "$(date): DNS check passed - no private IPs detected" >> $LOG_FILE
fi

Alert mechanism: When private IPs are found, the script logs the incident and sends an email alert to your security team for immediate action.

Automated Scheduling

Set up regular monitoring using cron to automatically check for DNS security issues.

# Add to crontab for daily monitoring:
# 0 9 * * * /usr/local/bin/dns-private-ip-monitor.sh

Monitoring importance: DNS configurations can change through automated deployments, infrastructure updates, or human error. Daily monitoring ensures that private IP exposure doesn't reoccur and compromise your security posture.

Last updated: August 2, 2025