[jcrites]

> Having DNS records leak could actually provide potential information on things you'd rather not have public.

This is true, but using a regular domain name as your root does not require you to actually publish those DNS records on the Internet.

For example, say that you own the domain `example.com`. You can build a private service `foo.example.com` and only publish its DNS records within the networks where it needs to be resolved – in exactly the same way that you would with `foo.internal`.

If you ever decide that you want an Internet-facing endpoint, just publish `foo.example.com` in public DNS.

[nine_k]

The wisdom goes: "Make invalid states unrepresentable".

In this case, foo.internal cannot represent a publicly accessible domain, much like 10.x.x.x cannot represent a publicly routable IP address.

No matter how badly you misconfigure things, you are still protected from exposure. Sometimes it's really valuable.

[leeter]

I'm not disagreeing at all. But Hanlon's Razor applies:

> Never attribute to malice what can better be explained by incompetence

You can't leak information if you never give access to that zone in any way. More than once I've run into well meaning developers in my time. Having a .internal inherently documents that something shouldn't be public. Whereas foo.example.com does not.

[luma]

It's not DNS that's leaking those names, it's certificate transparency. If you are using certs on foo.example.com, that's publicly discoverable due to CTLs. As others have mentioned here it leaves you with a dilemma, either you have good working certs internally but are also exposing all of your internal hostnames, or you keep your hostnames private but have cert problems (either dealing with trusting a private CA or dealing with not having certs).