4 ms·

>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

by 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 ago
Still, you're exposing your infrastructure. It's kind of nice to know that there is a mongo1.profiles.company.com somewhere.
- Hamuko 5y ago
  You 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 ago
  You 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 ago
    With 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 ago
I’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.

by Hamuko 5y ago

jbverschoor 5y ago

Still, you're exposing your infrastructure. It's kind of nice to know that there is a mongo1.profiles.company.com somewhere.

Hamuko 5y ago
You 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 ago
You 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 ago
  With 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 ago

I’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.