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

The days of .dev domains for testing code are over

medium.engineering

Post reply on HN
Print view View original

41–50 of 95 posts

Re: The days of .dev domains for testing code are over

#41

Post by YouAreGreat »

vertex-four wrote: post #24
paulgb wrote: post #15

Earlier quoted context omitted.

Thanks for the tl;dr, but why buy a tld for internal use only? Just so nobody else would? (Maybe it's in TFA; I'll admit I didn't read it)

To ensure that nobody else does. Google uses .dev pervasively for projects - if someone were to buy .dev and sell domains in it on the global DNS infrastructure, then myfancynewproject.dev would resolve to something entirely different from within Google than from outside it.

If that's true, wouldn't the right plan of action be for everybody to continue using dev as if it was a reserved TLD? Just pretend Google paid off ICANN to make it safe.

Re: The days of .dev domains for testing code are over

#42

Post by abritinthebay »

Kluny wrote: post #7

Is this a real problem? Usually when I need a testing domain I make a subdomain on an address I or my company owns. dev.kluny.com. Easy.

It was a really bad practice that, for some reason, got really really popular - so especially in the Ruby community and it's derived branches - but it was still always a bad idea to make up your own domains for testing.

So it isn't exactly a shock that this bad practice is going to bite its users. I think the reason it's getting headlines is why it's biting those users now, all at once.

Re: The days of .dev domains for testing code are over

#43

Post by jsmthrowaway »

koliber wrote: post #19

The article outlines two options. There is a third. Lobby google through petitions and collective developer action to surrender their .dev TLD and create an RFC that makes it reserved for developer used, similarly to .example and .test.

Except, as you point out, .example and .test exist (and should have been used for this). What's the technical justification for the third?

Remember when APNIC got 1/8 from IANA and had to go test what would happen if they announced 1.2.3.4 to the Internet? Just because something has been done historically doesn't mean we need to ban it entirely from the future.

Re: The days of .dev domains for testing code are over

#44

Post by Chaebixi »

vertex-four wrote: post #24
paulgb wrote: post #15

Earlier quoted context omitted.

Thanks for the tl;dr, but why buy a tld for internal use only? Just so nobody else would? (Maybe it's in TFA; I'll admit I didn't read it)

To ensure that nobody else does. Google uses .dev pervasively for projects - if someone were to buy .dev and sell domains in it on the global DNS infrastructure, then myfancynewproject.dev would resolve to something entirely different from within Google than from outside it.

> To ensure that nobody else does. Google uses .dev pervasively for projects - if someone were to buy .dev and sell domains in it on the global DNS infrastructure, then myfancynewproject.dev would resolve to something entirely different from within Google than from outside it.

So basically Google decided to break everyone else, because they were afraid someone would break them. They should be more considerate of other developers who use .dev internally like them.

Re: The days of .dev domains for testing code are over

#45

Post by SAI_Peregrinus »

peterwwillis wrote: post #36
jerf wrote: post #11

Earlier quoted context omitted.

"Is that monopolistic behaviour?" No. Acquiring the TLD has nothing to do with any monopoly, so it's just a browser decision made by Chrome, and it isn't locking anybody out of any markets. It's also technically not even a change to the status quo. Beforehand, you weren't supposed to be using .dev like that. As the article says, you should have been using .test or .invalid. After Google's actions, you still shouldn't…

It's locking literally every individual and business out of a "development" domain, solely for one corporation's for-profit use. Solely to associate Google with development, over any other corporation in the world. This is like Ford registering ".car" gTLD for themselves (although actually worse). > It's also technically not even a change to the status quo. If it wasn't a change to the status quo, they would have jus…

> You're saying that what we should not have done, is okay for Google to do.

No, what we should not have done is used an unregistered and unreserved TLD for testing/development. What Google has done is registered the .dev TLD, and started to use it for development.

Re: The days of .dev domains for testing code are over

#46

Post by level »

Rather than maintaining a list of HSTS websites which isn't cross-browser, why is there not an optional HSTS flag attached to the DNS response? I don't know anything about DNS requests, so changing the protocol in a backwards compatible way might be impossible, but that seems like a much better way to maintain that information than with a separate list.

Re: The days of .dev domains for testing code are over

#47

Post by mindcrime »

peterwwillis wrote: post #36
jerf wrote: post #11

Earlier quoted context omitted.

"Is that monopolistic behaviour?" No. Acquiring the TLD has nothing to do with any monopoly, so it's just a browser decision made by Chrome, and it isn't locking anybody out of any markets. It's also technically not even a change to the status quo. Beforehand, you weren't supposed to be using .dev like that. As the article says, you should have been using .test or .invalid. After Google's actions, you still shouldn't…

It's locking literally every individual and business out of a "development" domain, solely for one corporation's for-profit use. Solely to associate Google with development, over any other corporation in the world. This is like Ford registering ".car" gTLD for themselves (although actually worse). > It's also technically not even a change to the status quo. If it wasn't a change to the status quo, they would have jus…

It's locking literally every individual and business out of a "development" domain, solely for one corporation's for-profit use.

And? What entitles any of us to use that domain? And as far as that goes, you can, as I understand it, still use that tld, since your local DNS resolver or hosts file can always override how hosts are resolved in there. The only real issue is if you hit the specific issue where a change in Chrome behaviour w/r/t this specific TLD, breaks something in your workflow.

Re: The days of .dev domains for testing code are over

#48

Post by gremlinsinc »

Wow, is it so hard to use a self-signed in your local dev config for nginx/whatever? I have a bash script that auto-spins up a new dev environment ala: ng create something.dev apps/php/laravel/app/public -- auto makes a self-signed cert, reloads nginx, and should still work in new chrome, since it uses https.

Am I missing something or are they whining over nothing? I would get a little perturbed if only .dev domains show up if you're on a google ip or something, but for now, using https is totally do-able.

Re: The days of .dev domains for testing code are over

#50

Post by ekimekim »

Having read https://tools.ietf.org/html/rfc6761, I have a use-case which I've seen often but doesn't seem to be covered: What TLD should I use for internal, production domains? ie. names that are only resolvable within my network, but are definitely not "test" domains and calling them .test would generate confusion.

Mostly I tend to see companies either inventing an unregistered TLD, often using their own company name, or they use ".local", which can cause issues - some systems treat this name specially.

A third option would be putting all internal names under an "internal.yourcompany.com", but that's long and annoying.

Ideally I'd like to see a ".private" or ".internal" TLD recognised as special-use under the same semantics as ".test". Does anyone have any better option?

Post reply on HN