HTTPS перенаправляет из корневого домена (т.е. Вершину или "голый" ) в субдомен "www" без броска браузера?

DNS-записи требуют, чтобы IP-адрес был жестко закодирован в ваши приложения. Конфигурация DNS

... который Героку рекомендует избегать. Heroku предлагает два метода обхода:

... используя поставщика DNS, который поддерживает CNAME-подобные функции на вершине и использует перенаправление поддоменов`.

Мой вопрос вращается вокруг последней опции (потому что первая не поддерживается DreamHost AFAIK):

Можно ли перенаправить из корневого (то есть apex или 'голого ") домена в субдомен" www "для HTTPS-запросов без броузера браузера?

Героку не думает:

... приложения, требующие шифрования SSL, должны использовать конфигурацию ALIAS/ANAME в корневом домене. Переадресация поддомена вызовет ошибку браузера, когда корневой домен будет запрошен через SSL (т.е. https://example.com).

... но я надеюсь, что это неполное (или неверное) утверждение.

ОБНОВЛЕНИЕ ЗАЩИТЫ:

Реальная проблема с перенаправлением с вершины на "www" заключается в том, что набрав https://example.com непосредственно в браузер, вы получите предупреждение о сертификате. Конечно, это край, но не маленький.

ОБНОВЛЕНИЕ РЕШЕНИЯ:

Я решил эту проблему с DNSimple. (Даже не нужно было переносить мой домен!)

Я считаю, что easyDNS предлагает аналогичную функцию, но с удивлением обнаружил, что большинство других хостинговых компаний не делают.

Ответ 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 [Рекордный ресурс]. A CNAME RR идентифицирует имя своего владельца как псевдоним и определяет соответствующее каноническое имя в разделе RDATARR. Если a CNAME 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, голый домен будет работать нормально. На данный момент, это ваш выбор независимо от того, перенаправляет ли ваше приложение перенаправление или просто обслуживает ваш контент непосредственно над голым доменом.

Ответ 2

Вам нужен сертификат, который защищает как www.example.com, так и example.com.

Ответ 3

ПРИМЕЧАНИЕ. Я не пробовал это с помощью приложения Heroku. Я по-прежнему разделяю это решение здесь, так как это первая страница stackoverflow, которая появляется для поиска "перенаправления из голого домена в www-версию". Это может помочь другим, которые ищут ответ на общий перенаправление.

Я успешно перенаправил голый домен на www-версию. Кроме того, я также перенаправил версию HTTP в версию HTTPS, используя настройки DNS домена Google в синтетических записях.

Удалите все записи "A" для "@" в вашем DNS.
Добавить синтетическую запись с субдоменом = '@' и перенаправить ее на www-версию вашего сайта.
После добавления отредактируйте эту же запись и измените значение по умолчанию http://www.example.com 'на https://www.example.com '. Обратите внимание на 's' в http здесь. Нажмите "Сохранить".
Что это. Ваше перенаправление теперь выполняется по настройкам DNS.

Подробные шаги описаны здесь: https://www.am22tech.com/redirect-naked-domain-www-http-https-google-domains/

Ответ 4

Этот пост кажется относительно старым; Мне интересно, есть ли какие-нибудь хорошие новости по этой проблеме.

Вы упомянули "ОБНОВЛЕНИЕ РЕШЕНИЯ. Я решил эту проблему с помощью DNSimple (даже не пришлось переносить мой домен!)" - как они решают эту проблему? Я только что говорил с ними, они говорят, что эта функция находится в тестировании, поэтому они не могут сделать это сейчас, она недоступна.

Это такая странная проблема, но кажется, что решений вообще нет, если только я не хочу стать главным инженером и запускать свои собственные серверы.