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