Any ideas on how you would run SSL/TLS on these set-ups?
I think you can still run self signed, with a private CA/root cert?
.INTERNAL is now reserved for private-use applications
41–50 of 290 posts
Re: .INTERNAL is now reserved for private-use applications
#42[deleted]
Re: .INTERNAL is now reserved for private-use applications
#43Earlier quoted context omitted.
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.
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.
I think you're referring to the new gTLD process, which yes, costs a small boatload. Those aren't, and .intern isn't, a ccTLD, nor do I believe there is a means of acquiring a ccTLD (…outside of somehow becoming a country, I guess).
Re: .INTERNAL is now reserved for private-use applications
#44Are 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…
> 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.
Re: .INTERNAL is now reserved for private-use applications
#45Are 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 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.
Re: .INTERNAL is now reserved for private-use applications
#46My 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.
Re: .INTERNAL is now reserved for private-use applications
#47There 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.
On this topic, whoever owns "test.com" must be getting a lot of sensitive information.
Re: .INTERNAL is now reserved for private-use applications
#48I 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?
.example is used for examples in documentation and stuff like that.
.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.)
Re: .INTERNAL is now reserved for private-use applications
#49Are 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…
> leading Amazon's strategy for cloud-native AWS usage internally
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.
Re: .INTERNAL is now reserved for private-use applications
#50Earlier 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…
> .local is in this weird state where it's _technically_ not reserved […] I doubt ICANN will actually touch .local, but they could.
It is. See §2.2.1.2.1, "Reserved Names", of ICANN's gTLD Applicant Guidebook:
* https://newgtlds.icann.org/sites/default/files/guidebook-ful...