Wondering why your internal .dev web app has stopped working?

Network admins, code wranglers and other techies have hit an unusual problem this week: their test and development environments have vanished. Rather than connecting to private stuff on an internal .dev domain to pick up where they left off, a number of engineers and sysadmins are facing an error message in their web browser …

[ecofeco]

Derp

Derp.

I mean, really?

[AlexGreyhead]

Not heard of this before

I'd be interested to know how many of the bazillions of folks developing on the interwebs have actually been affected because they're using .dev domains?

I've only ever seen people using .local or dev.mydomain.com, stage.mydomain.com...

Oh well :)

[Anonymous Coward]

Re: Derp

Our devs have all switched to MS Edge. Faster too.

[Dan 55]

Solution

I see the blindingly obvious one of not using Chrome wasn't mentioned. Other Blink browsers are available.

[Notas Badoff]

Re: Solution

It's not in the browser, it's in the DNS. Google owns the root domain name dev. From the article:

"In fact, the .dev global top-level domain is owned by Google."

(Has anybody considered using ElReg as hurdle during employment interviews? As in, "here, read this article and summarize it, and tell us what these terms mean, and how would you verify at least one of the points made in the article?")

(see bottom for the important bits)

Contact Information

Registrant Contact

Name: Charleston Road Registry Inc.

Organization: Charleston Road Registry Inc.

Mailing Address: 1600 Amphitheatre Parkway | Mountain View, CA 94043, United States

Phone: [phone]

Ext:

Fax: [phone]

Fax Ext:

Email:[e-mail]

Admin Contact

Name: Domains Policy and Compliance

Organization: Google Inc.

Mailing Address: 601 N. 34th Street | Seattle, WA 98103, United States

Phone: [phone]

Ext:

Fax: [phone]

Fax Ext:

Email:[e-mail]

Tech Contact

Name: Richard Roberto

Organization: Google Inc.

Mailing Address: 76 9th Avenue, 4th Floor | New York, NY 10011, United States

Phone: [phone]

Ext:

Fax: [phone]

Fax Ext:

Email:[e-mail]

Registrar

WHOIS Server: whois.nic.google

URL: http://www.registry.google

Registrar:

IANA ID:

Abuse Contact Email:

Abuse Contact Phone:

Important Dates

Updated Date: 2016-08-03

Created Date: 2014-11-20

Name Servers

ns-tld1.charlestonroadregistry.com

ns-tld5.charlestonroadregistry.com

ns-tld2.charlestonroadregistry.com

ns-tld3.charlestonroadregistry.com

ns-tld4.charlestonroadregistry.com

> nslookup nic.dev

Server: UnKnown

Address: 192.168.2.1

Non-authoritative answer:

Name: nic.dev

Addresses: 2001:4860:4802:32::1d

216.239.32.29

[the spectacularly refined chap]

Re: Solution

But if you are doing this you are presumably running an internal DNS which will generally recognise itself as authoritative for the domain without reference to the root servers. Alternatives such as the hosts file will equally take precedence.

So yes, the fault lies squarely with Chrome for simply assuming a Google entity.

The job interview point is valid and I have used a similar technique in the past: ask about an area of current controversy and their opinion. Generally I have no interest in the actual opinion, rather it is the arguments used to support it: uninformed opinion and solid technical reasoning are easily separated.

However in this case the issue is indeed one of basic comprehension: the article makes clear the intended servers ARE indeed being reached, they simply are not configured for HTTPS which Google insist on out of nothing more than self interest. That's the point you failed to pick up on, and where this latest Google diktat falls apart.

[Kristian Walsh]

Re: Solution

Best job-interview question I've been asked (and have asked later) in recent years;

What is systemd?

[Dan 55]

Re: Solution

No, it's in the browser. Chrome insists on certificates for .dev sites and also does certificate pinning. If you go to your own .dev address, Chrome won't render the page because it's expecting a Google cert.

[tin 2]

Embrace and extend.

[sabroni]

Permissionless innovation actually...

[Dwarf]

I must have missed the change in standards bodies.

Since when was Google appointed as the body responsible for deciding Internet standards ?

More importantly why are they not working with standards bodies to propose changes - where these sorts of things are scrutinised by other experienced people, hence reducing the impact of poorly thought through ideas.

Sure, HTTPS is a good thing in most cases, but is not necessary everywhere.

Only the person implementing the site will know if its applicable and will be able to consider the raft of other security related tasks to ensure an appropriately designed, built and operated site. This may include security principles like role based authentication, resilience, firewalls, etc or perhaps none if its a noddy application that runs locally within their home or some management interface on a dumb device (like a home grade switch) that doesn't offer an HTTPS capability as its not powerful enough to do that.

[LosD]

