Некоторые хосты DNS предлагают способ иметь запись A, которая обслуживает IP-адрес, который определяется на лету (или достаточно часто через запланированное задание) путем разрешения некоторого другого имени хоста за кулисами. Это используется, когда example.com (а не субдомен, такой как www.example.com) ДОЛЖЕН указывать на хост, чей IP-адрес меняется время от времени, без необходимости вмешательства человека при каждом его изменении. В результате при разрешении example.com создается запись A, где IP-адрес записи A определяется сервером имен динамически путем поиска IP-адреса another.example.com, который сам может быть CNAME.
DNS Made Easy и easyDNS называет это «записью ANAME», Route 53 называет ее «записью ресурса псевдонима», CloudFlare называет ее «выравниванием CNAME», DNSimple называет ее «записью ALIAS». Независимо от того, как они это называют, при разрешении имени хоста возвращается стандартная запись A.
Я не встречал публикации о том, как это можно реализовать, хотя это довольно очевидная концепция. Я намерен воспроизвести это поведение на своем сервере имен, который является диспетчером DNS в Windows Server 2012 R2. Существует ли для этого плагин для DNS Manager?
РЕДАКТИРОВАТЬ: чтобы избежать проблема XY Я собираюсь предоставить полную предысторию, начиная с проблемы с точки зрения симптомов, и возвращаясь к зависимостям, поскольку они указывают на то, какие решения были и не были опробованы.
Соединения SSL / TLS с верхним доменом (example.com) создают несоответствие сертификата. Такие попытки подключения используются не очень часто, но все чаще из-за таких вещей, как автоматическое обнаружение хоста почтовыми клиентами. Например, мы просто добавили Exchange в качестве нашего почтового сервера, ориентированного на клиента, а при добавлении user@example.com в качестве учетной записи Exchange в Android или Mac Mail автоматическое обнаружение хоста, по-видимому, получает "типичные" имена хостов, такие как example.com, mail.example.com, exchange.example.com и т. д. и выдает пользователю большое страшное предупреждение о том, что CN в сертификате на example.com не является example.com. Фактически мы используем exchange.example.com, у которого есть соответствующий сертификат, но автоматическое обнаружение должно сначала пробовать example.com.
Предупреждение о несоответствии также появляется, когда веб-браузер указывает на https://example.com, но это смягчается тем фактом, что большинство людей вводят example.com в свою адресную строку без префикса https: //, поэтому они в конечном итоге обновляются до https://www.example.com с перенаправлением при необходимости. Поскольку www.example.com имеет CNAME, он может указывать на хост, на котором нет несоответствия CN.
Сервер с нашим совпадающим сертификатом (который, кстати, может легко иметь записи SAN, соответствующие как example.com, так и * .example.com, никаких проблем с этим) расположен на AWS ELB (эластичный балансировщик нагрузки), о котором предупреждает Amazon. что IP-адрес может измениться в любое время. Из-за динамического IP-адреса на ELB можно ссылаться только через его имя хоста, что означает CNAME / ANAME / Flattening / и т. Д. Вот почему мы можем указывать www.example.com на ELB, но не example.com. Amazon предлагает использовать Route 53 для преодоления любых ограничений. Когда это невозможно, единственное решение - иметь запись A example.com не на ELB, а на вышестоящий сервер, к которому обычно обратные прокси ELB.
Только сам ELB предназначен для меня, поэтому только ELB может иметь установленный мой шаблонный сертификат. Вышестоящий сервер совместно используется клиентурой хостинг-провайдера. Я мог бы попросить хостинговую компанию добавить example.com в свой общий список SAN в своем сертификате, и не было бы несоответствия, но вместо этого я заинтересован в том, чтобы в полной мере использовать ELB по разным причинам.
Мы зафиксировали использование внутреннего DNS на Win2012R2, в то время как все хосты WWW должны быть на AWS для обеспечения отказоустойчивости.
Учитывая точные обстоятельства проблемы, я бы сказал, что идеальным решением было бы указать вершину на веб-сервере, который перенаправляет HTTP-запросы для example.com к www.example.com. www.example.com может, в свою очередь, быть CNAME для записи DNS, управляемой AWS.
В конце концов, вы должны спросить себя, насколько важно, чтобы ваша апексная запись всегда функционировала должным образом. В вашей ситуации это должно быть защитой только для пользователей, которые вводят эту запись вручную. Убедитесь, что ваши серверы и приложения настроены с учетом этого, и риск должен быть значительно снижен. Это также следует отметить в вашей проектной документации (если применимо), чтобы все оставалось таким же.
Лучшее решение - использовать Amazon Route 53 для DNS, а затем добавить запись A с псевдонимом для адреса облачного интерфейса. Он отлично работает, мы используем его каждый день, и ваш DNS будет более «устойчивым», чем его использование на сервере в вашей локальной сети.
Ответ Эндрю абсолютно правильный; небольшой веб-сервер с единственной целью подтолкнуть людей к WWW прекрасно решает проблему со стороны веб-браузера.
Для автоматического обнаружения почты вы исследовали SRV записи? Учитывая, что вы используете Windows, я сразу пойму, что вы используете Exchange. Если это так, Outlook будет автоматически настраиваться на основе SRV и тем самым откажется от сценария несоответствия CN сертификата.
Переходя к ортогональным вариантам, использование лучшего облака позволит вам полностью отказаться от этой глупости (потому что они знают, как обрабатывать фиксированные IP-адреса с произвольной передачей), в то время как использование CDN более высокого уровня имеет встроенную возможность. [N.b. Я работаю в облачном провайдере, который предлагает услуги высокой доступности.]