What would be a better tld than .dev? [Feedback welcome]

[typicode]

Since .dev is a registered domain, sometimes it creates problem on OS X + Chrome like this one:
#215 ERR_ICANN_NAME_COLLISION

Unfortunately, .hotel is also a registered name ^^' so the next hotel default tld should be something unique and unregistered to avoid conflicts.

What do you think would be a good tld for projects served by hotel :) ?

http://app.<some new tld>

Note: it can be anything there's no particular restriction for this local tld

[kyleparisi]

.local

[typicode]

Hmm thought about this one too, but it seems to be used by other tools as it's quite common and to have some particular behavior on OS X (searched for local domain OS X on Google and there's also this page https://support.apple.com/en-us/HT201275)

[kyleparisi]

.test or .localhost maybe

[typicode]

.test is nice since it's short, but it feels weird because I would associate it with testing.
.localhost is explicit but a little longer to type.

Local servers would look like this then:

http://app.localhost
http://express-app.localhost
# ...

BTW, got another suggestion for .localhost on Twitter

[kyleparisi]

It's a shame .🏨 can't be used haha. Beyond the above I can only imagine using 'hotel' terms. Such as .porter or .lobby.

[typicode]

From https://twitter.com/wmhilton/status/900694844976320512
.this, .self., .here

and a list of already registered domains
http://data.iana.org/TLD/tlds-alpha-by-domain.txt

[typicode]

It's a shame .🏨 can't be used haha. Beyond the above I can only imagine using 'hotel' terms. Such as .porter or .lobby.

Totally agree :D that would be way easier. Nice ideas, I haven't thought of them.

[fengb]

http://www.faqs.org/rfcs/rfc2606.html - reserved TLDs guaranteed to never collide:

• .test
• .example
• .invalid
• .localhost - I like this the best

[indrakaw]

• .lan Local Area Network
• .wan Wide Area Network
• .man Metropolitan Area Network
• .wlan Wireless Local Area Network
• .san Storage Area Network
• .can Controller Area Network
• .pan Personal Area Network
• .gan Global Area Network
• .ian Internet Area Network

[EvertEt]

  The ".localhost" TLD has traditionally been statically defined in
  host DNS implementations as having an A record pointing to the
  loop back IP address and is reserved for such use.  Any other use
  would conflict with widely deployed code which assumes this use.

Localhost seems like a dangerous choice.

I like the shorter ones as suggested by @indrakaw (.lan for example)

[fengb]

@EvertEt I don't see that as a problem since the proxy is literally trying to point at localhost, and it's only HTTP_PROXY that assigns semantic meaning, which existing deployed software wouldn't use anyway.

[almerino]

What would you think of .htl?

[mittelgrau]

.build ?

[aadrian]

What about a 2 letter domain, since those seem to be used for countries only, and it's less probable to have conflicts in the future ?

The only combinations with H so far are HK, HM, HN, HR, HT, HU

One might use even more infrequent combinations, e.g. something with vowel only, since the only
this kind of domains are AE, AI, AO, AU, EE, EU, IE, IO, UA, UY, YE

[indrakaw]

@aadrian .yes, .no, or .maybe. I don't know.

[KeineLimonade]

A few other ideas for hotel related terms are:

• .guest
• .hostel
• .inn

[indrakaw]

@Tom-Julux, don't forget: .comfy, .maid, .bell.

[ghost]

What about

• .develop
• .development
• .node
• .code
• .project
• .local-project
• .appl
• .devs

[iamstarkov]

more info about .dev domain https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/

[iamstarkov]

these domains are safe to use:

• .example
• .example.{com,net,org}
• .invalid
• .local
• .localhost
• .onion
• .test

[iamstarkov]

because In 1999, the Internet Engineering Task Force reserved the DNS labels localhost, example, invalid, and test so that they may not be installed into the root zone of the Domain Name System.

[iamstarkov]

i'm for localhost

[typicode]

Was thinking also about .server, for example https://my-app.server

[duncanbeevers]

I think .localhost works best; the mechanism by which the domain is resolved is inherently intra-host. It dovetails nicely with the carved-out IETF namespace both in implementation and intended usage.

If people want to start pointing other hosts on their network at some instance of hotel's proxy file, then they can still twiddle the tld setting however they like.

[cmckni3]

.localhost and it doesn't require a hosts entry.

https://tools.ietf.org/html/rfc2606

The “.localhost” TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use.

Alternatively, don't use a domain at all, e.g. my-app, but you would need a hosts entry.

[entropitor]

@typicode If you are gonna change the tld, wouldn't it be a good idea to do something like:

app.ho.tel
app2.ho.tel
...

This way, you could maybe include a wildcard https certificate for the domain ho.tel so it's easier to trust the certificate for all hotel domains

[assaf]

This was not a problem a few versions back, but Chrome 61 decided to stop loading service workers, if it can't validate the certificate. It will load the page, scripts, and all other resources, except for service worker scripts. The error is Failed to load resource: net::ERR_INSECURE_RESPONSE.

There is a flag in Chrome allow-insecure-localhost: "Allows requests to localhost over HTTPS even when an invalid certificate is presented. #allow-insecure-localhost".

Enabling this flag solves the issue, but you have to use .localhost. It seems to be going based on the TLD.

[cmckni3]

HTTPS will also be forced in Chrome https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/

[duncanbeevers]

@assaf Nice research.

[typicode]

@assaf good to know!

[typicode]

@entropitor Nice idea. I don't know if there could be some side effects to it.

[czj]

Either .localhost (best) or .test (reserved)

[lukehler]

