Live data from Hacker News

The days of .dev domains for testing code are over

medium.engineering

71–80 of 95 posts

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

#71
post #10

> The other option is to change your .dev domain and never look back. But what domain could we migrate to? With the gTLD gold rush, is anything safe? Just buy medium-devel.com or something and make it resolve to 127.0.0.1 in internal DNS. This gets you a couple of benefits: - No one will ever take it from you - You can configure it in external DNS if you'd like - You can get a real, publicly-trusted SSL certificate f…

This is exactly what I've been doing for years and got my current workplace doing.

We set up `*.l.example.com` (where example.com is our company's domain) to all resolve to 127.0.0.1. I personally have nginx set up to map `project.client.l.example.com` to `/path/to/webroot/client/project/`.

All of our infrastructure has hostnames under our domain and references other pieces of infrastructure using those hostnames.

Why is everyone putting so much effort into trying to operate outside of the established domain name system? To avoid paying the $10/yr?

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

#72
"Like a small child, your operating system believes in "stranger danger" and doesn't trust self-signed certificates."

[ ] True [x] False

First, is it the OS that distrusts certificates, or is it the HTTP client?

Second, CA certificates such as the ones trusted by HTTP clients (contained in "browsers") are self-signed certificates.

Pre-installed CA certificates in corporate HTTP clients (e.g., Chrome, etc.) and CA certificates in downloadbale "bundles" available from corporations (e.g., Mozilla) are self-signed.

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

#74
post #10

> The other option is to change your .dev domain and never look back. But what domain could we migrate to? With the gTLD gold rush, is anything safe? Just buy medium-devel.com or something and make it resolve to 127.0.0.1 in internal DNS. This gets you a couple of benefits: - No one will ever take it from you - You can configure it in external DNS if you'd like - You can get a real, publicly-trusted SSL certificate f…

This is exactly what I've been doing for years and got my current workplace doing. We set up `*.l.example.com` (where example.com is our company's domain) to all resolve to 127.0.0.1. I personally have nginx set up to map `project.client.l.example.com` to `/path/to/webroot/client/project/`. All of our infrastructure has hostnames under our domain and references other pieces of infrastructure using those hostnames. Wh…

If your public website has access to sensitive credentials, and you tend to be logged in on your development machine (imagine you're amazon.com, or google.com, or something), I would recommend using a separate domain registration instead of a subdomain of your production domain, just so that vulnerabilities in your development site don't risk exposure of production cookies or other credentials. As you say, it's If your public-facing website is just a static landing page (e.g., you're a B2B company or a design agency or a hedge fund or whatever), then yeah, using .dev.contoso.com works.

