We have an SMTP only mail server behind a firewall which will have a public A record of mail.. The only way to access this mail server is from another server behind the same firewall. We do not run our own private DNS server.
Is it a good idea to use the private IP address as an A record in a public DNS server - or is it best to keep these server records in each servers local hosts file?
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.
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.
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?
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:
$ORIGIN example.com
@ IN MX mail.example.com
mail IN A 192.168.1.2
IN A some_public_IP
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.
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.
Your two options are /etc/hosts and putting a private IP address in your public zone. I'd recommend the former. If this represents a large number of hosts, you should consider running your own resolver internally, it's not that hard.
There may be subtle problems with it. One is that common solutions to DNS Rebind attacks filter local DNS entries resolved from public DNS servers. So you either open yourself to rebind attacks, or local addresses don't work, or require more sophisticated configuration (if your software/router even allows it).
It's best to keep it in the hosts file. If only one machine is ever supposed to connect to it anyway, what do you gain by putting it into public DNS?
/etc/hosts file because all 2,000 machines then need to manage these IP/name pairs...
– Alexis Wilke
Mar 15 at 23:36
If by private you mean a 10.0.0.0/8, a 192.168.0.0/16, or a 172.16.0.0/12, then don't. Most internet routers recognize it for what it is - a private address that must never be routed to the public internet in a direct fashion, which is what helped the popularity of NAT. Anyone attempting to contact your public DNS server will retrieve the private IP address from DNS, only to send a packet to .... nowhere. As their connection attempts to traverse the internet to your private address, some (sanely configured) router along the way will simply eat the packet alive.
If you want to get email from the "outside" to come "inside", at some point, the packet has to cross your firewall. I would suggest setting up a DMZ address to handle this - a single public IP address that is tightly controlled by any router/firewall you have in place. The existing setup you describe sounds like it does exactly that.
EDIT: clarification of intent... (see comments below). If this doesn't make sense, I'll vote to remove my own post.
I arrived here as I was looking for similar information and was surprised that many say it's fine to leak your private IP addresses. I guess in terms of being hacked, it doesn't make a huge difference if you are on a safe network. However, DigitalOcean has had all local network traffic on the exact same cables with everyone really having access to everyone else traffic (probably doable with a Man in the Middle attack.) If you just would get a computer in the same data center, having that information certainly gives you one step closer to hacking my traffic. (Now each client has its own reserved private network like with other cloud services such as AWS.)
That being said, with your own BIND9 service, you could easily define your public and private IPs. This is done using the view feature, which includes a conditional. This allows you to query one DNS and get an answer about internal IPs only if you are asking from your one of your own internal IP address.
The setup requires two zones. The selection uses the match-clients. Here is an example of setup from Two-in-one DNS server with BIND9:
acl slaves {
195.234.42.0/24; // XName
193.218.105.144/28; // XName
193.24.212.232/29; // XName
};
acl internals {
127.0.0.0/8;
10.0.0.0/24;
};
view "internal" {
match-clients { internals; };
recursion yes;
zone "example.com" {
type master;
file "/etc/bind/internals/db.example.com";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "example.com" {
type master;
file "/etc/bind/externals/db.example.com";
allow-transfer { slaves; };
};
};
Here is the external zone and we can see IPs are not private
; example.com
$TTL 604800
@ IN SOA ns1.example.com. root.example.com. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
@ IN NS ns1
IN MX 10 mail
IN A 192.0.2.1
ns1 IN A 192.0.2.1
mail IN A 192.0.2.128 ; We have our mail server somewhere else.
www IN A 192.0.2.1
client1 IN A 192.0.2.201 ; We connect to client1 very often.
As for the internal zone, we first include the external zone, which is how it works. i.e. if you are an internal computer, you only access the internal zone so you still need the external zone definitions, hence the $include command:
$include "/etc/bind/external/db.example.com"
@ IN A 10.0.0.1
boss IN A 10.0.0.100
printer IN A 10.0.0.101
scrtry IN A 10.0.0.102
sip01 IN A 10.0.0.201
lab IN A 10.0.0.103
Finally, you have to make sure that all your computers now make use of that DNS and its slaves. Assuming a static network, it would mean editing your /etc/network/interfaces file and using your DNS IPs in the nameserver option. Something like this:
iface eth0 inet static
...
nameserver 10.0.0.1 10.0.0.103 ...
Now you should be all set.
