The shared IPv4 address itself is often an additional server running an nginx (or something similar) that inspects the SNI and forwards the TLS traffic (which does not terminate here) to the respective endpoint, in this case potentially a Tor relay.
Do server providers even allow you to use a domain that you don't own (such as the proposed *.home.arpa)? That sounds like it could lead to issues for them down the line, e.g. if a customer comes along who owns a domain I "squatted" for my server. Thus, even if this is permitted nowadays, I wouldn't be surprised if they start locking this down.
* If a censor were to use fingerprints alone for detecting censorship, the censor would need to obtain a consensus which already contains the IP addresses plus port numbers anyway.
Why would they even bother with checking the fingerprints? Surely the odds of a "legitimate" service using [0-9a-f]{30}.home.arpa are negligible.
[this] will do nothing for an attacker who is actively trying to detect and/or block the use of Tor.
The simpler it is to block vanilla Tor, the harder it will be for censors to fuck it up. For one, you would no longer need to keep an up-to-date consensus - and some people do seem to exploit the fact that censors don't always keep it updated[1]. [1] https://github.com/ValdikSS/tor-relay-scanner Back to my first point, maybe relays should be able to set an arbitrary SNI instead? This would be much more flexible for e.g. when your provider requires you to actually own the used domain, but it also would mean that most relays could keep using the randomly generated domains. I assume this would only be used by a minority of relays, and the SNI would only be embedded in the microdescriptor if actually required, so hopefully this shouldn't affect their sizes too much?