3 ms·
One of the problems of that is now you need to list all your internal IP addresses in a public DNS server. It shouldn't theoretically be an issue but it might b
by dheera 5y ago
One of the problems of that is now you need to list all your internal IP addresses in a public DNS server. It shouldn't theoretically be an issue but it might be stuff you don't want to just lay out there in public view just in case.
Also you might just not want a domain like "my-top-secret-project.amazon.com" to actually exist and resolve to an IP (even if an intranet IP) in public DNS, but you might still want an easy-to-remember intranet hostname that employees can use.
- Hamuko 5y ago>One of the problems of that is now you need to list all your internal IP addresses in a public DNS server. You don't actually. You can just have them resolve in your local DNS server alone. My current setup is that the public DNS records for my internal network just return CNAME records, so "mail.myserver.com" has a CNAME record to "mail.myserver.internal" and my private DNS server has an A record for "mail.myserver.internal".
- jbverschoor 5y agoStill, you're exposing your infrastructure. It's kind of nice to know that there is a mongo1.profiles.company.com somewhere.
- Hamuko 5y agoYou can just obfuscate your names if you really need to keep it hidden. profiles.company.com? coffee.company.com. mail.company.com? tomato.company.com. passwords.company.com? tincan.company.com. If you're really paranoid, you can just flood a bunch of misdirects in there as well. If you need 10 internal subdomains, add 100 subdomains with random CNAMEs.
- aaomidi 5y agoYou can use wildcard certificates so you're not exposing any infrastructure. Also, you should really consider all your subdomains to not be private information. It's risky to build security based around that assumption. Tons of DNS services actually sell their queries, and those can be used to reconstruct these "private" subdomains.
- pixl97 5y agoWith this said, wildcards are massive security risks in themselves when devices start getting compromised. You can then chain together things like DNS poisoning and arp attacks to MITM further devices on the network. And confirming what you said. DNS leaks everywhere, so don't consider its obscurity a form of security.
- hultner 5y agoI’m going to steal this one, I’ve never thought about this. Also useful for local development with mdns. E.g. MacBook-X.local as an CNAME: "MacBook-X.internal.hultner.se CNAME MacBook-X.local" should just work for LE on my local dev machine when roaming between the home, office or on the go and the actual IP changes wildly.
- amarshall 5y agoYou don’t need to if you use ACME DNS challenge. I have split horizon where the ACME creates the temporary challenge record, LetsEncrypt sees it, and then the record is removed. There is never a public A record, and the window for enumerating the challenge record is short. That said, I never really understood worrying about exposing DNS records because someone has to brute-force enumerate the domain names, and because it just obfuscates. I do split horizon for different reasons and am currently moving away from it. Regardless, if you do care, you should be concerned about certificate transparency logs. The “workaround” for that is wildcard certs.
- hultner 5y agoLE publishes all issued certs so you might as well just keep it public anyway in that case.
- Hamuko 5y agoWildcard certs?
- edoceo 5y agoYep. The CN is something like "*.edoceo.com" And you can make self-signed too.
- amarshall 5y agoYes, I said this. Wildcard certs, as I mention, largely avoid the issue because it’s just one cert for a higher-level domain and largely uninteresting from an information disclosure perspective, at least compared with individual domain certs.