Re: I must have missed the change in standards bodies.

It's their TLD. They can enforce any rules they want on it.

The big problem here is that it was decided that Google could have it in the first place.

[JohnFen]

Re: I must have missed the change in standards bodies.

"It's their TLD. They can enforce any rules they want on it."

In the public internet, sure. But they have zero right to enforce any rules about it at all in a private network they don't own.

[Jonathan 27]

Re: I must have missed the change in standards bodies.

It's their web browser, same logic applies. They have the right to enforce any rules they like, in their web browser.

Also running local sites with real domains is a huge security risk. You're liable to leak data out to the internet domain.

[JohnFen]

Re: I must have missed the change in standards bodies.

I agree on both counts -- I wasn't claiming that coopting domain names in a private network was a good idea, only that nobody has any right to stop you.

[Dan 55]

Re: I must have missed the change in standards bodies.

Also running local sites with real domains is a huge security risk. You're liable to leak data out to the internet domain.

So what can you use that's not susceptible to being snagged one day as part of ICANN's money generation machine?

Then don't use a domain name you do not own. Your own domain and .local are both good (if not interchangeable) choices for intranet name resolution. A random domain that you think sounds cool and did not exist five years ago is not a good choice.

You may not have your own domain (e.g. home user) and you can't even use .local because Bonjour can go apeshit if you do.

[richardcox13]

Re: I must have missed the change in standards bodies.

> You may not have your own domain

