While I agree that it probably shouldn't matter it could help an attacker gather knowledge about your internal network. Perhaps it's of interest that you use a specific monitoring tool or mail server internally - that could make phishing emails easier to craft.
Edit: Or do you mean as part of the challenge-response mechanism? Yeah, that would have to be public.
Besides possibly being a function of a provider's API; DNS server security policies can be used to limit updates to certain domains and/or record types based on preshared key. Since the DNS-01 challenge only needs to make a TXT record with a predetermined name you can configure a zone like so (using BIND syntax as an example):
key "example-key" {
algorithm hmac-sha512;
secret <KEY_HERE>;
};
zone {
...
update-policy {
grant "example-key" name _acme-challenge.example.com TXT;
};
};
However how long before the default option is via https only.
Sure, someone can see you have internal servers under * .homelab.mydomain.com, but they aren't going to know what specific hostnames exist there.
You could use a private CA or official wildcard certs.
If you're hostnames are sensitive then Web PKI is not the correct solution, like you have identified. At that point you should be running an internal PKI and be responsible for running/maintaining to whatever standards you deem fit.
Making Web PKI less transparent to fit your use case is not the answer.
> CT is a bank alarm that goes off after the bank's been robbed
> There are better solutions
How do you propose to prevent invalid certificate issuance? In particular, how do you propose to observe whether any CA accepted by browsers has issued a certificate to someone other than you for a domain you control, if you presume that there are malicious actors willing and able to compromise certificate authorities? Your threat model is nation-states. Assume someone else is willing to put up the cash, what's your solution that works strictly better than certificate transparency, and in particular (since you called attention to it) prevents invalid certificate issuance rather than just logging it for subsequent audit (and CA trust revocation)?
Things like certlint have come about to help prevent misissuance, but I would wager that most CAs have not added it to their issuance pipeline.
I agree that CT is not the solution and ideally it would not be necessary, however, the number of issues found and still being discovered justifies it. Trusting CAs to just issue proper certificates has been a failed policy.