Наш домен размещен на Enom. Записи DNS управляются реселлером Enom в Индии, который называется Pugmarks. Мы хотим переключить службу управления записями DNS с Enom / Reseller на AWS Route53, однако, сохранив Enom в качестве регистратора доменов.
TTL для DNS-записей домена составляет 300 (5 минут). Я проверил TTL для серверов имен и обнаружил, что он составляет 3600 (1 час).
Когда мы заменили серверы имен Enom на серверы Route53, Enom мгновенно перестал разрешать домен. После чего DNS-серверы ISP последовали их примеру после истечения срока действия TTL. Посещаемость нашего сайта упала (по данным Google Analytic). Это влияние понятно.
Некоторое время спустя при запросе записи NS для домена через общедоступные / открытые серверы имен, такие как: 4.2.2.2 - 4.2.2.6 и 8.8.8.8 и 8.8.4.4, мы получаем обновленные записи, указывающие на Route53: т.е.
dig NS <domain.com> @8.8.4.4.
Приведенная выше команда показывает записи сервера имен Route53. Точно так же успешно отображаются все другие записи (A, CNAME и т. Д.), Указывающие, что изменение сервера имен успешно получено этими DNS-серверами. На данный момент мы наблюдаем масштабирование трафика в США в Google Analytics.
Но индийский трафик по-прежнему остается нулевым. Я запросил несколько DNS-серверов у двух разных индийских интернет-провайдеров (не открыт для публики / ограничен для пользователей интернет-провайдеров). Они не возвращают никаких записей. Мы ждали 4 часа, пока провайдер догонит смену рекордов, но тщетно.
Странно, что регион США смог установить новые рекорды, в то время как ни один из опробованных нами индийских интернет-провайдеров (по крайней мере, 5 из них) не смог внести изменения. Любые другие инструменты тестирования DNS в Интернете смогли выбрать изменение, за исключением провайдера. Это приводит к значительному падению трафика, что является серьезной проблемой, поскольку сайт нацелен именно на аудиторию.
После 4 часов ожидания и наблюдения мы вернули записи на серверы имен Enom. В считанные секунды индийский интернет-провайдер смог разрешить записи, как если бы он всегда запрашивал записи у серверов Enom, даже если TTL составляет 1 час. (Route53 будет продолжать разрешаться, поэтому трафик в США не изменился)
У меня есть два сомнения:
Насколько я понимаю, пункт 1 является главным подозреваемым. Вот ссылка на сайт это дает подробную информацию о домене. Он показывает родительский сервер имен как 48-часовой TTL, в то время как локальный сервер имен составляет 1 час TTL. Может ли это быть причиной проблемы?
Я хочу перенести управление DNS на Route53, и у меня не может быть простоя более 6 часов. Мы тщетно пробовали до 4 часов.
Почему это происходит и каков выход?
Одна альтернатива, возможно, заключается в том, чтобы сохранить все записи DNS до 49 часов TTL (TTL больше, чем TTL для NS-записи в родительской записи), а затем переключить серверы имен после распространения записи этого изменения TTL. Однако это не надежно, хотя его можно попробовать.
(Это старый вопрос, но все же он заслуживает ответа)
По всей видимости, вы сделали следующее: вы подготовили новые серверы имен для авторитетного ответа на вопросы для вашего домена. Затем вы переключили регистрацию (т.е. изменили записи NS для dnsindia.com на родительских DNS-серверах, ответственных за com указать на новые DNS-серверы); в тот же момент старые серверы имен перестали отвечать на запросы о dnsindia.com (или ответил NXDOMAIN или что-то в этом роде).
Как следствие, влияние - особенно для вашей основной аудитории - было следующим: через 1 час любые данные, кэшированные на преобразователях DNS у индийских интернет-провайдеров, устаревают - но только данные для ваших записей, такие как записи A для www.india.com. Следовательно, преобразователи попытаются запросить соответствующие серверы имен для получения свежих данных. Однако информация который запрашиваемый сервер еще не устарел: эта информация поступила из com зона и TTL равнялся 48 часам (так что, вероятно, до 47 часов, скажем, 24 часа в среднем); поскольку это относится к ныне несуществующим DNS-серверам у старого провайдера, как вы заметили, происходят сбои. С другой стороны, запрос удаленного распознавателя будет успешным, поскольку вряд ли будет иметь кешированную копию родительских записей NS.
Как это правильно делать? Возможны следующие стратегии (в порядке убывания предпочтения):
a) Убедитесь, что старые DNS-серверы продолжают обслуживать вашу зону в течение как минимум 48 часов после перехода (родительский TTL), но не намного дольше. Фактически, это метод, который я использовал большую часть времени; старый администратор сервера просто должен не забыть удалить зоны позже.
б) Убедитесь, что старые DNS-серверы разрешают рекурсивные запросы (как минимум для вашей зоны и как минимум на 48 часов); обратите внимание, что серверы, которые являются "официальными" DNS-серверами для некоторых зон, обычно не разрешить рекурсивные запросы
c) Перед перемещением зон измените местный TTL для всех записей, скажем, на 96 часов. Затем подождите 48 часов, прежде чем делать ход. Таким образом, резолверы обычно должны иметь копию ваших записей DNS в кеше, которая сохраняется дольше, чем устаревшие записи NS. Этот метод не идеален и становится проблематичным, особенно если есть «перекрестные ссылки» между доменами или если есть записи, которые запрашиваются реже, чем основные записи.
г) В качестве альтернативы, перед движением зон уменьшите родитель TTL до 1 часа (или до времени простоя, которое вы сочтете приемлемым), подождите 48 часов и делайте ход. Однако, возможно, будет невозможно изменить TTL на такое низкое значение в родительской зоне (они не хотят, чтобы их запрашивали так часто), и даже если это так, вам придется учитывать их графики обновления зоны