[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... If you don't have HTTPS of some sort, you can't test these features locally.)

[hobofan]

- You can set up a service on the domain that logs the incoming requests on the domain, which can help you pinpoint misconfigured parts of your infrastructure

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