(By the way, the same analysis applies to running internal services at out-of-date-wiki.corp.contoso.com - consider whether you'd be happier hosting them at out-of-date-wiki.contoso-corp.com instead, and having contoso-corp.com not exist in external DNS.)

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

#75
Typical jerk move. This is not only taking the ball with you but closing the field and locking it requiring keys that only you have.

Not only is this problematic but so is HSTS, and the push for increasing reliance on CAs and in effect making self signed certs pointless.

The great concern for SSL by many people is simply ad supporting behavior masquerading as concern for privacy and state actors. Apparently ssl which is routinely mitm'd by small time corporations can protect privacy. Accept that with straight face while mitm vendors interests are paid attention to in standards meetings.

And Mozilla, the so called 'defender' cashing in on the public good will whenever it suits them conveniently caves in to Google at every opportunity.

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

#76

Earlier quoted context omitted.

> What entitles any of us to use that domain? You're right. I didn't pay for it, so I'm not entitled to get to use it. Just because there is only one internet, and only one top level domain namespace, and just because I don't have $150,000, does not entitle me to get to use some part of the internet in the same way as a single corporation with a lot of money. What entitles anyone to use the internet? I don't pay for…

You're right. I didn't pay for it, so I'm not entitled to get to use it. Correct. So what was the point of the rest of your nonsensical rambling? Or do you have some other explanation of why you're entitled to you use that specific tld namespace? You can't just use arbitrary domains that you don't own, why should tld's be any different especially given the advent of gtld's which radically expanded the namespace? You'…

The taking of a gTLD for private use simply to associate an entire generic concept with a single corporation is an abuse of the public's interest in top-level domains to be used to navigate resource on the world wide web.

The Chairman of ICANN said at the creation of gTLDs: "Today's decision will usher in a new internet age. We have provided a platform for the next generation of creativity and inspiration. Unless there is a good reason to restrain it, innovation should be allowed to run free."

Taking the entire ".DEV" TLD for a single corporation, as if Google is the only development corporation in the world, is not providing a platform for the next generation of creativity and inspiration. Potentially millions of users of this TLD no longer have the option.

I am not the only person who feels this way: https://www.theregister.co.uk/2015/03/13/google_developer_gt...

Google also tried to take ".BLOG", for sole use by its Blogger platform. Luckily they were outbid.

When Amazon proposed it taking the ".BOOK" TLD, publishers objected because, duh, this would be a hugely unfair attack on book publishers, sellers, and authors.

On top of the above, Google broke private use of the TLD for literally everyone who wasn't using TLS (and not just for domains Google registers in the TLD), but I'm sure lots of people simply don't care when Google does dick things, so nevermind that.

My position is that a corporation should not be able to stifle free and fair use of the internet. It's not about entitlement, it's about the fact that the internet is a global economic engine intended to be used by everyone, and not just exclusive corporations with money and influence.

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

#77

Earlier quoted context omitted.

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

They should be more considerate of other developers who use .dev internally like them. Why? What do they owe anyone?

>> They should be more considerate of other developers who use .dev internally like them.

> Why? What do they owe anyone?

Your attitude is the root cause of so many problems.

The have a moral obligation to not be jerks. If you're not aware, one of the things jerks are known for is acting selfishly with no concern for how their actions affect others.

Google shouldn't have been allowed to buy a gTLD like dev in the first place. But, since it has and Google only plans on using it internally, it should only use it in ways that don't break existing usages.

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

#78
post #74

Earlier quoted context omitted.

This is exactly what I've been doing for years and got my current workplace doing. We set up `*.l.example.com` (where example.com is our company's domain) to all resolve to 127.0.0.1. I personally have nginx set up to map `project.client.l.example.com` to `/path/to/webroot/client/project/`. All of our infrastructure has hostnames under our domain and references other pieces of infrastructure using those hostnames. Wh…

If your public website has access to sensitive credentials, and you tend to be logged in on your development machine (imagine you're amazon.com, or google.com, or something), I would recommend using a separate domain registration instead of a subdomain of your production domain, just so that vulnerabilities in your development site don't risk exposure of production cookies or other credentials. As you say, it's If yo…

Good points and appreciate the advice - I hadn't considered that. Thankfully our public-facing site is essentially static.

Even in the static-site case where the risk may be minimal, there's certainly no harm in moving these sorts of things to a separate domain - especially for anyone looking at this as a new setup due to .dev issues.

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

#79
post #27

I had no idea you could buy gTLDs for internal company use. That’s outrageous, and ICANN should have rejected the application. I don’t mind the idea behind gTLDs, but the while thing has been handled pretty poorly.

Especially something as generic as .dev. I could possibly see Google having a legitimate claim to a .google TLD, but not something like .dev that is in no way limited to Google.

As a side note, Google already owns and uses the .Google TLD.

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

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

I'm not sure a strong case can be made that Google should be obliged to do that. There already exist TLD suffixes reserved for testing. ".dev" just isn't one of them.

I would beg to differ. As you've mentioned, there exists an official TLD suffix. However, de facto, .dev is the testing TLD. I've never seen .example or .invalid in real life. I've seen a tiny bit of .test. At every job that had a test dev, we used .dev. In many cases that decision was made by other developers. Judging by the comments here, and the article, it seems that many people have been using it.

A case can be made. How strong it will be remains to be seen. I hope Google can see the greater good in this. They have a lot of good will to win amongst the developer community.

Post reply on HN