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?
-
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?
womble : What real problem(s) are these? In what ways will people be confused?womble : So it's... polite... not to put 1918 addresses into public DNS? I've hit plenty of problems that "hidden" and "split horizon" DNS zones have caused, but not nearly so many caused by private IP in public DNS. I just don't see the problem.jj33 : Then we disagree. I'm quite happy with the public/private split-view zones I've created. It appears that we have both stated opinions. If you have NANOG on your side, you probably have consensus.Zoredache : @womble, computers might be confused if for some reason they attempt to connect to that host outside your network and instead of getting the SMTP server they expected they got whatever was living at that IP address on the lan they where currently connected to. It could even be that one of your staff using a laptop on a remote might start spewing the user name and password out in plain-text on someone else's network just because they also happen to have a 192.168.1.1womble : The problem I have with your answer is that you allude to problems, but don't provide any details. If there are reasons not to do it, I want to know about them, so I can make a fully reasoned decision on the subject.womble : @Zoredache: Why is someone resolving a name they don't have access to? DNS isn't the only place you could get private addresses, anyway -- HTML can use IP literals, for instance...Mihai Limbăşan : I would also like to know what "confusion" can arise. The only "confusion" I can think of is RFC1918 addresses in public NS or MX records, and that is a big fat error, not confusion. The security issue is a red herring, 90% of people will already have 192.168.1.0/24 and nobody will really bother to check DNS for more, and if you're bothered about leaking internal networks, have you checked your SMTP headers lately? Thought so.Mihai Limbăşan : Having RFC1918 addresses in the public DNS is for example superbly useful if you push routes to the internal networks through VPNs - that allows people to use their preferred DNS server and *still* resolve your internal names correctly.duffbeer703 : In most environments, putting private address space in public DNS isn't a big deal. It becomes a problem in large companies and governments where divisions, agencies, or operating companies have a untrusted intranet between business units. In that case, the meaning of "internal" isn't clear-cut.Benoit : Views is, for me, the best idea. 1 view contains only the public records while the second one contains also the private records. The second view is served only on the private (local or vpn) networks.From jj33 -
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.
Mihai Limbăşan : +1, thank you for being a voice of sanity in all the FUD responses to this question. "Security risk" my lower dorsal regions, and seeing routing problems and DNS issues colluded into one knee-jerk "don't do it" reaction just makes me wonder about the competence of people running networks all over the place.Mihai Limbăşan : Correction: Make that "seeing routing problems and DNS issues *and* authentication/identity issues colluded".From womble -
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.
Mihai Limbăşan : +1, see comment to womble's answer for reason :)sucuri : This is a good example of an issue with this idea: http://www.merit.edu/mail.archives/nanog/2006-09/msg00364.htmlFrom Tall Jeff -
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.
womble : If the user has a laptop they use in your office as well as elsewhere, chances are they'll have configured their hosts file to point at the internal IP of the MTA, or used the IP directly in their MUA config. Same end result. Bring on IPv6 and the death of RFC1918, it's the only way to be sure...Dave Cheney : Excellent point Zoredache. This is an interesting attack vector. Depending on the MUA it might present the usual "something annoying happened, please click me to do what you wanted me to do in the first place" dialog box, or it could fail outright if the ssl cert doesn't match.From Zoredache -
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.
Mihai Limbăşan : That's certainly an option, but why? What does running an internal resolver or (much smarter) using something like BIND views gain you beside administrative overhead and maintenance burden? That's what I don't understand.Dave Cheney : Running your own name server is not rocket science. If your network is of a sufficient size that you consider using /etc/hosts as a hack or to time consuming, then you need to setup a pair of resolvers in your network. As a side benefit you reduce the amount of dns traffic leaving your network and you speed up resolution of common queries.Mihai Limbăşan : I know it's not rocket science, but it's a maintenance overhead and a potential security risk. Certainly a higher security risk than leaking the existence of a RFC1918 network. DNS traffic is utterly negligible - I host in excess of 80 moderately large and busy zone files on my DNS at work and weekly DNS traffic is less than 2 minutes of Youtube. Speeding up query resolution is actually the first halfway sane argument against RFC1918 numbers in DNS I've seen here :) Upvoted for actually thinking a bit beyond the usual knee-jerk "oh, noes, it's a security risk" reaction :)Dave Cheney : @Mahli, if it was my network, I would run a pair of resolvers. The maintenance overhead for me is less than the value they bring. In addition to doing split horizon dns tricks, you get the ability to use CNAMEs on your network so you can create useful aliases for moving services around between machines without chasing config. I also find DNS an excellent canonical reference of where hosts live, because its not possible to move the host (or service, if you follow my CNAME advice) without updating your internal DNS.Alnitak : @Mihai - almost all ISPs have access to AS112 anycast for fast resolution of RFC1918 space. More likely (per my answer) are timeouts as the SMTP layer tries to reach an IP address that's either not in the routing table, or in the routing table but firewalled.Mihai Limbăşan : @Alnitak: I understand where you're coming from but that's still not a DNS problem, and I maintain that trying to fix issues originating somewhere else through DNS is not a good idea at all. Problems should be fixed at the source, not patched up by DNS hacks - hacks make networks brittle.Alnitak : well, yes, I agree. And putting your private host's information in the public DNS is a hack solution for the problem of not having an internal DNS server... :) The problem is that the higher layers don't _know_ that this information is supposed to be "private".Mihai Limbăşan : *nods* My take is that this information is should not be regarded as private because the distinction between public and private should not be made at the name resolution level. Guess we'll have to agree about disagreeing :)From Dave Cheney -
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.
Mihai Limbăşan : How is delivering mail to the wrong machine a DNS problem? You should authenticate the SMTP server. That's a SMTP configuration problem which has absolutely nothing to do with DNS. You're not even comparing apples to oranges here, you're comparing a radioactive buttered toast to five milligrams of Lagrangian derivatives on a stick. If you're worrying about getting the wrong MX or A result you should use DNSSEC instead of holding DNS responsible for what it's not responsible, and if you're mistakenly delivering SMTP to the wrong RFC1918 number you've misconfigured or misdesigned your network.Mihai Limbăşan : (reposted commend for clarification)Mihai Limbăşan : If someone on your network "made up" an IP number then the IP protocol is functioning exactly as designed, i.e. without security in mind. What you are asking is "how can I trust that I'm actually talking to whomever I'm supposed to talk to?" and the answer to that cannot be delivered by IP and/or by DNS, the answer to that is delivered by DNSSEC and/or SSL/TLS and/or an application layer mechanism.Mihai Limbăşan : Just read your comment to Dave's post - your post makes more sense now :) I still disagree with the premise, but I don't think it's irrational anymore...Alnitak : @Mihai - firstly, cool it with the attitude! You're now conflating security issues with simple good network manners. Yes, I believe you shouldn't put RFC1918 addresses in the public DNS, but not for security reasons, it's simply not "nice". I also didn't say *anything* about proving that the far end is who they say they are. Believe me, I know _plenty_ about DNSSEC.Mihai Limbăşan : (Offtopic comment) "Cool it with the attitude"? Um, how about "cool it with the condescence" and we counter each other with arguments instead of personal issues, shall we.Mihai Limbăşan : (On-topic comment) I interpreted *"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."* as referring to authentication, hence the diatribe - if I was wrong I retract my argument.Alnitak : no, it wasn't about authentication at all, just about connections ending up in the wrong place. I saw _plenty_ of that when Verisign decided to wildcard *.com back in ~2001.Mihai Limbăşan : Hah, the Verisign wildcard was exactly what popped into my head when reading that paragraph. Guess we're seeing the same issue from two different directions - my reaction to it back then wasn't "why are people upset about their misaddressed mail ending up at Verisign?" (i.e. DNS causing misrouting), it was "Why are people delivering their misaddressed mail to Verisign?" (i.e. DNS being used for authentication.) Granted, DNSSEC *still* hasn't picked up enough momentum...Avery Payne : It isn't so much a security issue as it is one of identity. If everyone decided to expose their 10./8 network, can you imagine the ensuing anarchy as different machines claimed to all be 10.1.1.1? "I'm Spartacus!" "No, I am!" "Ignore him, I'm Spartacus!" "No, me!" "Me too!" (group looks and speaks in unison) "Who are you?!?"Alnitak : Why were people delivering their misaddressed e-mail to Verisign - because the DNS told them to! Sure, misaddress e-mail was always a problem, but nobody ever expected a major gTLD to do something so stupid! :) FWIW, I'm doing my bit towards DNSSEC - do a Google search for 'SAC035'.Mihai Limbăşan : @Avery: Yes, that's what I was referring to (and why I became so *ahem* passionate about it), but ultimately it boils down to trust in the DNS server, which is a major risk in the first place, hence DNSSEC. It does not matter one iota even if everyone were to advertise PTRs to 10./8, all that matters is which server is authoritative as far as the client's trusted DNS server is concerned. That trust relationship is the problem, that's what makes it a security issue, and this problem can only be fixed by something like DNSSEC, which currently is a chicken-and-egg problem like IPv6 :(Avery Payne : @Mihai Limbasan - ok, now I understand your point of view. True, the DNS side of things is indeed an issue ATM, but even without it, with just straight IP routing, it's still trouble. The two of them together would probably bring all kinds of untold horror unto the internet in general, so we're agreeing to the same thing, just on two different sides of the same coin. :)Mihai Limbăşan : @Alnitak: Nice :) I envy you actually being able to spell out results. The extent to which I'm contributing is currently fighting the windmills^W^W^W lobbying/petitioning the decentralized government structures in my country to at least *consider the idea*. The results so far are a looks of bewilderment or resounding silences on the receiving end, and blinding headaches and homicidal thoughts on this end, but that's par for the course when dealing with bureaucratic inertia, I guess, so I try to stay positive and look forward to the day when .ro. is signed...Mihai Limbăşan : Incidentally - FWIW, I got a bit carried away there, and apologize. Guess Jeff was right and SO/SF aren't that well suited to forum-type back-and-forth discussions... Perhaps we can commiserate about the current progress in networking technology deployment (or debatable lack thereof) somewhere else :)Mihai Limbăşan : @Alnitak: +1 for "No, it's not DNS's fault, it's just doing what it's told to."From Alnitak -
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.
Mihai Limbăşan : That's all nice and true, but you haven't given an actual reason for why one should not publish RFC1918 addresses in DNS. You have just described what RFC1918 addresses are and that it's possible to not have a route to some of them. How is that different from any other IP number? It's possible to not have a route to 198.41.0.4 - does that mean it's wrong to publish 198.41.0.4 in DNS? DNS is a *name resolution system*. It has nothing to do with routing, the two are orthogonal. You're colluding two categories of problems, which basically amounts to FUD.Avery Payne : The context of the discussion was the use of private IP addresses in a *public* DNS server. The point of the post was to indicate that, by default, routers are not to route private IP addresses. I was not attempting to indicate that you *can't* use private IP addresses in a DNS server, only that you shouldn't provide those IP addresses "to the outside". If this is not clear enough, I'll gladly withdraw the post. Otherwise, I disagree, the post is 100% spot-on - the net effect for this person is that /they will have problems/ if they do this.Mihai Limbăşan : *nods* Your comment under Alnitak's post cleared it up :) Thanks.From Avery Payne -
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?
From sh-beta
0 comments:
Post a Comment