Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.INTERNAL is now reserved for private-use applications

icann.org

Post reply on HN
Print view View original

51–60 of 290 posts

Re: .INTERNAL is now reserved for private-use applications

#51

Post by samstave »

bawolff wrote: post #45
jcrites wrote: post #24

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 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.

This. And it allows for much easier/trustworthy automated validation of [pipeline] - such as ensuring that something doesnt leak, exfil, egress inadvertently. (even perhaps with exclusive/unique routing?)

Re: .INTERNAL is now reserved for private-use applications

#52

Post by ghshephard »

jcrites wrote: post #24

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 c…

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.

Re: .INTERNAL is now reserved for private-use applications

#53

Post by mnahkies »

bawolff wrote: post #45
jcrites wrote: post #24

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 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.

Somewhat off topic, but I'm a big fan of fail safe setups.

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

Re: .INTERNAL is now reserved for private-use applications

#54

Post by wlonkly »

candiddevmike wrote: post #36
jeroenhd wrote: post #19

Earlier quoted context omitted.

.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…

It's reserved per RFC 6762: > This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local. https://datatracker.ietf.org/doc/html/rfc6762 Applications can/will break if you attempt to use .local outside of mDNS (such as systemd-resolved). Don't get upset when this happens. Interesting fact: RFC 6762 predates Kubernet…

But that's an IETF standard, not an ICANN policy. AFAIK there's nothing in place today that would _prevent_ ICANN from granting .local to a registry other than it just being a bad idea.

Re: .INTERNAL is now reserved for private-use applications

#57

Post by xer0x »

8organicbits wrote: post #46

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 t…

Oh neat, thanks for sharing this idea

Re: .INTERNAL is now reserved for private-use applications

#59

Post by [deleted] »

ghshephard wrote: post #52
jcrites wrote: post #24

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 c…

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…

[deleted]
Post reply on HN