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 …

Page:

  1. ecofeco Silver badge

    Derp

    Derp.

    I mean, really?

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

    2. Anonymous Coward
      Anonymous Coward

      Re: Derp

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

  2. Dan 55 Silver badge

    Solution

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

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

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

        1. Kristian Walsh Silver badge

          Re: Solution

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

          What is systemd?

      2. Dan 55 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.

  3. tin 2

    Embrace and extend.

    1. sabroni Silver badge

      Permissionless innovation actually...

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

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

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

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

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

          2. Dan 55 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.

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

              1. Dan 55 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).

                1. bombastic bob 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.

          3. Dan 55 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. Anonymous Coward
              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. :)

        2. Anonymous Coward
          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.

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

          2. bombastic bob 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.

        3. Hans 1
          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.

          1. sabroni 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?

  5. handleoclast
    Coat

    .test.icann?

    Surely ithink.icann is a better choice.

    1. Bronek Kozicki
      Joke

      Re: .test.icann?

      "ithinnk.icann"

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

    1. sabroni Silver badge

      Re: NOT in charge

      If only that were true...

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

    1. Anonymous Coward
      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?

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

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

    1. Ken Hagan 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.

      1. Anonymous Coward
        Anonymous Coward

        Re: also ICANN

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

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

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

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

    1. Richard 12 Silver badge

      True

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

      1. katrinab Silver badge

        Re: True

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

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

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

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

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

        2. bombastic bob 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!

      2. Paul Kinsler
        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.

      3. HieronymusBloggs

        Re: Be careful with .local

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

        Reserved by whom?

    3. Shoot Them Later
      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.

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

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

Other stories you might like