Если у вас www.domain1 -> CNAME на domain2 -> Route 53 NS -> сервер, можно ли заменить domain2 и все равно достичь сервера с www.domain1?

Вопрос или проблема

Наш сайт не работает, потому что наш провайдер хостинга закрылся, и срок действия доменного имени, используемого для настройки производственных и развивающих серверов на AWS, истек. У нас нет доступа к этому доменному имени, и мы не можем связаться с кем-либо из бывшего провайдера. Текущая настройка DNS выглядит примерно так:

companyname.com [CNAME www - это псевдоним prod.company-deadhost.com] ->

companyname-deadhost.com [NS ns-2048.awsdns-64.com, ns-2049.awsdns-65.net, ns-2050.awsdns-66.org, ns-2051.awsdns-67.co.uk] ->

[IP, который мы не знаем] Сервер веб-сайта

У нас есть полный доступ к companyname.com, но нет доступа к companyname-deadhost.com, и мы не можем проверить, были ли там какие-либо записи A или другие записи. Я видел документацию AWS / Route 53, в которой говорится, что настройка доменного имени и использование NS-записей Route 53 – это все, что нужно для подключения веб-сервера к доменному имени (то есть, вам не нужен IP-адрес или что-то еще) Эээ, нет, не видел – похоже, нам тоже понадобится IP-адрес.

У нас нет доступа к companyname-deadhost.com, но могу ли я настроить новый ‘промежуточный’ домен с этими NS-записями (не теми, что выше, мы нашли запись о первоначальных), например:

companyname.com [CNAME www - это псевдоним prod.newmiddledomain.com] ->

newmiddledomain.com [NS ns-2048.awsdns-64.com, ns-2049.awsdns-65.net и т. д. и т. д.] ->

[IP, который мы не знаем] Сервер веб-сайта

Трафик на веб-сервере все равно будет исходить от ‘companyname.com’, и веб-сервер должен быть настроен для разрешения этого – так что это должно сработать? Или все же не сработает, потому что он идет через newmiddledomain.com, а не companyname-deadhost.com.

Мне нужно что-то запустить на домене как можно скорее, и мне не хочется тратить время на попытки и ожидание, пока DNS-записи распространятся, если это невозможно… Похоже, мы в тупике без IP для экземпляра EC2, так что это больше гипотетическая ситуация…

Ответ или решение

Теоретически вы затрагиваете вопрос настройки DNS структуры, связанной с механизмом перенаправления через CNAME записи и использованием службы Route 53 от AWS для резолвера DNS. В данной ситуации важно учитывать несколько ключевых факторов, которые могут повлиять на работоспособность предложенной альтернативы.

Теория:

Понимание DNS и CNAME записей: DNS (система доменных имен) действует как телефонная книга для интернет, позволяя пользователям использовать доменные имена вместо IP-адресов. CNAME записи (Canonical Name Records) служат для создания псевдонимов, направляя одно доменное имя на другое.
Роль Route 53: Amazon Route 53 – это масштабируемая и надежная служба DNS от AWS, которая позволяет управлять DNS-записями для доменных имен. Route 53 может использоваться для маршрутизации трафика к AWS ресурсам (например, EC2) с помощью соответствующих NS (Name Server) записей.
Зависимость от промежуточного домена: В вашем случае, домен companyname.com устанавливает CNAME на prod.company-deadhost.com, который затем перенаправляет на соответствующие NS серверы AWS, управляющие маршрутизацией трафика к серверу. Потеря доступа к companyname-deadhost.com создает проблему, так как точка входа (NS серверы) больше не принадлежит вам.

Пример:

Предположим, ваш текущий CNAME маршрут выглядит следующим образом:

companyname.com -> prod.company-deadhost.com (CNAME на промежуточный домен)
prod.company-deadhost.com -> ns-yyyy.awsdns-xx.xyz (NS записи AWS)

Если вы попытаетесь заменить company-deadhost.com на новый домен, например, newmiddledomain.com, создавая такую цепочку:

companyname.com -> prod.newmiddledomain.com (новый CNAME)
prod.newmiddledomain.com -> ns-yyyy.awsdns-xx.xyz

на первый взгляд, это может выглядеть как прямая замена. Однако есть один важный момент: сервер должен корректно обрабатывать HTTP запросы, идентифицировать домен, с которого они поступают, и принимать их. Если сервер настроен на отклонение запросов от неизвестных доменов, это может вызвать проблемы, даже если DNS запись выглядит правильно.

Применение:

Определение текущей конфигурации сервера: Прежде чем вносить изменения, необходимо понять текущее состояние конфигурации сервера. Если сервер был настроен на обработку запросов только от известных доменов, вам потребуется внести соответствующие изменения на сервере, чтобы он принимал запросы от newmiddledomain.com.
Тестирование перед внедрением: Поскольку DNS изменения могут занять время для распространения, важно сначала протестировать новую настройку в контролируемом окружении. Это можно сделать с помощью временных записей в DNS, которые можно будет быстро изменить в случае неудачи.
Поиск IP-адреса сервера: Ваша проблема усложняется тем, что вы не знаете конечного IP-адреса. Даже если вы успешно создадите новые DNS записи, незнание IP-адреса может усложнить задачу маршрутизации. Попробуйте обратиться к старым резервным копиям или другим источникам информации, которые могли бы содержать этот IP.
Дополнительные шаги: Если ни один из этих шагов не помогает, рассмотрите возможность запуска нового экземпляра сервера на AWS и перенаправления DNS на этот новый ресурс, чтобы быстро восстановить доступность сервиса. Это может потребовать больше ресурсов, но в крайних случаях это может быть наилучшим выходом.

Вывод:

Заменить домен-убежище и перенаправить DNS трафик возможно, если сервер настроен правильно и у вас есть доступ к соответствующим ресурсам, таким как IP-адреса и необходимые разрешения на внесение изменений. Это требует тщательной проверки и тестирования перед переносом в продуктивную среду. Однако, без знания IP-адреса старого сервера или без возможности его получения, вы можете столкнуться с дополнительными трудностями. В таких случаях может понадобиться реструктуризация сети или работа с инфраструктурой AWS для минимизации простоя.