[dead]
.INTERNAL is now reserved for private-use applications
21–30 of 290 posts
Re: .INTERNAL is now reserved for private-use applications
#221. Buy .intern TLD 2. Sell to scammers. 3. Profit. (I want to appreciate how hard it probably is for ICANN to figure out proper TLDs.)
Amateur hour. Real professionals use .int domains...
Re: .INTERNAL is now reserved for private-use applications
#23Earlier quoted context omitted.
If you've got a couple hundred grant laying about, you could probably set up a shell company and acquire .intern through a several-year ccTLD acquisition process. I'd like to think people learned from .dev and such. I doubt any scammer will be able to use it.
Sorry, what happened with .dev? EDIT: just saw your comment about Google here https://news.ycombinator.com/item?id=41205394
To expand on my comment: Google bought .dev and started selling domains. In truth, developers probably only noticed because Google pre-loaded their .dev TLD into HSTS, which meant that any domain ending in .dev, even if it's a local one or one you own, must communicate over HTTPS if you want a browser to interact with it.
As a result, even if you bought steves-laptop.dev for yourself, you still wouldn't be able to run an HTTP dev environment on it, you'd need to set up HTTPS. I think that was probably a good move by Google, because otherwise it could've taken weeks for most devs to notice.
Re: .INTERNAL is now reserved for private-use applications
#24Are 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.
Re: .INTERNAL is now reserved for private-use applications
#25Earlier quoted context omitted.
.local is already reserved for mDNS.
.local is in this weird state where it's _technically_ not reserved, but most PCs in the world already resolve it with special non-DNS software because of the Bonjour/mDNS protocol. 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…
Modern windows supports mDNS these days!
Re: .INTERNAL is now reserved for private-use applications
#26Are 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 c…
Why? Remember the .dev debacle?
Re: .INTERNAL is now reserved for private-use applications
#27Are 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 c…
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.
Re: .INTERNAL is now reserved for private-use applications
#28I 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.)
Re: .INTERNAL is now reserved for private-use applications
#29I 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…
> 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?
Re: .INTERNAL is now reserved for private-use applications
#30Are 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 c…
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).