[HN Gopher] .INTERNAL is now reserved for private-use applications
___________________________________________________________________
.INTERNAL is now reserved for private-use applications
Author : joncfoo
Score : 101 points
Date : 2024-08-09 16:36 UTC (6 hours ago)
(HTM) web link (www.icann.org)
(TXT) w3m dump (www.icann.org)
| joncfoo wrote:
| [...] 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.
| csdreamer7 wrote:
| Can we get .local or .l added for private-use applications too?
| kxrm wrote:
| Is it not already?
|
| https://en.wikipedia.org/wiki/.local
| csdreamer7 wrote:
| Not by ICANN? https://www.iana.org/domains/root/db
| duskwuff wrote:
| The ICANN root zone only contains gTLDs and ccTLDs which
| are delegated. Other TLDs which are explicitly reserved for
| non-public use, like .localhost, .test, or .invalid, don't
| appear on that list either.
| quectophoton wrote:
| I think a more correct place to look at would be the gTLD
| Applicant Guidebook[1][2], section "2.2.1.2.1 Reserved
| Names", which I guess should be updated to now include
| "INTERNAL".
|
| Though that list apparently includes all reserved names,
| not only those reserved for non-public use.
|
| [1]: https://newgtlds.icann.org/en/applicants/agb
|
| [2]:
| https://newgtlds.icann.org/sites/default/files/guidebook-
| ful...
| csdreamer7 wrote:
| Ty for the information.
| duskwuff wrote:
| .local is already reserved for mDNS.
| jeroenhd wrote:
| .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 globally registered to
| prevent Windows clients (who don't always support mDNS) from
| resolving .local domains wrong.
| arjvik wrote:
| Modern windows supports mDNS these days!
| candiddevmike wrote:
| 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 Kubernetes (one of the
| biggest .local violators), they should really change the
| default domain...
| wlonkly wrote:
| 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.
| throw0101d wrote:
| > _.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 SS2.2.1.2.1, "Reserved Names", of ICANN's _gTLD
| Applicant Guidebook_ :
|
| * https://newgtlds.icann.org/sites/default/files/guidebook-
| ful...
| tetris11 wrote:
| I need a dumbed down version of this.
| kijeda wrote:
| https://www.ietf.org/archive/id/draft-davies-internal-tld-00...
|
| 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]).
| pixl97 wrote:
| 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.
| GuB-42 wrote:
| 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.
| jeroenhd wrote:
| 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.
| quectophoton wrote:
| 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.
| huijzer wrote:
| 1. 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.)
| gjsman-1000 wrote:
| 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.
| jeroenhd wrote:
| 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.
| LordKeren wrote:
| Sorry, what happened with .dev?
|
| EDIT: just saw your comment about Google here
|
| https://news.ycombinator.com/item?id=41205394
| n_plus_1_acc wrote:
| People were using .dev for internal things and acted
| surprised when Google decided to use it on the internet.
| jeroenhd wrote:
| 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.
| deathanatos wrote:
| 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).
| pimlottc wrote:
| Amateur hour. Real professionals use .int domains...
|
| https://www.iana.org/domains/int
| colejohnson66 wrote:
| What about .intern.al?
| ChrisArchitect wrote:
| Bunch more discussion on the proposal earlier in the year:
|
| _Proposed top-level domain string for private use: ".internal"_
|
| https://news.ycombinator.com/item?id=39152306
| jcrites wrote:
| 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.
| colejohnson66 wrote:
| Why? Remember the .dev debacle?
| leeter wrote:
| 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.
| jcrites wrote:
| > Having DNS records leak could actually provide potential
| information on things you'd rather not have public.
|
| 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.
| leeter wrote:
| I'm not disagreeing at all. But Hanlon's Razor applies:
|
| > Never attribute to malice what can better be explained by
| incompetence
|
| You can't leak information if you never give access to that
| zone in any way. More than once I've run into well meaning
| developers in my time. Having a .internal inherently
| documents that something shouldn't be public. Whereas
| foo.example.com does not.
| zzo38computer wrote:
| 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).
| quectophoton wrote:
| > 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.
| bawolff wrote:
| 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.
| samstave wrote:
| 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?)
| mnahkies wrote:
| 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
| pid-1 wrote:
| > 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.
| ghshephard wrote:
| 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.
| zzo38computer wrote:
| 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.)
| Denvercoder9 wrote:
| > 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?
| zzo38computer wrote:
| .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.)
| 2snakes wrote:
| 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.
| quectophoton wrote:
| On this topic, whoever owns "test.com" must be getting a lot of
| sensitive information.
| xvilo wrote:
| Any ideas on how you would run SSL/TLS on these set-ups?
| the8472 wrote:
| 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.
| rileymat2 wrote:
| I think you can still run self signed, with a private CA/root
| cert?
| 8organicbits wrote:
| 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.
|
| [1] https://www.getlocalcert.net/
| xer0x wrote:
| Oh neat, thanks for sharing this idea
| wolpoli wrote:
| Anyone know when I should use .internal and when I should use
| .local?
___________________________________________________________________
(page generated 2024-08-09 23:00 UTC)