Это может показаться довольно непонятным и, возможно, довольно нишевым, но потерпите меня.
Ситуация такая:
Мы хотели бы удалить SPOF, чтобы это перенаправление выполнялось на нескольких серверах. Я считаю, что установка корневого домена на CNAME для использования ELB противоречит RFC, и я не верю, что наш DNS-хост позволит нам это сделать.
Что мы должны сделать, чтобы удалить этот SPOF с учетом этих ограничений? По общему признанию, это незначительное влияние, если оно исчезнет по какой-либо причине, но бизнес хочет снизить этот риск.
Есть лучший подход для работы с доменом apex, чем размещение экземпляра «перенаправителя» на EC2.
Вы можете разместить статический веб-сайт на Amazon S3, который можно настроить для перенаправления ваших запросов на определенный домен. Если вы используете Route53 - существует запись типа «псевдоним», которая поможет вам в этом. У других DNS-провайдеров есть похожие.
Следуйте этой статье в блоге, чтобы узнать подробности https://aws.amazon.com/blogs/aws/root-domain-website-hosting-for-amazon-s3/
S3 - отказоустойчивый сервис, поэтому вы обязательно удалите свой SPOF по довольно низкой цене.
Как уже упоминалось, статический хостинг S3 - хороший вариант, но для него требуется запись псевдонима, размещенная в Route 53 ... и он не поддерживает TLS.
TLS (для браузеров с поддержкой SNI) для сайтов, размещенных в корзине S3, может быть предоставлен с помощью CloudFront перед S3, который отлично работает, но также требует псевдонима в Route 53.
Обратите внимание, что псевдоним не является типом записи DNS. Псевдоним - это внутренняя конфигурационная директива на DNS-серверах Route 53, в которой говорится: «Когда мы получим здесь запрос на эту запись, мы внутри (в базе данных Route 53) найдите и верните тот же результат, который мы бы вернули, если бы мы действительно получили запрос для другой, другой записи ». В конце концов, он предлагает функциональность, которая кажется похожей на CNAME, но вместо рассказывая решатель чтобы рассматривать одно имя хоста как эквивалентное другому, и искать другую запись для получения дополнительной информации, Route 53 выполняет этот шаг поиска внутри, оставляя преобразователю ничего не знать о фактическом механизме, используемом для удовлетворения запроса ... и благодаря этому внутреннему (а не внешнему) механизму поиска записи псевдонимов работают так, как нужно, на вершине зоны, а CNAME - нет.
Если у вас нет механизма DNS, который может адаптироваться к динамическим IP-адресам, как того требуют хостинговые сайты на S3 и CloudFront, не существует надежного способа устранить SPOF, хотя некоторые другие поставщики DNS поддерживают возможность, аналогичную записям Alias в Route 53. CloudFlare, например, называет это «выравнивание CNAME», когда их DNS-сервер, когда он получает запрос для вашей A-записи, выполняет поиск на задней стороне для разные A-Record (в другом домене, например s3.amazonaws.com или cloudfront.net), а затем возвращает этот ответ запрашивающей стороне. Это дает тот же чистый результат, что и псевдоним. Он не является «внутренним» для стороннего DNS-сервера, но поскольку второй запрос отправляется обратно, преобразователь клиента не видит ничего необычного в его поведении.
В январе 2015 г. AWS объявила об автоматическом восстановлении инстансов EC2, который разрушит и перестроит экземпляр, который не прошел проверку доступности Cloudwatch, создав новый экземпляр с тем же «всем» - идентификатором экземпляра, томами EBS, эластичным IP-адресом и т. д., и эта функция работает с несколькими классами экземпляров, включая класс t2.
Или, в крайнем случае, вы можете частично смягчите SPOF, подготовив более одной из этих перенаправляющих машин и предоставив несколько A-записей на вершине зоны для циклической «балансировки нагрузки». Это уменьшит, но не устранит, влияние выхода из строя одной из машин, хотя жизнеспособность такого решения во многом зависит от поведения браузера. Это не будет считаться решением "высокой доступности", но (возможно) лучше, чем ничего.
Чтобы избежать повторного перенаправления, я бы хотел по возможности сделать там TLS.
Если я правильно понимаю этот комментарий, то вы на самом деле иметь делать там TLS. Если я укажу в браузере на https://example.com, эта конечная точка должен говорить TLS и иметь действующий сертификат для имени хоста, или ссылка фактически не работает - сервер не может выполнить перенаправление, если он не может согласовать TLS таким образом, чтобы браузер был доволен.