I really like both .server and .project, personally.

Should we also consider .tld as a reasonably representative placeholder for the TLD?

[jeroenrinzema]

what about .clerk?

[viztor]

.test is bit weird but nice and short.

[joepvl]

Bit late to the party I know, but here are some ideas:

.bug
.bugs
.plz
.null
.wip

I'm using .plz myself at the moment, but I could see myself using .wip (for "work in progress") as well. Not sure how to judge chances of any of these ever becoming a real TLD though.

[mimischi]

When will this be decided?

[joeyaurel]

Chrome 63 (out since December 2017), will force all domains ending on .dev (and .foo) to be redirected to HTTPS via a preloaded HTTP Strict Transport Security (HSTS) header.

Source: https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/

You might consider removing the default tld .dev from the configuration and may change it to .test, .example, .invalid or .localhost since those TLDs are Reserved Top Level DNS Names according to https://tools.ietf.org/html/rfc2606#section-2

[Ti-webdev]

app.www

[JimDabell]

.internal, as defined by draft-wkumari-dnsop-internal-00.

[lukehler]

Taking a moment to try to summarize the above...

Any suggestion of tld other than .test, .example, .invalid, or .localhost does not resolve the root cause of the issue and could come up again in the future. I mentioned earlier that I really like the idea of using something like app_name.project but it's entirely possible that doing so could put us in exactly the same situation at any point in the future. Though less likely to come up, this even applies to two-character country codes. I'm 100% certain how .local fits into this scheme, but the potential to cause conflicts with local networking/bonjour seems like it's not worth pursuing.

@JimDabell 's .internal suggestion is genuinely the best option on the reserved list, but it's just a draft. Unless that status changes, it suffers from the same issue as above. If the status does change and it's accepted, then it would get bumped to the top of the list (despite being a bit longer).

Using an invalid tld - like .h or .:love_hotel: - could be a means of circumventing the possibility of future gTLD registrations, but seems likely to cause other issues if the apps themselves (or the clients used to view them) involve some domain validation. It's true that anyone doing anything which causes issues could update their own settings to something like .test, but it still feels like a weak, incomplete solution.

Therefore using one of the specific exceptions seems like the only fix to the root cause of the issue. That gives us .test or .localhost as the primary contenders. .test is not entirely descriptive - it sounds like it should be used for... well... running tests - but it's convenient. .localhost is more descriptive, but has its own incompatibility concern: it seems to cause some issues with service workers (according to @assaf). [ edit: that was exactly the opposite of true. .localhost allows you to ignore the https requirement for service workers ]

In total, .test seems like the clear winner.

[lukehler]

With all that said, and taking #197 into account, is it worth discussing a default of *.hotel.test?

It's more descriptive than just the tld and it seems relatively easy to include setup of a wildcard certificate for *.hotel.test and hotel.test itself (which could remain the admin view). The relative ease of adding https support seems like it could be a worthwhile trade-off for the added length.

I haven't tried this myself, yet, but it seems like there may be some updates to handle second-level domains first, however.

[assaf]

@lukehler on the contrary, if you want to test Service Workers in Chrome, with a self-signed certificate you have to use .localhost. Other TLD's won't work.

[czj]

@lukehler thank you so much for this great summarization ; .test seems to be the best and we have adopted it already with success, company-wide.

Having a .hotel.test makes sense for self signed certificates, something we really miss coming from invoker which had SSL supports built in. However it makes our app's config hotel-dependant et sometimes we use .test with something else than hotel.

[typicode]

Based on the different comments, I've finally gone with .localhost as the default domain (this can be changed in .hotel/conf.json if you prefer something else).

It seems to be the safest choice, as it's a reserved domain, should work better with Service Workers as @assaf explained 👍 and should avoid conflicts with bonjour service/local networking.

Also many of you seem to like it :)

See README for upgrading to v0.8.0

Thank you EVERYONE for the all the great comments, ideas, researches and feedback! 👏 🙏

[EvertEt]

https://github.com/typicode/hotel/blob/master/README.md#L192
Here it still mentions dev as the default.

[typicode]

@EvertEt fixed, thanks 👍

[danemacmillan]

I realize this issue has been closed and the decision was made to use .localhost, but it should be pointed out that Chrome will ignore a local machine's hosts file when resolving names with a .localhost TLD.

https://bugs.chromium.org/p/chromium/issues/detail?id=489973

This means that, for example, pointing a devproject.localhost domain to something other than 127.0.0.1 will fail; Chrome will just resolve that domain name to the loopback interface. There are numerous reports of this behaviour.

[assaf]

Check out https://github.com/josh/launchdns It sets up a local DNS resolver, all .localhost domains resolve as 127.0.0.1 so you don't need to edit the hosts file.

[danemacmillan]

@assaf That's actually the problem I'm bringing up. That's specifically something I would not want. Chrome will not read a local hosts file if the TLD contains .localhost. That means the following would fail to load in Chrome:

192.168.70.70 foobar.localhost

Chrome will simply point foobar.localhost to 127.0.0.1. It ignores the real IP address.

[assaf]

I see. I misunderstood the question. Yes, that's the drawback to Chrome giving localhost special treatment.

[zimgodo]

It's 2019, what about .suite? Anyone?

[czj]

Why this TLD ?

[bobtherobot]

Since .dev is now own my mega ai, I use:

.ved

[JimDabell]

The status of .internal has changed:

The Internet Assigned Numbers Authority (IANA) has made a provisional determination that “.INTERNAL” should be reserved for private-use and internal network applications.

— Proposed Top-Level Domain String for Private Use