My biggest frustration with .internal is that it requires a private certificate authority. Lots of organizations struggle to fully set up trust for the private CA on all internal systems. When you add BYOD or contractor systems, it's a mess.
Using a publicly valid domain offers a number of benefits, like being able to use a free public CA like Lets Encrypt. Every machine will trust your internal certificates out of the box, so there is minimal toil.
Last year I built getlocalcert [1] as a free way to automate this approach. It allows you to register a subdomain, publish TXT records for ACME DNS certificate validation, and use your own internal DNS server for all private use.
Just be mindful that any certs you issue in this way will be public information[1] so make sure the domain names don't give away any interesting facts about your infrastructure or future product ideas.
I did this at my last job as well and I can still see them renewing them, including an unfortunate wildcard cert which wasn't me.
The problem with internal CAs is also that it's really hard to add them on some OSes now. Especially on android since version 7 IIRC, you can no longer get certs into the system store, and every app is free to ignore the user store (I think it was even the default to ignore it). So a lot of apps will not work with it.
Do you mean to say that your biggest frustration with HTTPS on .internal is that it requires a private certificate authority? Because I'm running plain HTTP to .internal sites and it works fine.
It would be impossible for .internal domains to be publicly CAed, because they're non-unique; the whole point of .internal domains is that, just like private-use IP space, anyone can reuse the same .internal DNS names within their own organization.
X.509 trust just doesn't work if multiple entities can get a cert for the same CN under the same root-of-trust, as then one of the issuees can impersonate the other.
If public issuers would sign .internal certs, then presuming you have access to a random org's intranet, you could MITM any machine in that org by first setting up your own intranet with its own DNS, creating .internal records in it, getting a public issuer to issue certs for those domains, and then using those certs to impersonate the .internal servers in the org-intranet you're trying to attack.
I don’t understand the frustration. The use of .internal is explicitly for when you don’t want a publicly valid domain. Nobody is forcing anyone to use .internal otherwise.
This is why I'm using a FQDN for my home lab, I'm not going to setup a private CA for this, I can just use ACME-dns and get a cert that will work everywhere, for free!
Are there any good reasons to use a TLD like .internal for private-use applications, rather than just a regular gTLD like .com?
It's nice that this is available, but if I was building a new system today that was internal, I'd use a regular domain name as the root. There are a number of reasons, and one of them is that it's incredibly nice to have the flexibility to make a name visible on the Internet, even if it is completely private and internal.
You might want private names to be reachable that way if you're following a zero-trust security model, for example; and even if you aren't, it's helpful to have that flexibility in the future. It's undesirable for changes like these to require re-naming a system.
Using names that can't be resolved from the Internet feels like all downside. I think I'd be skeptical even if I was pretty sure that a given system would not ever need to be resolved from the Internet. [Edit:] Instead, you can use a domain name that you own publicly, like `example.com`, but only ever publish records for the domain on your private network, while retaining the option to publish them publicly later.
When I was leading Amazon's strategy for cloud-native AWS usage internally, we decided on an approach for DNS that used a .com domain as the root of everything for this reason, even for services that are only reachable from private networks. These services also employed regular public TLS certificates too (by default), for simplicity's sake. If a service needs to be reachable from a new network, or from the Internet, then it doesn't require any changes to naming or certificates, nor any messing about with CA certs on the client side. The security team was forward-thinking and was comfortable with this, though it does have tradeoffs, namely that the presence of names in CT logs can reveal information.
Number one reason that comes to mind is you prevent the possibility of information leakage. You can't screw up your split-dns configuration and end up leaking your internal IP space if everything is .internal.
It's much the same reason why some very large IPv6 services deploy some protected IPv6 space in RFC4193 FC::/7 space. Of course you have firewalls. And of course you have all sorts of layers of IDS and air-gaps as appropriate. But, if by design you don't want to make this space reachable outside the enterprise - the extra steps are a belt and suspenders approach.
So, even if I mess up my firewall rules and do leak a critical control point: FD41:3165:4215:0001:0013:50ff:fe12:3456 - you wouldn't be able to route to it anyways.
Same thing with .internal - that will never be advertised externally.
> Are there any good reasons to use a TLD like .internal for private-use applications, rather than just a regular gTLD like .com?
That assumes you are able to pay to rent a domain name, and keep paying for it, and that you are reasonably sure that the company you're renting it from is not going to take it away from you because of a selectively-enforced TOS, and that you are reasonably sure that both yourself and your registrar are doing anything possible to avoid getting your account compromised (resulting in your domain being transferred to someone else's and probably lost forever unless you can take legal action).
So it might depend on your threat model.
Also, a good example, and maybe the main reason for this specific name instead of other proposals, is that big corps are already using it (e.g. DNS search domains in AWS EC2 instances) and don't want someone else to register it.
I just got burned on my home network by running my own CA (.home) and DNS for connected devices. The Android warning when installing a self-signed CA ('someone may be monitoring this network') is fine for my case, if annoying, but my current blocker is using webhooks from a security camera to Home Assistant.
HA allows you to use a self-signed cert, but if you turn on HTTPS, your webhook endpoints must also use HTTPS with that cert. The security camera doesn't allow me to mess with its certificate store, so it's not going to call a webhook endpoint with a self-signed/untrusted root cert.
Sure, I could probably run a HTTP->HTTPS proxy that would ignore my cert, but it all starts to feel like a massive kludge to be your own CA. Once again, we're stuck in this annoying scenario where certificates serve 2 goals: encryption and verification, but internal use really only cares about the former.
Trying to save a few bucks by not buying a vanity domain for internal/test stuff just isn't worth the effort. Most systems (HA included) support ACME clients to get free certs, and I guess for IoT stuff, you could still do one-off self-signed certs with long expiration periods, since there's no way to automate rotation of wildcards for LE.
I think there is a benefit that it reduces possibility of misconfiguration. You can't accidentally publish .internal. If you see a .internal name, there is never any possibility of confusion on that point.
I can't speak for others but HSTS is a major reason. Not everybody wants to deal with setting up certs for every single application on a network but they want HSTS preload externally. I get why for AWS the solution of having everything from a .com works. But for a lot of small businesses it's just more than they want to deal with.
Another reason is information leakage. Having DNS records leak could actually provide potential information on things you'd rather not have public. Devs can be remarkably insensitive to the fact they are leaking information through things like domains.
Sometimes it may be reasonable to use subdomains of other domain names that you have registered, but I would think that sometimes it would not be appropriate, such as if you are not using it with internet at all and therefore should not need to register a domain name, or for other reasons; if it is not necessary to use internet domain names then you would likely want to avoid it (or, at least, I would).
>Are there any good reasons to use a TLD like .internal for private-use applications, rather than just a regular gTLD like .com?
These local TLDs should IMO be used on all home routers, it fixes a lot of problems.
If you've ever plugged in e.g. a raspberry pi and been unable to "ping pi" it it's because there is no DNS mapping to it. There are cludges that Windows, Linux, and Macs use to get around this fact, but they only work in their own ecosystem, so you often can't see macs from e.g. windows, it's a total mess that leads confusing resolution behaviour, you end up having to look in the router page or hardcode the IP to reach a device which is just awful.
Home routers can simply assign pi into e.g. pi.home when doing dhcp. Then you can "ping pi" on all systems. It fixes everything- for that reason alone these reserved TLDs are, imo, useful. Unfortunately I've never seen a router do this, but here's hoping.
A big area are consumer devices like WiFi routers. They can advertise the .internal name and probably even get TLS certificates for those names and things may work.
See for instance the trouble with AVM's fritz.box domain, which was used by their routers by default, then .box wasade an TLD and AVM was too late to register it.
Pretty much "anything that has to use a real network address, resolved via DNS" rather than using the hosts file based loopback device, or the broadcast IP.
I think it is good to have a .internal TLD for internal use.
(I also think that a .pseudo TLD should be made up which also cannot be assigned on the internet, but is also not for assigning on local networks either. Uusually, in the cases where it is necessary to be used, either the operating system or an application program will handle them, although the system administrator can assign them manually on a local system if necessary.)
> I also think that a .pseudo TLD should be made up which also cannot be assigned on the internet, but is also not for assigning on local networks either.
There's already .example, .invalid, .test and .localhost; which are reserved. What usecase do you have that's not covered by one of them?
[...] the Board reserves .INTERNAL from delegation in the DNS root zone permanently to provide for its use in private-use applications. The Board recommends that efforts be undertaken to raise awareness of its reservation for this purpose through the organization's technical outreach.
Ever since this kind of stuff was introduced I've been annoyed that there is no way to disable it for yourself. And it's allowed for straight up evil stuff like google buying the .dev TLD
Your mention of .dev seems like a complete non-sequiter to me. What happened to .internal here is the exact opposite of what happened to .dev. And how would you even propose to "disable" reservation of a TLD. Sorry your comment just makes no sense from my POV.
There used to be issues with the public part of a .com getting sent weird private windows traffic iirc. This was discovered with honeypot analysis and the potential for information exposure if you could register a .com and another company was using it as their AD domain.
The dumbed down version is that no one will be allowed to register a .internal domain on the internet, ever. So you are free to use it for your internal network in any way you like and it will not come into conflict with registered domains and internet standard.
Remember how tons of developers got surprised when Google got the .dev TLD, because they were using domains they didn't own to develop software? Well, now .internal has been reserved so developers and companies can safely use .internal domains without that happening to them.
When setting up local networks people commonly use a top level domain like 'my.lan', 'my.network', 'my.local'. Instead of using one of these non-reserved domains that may one day end up as a TLD, it is recommended to use 'my.internal'.
If the 'private' TLD you're using suddenly becomes real, then you can ship off data, every possibly unencrypted data and connection requests to computers you do not control.
There are certain circumstances where private network operators may wish to use their own domain naming scheme that is not intended to be used or accessible by the global domain name system (DNS), such as within closed corporate or home networks.
The "internal" top-level domain is reserved to provide this purpose in the DNS. Such domains will not resolve in the global DNS, but can be configured within closed networks as the network operator sees fit.
This reservation is intended for a similar purpose that private-use IP address ranges that are set aside (e.g. [RFC1918]).
When you need to assign an IP address for a host, the safest thing to do is to either use an IP address you own^Ware renting, or to use an IP address nobody will be able to "own" in the foreseeable future.
This is that but for domain names. When you need to use a domain name to refer to a host, the safest thing to do is to either use a domain name you own^Ware renting, or to use a domain name nobody will be able to "own" in the foreseeable future.
For an IP address, you might usually choose from 192.168.0.0/16 or similar reserved ranges. Your "192.168.1.1" is not the same as my "192.168.1.1", we both can use it and neither of us can "officially" own it.
For a domain name, you can use ".internal" or other similar (if uglier) reserved TLDs. Your "nas.internal" is not the same as my "nas.internal", we both can use it and neither of us can "officially" own it.
Since you're asking this question you might also be wondering how people can even use custom domains like that, and the answer is by self-hosting a DNS server, and using that as a DNS server instead of a public one (so you'd use your self-hosted server instead of, say, "8.8.8.8"). Then you configure your DNS server so that whenever someone requests "google.com" it does "the normal thing", but when someone requests "nas.internal" it returns whatever IP address you want.
Is there an appliance or offline service to setup a private CA, do secure remote attestation, and issue certificates only to authenticated peers? Also preferably with fido2 support for administrative purposes.
Um... no? .intern is not a valid TLD; you can't get any domains with it, nobody has proposed that TLD, and if someone did that issue would be discovered then.
Things like this are rarely simple or obvious. I don't know what potential gotchas there could have been, but I'm sure there were strange and unusual things they had to carefully consider before making this an official standard.
An internal certificate authority would probably be the easiest option. Combined with MDM/group policy, you could tell most devices in your network to set up a trust chain of your own. From then on you can automate access by running your own ACME server internally to automatically hand out certificates to local devices.
The automated setup probably isn't very secure, though. Anyone can register any .local name on the network, so spoofing hostnames becomes very easy once you get access to any device on the network. Send a fax with a bad JPEG and suddenly your office printer becomes xvilo.local, and the ACME server has no way to determine that it's not.
That means you probably need to deal with manual certificate generation, manually renewing your certificates every two years (and, if you're like me, forgetting to before they expire).
I just got myself a proper domain name. You can get a domain for pretty cheap if you're not picky about what you get. You could for example register cottagecheese.download on Cloudflare for about $5/year right now.
I have my domain's DNS on Cloudflare, so I can use DNS verification with Let's Encrypt to get myself a proper certificate that works on all of my devices. Then I just have Cloudflare DNS set up with a bunch of CNAME records to .internal addresses.
For example, if I needed to set up a local mail server, I'd set mail.cottagecheese.download to have a CNAME record pointing to localserver.internal and then have my router resolve localserver.internal to my actual home server's IP address. So if I punch in https://mail.cottagecheese.download in my browser, the browser resolves that to localserver.internal and then my router resolves that to 10.x.x.x/32, sending me to my internal home server that greets me with a proper Let's Encrypt certificate without any need to expose my internal IP addresses.
Windows doesn't seem to like my CNAME-based setup though. Every time I try to use them, it's a diceroll if it actually works.
Either pin the appropriate server cert in each application or run your internal CA (scoped to that domain via name constriants) and deploy the root cert to all client machines.
Now we just wait until browsers stop doing a search if you type anything ending with .internal, which is the biggest issue with using non standard private domains.
8organicbits|1 year ago
Using a publicly valid domain offers a number of benefits, like being able to use a free public CA like Lets Encrypt. Every machine will trust your internal certificates out of the box, so there is minimal toil.
Last year I built getlocalcert [1] as a free way to automate this approach. It allows you to register a subdomain, publish TXT records for ACME DNS certificate validation, and use your own internal DNS server for all private use.
[1] https://www.getlocalcert.net/
prussian|1 year ago
[1] https://crt.sh/
wkat4242|1 year ago
yjftsjthsd-h|1 year ago
AndyMcConachie|1 year ago
The SSAC's recommendation is to only use .INTERNAL if using a publicly registered domain name is not an option. See Section 4.2.
https://itp.cdn.icann.org/en/files/security-and-stability-ad...
mschuster91|1 year ago
Made worse by the fact phone OSes have made it very difficult to install CAs.
derefr|1 year ago
X.509 trust just doesn't work if multiple entities can get a cert for the same CN under the same root-of-trust, as then one of the issuees can impersonate the other.
If public issuers would sign .internal certs, then presuming you have access to a random org's intranet, you could MITM any machine in that org by first setting up your own intranet with its own DNS, creating .internal records in it, getting a public issuer to issue certs for those domains, and then using those certs to impersonate the .internal servers in the org-intranet you're trying to attack.
layer8|1 year ago
jacooper|1 year ago
seb1204|1 year ago
7bit|1 year ago
So don't use it?
xer0x|1 year ago
TheRealPomax|1 year ago
jcrites|1 year ago
It's nice that this is available, but if I was building a new system today that was internal, I'd use a regular domain name as the root. There are a number of reasons, and one of them is that it's incredibly nice to have the flexibility to make a name visible on the Internet, even if it is completely private and internal.
You might want private names to be reachable that way if you're following a zero-trust security model, for example; and even if you aren't, it's helpful to have that flexibility in the future. It's undesirable for changes like these to require re-naming a system.
Using names that can't be resolved from the Internet feels like all downside. I think I'd be skeptical even if I was pretty sure that a given system would not ever need to be resolved from the Internet. [Edit:] Instead, you can use a domain name that you own publicly, like `example.com`, but only ever publish records for the domain on your private network, while retaining the option to publish them publicly later.
When I was leading Amazon's strategy for cloud-native AWS usage internally, we decided on an approach for DNS that used a .com domain as the root of everything for this reason, even for services that are only reachable from private networks. These services also employed regular public TLS certificates too (by default), for simplicity's sake. If a service needs to be reachable from a new network, or from the Internet, then it doesn't require any changes to naming or certificates, nor any messing about with CA certs on the client side. The security team was forward-thinking and was comfortable with this, though it does have tradeoffs, namely that the presence of names in CT logs can reveal information.
ghshephard|1 year ago
It's much the same reason why some very large IPv6 services deploy some protected IPv6 space in RFC4193 FC::/7 space. Of course you have firewalls. And of course you have all sorts of layers of IDS and air-gaps as appropriate. But, if by design you don't want to make this space reachable outside the enterprise - the extra steps are a belt and suspenders approach.
So, even if I mess up my firewall rules and do leak a critical control point: FD41:3165:4215:0001:0013:50ff:fe12:3456 - you wouldn't be able to route to it anyways.
Same thing with .internal - that will never be advertised externally.
quectophoton|1 year ago
That assumes you are able to pay to rent a domain name, and keep paying for it, and that you are reasonably sure that the company you're renting it from is not going to take it away from you because of a selectively-enforced TOS, and that you are reasonably sure that both yourself and your registrar are doing anything possible to avoid getting your account compromised (resulting in your domain being transferred to someone else's and probably lost forever unless you can take legal action).
So it might depend on your threat model.
Also, a good example, and maybe the main reason for this specific name instead of other proposals, is that big corps are already using it (e.g. DNS search domains in AWS EC2 instances) and don't want someone else to register it.
briHass|1 year ago
HA allows you to use a self-signed cert, but if you turn on HTTPS, your webhook endpoints must also use HTTPS with that cert. The security camera doesn't allow me to mess with its certificate store, so it's not going to call a webhook endpoint with a self-signed/untrusted root cert.
Sure, I could probably run a HTTP->HTTPS proxy that would ignore my cert, but it all starts to feel like a massive kludge to be your own CA. Once again, we're stuck in this annoying scenario where certificates serve 2 goals: encryption and verification, but internal use really only cares about the former.
Trying to save a few bucks by not buying a vanity domain for internal/test stuff just isn't worth the effort. Most systems (HA included) support ACME clients to get free certs, and I guess for IoT stuff, you could still do one-off self-signed certs with long expiration periods, since there's no way to automate rotation of wildcards for LE.
bawolff|1 year ago
leeter|1 year ago
Another reason is information leakage. Having DNS records leak could actually provide potential information on things you'd rather not have public. Devs can be remarkably insensitive to the fact they are leaking information through things like domains.
zzo38computer|1 year ago
macromaniac|1 year ago
These local TLDs should IMO be used on all home routers, it fixes a lot of problems.
If you've ever plugged in e.g. a raspberry pi and been unable to "ping pi" it it's because there is no DNS mapping to it. There are cludges that Windows, Linux, and Macs use to get around this fact, but they only work in their own ecosystem, so you often can't see macs from e.g. windows, it's a total mess that leads confusing resolution behaviour, you end up having to look in the router page or hardcode the IP to reach a device which is just awful.
Home routers can simply assign pi into e.g. pi.home when doing dhcp. Then you can "ping pi" on all systems. It fixes everything- for that reason alone these reserved TLDs are, imo, useful. Unfortunately I've never seen a router do this, but here's hoping.
Also, p. sure I grew up playing wc3 w you?
johannes1234321|1 year ago
See for instance the trouble with AVM's fritz.box domain, which was used by their routers by default, then .box wasade an TLD and AVM was too late to register it.
colejohnson66|1 year ago
pid-1|1 year ago
I've been on the other end of the business scale for the past decade, mostly working for SMBs like hedge funds.
That made me a huge private DNS hater. So much trouble for so little security gain.
Still, it seems common knowledge is to use private DNS for internal apps, AD and such, LAN hostnames and likes.
I've been using public DNS exclusively everywhere I've worked and I always feel like it's one of the best arch decisions I'm bringing to the table.
TheRealPomax|1 year ago
layer8|1 year ago
slashdave|1 year ago
On the contrary, it is helpful to make this is impossible. Otherwise you invite leaking private info by configuration mistake.
dawnerd|1 year ago
undersuit|1 year ago
spartanatreyu|1 year ago
TheRealPomax|1 year ago
ChrisArchitect|1 year ago
Proposed top-level domain string for private use: ".internal"
https://news.ycombinator.com/item?id=39152306
zzo38computer|1 year ago
(I also think that a .pseudo TLD should be made up which also cannot be assigned on the internet, but is also not for assigning on local networks either. Uusually, in the cases where it is necessary to be used, either the operating system or an application program will handle them, although the system administrator can assign them manually on a local system if necessary.)
Denvercoder9|1 year ago
There's already .example, .invalid, .test and .localhost; which are reserved. What usecase do you have that's not covered by one of them?
csdreamer7|1 year ago
eddyg|1 year ago
Ref: https://www.icann.org/en/board-activities-and-meetings/mater...
duskwuff|1 year ago
kxrm|1 year ago
https://en.wikipedia.org/wiki/.local
mjevans|1 year ago
LeoPanthera|1 year ago
joncfoo|1 year ago
NietTim|1 year ago
NewJazz|1 year ago
2snakes|1 year ago
quectophoton|1 year ago
Filligree|1 year ago
throwaway290|1 year ago
tetris11|1 year ago
GuB-42|1 year ago
jeroenhd|1 year ago
pixl97|1 year ago
If the 'private' TLD you're using suddenly becomes real, then you can ship off data, every possibly unencrypted data and connection requests to computers you do not control.
kijeda|1 year ago
There are certain circumstances where private network operators may wish to use their own domain naming scheme that is not intended to be used or accessible by the global domain name system (DNS), such as within closed corporate or home networks.
The "internal" top-level domain is reserved to provide this purpose in the DNS. Such domains will not resolve in the global DNS, but can be configured within closed networks as the network operator sees fit.
This reservation is intended for a similar purpose that private-use IP address ranges that are set aside (e.g. [RFC1918]).
quectophoton|1 year ago
This is that but for domain names. When you need to use a domain name to refer to a host, the safest thing to do is to either use a domain name you own^Ware renting, or to use a domain name nobody will be able to "own" in the foreseeable future.
For an IP address, you might usually choose from 192.168.0.0/16 or similar reserved ranges. Your "192.168.1.1" is not the same as my "192.168.1.1", we both can use it and neither of us can "officially" own it.
For a domain name, you can use ".internal" or other similar (if uglier) reserved TLDs. Your "nas.internal" is not the same as my "nas.internal", we both can use it and neither of us can "officially" own it.
Since you're asking this question you might also be wondering how people can even use custom domains like that, and the answer is by self-hosting a DNS server, and using that as a DNS server instead of a public one (so you'd use your self-hosted server instead of, say, "8.8.8.8"). Then you configure your DNS server so that whenever someone requests "google.com" it does "the normal thing", but when someone requests "nas.internal" it returns whatever IP address you want.
layer8|1 year ago
AndyMcConachie|1 year ago
myshkin5|1 year ago
gxt|1 year ago
huijzer|1 year ago
2. Sell to scammers.
3. Profit.
(I want to appreciate how hard it probably is for ICANN to figure out proper TLDs.)
pimlottc|1 year ago
https://www.iana.org/domains/int
colejohnson66|1 year ago
gjsman-1000|1 year ago
VoodooJuJu|1 year ago
poikroequ|1 year ago
Hamuko|1 year ago
wolpoli|1 year ago
Macha|1 year ago
https://en.wikipedia.org/wiki/.local
SoftTalker|1 year ago
mmooss|1 year ago
[deleted]
xvilo|1 year ago
jeroenhd|1 year ago
The automated setup probably isn't very secure, though. Anyone can register any .local name on the network, so spoofing hostnames becomes very easy once you get access to any device on the network. Send a fax with a bad JPEG and suddenly your office printer becomes xvilo.local, and the ACME server has no way to determine that it's not.
That means you probably need to deal with manual certificate generation, manually renewing your certificates every two years (and, if you're like me, forgetting to before they expire).
Hamuko|1 year ago
I have my domain's DNS on Cloudflare, so I can use DNS verification with Let's Encrypt to get myself a proper certificate that works on all of my devices. Then I just have Cloudflare DNS set up with a bunch of CNAME records to .internal addresses.
For example, if I needed to set up a local mail server, I'd set mail.cottagecheese.download to have a CNAME record pointing to localserver.internal and then have my router resolve localserver.internal to my actual home server's IP address. So if I punch in https://mail.cottagecheese.download in my browser, the browser resolves that to localserver.internal and then my router resolves that to 10.x.x.x/32, sending me to my internal home server that greets me with a proper Let's Encrypt certificate without any need to expose my internal IP addresses.
Windows doesn't seem to like my CNAME-based setup though. Every time I try to use them, it's a diceroll if it actually works.
rileymat2|1 year ago
the8472|1 year ago
ryukoposting|1 year ago
ahoka|1 year ago
Arch-TK|1 year ago
unknown|1 year ago
[deleted]
unknown|1 year ago
[deleted]
amelius|1 year ago
Like .lnternal
Or .ιnternal
endorphine|1 year ago
zigzag312|1 year ago
mmooss|1 year ago
[deleted]
shrimp_emoji|1 year ago
[deleted]
vedangvatsa|1 year ago
[deleted]
PufPufPuf|1 year ago