back to article 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 …

Silver badge

Derp

Derp.

I mean, really?

9
0

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

5
1
Anonymous Coward

Re: Derp

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

0
0
Silver badge

Solution

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

32
6
Silver badge

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: 1 650 253 0000

Ext:

Fax: 1 650 253 0001

Fax Ext:

Email:iana-contact@google.com

Admin Contact

Name: Domains Policy and Compliance

Organization: Google Inc.

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

Phone: 1 202 642 2325

Ext:

Fax: 1 650 492 5631

Fax Ext:

Email:iana-contact@google.com

Tech Contact

Name: Richard Roberto

Organization: Google Inc.

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

Phone: 1 212 565 2633

Ext:

Fax: 1 650 492 5631

Fax Ext:

Email:crr-tech@google.com

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

5
16

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.

18
1
Silver badge

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.

6
1
Silver badge

Re: Solution

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

What is systemd?

0
0

Embrace and extend.

6
1
Silver badge

Permissionless innovation actually...

5
0
Silver badge

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.

13
8

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.

23
2
Silver badge

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.

6
11
Bronze badge

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.

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

28
4
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. :)

8
0
Silver badge

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.

2
1
Silver badge
WTF?

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.

7
1
Silver badge

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?

1
7
Silver badge

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.

2
3

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

4
1
Silver badge

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

2
0
Silver badge
Devil

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.

2
1
Silver badge
Devil

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.

1
1
Silver badge

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.

1
0
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. :)

0
0
Silver badge
Coat

.test.icann?

Surely ithink.icann is a better choice.

19
0
Silver badge
Joke

Re: .test.icann?

"ithinnk.icann"

1
0
Silver badge

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.

13
5
Silver badge

Re: NOT in charge

If only that were true...

6
1
Silver badge

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.

15
2
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?

9
0

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.

5
1
Silver badge

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.

15
0
Gold badge
Flame

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.

6
1
Silver badge

Re: also ICANN

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

0
4
Silver badge

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.

1
0
Thumb Down

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.

0
0
Bronze badge

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

14
2
Silver badge

True

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

19
2
Silver badge

Re: True

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

6
0
Facepalm

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.

5
1

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.

0
0
Headmaster

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.

0
4
Windows

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.

10
0
Bronze badge

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.

2
0
Bronze badge

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.

1
3

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.

1
0
Silver badge
Devil

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!

1
0
Silver badge
Devil

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

/me buys up ".semprini"

0
1

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2018