Best Practices: Using Private IP Address in Public DNS Records for SMTP Servers Behind Firewall


16 views

When configuring an SMTP server in a firewalled environment with no private DNS, engineers face a fundamental design choice: whether to expose private IP addresses in public DNS records or rely on local hosts files for internal resolution.

The described architecture has these key characteristics:

  • SMTP-only mail server (Postfix/Exim/Sendmail)
  • Restricted to internal network communication
  • Public-facing DNS (e.g., Route53, Cloudflare)
  • No internal DNS infrastructure
# Example problematic DNS configuration
mail.example.com.    IN  A  10.0.0.15

Security concerns include:

  • Exposing internal network topology
  • Potential reconnaissance by attackers
  • Violation of RFC 1918 guidance

Linux example (/etc/hosts):

10.0.0.15    mail.example.com    mail

Windows example (C:\Windows\System32\drivers\etc\hosts):

10.0.0.15    mail.example.com

For organizations that may eventually need internal DNS:

# Public DNS record
mail.example.com.    IN  A  203.0.113.5  # Firewall public IP

# Private DNS (future implementation)
mail.example.com.    IN  A  10.0.0.15

For pfSense (using NAT):

# Firewall rule
pass in quick on $INT_IF proto tcp from $TRUSTED_NETS to 10.0.0.15 port 25

For immediate needs:

  1. Use hosts files for all internal servers
  2. Maintain consistent IP addressing
  3. Document all manual configurations

For long-term solutions:

  1. Implement private DNS (BIND, Unbound, etc.)
  2. Consider DNS-over-HTTPS for internal resolution
  3. Evaluate cloud DNS solutions with private zones

When configuring an SMTP server behind a firewall that only needs internal access, many sysadmins face this architectural decision: Should private IPs appear in public DNS records, or should local hosts files handle the resolution?

Modern infrastructure often mixes public and private resources. Our specific case involves:

  • An SMTP server performing only mail relay functions
  • No outward-facing services (MX records point elsewhere)
  • Strict firewall policies limiting access to same-subnet servers
  • No internal DNS infrastructure

Using private IPs in public DNS isn't inherently insecure, but consider:

# Example of what NOT to do in public zone files:
mail.example.com.    IN A    10.0.0.12

Potential risks include:

  • Information disclosure about internal network structure
  • Potential aid for phishing attacks (fake internal hostnames)
  • DNS cache poisoning revealing internal topology

For limited internal communication, /etc/hosts provides:

# /etc/hosts entry on connecting servers
10.0.0.12    mail.internal.example.com smtprelay

Advantages:

  • No private IPs exposed publicly
  • No DNS dependency for critical services
  • Simpler troubleshooting (no DNS propagation delays)

For organizations needing both:

# Public DNS (minimal info)
mail.example.com.    IN CNAME firewall-vip.example.com.

# Internal resolution options:
1. Split-horizon DNS
2. Local hosts files
3. Private DNS overlay (Consul, etcd)

For Postfix configurations:

# main.cf snippet using hosts file resolution
relayhost = [smtprelay]
smtp_host_lookup = native

This forces Postfix to use getaddrinfo() which checks /etc/hosts first.

Whatever solution you choose, implement checks for:

  • Hosts file drift between servers
  • Unexpected public DNS queries for internal hosts
  • SMTP connectivity tests from monitoring systems