Private IP address in public DNS
Solution 1:
Some people will say no public DNS records should ever disclose private IP addresses....with the thinking being that you are giving potential attackers a leg up on some information that might be required to exploit private systems.
Personally, I think that obfuscation is a poor form of security, especially when we are talking about IP addresses because in general they are easy to guess anyway, so I don't see this as a realistic security compromise.
The bigger consideration here is making sure your public users don't pickup this DNS record as part of the normal public services of your hosted application. ie: External DNS lookups somehow start resolving to an address they can't get to.
Aside from that, I see no fundamental reason why putting private address A records into the public space is a problem....especially when you have no alternate DNS server to host them on.
If you do decide to put this record into the public DNS space, you might consider creating a separate zone on the same server to hold all the "private" records. This will make it clearer that they are intended to be private....however for just one A record, I probably wouldn't bother.
Solution 2:
I had a lengthy discussion on this topic on the NANOG list a while ago. Though I'd always thought it was a bad idea, turns out that it's not such a bad idea in practice. The difficulties mostly come from rDNS lookups (which for private addresses Just Don't Work in the outside world), and when you're providing access to the addresses over a VPN or similar it's important to ensure that the VPN clients are properly protected from "leaking" traffic when the VPN is down.
I say go for it. If an attacker can get anything meaningful from being able to resolve names to internal addresses, you've got bigger security problems.
Solution 3:
In general introducing RFC1918 addresses into public DNS will cause confusion, if not a real problem, at some point in the future. Use IPs, host records, or a private DNS view of your zone to use the RFC1918 addresses behind your firewall but not include them in the public view.
To clarify my response based on the other submitted response, I think introducing RFC1918 addresses into public DNS is a faux pas, not a security issue. If someone calls me to trouble shoot an issue and I stumble across RFC1918 addresses in their DNS, I start talking really slowly and asking them if they've rebooted recently. Maybe that's snobbery on my part, I don't know. But like I said, it's not a necessary thing to do and it's likely to cause confusion and miscommunication (human, not computer) at some point. Why risk it?
Solution 4:
No, don't put your private IP addresses in the public DNS.
Firstly, it leaks information, although that's a relatively minor problem.
The worse problem if your MX records point to that particular host entry is that anyone that does try to send mail to it will at best get mail delivery timeouts.
Depending on the sender's mail software they may get bounces.
Even worse, if you're using RFC1918 address space (which you should, inside your network) and the sender is too, there's every chance that they'll try and deliver the mail to their own network instead.
For example:
- network has internal mail server, but no split DNS
- admin therefore puts both public and internal IP addresses in the DNS
- and MX records point to both:
$ORIGIN example.com
@ IN MX mail.example.com
mail IN A 192.168.1.2
IN A some_public_IP
- someone seeing this might try to connect to 192.168.1.2
- best case, it bounces, because they've got no route
- but if they've also got a server using 192.168.1.2, the mail will go to the wrong place
Yes, it's a broken configuration, but I've seen this (and worse) happen.
No, it's not DNS's fault, it's just doing what it's told to.
Solution 5:
Though the possibility is remote I think you may be setting yourself up for some of MITM attack.
My concern would be this. Lets say one of your users with a mail client configured to point at that mail server takes their laptop to some other network. What happens if that other network also happens to have the same RFC1918 in use. That laptop may attempt to login to the smtp server and offer the user's credentials to a server that shouldn't have it. This would be particularly true since you said SMTP and didn't mention that you where requiring SSL.