Live data from Hacker News

The days of .dev domains for testing code are over

medium.engineering

51–60 of 95 posts

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

#51

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.

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

Well, sure. If everyone had just followed the RFCs and used “test”, this wouldn't have been a problem, since lots of people didn't, most of them were going to get broken at sometime (unless someone submitted and got approved an RFC to reserve “dev” like “test”.)

Once the gTLD landgrab was announced, it was too late to push the new RFC approach, and it was likely someone was going to get the gTLD.

Someone who was using it for internal use like Google is probably less disruptive to existing users (even with their HSTS action) than if it had been someone who wanted to sell it for public use, which would have produced real chaos.

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

#52

Earlier quoted context omitted.

It's locking literally every individual and business out of a "development" domain, solely for one corporation's for-profit use. Solely to associate Google with development, over any other corporation in the world. This is like Ford registering ".car" gTLD for themselves (although actually worse). > It's also technically not even a change to the status quo. If it wasn't a change to the status quo, they would have jus…

> You're saying that what we should not have done, is okay for Google to do. No, what we should not have done is used an unregistered and unreserved TLD for testing/development. What Google has done is registered the .dev TLD, and started to use it for development.

They were already using it for development. Just like everyone else. They "officially" took it away from everyone else, and then forced it to be TLS-only.

This is the internet development equivalent of the copyrighting of the song "Happy Birthday to You".

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

#53

Having read 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 na…

The third option IMHO is the best, although I'd consider using a domain just for this instead of a subdomain. (can be shorter and uglier then as well)

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

#54
post #14
post #8

Earlier quoted context omitted.

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

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.

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

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

#55
post #46

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.

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

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

#56
post #25

isn't this solved by using Firefox instead?

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.

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

#57
post #40
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.

> 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/ ) 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…

But .dev is being used only internally, according to the article.

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

#58

Earlier quoted context omitted.

It's locking literally every individual and business out of a "development" domain, solely for one corporation's for-profit use. Solely to associate Google with development, over any other corporation in the world. This is like Ford registering ".car" gTLD for themselves (although actually worse). > It's also technically not even a change to the status quo. If it wasn't a change to the status quo, they would have jus…

It's locking literally every individual and business out of a "development" domain, solely for one corporation's for-profit use. And? What entitles any of us to use that domain? And as far as that goes, you can, as I understand it, still use that tld, since your local DNS resolver or hosts file can always override how hosts are resolved in there. The only real issue is if you hit the specific issue where a change in…

> 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 the root name servers. I don't pay for peering transit. I don't pay for core routers.

I guess your point must be that corporations [and nations] should use their money and influence to acquire large chunks of the internet and screw with it in any way that they possibly can. And we should not care, because we are not entitled to it.

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

#59

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.

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

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

#60
post #40
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.

> 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/ ) 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…

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

Post reply on HN