Динамическая переадресация поддоменов Route53

Я пытаюсь перенаправить домен Route53 на другой домен Route53, сохраняя при этом поддомен.

У меня есть зона хостинга Route 53 для example.com, в которой находится мой основной веб-сайт.

У меня есть еще одна зона хостинга Route 53, например, example.co.uk, которую я перенаправляю на example.com, используя правила перенаправления статических веб-сайтов S3 (как описано на https://stackoverflow.com/a/14289082/918030)

Это отлично работает для корневого домена, но я хотел бы сопоставить поддомены, как в следующих примерах:

sub1.example.co.uk   -->    sub1.example.com

sub2.example.co.uk   -->    sub2.example.com

...

sub999.example.co.uk -->    sub999.example.com

Я знаю, что это можно сделать, создав новую корзину S3 для каждого поддомена и настроив соответствующие правила перенаправления статических веб-сайтов S3, но мне было интересно, есть ли способ сделать это динамически, чтобы * .example.co.uk пересылал на * .example.com. Предпочтительно без запуска отдельного экземпляра EC2 (с запущенным nginx)

Спасибо!

Stijn


person stikkos    schedule 15.10.2015    source источник


Ответы (1)


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

Это, конечно, не решает проблему их предоставления, хотя единичный подстановочный знак CNAME в Route 53 позволит вам выполнить маршрутизацию затем в массовом порядке на S3, используя конечную точку корневого регионального веб-сайта в качестве цели, по крайней мере, так, как S3 работает в настоящий момент, что означает использование некоторого недокументированного поведения S3, которое вряд ли изменится, но, тем не менее, может измениться.

Запросы имен хостов, не совпадающих с уже созданными корзинами, по-прежнему будут отправляться на S3 и возвращать ошибку «NoSuchBucket», которая представляет собой отдельную проблему ... фактически, это пища для размышлений в поисках подстановочных знаков.

Два абзаца назад я упомянул об использовании некоторого недокументированного поведения с подстановочным знаком CNAME, указывающим на S3. Представив, что меня вызывают потенциальные комментаторы, которые прочитали документацию, но не экспериментировали с фактическим поведением S3, я установил подстановочный знак CNAME в одной из моих зон, размещенных на Route 53, указав *.mysterystring.example.com на s3-website-us-west-2.amazonaws.com. Это не то, как в документации говорится, что вы должны это делать, но, конечно же, это работает именно так, как я ожидал ... что бы вы ни поставили вместо *, если у вас есть корзина, названная в честь полного доменного имени в us-west- 2, S3 обслуживает его по запросу. В противном случае это ошибка «NoSuchBucket» с именем сегмента, который S3 пытался найти, но не смог. Итак, почему я не упомянул фактическую область настройки тестирования, чтобы доказать свою точку зрения? Что ж ... Любой, который обнюхивает, может создать корзину, используя одно из неиспользуемых имен хостов, соответствующих этому подстановочному знаку, и иметь веб-сайт в моем домене, размещенный на S3 с этой настройкой, без какой-либо конфигурации с моей стороны и без мои знания. (!?) Конечно, им будет выставлен счет за ведро, но эй, сквоттинг бесплатного домена! Следующее, что вы знаете, они выдают себя за меня, крадут клиентов, кто знает?

Итак, красный флаг: остерегайтесь последствий перенаправления неподготовленных ресурсов с использованием подстановочных знаков.

С другой стороны, если вы хотите перенаправить все (и вы предпринимаете шаги, чтобы убедиться, что пункт назначения действительно тупиковый, который не может быть тайно заявлен за неиспользуемые имена хостов), экземпляр EC2 не будет плохой сделкой. T2.micro может легко обслуживать сотни тысяч легких запросов, таких как перенаправления, в день (у меня есть один, который обычно обрабатывает более 300 тыс. В день и всегда имеет резервные ресурсы ЦП) за <10 долларов в месяц.

person Michael - sqlbot    schedule 15.10.2015