Saboteur

Для того, чтобы создать https, на стороне сервера нужен сертификат.
Сертификат содержит внутри пару ключей (приватную, публичную), и некоторые другие поля, например доменное имя сайта для валидации.

Клиент (браузер) при попытке подключиться по https получает сертификат и публичный ключ. По сертификату он может валидировать что он попал на нужный домен, а публичный ключ нужен чтобы отправить назад на сервер зашифрованный только что сгенерированный ключ-пароль для этой сессии.

Сервер получив зашифрованный пакет расшифровывает его приватным ключом и вот у нас есть tls (https) сессия, и уникальный секрет у браузера и у сервера.

Для каждой новой сессии этот секрет будет генерироваться заново.

Ну а доверие к сертификату идет, если ты сертификат покупаешь у доверенных центров сертификации, чьи сертификаты встроены в систему/браузер и периодически обновляются с новыми версиями браузеров.

Либо ты можешь руками установить сертификат в доверенные. Но самоподписанные нужно будет в каждую систему/браузер руками ставить.

Если в заголовках не идет никакой информации, ты никак не сможешь разрулить, потому отправляя просто tcp пакет на удаленный host.com, этот самый host.com резолвится в айпи-адрес на уровне твоего клиента, и пакет идет на айпи-адрес. Сам айпи адрес, получив пакет, не знает на какой домен этот пакет должен был прийти. Он просто пришел на связку айпи-порт.

http разруливается потому, что в каждом http реквесте приходят заголовки, типа user agent и другие, в том числе и заголовок с урлом (в http1 это Host, в http2 вроде :authority), и по этому хедеру веб сервер может разрулить и перенаправить тебя на нужный сайт/айпи/порт.

Поэтому либо разноси по разным портам, либо юзай http, либо, если это какой-то свой кастомный протокол, добавлять в него информацию про поддомен, и придумать какой-то прокси, который будет эту инфу вытаскивать и роутить уже на конкретные сервера в локалке, но это прям мегавелосипед.

Например, ведь у провайдера DNS-сервер всего лишь кэширует DNS-записи полученные от другого такого же кэширующего DNS-сервера, и эта цепочка в итоге приводит к настоящему DNS-серверу, хранящему настоящую базу DNS-записей (по своей зоне конечно, например зона ".ru")

Нет, там нет длинной цепочки.
ДНС сервер или использует вышестоящий сервер для запросов, если у него нет закешированного ответа, то он не ждет пока там отработает "цепочка", а сразу обращается к "рутовым серверам" (точнее серверам конкретной зоны), чтобы выяснить какой нейм сервер отвечает за конкретный домен.

При регистрации домена, наверх (в сервер отвечающий за зону) отправляется запись про NS сервера, которые будут отвечать за этот конкретный домен - именно этим занимается регистратор. То, что многие регистраторы еще и предлагают свои NS сервера для хранения записи это уже другой вопрос. Ты можешь свои собственные NS сервера для этого использовать.

Если ты обращаешься к DNS серверу провайдера, а тот не знает ответа, он может обратиться к вышестоящему серверу, если так настроено (может быть какой-то централизованный DNS сервер со блок-списком или дополнительными внутренними зонами, например, или какой-то аналог), или может сразу обратиться к серверу соответствующей зоны, который вернет данные про NS сервер на котором уже лежит файл зоны нужного домена со всеми его поддоменами и записями, у него напрямую и выясняешь данные и кешируешь их согласно этой же записи.