I've been trying to upgrade from 10.10 to 10.11 for a while now, as the Android TV app keeps nagging me, and every attempt ended with impossibly long library scan times.
After some thorough investigation, it appeared that a Home Videos type collection causes unending scan (yet to be solved), but also that Jellyfin does a lot of writes to the config directory (either database or metadata or both). Mine's on spinning media part of a ZFS pool. I tried a few performance tuning options, such as testing the config dir with recordsize (similar to block size) of 4K, 8K, 64K, 128K and library scans fell from 30-40 minutes down to 8-13min with 4K-64K. The ZFS tuning wiki suggest 64K recordsize with LZ4 compression for SQLite workloads such as Jellyfin. That seems to work as well as 4K and 8K but likely is faster when reading thumbnails and such.
Note that upgrading to 12-rc3, which is supposed to speed up library scans did not improve scan times for me. Optimizing config/database write speed did. I cross-checked the culprit by experimenting with moving the config dir to NVMe and RAM. Both of those got the scan times down to 8-9 minutes compared to the optimized spinning media's 12-13.
So if you had upgraded (or about to) to 10.11 your library scans are (about to get) dog slow and your Jellyfin's config dir resides on spinning media, optimize its write performance for SQLite.
Hm. As far as I know that can only be done if AXFR is enabled (it's not), if the domain has entered some search engine that has remembered it, or through brute force lookup. Am I missing something?
Give it a look on https://dnsdumpster.com/ or similar. Your dns records are inherently public, so anyone that works out the domain can work out the subdomain. In fact there are plenty of tools that just scan every domain/subdomain they can find.
Thanks for the pointer. Checked, tried a couple others - they don't know about it. They have some other non-random DNS records. AFAIK they can absolutely find it if they scan for all domains, but it'll take forever if the name is randomly-generated and sufficiently long. Someone has to be determined to spend the resources. This doesn't guard against that but against bots trying to fuck with the service at the port. I could move it to a wildcard though. There's an overlap with another subdomain (they're actually sub-subdomains and the first sub is common) but I could move that.