4 ms·

I do this as well, but be aware that these external names you're using for internal devices become a matter of public record this way. If that's okay for you (i

I do this as well, but be aware that these external names you're using for internal devices become a matter of public record this way. If that's okay for you (it is for me), then this is a good solution. The advantage is also that you run no risk of name clashes because you actually own the domain

xfer 2y ago
Or use a wildcard cert for all internal certs.
- ndsipa_pomu 2y ago
  That could be a good idea, though it means that the certificate/key has to be well guarded.
- project2501a 2y ago
  Please don't. Technical debt accumulates by force of practice.
  - qwertox 2y ago
    It's working good for me. My technical debt is to always make sure that I'm able to renew a certificate and that the distribution occurs successfully. I don't see how other solutions are less problematic.
- pridkett 2y ago
  This is exactly what I do. After seeing how much of my internal network was exposed in certificate transparency logs, I noped out and just do a DNS challenge for a wildcard for almost everything. Now it’s have a nice script that distributes my key automatically to 20 or so hosts and apps and have a real SSL cert on everything from my UDM Pro to my Synology to random Raspberry Pis running containers. Most of which have domain names that only resolve on my local network. This is made possible by a fairly robust DNS setup that consists of not only giving A records to all my hosts automatically, but also adding in CNAMEs for services and blocking almost all outbound DNS, DNS over TLS, DoH, etc.
  - dopp0 2y ago
    > fairly robust DNS setup that consists of not only giving A records to all my hosts looks nice, can you give more details on this? tks!
magicalhippo 2y ago
I decided to try split DNS to avoid leaking the internal IPs, but it turned out a bit more fragile than I imagined. Especially Android is finicky, ignoring your DNS server if it doesn't like your setup. For example, if it gets an IPv6 address, it requires the DNS server to also have an IPv6 address, or it'll use Google's DNS servers. It works now but I'm not convinced it's worth it for me.
- Hamuko 2y ago
  I use CNAME records and it works on everything except Windows, where it works sometimes. Basically, CNAME record from service.myserver.com to myserver.internal on a public DNS server, A record from myserver.internal to 1.2.3.4 on private DNS server. I think I could maybe get it working on Windows too by tweaking the TTLs. Currently both DNS servers are automatically setting the TTL and I think Windows freaks out about that.
  - ebb_earl_co 2y ago
    This seems like a good technique. What DNS software do you use?
    - Hamuko 2y ago
      I just use the one built into my UniFi router. Public DNS side is Cloudflare, which allows easy DNS validation for Let's Encrypt.
- capitol_ 2y ago
  Split DNS causes lots headaches, it also makes it really hard to root cause analysis of failures when they involve DNS.
ndsipa_pomu 2y ago
> be aware that these external names you're using for internal devices become a matter of public record this way Yes, I sometimes think about that, but have come to the conclusion that it's not likely to make any difference. If someone is trying to infiltrate my home network, then it's not going to really help them to know internal IP addresses as by the time they get to use them, they're already in.
- qwertox 2y ago
  You don't need to publish the IP addresses publicly if you use an internal DNS server. I think even Pi-hole could do this.
- dspillett 2y ago
  > If someone is trying to infiltrate my home network I don't think the publishing of host names was mentioned as a concern for small home networks, but more for larger organisations that might be subject to a coordinated break-in or simply have trade secrets¹² that might be hinted at by careless naming of resources. ---- [1] Their next big product/enhancement, as yet unannounced even within the company, for instance. [2] Hmm, checking what is recorded against one of DayJob's domains I see clues as to who some of our clients are. Not really a significant issue for security at all, but I know at least some of our contracts say we shouldn't openly talk about that we provide services to that client³ so I'll drop a message to the ISC to suggest we discuss if we need to care about the matter… [3] Though that is mostly in the form of not using their logos in our advertising and such.
  - xena 2y ago
    That's why you have an internal domain that's not related to the company. Something like "packet-flinging.ninja". Everything's a tradeoff though.
    - deltaburnt 2y ago
      It seems really easy to associate a company with its internal domain though? Unless the company treats it as a secret only known between machines.
deleted 2y ago
[deleted]
prmoustache 2y ago
you can use a wildcard of type *.internal.example.com or use names that do not relate to the service name if you want to obfuscate the tech stack used. The only thing public is that you may have an internal network with nodes.
Eikon 2y ago
Shameless plug: https://www.merklemap.com/ https://www.merklemap.com/
js2 2y ago
Using a wildcard cert doesn't leak anything much. I went with `*.home.example.com` for my internal stuff.

xfer 2y ago

Or use a wildcard cert for all internal certs.

ndsipa_pomu 2y ago
That could be a good idea, though it means that the certificate/key has to be well guarded.
project2501a 2y ago
Please don't. Technical debt accumulates by force of practice.
- qwertox 2y ago
  It's working good for me. My technical debt is to always make sure that I'm able to renew a certificate and that the distribution occurs successfully. I don't see how other solutions are less problematic.
pridkett 2y ago
This is exactly what I do. After seeing how much of my internal network was exposed in certificate transparency logs, I noped out and just do a DNS challenge for a wildcard for almost everything. Now it’s have a nice script that distributes my key automatically to 20 or so hosts and apps and have a real SSL cert on everything from my UDM Pro to my Synology to random Raspberry Pis running containers. Most of which have domain names that only resolve on my local network. This is made possible by a fairly robust DNS setup that consists of not only giving A records to all my hosts automatically, but also adding in CNAMEs for services and blocking almost all outbound DNS, DNS over TLS, DoH, etc.
- dopp0 2y ago
  > fairly robust DNS setup that consists of not only giving A records to all my hosts looks nice, can you give more details on this? tks!

magicalhippo 2y ago

I decided to try split DNS to avoid leaking the internal IPs, but it turned out a bit more fragile than I imagined. Especially Android is finicky, ignoring your DNS server if it doesn't like your setup. For example, if it gets an IPv6 address, it requires the DNS server to also have an IPv6 address, or it'll use Google's DNS servers. It works now but I'm not convinced it's worth it for me.

Hamuko 2y ago
I use CNAME records and it works on everything except Windows, where it works sometimes. Basically, CNAME record from service.myserver.com to myserver.internal on a public DNS server, A record from myserver.internal to 1.2.3.4 on private DNS server. I think I could maybe get it working on Windows too by tweaking the TTLs. Currently both DNS servers are automatically setting the TTL and I think Windows freaks out about that.
- ebb_earl_co 2y ago
  This seems like a good technique. What DNS software do you use?
  - Hamuko 2y ago
    I just use the one built into my UniFi router. Public DNS side is Cloudflare, which allows easy DNS validation for Let's Encrypt.
capitol_ 2y ago
Split DNS causes lots headaches, it also makes it really hard to root cause analysis of failures when they involve DNS.

ndsipa_pomu 2y ago

> be aware that these external names you're using for internal devices become a matter of public record this way Yes, I sometimes think about that, but have come to the conclusion that it's not likely to make any difference. If someone is trying to infiltrate my home network, then it's not going to really help them to know internal IP addresses as by the time they get to use them, they're already in.

qwertox 2y ago
You don't need to publish the IP addresses publicly if you use an internal DNS server. I think even Pi-hole could do this.
dspillett 2y ago
> If someone is trying to infiltrate my home network I don't think the publishing of host names was mentioned as a concern for small home networks, but more for larger organisations that might be subject to a coordinated break-in or simply have trade secrets¹² that might be hinted at by careless naming of resources. ---- [1] Their next big product/enhancement, as yet unannounced even within the company, for instance. [2] Hmm, checking what is recorded against one of DayJob's domains I see clues as to who some of our clients are. Not really a significant issue for security at all, but I know at least some of our contracts say we shouldn't openly talk about that we provide services to that client³ so I'll drop a message to the ISC to suggest we discuss if we need to care about the matter… [3] Though that is mostly in the form of not using their logos in our advertising and such.
- xena 2y ago
  That's why you have an internal domain that's not related to the company. Something like "packet-flinging.ninja". Everything's a tradeoff though.
  - deltaburnt 2y ago
    It seems really easy to associate a company with its internal domain though? Unless the company treats it as a secret only known between machines.

deleted 2y ago

[deleted]

prmoustache 2y ago

you can use a wildcard of type *.internal.example.com or use names that do not relate to the service name if you want to obfuscate the tech stack used. The only thing public is that you may have an internal network with nodes.

Eikon 2y ago

Shameless plug: https://www.merklemap.com/ https://www.merklemap.com/

js2 2y ago

Using a wildcard cert doesn't leak anything much. I went with `*.home.example.com` for my internal stuff.