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