[dns-operations] TLD(s) for private use

[Phil Pennock]

On 2017-09-08 at 11:05 +0100, James Stevens wrote:
> the "correct" solution is to register a name - probably at least 7 or 8
> characters long by now, add a "private" or "prv" prefix, then add the
> department & host name, so
> 
> printer.sales.prv.corporate.com

Be aware that this means every ancient printer with a web interface and
an XSS vulnerability can be a path to stealing cookies for
"corporate.com" because cookies can be shared up until the demarcation
point for being into a public suffix (cue angst over whether PSL is evil
or not, angst over failed IETF attempts to put demarcation in DNS
somehow, etc).

So, sticking inside the "corporate box" for a moment longer:

This is why the approach I've seen work best is to just use a different
TLD for internal stuff.  ".biz" works well, because it was an early new
gTLD and got a lot of spammers, so ended up blacklisted on mail-systems
everywhere.  Thus for systems which you never want sending mail anyway,
except perhaps to you through your systems, it's even better.

"printer.sales.corporate.biz" for internal stuff,
"something.corporate.com" for public-facing stuff which gets access to
account signin cookies, etc.

Has the advantage that you _can_ tie into public DNS if you want, and so
get X.509 PKIX certificates issued from public CAs.

<https://jira.product.corporate.biz/> without needing to deal with
helping folks install a corporate Certificate Authority on their iPads
or whatever is currently trendy.

> I think its also important to think outside the "large US corporate" box and
> think about (say) a 6 to 10 PC business in any developing nation for whom
> paying $8 to $10 per year to be "correct" is out of the question.

Just keeping this in to (1) agree absolutely, and so draw a line between
the issue of whether or not
<https://tools.ietf.org/html/draft-lewis-user-assigned-tlds-00> or
<https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00> should
make progress (I think that both are great) and (2) contrast this
solution for small unmanaged or locally-managed setups with what should
be done today for managed corp-internal setups.

For myself: ULA exists, RFC1918 exists, the general problem space
therefore exists, the world is _not_ flat and the more we try to make it
absolutely flat the more human nature and abuse reminds us of why total
visibility is not necessarily the best engineering solution to social
problems, so ".internal" is a good path forward.

Renumbering or renaming might be painful.  Doesn't mean that the right
solution is to try to make them unnecessary with Total Global
Uniqueness, but to make sure that things can be well managed and
migrated smoothly should the time come that you do need to rename.
Manageability and getting a box cut over to a new name helps more than
the unpatched box with 7-year-old security vulnerabilities continuing to
work untouched for all time because hey, the name was right from the
very beginning.

-Phil