When configuring development.example.com to resolve to a private IP (192.168.2.13) through public DNS, we face several technical considerations:

example.com.    IN  A      192.168.2.13
development     IN  CNAME  example.com.

Public DNS records containing private IPs create these issues:

• External users get unreachable private IP addresses
• Potential security exposure of internal network topology
• Violates RFC 1918 address allocation principles

1. Split DNS Configuration

Implement separate DNS views for internal and external resolution:

// External zone file
example.com.    IN  A     203.0.113.45

// Internal zone file
development.example.com. IN A 192.168.2.13

2. VPN with Conditional Forwarding

For remote developers:

# OpenVPN client configuration
route 192.168.2.0 255.255.255.0

# Local DNS config
zone "example.com" {
    type forward;
    forwarders { 192.168.2.13; };
};

3. Cloud-Based Alternatives

Using AWS Route53 private hosted zones:

aws route53 create-hosted-zone \
    --name example.com \
    --vpc VPCRegion=us-west-2,VPCId=vpc-1a2b3c4d \
    --caller-reference $(date +%s)

Complete BIND9 split-horizon configuration:

view "internal" {
    match-clients { 192.168.2.0/24; };
    zone "example.com" {
        type master;
        file "/etc/bind/zones/internal.example.com";
    };
};

view "external" {
    match-clients { any; };
    zone "example.com" {
        type master;
        file "/etc/bind/zones/external.example.com";
    };
};

• Always firewall private IP ranges at network perimeter
• Implement DNSSEC to prevent cache poisoning
• Regularly audit DNS records for accidental private IP exposure

Sample Nagios check for accidental private IP exposure:

define command {
    command_name    check_private_dns
    command_line    /usr/lib/nagios/plugins/check_dns -H $HOSTADDRESS$ -a '!^10\.|!^192\.168\.|!^172\.(1[6-9]|2[0-9]|3[0-1])\.'
}

---

When configuring internal development environments, many engineers face this architectural question: Should we expose private RFC 1918 addresses (192.168.x.x, 10.x.x.x, 172.16.x.x) in public DNS records? While technically possible, this approach violates several networking fundamentals.

Public DNS records containing private IPs create these issues:

• Resolution failures for external clients (the private IP isn't routable)
• Security exposure revealing internal network topology
• Portability problems when changing networks

Option 1: Split DNS Architecture

Maintain separate DNS views:

// Public zone file (excerpt)
example.com. IN A 203.0.113.45
dev.example.com. IN A 203.0.113.46

// Internal zone file
dev.example.com. IN A 192.168.2.13

Option 2: Local Hosts File Override

For small teams, modify /etc/hosts:

# Linux/MacOS hosts file
192.168.2.13 dev.example.com

Option 3: VPN with Internal DNS

Corporate networks often use:

# OpenVPN client config
route dev.example.com 255.255.255.255

For BIND9 split-horizon DNS:

view "internal" {
    match-clients { 192.168.2.0/24; };
    zone "example.com" {
        type master;
        file "/etc/bind/zones/internal.example.com";
    };
};

view "external" {
    match-clients { any; };
    zone "example.com" {
        type master;
        file "/etc/bind/zones/external.example.com";
    };
};

• Monitor for DNS leaks using tools like dig +short dev.example.com @8.8.8.8
• Implement DNSSEC to prevent cache poisoning
• Consider cloud alternatives like AWS Route53 Private Hosted Zones