Ответ 1
Здесь есть два отдельных, но взаимозависимых уровня косвенности. Во-первых, какой IP-адрес DNS-имя в конечном итоге разрешает. Второй - это то, что делает сервер на этом IP-адресе.
Помните, что при вводе URL-адреса в браузере первое, что происходит, это поиск DNS. Как правило, это обрабатывается операционной системой – а не сам браузер.
Итак, ваш браузер спросит ОС, "что такое адрес example.com?" ОС будет искать запись, и если она получит CNAME
, она будет искать эту запись, пока не найдет запись A
. Затем ОС отвечает на браузер с ответом.
Затем ваш браузер открывает TCP-соединение с этим IP-адресом:
- Если URL http://, он подключается к порту 80, затем выдает запрос HTTP.
- Если URL http s://, он подключается к порту 443, устанавливает соединение TLS/SSL (что означает проверку сертификатов), затем выдает HTTP-запрос по защищенному каналу.
Только в этот момент может произойти перенаправление HTTP. Браузер отправляет запрос (GET /
, и сервер может ответить 301 на любой другой URL-адрес.
Поймите, что услуги "перенаправления поддоменов", предлагаемые регистраторами, представляют собой не что иное, как обычный HTTP-сервер, который выдает 301. Когда вы выбираете опцию перенаправления регистратора, они просто устанавливают запись A
вашей вершины домена на сервер, которым они управляют, и этот сервер сообщает браузерам перейти на www.example.com.
Поскольку большинство регистраторов не позволяют загрузить SSL-сертификат на свой сервер перенаправления, браузеры не могут установить необходимое безопасное соединение с сервером, и поэтому они никогда не выдают HTTP-запрос. Таким образом, запросы на https://example.com терпят неудачу.
Итак, почему вы не можете просто CNAME
вершину? Это запрещено.
Доменная система предоставляет такую функцию, используя каноническое имя (
CNAME
) RR [Рекордный ресурс]. ACNAME
RR идентифицирует имя своего владельца как псевдоним и определяет соответствующее каноническое имя в разделеRDATA
RR. Если aCNAME
RR присутствует в node, никакие другие данные не должны быть присутствует; это гарантирует, что данные для канонического имени и его псевдонимов не могут быть разными. Это правило также гарантирует, что кешированныйCNAME
может быть используется без проверки с авторитетным сервером для других типов RR.
Спецификация требует, чтобы запись CNAME
была единственной записью для данного (дополнительного) домена. Это противоречит требованию наличия записи SOA
на вершине. (Есть некоторые попытки там изменить спецификации, чтобы позволить CNAME
и SOA
сосуществовать, но все еще есть много сломанных реализаций SMTP, которые будут смущены CNAME
в домене.)
У вас есть следующие опции, чтобы заставить SSL работать на вершине:
- Используйте стороннюю службу, поддерживающую SSL на сервере переадресации. Вы, скорее всего, заплатите за это. Здесь одна услуга. я не будет рекомендовать этот маршрут, так как он берет контроль над надежностью из ваших рук и требует, чтобы вы сдали ключи к вашему сертификату SSL тому, кто может или не может быть заслуживающим доверия.
- Запустите собственный сервер перенаправления. Поскольку для вершины требуется запись
A
, вам понадобится статический IP-адрес, который не предоставляет сервисы, такие как Heroku и AWS ELB. Поэтому, если вы находитесь в облачной среде, будет очень сложно (если не невозможно) гарантировать надежность. С положительной стороны вы сохраняете контроль над вашими SSL-ключами. - Используйте хост DNS, который позволяет вам установить псевдоним. Укажите псевдоним в ваш домен Heroku/ELB/что угодно. Это, скорее всего, лучший вариант.
Псевдоним не является технически типом записи DNS. Вместо этого это особая конфигурация на стороне хоста DNS, которая возвращает запись A
из результата другого поиска. Другими словами:
- Ваша ОС выдает DNS-запрос example.com на ваш хост DNS.
- Ваш DNS-узел считывает внутреннюю конфигурацию псевдонима и выдает запрос DNS для этого домена. Поэтому, если у вас есть псевдоним, настроенный для example.herokuapp.com, он будет искать запись
A
этого домена. - DNS-хост возвращает простую запись
A
с IP-адресами, полученными от поиска псевдонима.
С записью псевдонима вы можете указать свою вершину на тот же балансировщик облачной нагрузки, что ваш домен www CNAME
d to. Предполагая, что вы настроили SSL в домене www, голый домен будет работать нормально. На данный момент, это ваш выбор независимо от того, перенаправляет ли ваше приложение перенаправление или просто обслуживает ваш контент непосредственно над голым доменом.