
The days of .dev domains for testing code are over - micahgoulart
https://medium.engineering/use-a-dev-domain-not-anymore-95219778e6fd
======
Animats
OK, so after a few pages of unnecessary history, the story is that Google
bought the .dev TLD and uses it only for internal purposes.

~~~
cmroanirgo
Thanks Chrome. I use _.dev_ quite a lot. Looks like I'll be using FFox for
development from here on, until they also decide to usurp their position! And
then I'll just use lynx.

Of course, I could change my ways and start using a different naming system: I
notice a lot of development shops using _.local_ , albeit for _same machine_
dev & testing.

Edit: lol. tried to use 'star'.dev, but it came out in italics!

------
JoshTriplett
While this is an interesting exploration of the history of the Internet,
gTLDs, HSTS, and various other things, the story boils down to this: never
make up an unregistered domain/TLD and assume it won't exist in the future;
always use a reserved test domain/TLD from RFC 2606
([https://tools.ietf.org/html/rfc2606](https://tools.ietf.org/html/rfc2606))
or the updated RFC 6761
([https://tools.ietf.org/html/rfc6761](https://tools.ietf.org/html/rfc6761)):
.test, .invalid, .example, or .localhost, depending on what semantics you
need.

~~~
gruez
to be fair, before icann introduced the gtld program, it was a fair assumption
that there wouldn't be a .dev tld.

~~~
cls59
But also, the folks at medium made that assumption long after RFC 2606 had
established a "right answer" for which tld to use when testing.

~~~
gruez
i think i wasn't being clear with my initial comment. it's a "fair assumption"
in the same way that it's a fair assumption that emails can be validated with
the regex

    
    
        [a-zA-Z0-9\.]+@[a-zA-Z0-9]+\.[a-zA-Z0-9]+
    

sure, it breaks for gmail aliases (with +), isn't RFC compliant, and the
proper regex is a google search away, but it's understandable why that was
chosen. same with .dev domains. yeah, you probably should have looked for a
reserved tld, but why do that when .dev already didn't exist, and it didn't
look like icann was going to delegate that any time soon?

see also:
[https://hn.algolia.com/?query=falsehoods%20programmers%20bel...](https://hn.algolia.com/?query=falsehoods%20programmers%20believe%20about%20&sort=byPopularity&prefix&page=0&dateRange=all&type=story)

~~~
kijeda
These don't strike me as comparable scenarios.

In the case of .dev, it didn't even appear in the weeds of usage when the DNS
root servers were measured for traffic to identify potential new TLDs usage
conflicts in the real world (e.g.
[https://www.icann.org/en/system/files/files/name-
collision-0...](https://www.icann.org/en/system/files/files/name-
collision-02aug13-en.pdf) p22). Even if .dev were in significant usage, that
traffic was not reaching the domain name system. The complaint seems to be
fundamentally to be about the pre-loaded configuration of Chrome, not the DNS.

In the case of your regex, it would breaks millions of production domains in
used today and fail in a wide variety of scenarios. It is only understandable
in the context of someone who hasn't done any cursory research into the topic.

------
geofft
> _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 for it, for free,
because Let's Encrypt can resolve DNS challenges against it

(By the way, you want to get an SSL certificate for internal development,
because of the policy - Chrome-initiated but now followed by the HTML
standards folks in general - to require HTTPS for fancy new features like
geolocation and service workers: [https://www.chromium.org/Home/chromium-
security/prefer-secur...](https://www.chromium.org/Home/chromium-
security/prefer-secure-origins-for-powerful-new-features) If you don't have
HTTPS of some sort, you can't test these features locally.)

~~~
nucleardog
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?

~~~
geofft
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 <$10/year. It also lets you buy
a wildcard cert for *.contoso-dev.com and make the private key readable to the
entire company and not have to think about whether this is a security risk.

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

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

------
TheAceOfHearts
I absolutely hate this gTLD crap. The fact that companies can pick up any TLD
on the global namespace is absurd. Even worse, the internet community never
had a chance to object to these sales.

Something that pisses me off even more is that a few months back there was an
IETF draft to specify the .home TLD to only resolve local network requests. It
seemed pretty reasonable, but there was pushback and it was changed to
home.arpa, since the .arpa TLD is already restricted. So big companies can
pick up any TLD they want, but regular users will forever be forced to type in
extra characters.

~~~
kijeda
Never had a chance? The rules that would allow this kind of allocation were
debated publicly and strenuously for many years in Internet governance
circles, with many iterations of drafts and public comment periods. Some of
those rules specifically governed which domains should be disallowed because
they would have impact on existing utilization, as well as those that needed
to be reserved for technical reasons.

~~~
ekimekim
“There’s no point in acting surprised about it. All the planning charts and
demolition orders have been on display at your local planning department in
Alpha Centauri for 50 of your Earth years, so you’ve had plenty of time to
lodge any formal complaint and it’s far too late to start making a fuss about
it now.”

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

~~~
TheDong
> for internal company use.

There are no gTLDs intended only for _internal_ company use. There are many
that are intended for only a single companyto use them, though externally.

For example, the .americanexpress gtld
([https://www.nic.americanexpress/](https://www.nic.americanexpress/)) will
only provide domains to entities affiliated with american express.

Same with .dodge, and .google, and many many others.

ICANN handled this quite well -- they let others object to applications, let
anyone who may have a trademark or reason to claim the word was generic come
forwards, left time for comments, etc etc.

If you're objecting to this now, not back when the program was being formed,
you clearly handled this poorly by not being involved in something you care
about.

If you don't care and weren't involved, you also don't have the full picture
and your outrage very well might be misplaced.

~~~
Chaebixi
> If you're objecting to this now, not back when the program was being formed,
> you clearly handled this poorly by not being involved in something you care
> about.

> If you don't care and weren't involved, you also don't have the full picture
> and your outrage very well might be misplaced.

That's an unhelpful and unreasonable response. You shouldn't blame people for
not being attuned to the activities an obscure bureaucracy (the gTLD process),
just because they might be affected by it. The gTLD process has a problem, not
the people negatively affected by it.

There really ought to be a long post-implementation objection period for
gTLDs, and the existing process should be changed to allow for that. The top
goal of the DNS system right now should be to not break stuff, and that should
override any entity's desire to buy a gTLD for $$$.

~~~
CydeWeys
You can't un-delegate TLDs once they've been delegated. That breaks the
Internet. The creation of a TLD is thus irreversible, and deleting a TLD would
cause a lot more harm than it would prevent.

What you _can_ do is transfer the TLD to a different operator, and/or change
its registration policies, though all of the existing domains on the TLD need
to remain with their existing owners, as domain names are legally treated as
property and cannot be confiscated except through due process (like a court
seizure following a ruling on illegal activities).

~~~
Chaebixi
> as domain names are legally treated as property and cannot be confiscated
> except through due process (like a court seizure following a ruling on
> illegal activities).

That's just current convention, though. If better governance means being less
private-property absolutism, I'm for it. ICANN or whoever could just update
the terms of their contract to allow revocation of the TLD (with a refund), if
there's too much weeping and gnashing of teeth over it's issuance. People
would just need to understand domains on a new TLD aren't going to be as
ironclad as ones on more established TLDs.

------
ekimekim
Having read
[https://tools.ietf.org/html/rfc6761](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?

~~~
dragonwriter
> What TLD should I use for internal, production domains?

The currently safe way is to use a public domain that you own (you could use a
distinct subdomain for this, which is not publicly exposed but which is in DNS
on your internal network; e.g., intranet.example.com if you own example.com);
as you note, this gives a long full domain.

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

“.local” is a reserved domain with special semantics, see RFC 6762.

> Ideally I'd like to see a ".private" or ".internal" TLD recognised as
> special-use under the same semantics as ".test".

I'm kind of surprised that we haven't seen an RFC gain acceptance for this
already, but I expect something like this will happen and be registered with
the IANA special use domains registry.

~~~
CydeWeys
My colleague has written a draft RFC for this very use case, in fact:
[https://datatracker.ietf.org/doc/draft-wkumari-dnsop-
interna...](https://datatracker.ietf.org/doc/draft-wkumari-dnsop-internal/)

It's still very much in the early stages though.

Even then, though, you can end up with all sorts of problems during
mergers/acquisitions when previously separate intranets end up getting joined,
exposing naming conflicts. Ultimately you always need to use a globally unique
namespace, so either use a real domain name (guaranteed unique) or do
something unique on top of .internal, e.g. .yourcompanyname.internal (still
not guaranteed unique, but better).

See also: [https://jdebp.eu/FGA/dns-use-domain-names-that-you-
own.html](https://jdebp.eu/FGA/dns-use-domain-names-that-you-own.html)

------
peterburkimsher
tl;dr - Google bought the .dev gTLD, specified it for internal use, and pushed
changes in Chrome to require HTTPS.

Is that monopolistic behaviour?

~~~
paulgb
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)

~~~
vertex-four
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.

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

~~~
mdekkers
_They should be more considerate of other developers who use .dev internally
like them._

Why? What do they owe anyone?

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

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

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

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

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

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

------
brosky117
I really enjoyed this piece. We don't use .dev on my team so it allowed me to
read it as purely educational. And it really was informative and surprisingly
entertaining!

------
matt_wulfeck
On a blog hosted at .engineering. Let’s just move away from all of these
novelty Tlds.

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

------
drefanzor
Google will be buying up the 127.x.x.x ip range before you know it /sarcasm

~~~
gruez
i'm sure that icann can be persuaded to reassign ownership of that subnet if
google paid enough money. it's not like there's much people using anything
other than 127.0.0.1, so why not sell 127.128.0.0/9 for some quick bucks? the
only thing stopping them is the billions of legacy devices around that can't
route to that address.

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

------
reaperducer
If Google is only using .dev internally, and there won't be any public .dev
domains, then who cares? As long as my hosts file routes .dev to the proper
localhost nooks and crannies, nothing changes.

Unless you've bound yourself to Big G's browser. We only use that for last-
minute rendering tests because management doesn't trust it not to leak info
back to Mountain View.

Also, does Medium have a minimum word requirement? For some reason Medium
articles always seem unnecessarily extra large.

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

~~~
ekimekim
That would need to be combined with DNSSEC to be useful for security, but with
that caveat that sounds like a good idea.

------
nhance
Just use lacolhost.com:
[https://news.ycombinator.com/item?id=13749515](https://news.ycombinator.com/item?id=13749515)

------
giancarlostoro
In my job we use our hostname.ourdomainname.com for internal things, so I
don't see this problem as much. And it wont be accessible externally anyway.

------
mrmondo
We still have a huge number of the dev environments running on .dev, needless
to say we were pretty pissed off when Google were able to buy the TLD to use
as they wish. Anyway, not much we can do about it now other than start the
process of setting up a new subdomain and reconfiguring all our CI/CD, Apps,
Docs etc... I know we should have done it ages ago, there’s a ticket there for
it... but resourcing.... _sigh_

------
nathan_long
_Looks at ` /etc/hosts`_

:(

------
Zekio
isn't this solved by using Firefox instead?

~~~
Chaebixi
No. If you waded through the history lesson, you'd eventually learn that
Google maintains the list of domains requiring HTTPS that all the other
browsers use. Unless something changes, Firefox will eventually pick it up.

------
dboreham
Hmm. I have never seen this done or heard of it being done.

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

------
grawprog
As much as I agree with not using a public TLD as a dev environment, why the
fuck was google allowed to register and privately secure not one but several
domains for their own private use? Fuck them. That shouldn't have been
allowed, especially for a TLD that's well known to be heavily used.

I really dislike allowing domains to be used in such a way. It seems extremely
short sighted.

~~~
Kalium
Anyone is allowed to buy any gTLD for any use. As a result, Google was allowed
to buy .dev. They then chose to use it for internal use only.

Unfortunately, the time to oppose this was long ago when gTLDs were first
being debated...

~~~
grawprog
So I'm not allowed to disagree with something just because it happened a while
ago? I was against it then because of exactly this kind of thing happening. My
opinion hasn't changed. But, I guess it should because you say so right?

I see this kind of attitude a lot when it comes to technology "Oh it's already
happened just accept it" Or "It's the way everything is so just go along with
it"

I'm getting fairly sick of being told I shouldn't disagree with or be against
something because"that's the way it is"

Since when has technology ever been about accepting things the way they are?
The whole reason we even have an internet is because people decided the way
things were weren't good enough.

~~~
Kalium
Of course you're allowed to disagree! Without exception, any person is allowed
to disagree with any thing at any time. It's a basic human right.

Whether or not that disagreement can be reasonably expected to have meaningful
impact on what many others regard as a decision long made is a different
question, and the one to which I was speaking.