Then get one or more. Despite recent registration/renewal fee inflation they are still cheap (vastly less than the hardware you'll be using).

[Dan 55]

Re: I must have missed the change in standards bodies.

A TLD for your own internal LAN should be doable without having to pay a rentier to do it properly. The fact that it isn't shows what this is really about.

No, you can't use .lan, because that's taken too. Try www.lan (El Reg won't let me link to it, probably rightly so in this case).

[bombastic bob]

Re: I must have missed the change in standards bodies.

"A TLD for your own internal LAN should be doable without having to pay a rentier to do it properly."

yourname.local <-- try that. set up your DNS server using 'bind', hook it in with the isc DHCP server, and voila! works for me, since, like, forever, LONG before RFC6762 was written. May require Linux or BSD, to work properly.

I can't remember where I first read about '.local' though. It wasn't in the RFCs as I recall, but it may have been mentioned in IANA or ICANN documents someplace. It was related to the use of '.localhost' for ONLY the loopback, and '.local' for anything in a private address space.

A quick google search shows that Micro-shaft recommends it for domain controllers. Maybe THAT is where I first read about it, back in the 90's, setting up a windows NT 4 server domain controller for testing.

Worthy of note: according to SOME several-year-old intarwebs references, Apple's mDNS stuff attempts (or used to attempt) to resolve a "name.local" name differently than a DNS lookup, by assuming they're multicast-only, but "name.whatever.local" appeared to work properly. Just to point it out, anyway.

[Dan 55]

Re: I must have missed the change in standards bodies.

It's their web browser, same logic applies. They have the right to enforce any rules they like, in their web browser.

It wouldn't be they realised they bought a lemon in the shape of a .dev TLD because other people used it before them and now they're using their general purpose trojan horse browser to make .dev get some traction by enforcing certificates so nobody else can use that TLD on their LAN?

Once Google's got everybody off its lawn, they can begin to monetise .dev.

[Anonymous Coward]

Re: I must have missed the change in standards bodies.

"Once Google's got everybody off its lawn, they can begin to monetise .dev."

Cynical, and probably true, I like it. :)

[Anonymous Coward]

Re: I must have missed the change in standards bodies.

> In the public internet, sure. But they have zero right to enforce any rules about it at all in a private network they don't own.

Then don't use a domain name you do not own. Your own domain and .local are both good (if not interchangeable) choices for intranet name resolution. A random domain that you think sounds cool and did not exist five years ago is not a good choice.

[Anonymous Coward]

Re: I must have missed the change in standards bodies.

"Then don't use a domain name you do not own. Your own domain and .local are both good (if not interchangeable) choices for intranet name resolution. A random domain that you think sounds cool and did not exist five years ago is not a good choice."

This ^. This is not only good practise to use a domain you own, but for internal use, it is also recommended to use a subdomain of it, such as mycooldomain.example.com. This would only be resolvable internally, and not on the public Internet. So best practise (if you're referring to an AD domain) still lets you get mycooldomain when logging on. :)

[bombastic bob]

Re: I must have missed the change in standards bodies.

"Then don't use a domain name you do not own. Your own domain and .local are both good"

etc.

I've been using ".local" for my own domain since the 90's. Prior to that I made up my own TLD but after reading up on it, it seemed that it was a bad idea (even back then).

I'd had some problems with a customer VPN setup that used the registered domain for their web site as their "windows domain". That caused lots of problems when VPN'ing into their network (as well as their router and network setup in general - they insisted on using the common/default 192.168.1.x address space, forcing my private LAN to use something else in order to VPN into them).

in any case, it's welcome that there's an RFC for '.local' (6762) but it shouldn't be restricted to ONLY multicast at any point in the future, either. RFC6762 might need an ammendment RFC to clarify that '.local' should be reserved for "general use" and NOT assumed to be multi-cast.

anyway, "companyname.local" works VERY VERY WELL for a corporate domain (for internal network addresses). I expect zillions of BOFH's and IT specialists have done this.

[Hans 1]

Re: I must have missed the change in standards bodies.

But they have zero right to enforce any rules about it at all in a private network they don't own.

If you use a TLD privately that is available on the global internet, you get all you deserve, it is as simple as that. It is not YOURS to use.

On the other hand, I think this change is silly and should be reverted.

[sabroni]

Re: It's their web browser, same logic applies.

Wow. Seriously? How far up Google's arse do you have to crawl for that to look reasonable?

[handleoclast]

.test.icann?

Surely ithink.icann is a better choice.

[Bronek Kozicki]

Re: .test.icann?

"ithinnk.icann"

[Mage]

This is part of Google's larger and welcome push for HTTPS

No, typical Google arrogance

While HTTPS is a good idea, Google are NOT in charge.

[sabroni]

Re: NOT in charge

If only that were true...

[JohnFen]

Easy enough to fix

Don't use Chrome. I know that browser choice is a matter of taste, but I still can't understand why Chrome is so popular. I find it downright painful.

[Anonymous Coward]

Re: Easy enough to fix

Perhaps it is a mere coincidence that it is pushed by one of the world's largest advertising entities, and it is simply a classical appeal to shininess?

[John Sager]

Re: Easy enough to fix

If you're developing stuff for the web then not using Chrome isn't an option. It is needed to be tested against if for no other reason. The Chrome stupidity, if I read it right, is that any request to a .dev url must use https as enforced by Chrome. Glad I didn't choose .dev for my own internal TLD many moons ago. I'm not going to change it, but if I were doing it now, I would probably choose something else.

[Mage]

also ICANN

Stupid idea creating practically any new top level. It's a money making scam.

Corporates pass on costs to customers. We are all paying.

[Ken Hagan]

Re: also ICANN

The only TLDs that count are the two-letter CCs and the original seven (.com, .org, .net, .int, .edu, .gov & .mil). Any sensibly configured DNS will drop everything else on the floor. There is nothing of any value on them that does not also exist on the real internet.

[Anonymous Coward]

Re: also ICANN

.net should be at the top of the queue for being ignored.

[JohnFen]

Re: also ICANN

I sortof agree with this. Personally, I view any domain name under one of the "vanity" gTLDs to be suspicious by default, and avoid them (I honestly can't think of a single time that I've visited one). But I feel no need to recommend the same behavior to others.

[whbjr]

Re: also ICANN

A local church uses .faith, as in ChurchName.faith, and in fact they have a .org address which redirects to the faith-based (ha!) hostname. If my DNS server dropped that on the floor, I'd never be able to get info which is required for my BUSINESS (not my personal life). Dropping valid DNS requests is not an option.

[Jonathan 27]

.dev is a internet TLD. .local is reserved, use that or one of the others. The coming of generic TLDs was announced in 2000, anyone who stuck their head in the sand for 17 years shouldn't really be whining about it today.

[Richard 12]

True

However these new TLDs are rightly ignored by absolutely everyone, except for idiotic companies with more money or greed than sense

[katrinab]

Re: True

The only time I pay attention to them is when maintaining my spam filters, as spammers seem to like them.

[TechDrone]

Be careful with .local

it's reserved for Bonjour / avahi / mDNS and if you try to use that with "classic" internal DNS then you can have all sorts of fun and games if you plug in a ithing or Linux box. As anyone who followed the original advice from Microsoft in setting up AD as [domain_name].local all those years ago will have long since discovered.

[Cursorkeys]

Re: Re: Be careful with .local

Exactly, don't ever use any domain you don't own.

.local will also bite you even harder in the bum as you can't get a cert from any CA for a domain with a reserved name in it since a few years ago: https://cabforum.org/internal-names/

Some people remain convinced that the NETBIOS name and the AD FQDN are one and the same, but you can have a nice 'mycompany' NETBIOS name while having 'internal.mycompany.com' as the FQDN.

[Jonathan 27]

Re: Be careful with .local

Well, obviously. You need to use self-signed certs for local domains. Even if you're squatting a .dev domain you'd have to do that. Doesn't really make any difference.

[Cursorkeys]

Re: Be careful with .local

Not really. The common use-case was for things like OWA portals, and you _didn't_ have to self cert until recently as CAs would quite happily issue you a cert for, say, whatever.mycompany.local until the rules changed.

Edit: That obviously didn't change it being not a great idea, but you could if you wanted.

[bombastic bob]

Re: Be careful with .local

"you can't get a cert from any CA for a domain with a reserved name in it"

ahem - make your OWN root cert for local things. don't pay the toll!

[Paul Kinsler]

Re: .local reserved for Bonjour / avahi / mDNS an

Surely although .local might (now) be 'reserved' *by* Bonjour/avahi/mDNS, that is not the purpose for which .local was originally defined.

[HieronymusBloggs]

Re: Be careful with .local

"it's reserved for Bonjour / avahi / mDNS"

Reserved by whom?

[Shoot Them Later]

Generic TLDs were a shit idea when they were proposed, and they are a shit idea now. Plenty of people didn't stick their head in the sand, and complained - but we still have them. I think people are fully entitled to whinge about them as much as they want to.

[Jonathan 27]

I think they're great unless you're one of those leeches that buys up thousands of domains. It's made their business plan obsolete. But then again, I've noticed that the commenters here on El Reg tend to be very resistant to change of any kind regardless of how useful the new feature might be.

[bombastic bob]

"unless you're one of those leeches that buys up thousands of domains"

/me buys up ".semprini"

[HieronymusBloggs]

"I've noticed that the commenters here on El Reg tend to be very resistant to change of any kind regardless of how useful the new feature might be."

It usually happens when the new "feature" is not actually useful to those resisting it (and may cause them a lot of pain into the bargain).

[Orv]

To me this feels is a bit like people who pick numbers at random for private subnets, then deploy NAT and wonder why routing doesn't work.

[Anonymous Coward]

You mean I shouldn't have put my router at 1.1.1.1 using a /8 ?

[Anonymous Coward]

.invalid

Should return NXDOMAIN. Use .test

[Anonymous Coward]

An attempt at journalism?

Or an opinionated rant about something waiting to be broken having finally been broken?

Why would any half-competent developer use a domain they do not own and point it at their internal interfaces to boot? That is just begging for all sorts of trouble, of which denial of service is about the least problematic.

[Bronek Kozicki]

Re: An attempt at journalism?

El Reg news are not reserved for competent developers or administrators (or operators). Sometimes their less competent or less experienced colleagues, or perhaps just learning, or even pointy-haired bosses read them, too. Something that is not news for one folk, might be news for another.

[Anonymous Coward]

Re: An attempt at journalism?

> Something that is not news for one folk, might be news for another.

I agree, but the ranting was preposterous.

[Jonathan 27]

Re: An attempt at journalism?

Obviously, no one with even a shred of competence would.

[Phil Endecott]

Are any comentards going to admit to using .dev for internal purposes, as described in the article? I've never come across it, but then I don't get out much. Would be interesting to know if it really is widespread.

[Indolent Wretch]

My previous employer had a large variety of test websites available in their intranet, many of which were using .dev. I switched them over 2 years ago as soon as I heard about .dev being sold off because something like this was clearly going to happen at some point.

[JohnFen]

"Are any comentards going to admit to using .dev for internal purposes, as described in the article?"

I don't, and I've never personally seen anybody do it.

[kain preacher]

at one point Google tried to snag .home.

[Jim Mitchell]

Come on El Reg! This was a chance to push your next conference: ".Devops"!

[Anonymous Coward]

I wonder whether the people using a domain that they don't control are also using someone else's public IP range on their internal LAN?

It's tantamount to the same thing and will lead to the same problems.

10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 are available for a reason. The reserved TLDs listed in the article are available for exactly the same reason.

[Dan 55]

Except one day ICANN won't sell off 10.0.0.0/8 when it needs a new fleet of yachts for the board of directors.

[Anonymous Coward]

I remember coming across a “consultant” who used 1.209 or something similar as the internal ip range

For a company when asked why it was a us military range and nobody would ever needs to get to it.

When they moved buildings they were shifted to a proper private space to match the rest of the company.....

[c0ldr3x]

Am I the only one who's using host file for local development?

[richardcox13]

That won't help.

.dev is listed in Chrome's internal list of domains with pinned certificates. They way the address is resolved makes no difference..

[Jonathan 27]

It's easier just to have separate dev, test and deploy config files.

[Triumphantape]

Is it just me?

My work environment is separate from my leisure time environment, and the work stuff stays static while the project is in play.

I don't update the work environment, unless it's needed for the project (never is) and testing can occur on another machine.

[Jonathan 27]

Re: Is it just me?

Some of us work in companies that have continuous deployment strategies, so maybe.