When managing a server hosting multiple domains on a single IP address, Reverse DNS (rDNS) configuration becomes particularly important for email deliverability, security checks, and network troubleshooting. The core issue arises when we need to associate a single IP address with multiple domain names in reverse lookups.
In DNS architecture, PTR records follow these key principles:
; Correct format for IPv4 PTR records
$ORIGIN 55.34.12.in-addr.arpa.
241 14400 IN PTR nameserver1.network.co.uk.
The critical detail is that each IP address can only have one PTR record, regardless of how many domains it hosts. This is why we typically point it to the server's hostname rather than any individual hosted domain.
For a server with IP 12.34.56.236 hosting multiple domains:
; Forward zone file
websitename.co.uk. IN A 12.34.56.236
othersite.com. IN A 12.34.56.236
; Reverse zone file (managed by your hosting provider)
$ORIGIN 56.34.12.in-addr.arpa.
236 IN PTR ns1.domainnetwork.co.uk.
For your dedicated IP case (12.34.56.241), these are the possible issues:
- The reverse DNS zone might not be properly delegated to your nameservers
- TTL values might need refreshing
- The PTR record might exist in a different nameserver than expected
Verification commands:
dig -x 12.34.56.241
host 12.34.56.241
nslookup 12.34.56.241
For mail servers especially, you'll want to ensure:
; Mail server configuration should match:
1. The PTR record (ns1.domainnetwork.co.uk)
2. The HELO/EHLO greeting
3. The SSL certificate (if applicable)
If you're still experiencing issues with the dedicated IP (241), contact your hosting provider to verify:
1. They've properly delegated the .241 PTR to your nameserver
2. The reverse zone file is correctly formatted
3. There are no firewall rules blocking DNS queries
- PTR record points to server hostname (not client domains)
- Forward confirmation (A record exists for the hostname)
- TTL values are appropriate (14400 is standard)
- Zone serial numbers increment after changes
When hosting multiple domains on a single IP address, reverse DNS configuration becomes particularly tricky. The fundamental rule is:
For any given IP address, there should be exactly one PTR record pointing to a canonical hostname.
Your existing configuration shows a common pattern where all domains on shared IPs point to the nameserver's hostname:
55.34.12.in-addr.arpa. 14400 IN PTR nameserver1.network.co.uk.
For domains with dedicated IPs (like your 12.34.55.241 case), the PTR record should ideally match either:
- The domain's primary hostname (websitenameTwo.co.uk)
- Or a specific subdomain like mail.websitenameTwo.co.uk if used for email
To diagnose your PTR issues, run these commands:
# Check forward resolution
host nameserver1.network.co.uk
# Check reverse resolution
host 12.34.55.241
# Verify DNS propagation
dig +short -x 12.34.55.241
For your dedicated IP domain, the zone file should contain:
; Zone file for 55.34.12.in-addr.arpa
$ORIGIN 55.34.12.in-addr.arpa.
241 IN PTR websitenameTwo.co.uk.
The PTR record for 12.34.55.241 points to nameserver1.network.co.uk, but:
- nameserver1.network.co.uk likely resolves to your main server IP (12.34.55.236)
- This creates a mismatch in the forward-confirmed reverse DNS (FCrDNS) check
If this server handles email, you'll need special PTR configurations:
; For mail server on dedicated IP
241 IN PTR mail.websitenameTwo.co.uk.
; Corresponding A record
mail.websitenameTwo.co.uk. IN A 12.34.55.241
When setting up PTR records for shared/dedicated IP configurations:
- For shared IPs: Use the server's canonical hostname (nameserver1.network.co.uk)
- For dedicated IPs: Use the domain's primary hostname or specific service subdomain
- Always verify both forward and reverse DNS resolution
- Ensure the forward record matches the reverse record (FCrDNS)
Essential commands for debugging:
# Comprehensive DNS check
dig +trace websitenameTwo.co.uk
dig +trace -x 12.34.55.241
# Check specific nameserver
dig @ns1.domainnetwork.co.uk +short -x 12.34.55.241
# MX tool verification
nslookup -type=PTR 12.34.55.241