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://crt.sh/
So there are a bunch of cases where we only want the second (simpler, lower-risk) case, but we have to incur all the annoyance and risk and locked-down-ness of the first use-case.
That's because the purpose of certificate pinning is to protect software from the user. Letting you supply your own certificates would defeat the purpose of having them.
For example, you won't be able to run internal videocalls (no access to webcams!), or a web page able to scan QR codes.
Here's the full list:
* https://developer.mozilla.org/en-US/docs/Web/Security/Secure...
A true hassle for internal testing between hosts, to be honest. I just cannot run an in-development video app on my PC and connect from a phone or laptop to do some testing, without first worrying about certs at a point in development where they are superfluous and a loss of time.
As mentioned, some browser features are HTTPS only. You get security warnings on HTTP. Many tools now default to HTTPS by default - like newer SQL Server drivers. Dev env must resemble prod very closely so having HTTP in DEV and HTTPS in prod is asking for pain and trouble. It forces you to have some kind of expiration registry/monitoring and renewal procedures. And you happen to go throught dev env first and gain confidence and then prod.
Then there are systems where client certificate is mandatory and you want to familiarize yourself already in dev/test env.
Some systems even need additional configuration to allow OAuth via HTTP and that makes me feel dirty thus I rather not do it. Why do it if PROD won't have HTTP? And if one didn't know such configuration must be done, you'd be troubleshooting that system and figuring out why it doesn't work with my simple setup?
Yeah, we have internal CA set up, so issuing certs are pretty easy and mostly automated and once you go HTTPS all in, you get the experience why/how things work and why they may not and got more experience to troubleshoot HTTPS stuff. You have no choice actually - the world has moved to TLS secured protocols and there is no way around getting yourself familiar with security certificates.
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...
Made worse by the fact phone OSes have made it very difficult to install CAs.
Same with the .dev domain
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.
You can't just add the CA to system trust stores on each device, because some applications, notably browsers and java, use their own trust stores, you have to add it to.
You also can't scope the CA to just .internal, which means in a BYOD environment, you have to require your employees to trust you not to sign certs for other domains.
And then there is running the CA itself. Which is more difficult than using let's encrypt.
and the recommendation is to simply do "*.internal.example.com" with LetsEncrypt (using DNS-01 validation), so every client gets the correct CA cert "for free"
...
obviously if you want mTLS, then this doesn't help much. (but still, it's true that using a public domain has many advantages, as having an airgapped network too)
So don't use it?
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.
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.
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.
Of course, this is a bad idea, but it does allow you to avoid the "rent".
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.
Depending on your threat model, I'm not sure that's true. Encryption without verification prevents a passive observer from seeing the content of a connection, but does nothing to prevent an active MITM from decrypting it.
One of the (relatively few) things that frustrate me about GKE is the integration with GCP IAP and k8 gateways - it's a separate resource to the http route and if you fail to apply it, or apply one with invalid configuration then it fails open.
I'd much prefer an interface where I could specify my intention next to the route and have it fail atomically and/or fail closed
Well sure you can. You expose your internal DNS servers to the internet, or use the same DNS servers for both and they're on the internet. The root servers are not going to delegate a request for .internal to your nameservers, but anybody can make the request directly to your servers if they're publicly accessible.
When someone embeds https://test.internal with a cert validation turned off (rather then fingerprint pinning or setting up an internal CA) in their mobile application that client will greedily accept whatever response is provided by their local resolver... Correct or malicious.
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.
This is true, but using a regular domain name as your root does not require you to actually publish those DNS records on the Internet.
For example, say that you own the domain `example.com`. You can build a private service `foo.example.com` and only publish its DNS records within the networks where it needs to be resolved – in exactly the same way that you would with `foo.internal`.
If you ever decide that you want an Internet-facing endpoint, just publish `foo.example.com` in public DNS.
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?
dnsmasq has this feature. I think it’s commonly available in alternative router firmware.
On my home network, I set up https://pi-hole.net/ for ad blocking, and it uses dnsmasq too. So as my network’s DHCP + DNS server, it automatically adds dns entries for dhcp leases that it hands out.
There are undoubtably other options, but these are the two I’ve worked with.
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.
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.
And the larger the scale, to more benefits you get from avoiding internal-specific resolution.
On the contrary, it is helpful to make this is impossible. Otherwise you invite leaking private info by configuration mistake.
Proposed top-level domain string for private use: ".internal"
(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.)
There's already .example, .invalid, .test and .localhost; which are reserved. What usecase do you have that's not covered by one of them?
.invalid means that a domain name is required but a valid name should not be used; for example, a false email address in a "From:" header in Usenet, to indicate that you cannot send email to the author in this way.
.test is for a internal testing use, of DNS and other stuff.
.localhost is for identifying the local computer.
.internal is (presumably) for internal use in your own computer and local network, when you want to assign domain names that are for internal use only.
.pseudo is for other cases that do not fit any of the above, when a pseudo-TLD which is not used as a usual domain name, is required for a specialized use by a application, operating system, etc. You can then assign subdomains of .pseudo for specific kind of specialized uses (these assignments will be specific to the application or otherwise). Some programs might treat .pseudo (or some of its subdomains) as a special case, or might be able to be configured to do so.
(One example of .pseudo might be if you want to require a program to use only version 4 internet or only version 6 internet, and where this must be specified in the domain name for some reason; the system or a proxy server can then handle it as a special case. Other examples might be in some cases, error simulations, non-TCP/IP networks, specialized types of logging or access restrictions, etc. Some of these things do not always need to be specified as a domain name; but, in some cases they do, and in such cases then it is helpful to do so.)
Ref: https://www.icann.org/en/board-activities-and-meetings/mater...
So you end up with the IETF standardising .local, because Apple was already using it, but ICANN never did much with that standardisation.
I doubt ICANN will actually touch .local, but they could. One could imagine a scheme where .local is globally registered to prevent Windows clients (who don't always support mDNS) from resolving .local domains wrong.
.internal is just admitting there's only so many times we can repeat the same mistake before we start to look silly.
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]).
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.
The advantage is that I can run real letsencrypt certs for services in my house, which is nicer than having to agree to self signed cert warnings or otherwise having my browser nag me about plaintext passwords/etc.
If anyone cares about the details, I run an nginx instance on port 80 through an ipv6 address which I allow through my network firewall (no NAT, so I don’t have to burn my only incoming ipv4 port 80 for this, although I block that anyway) and let certbot manage its configs. Wildcard external dns pointing AAAA records to said v6 address. The certbot vhost just renders an empty 404 for all requests except for the ACME challenges, so there’s nothing being “leaked” except generic 404 headers. I get certs dumped to my nginx config dir, then from there I use them for an internal-only reverse proxy listening on my local subnet, for all my internal stuff. The only risk is if I mess up the config and expose the RP to the internet, but so far I haven’t managed to screw it up.
2. Sell to scammers.
3. Profit.
(I want to appreciate how hard it probably is for ICANN to figure out proper TLDs.)
I'd like to think people learned from .dev and such. I doubt any scammer will be able to use it.
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 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.
Like .lnternal
Or .ιnternal
