Проверка «работоспособности» DNS - указывают ли домены на правильные IP-адреса

Планирую переход от одного регистратора к другому. К счастью, мне удалось предварительно ввести информацию о зоне, чтобы при передаче все работало так же.

Однако, будучи обожженным в прошлом, я немного параноик и хочу иметь возможность заранее настроить системы мониторинга, чтобы убедиться, что домены продолжают указывать на одни и те же места.

Меня беспокоит, как мне установить что-то подобное, не сталкиваясь с проблемой кешированных запросов DNS? Я очень хочу, чтобы каждый поиск был новым, чтобы не было проблем.

Итак, я думаю, я ищу две вещи:

1. а надежный инструмент для тестирования поиска DNS (который по очевидным причинам не размещен ни на одном из моих серверов, поскольку существует опасность, что они не смогут отправить мне электронное письмо, если что-то пойдет не так) и
2. а тест, который не извлекает кешированную запись и сохраняет информацию DNS в актуальном состоянии

Кроме того, я предполагаю, что для кэшированных серверов все будет хорошо, поскольку новые записи совпадают со старыми. Но есть ли что-нибудь опасное в этом предположении? Есть ли основания полагать, что смена регистраторов и серверов имен одновременно может иметь побочные эффекты, о которых я не знаю?

Как все прошло, если кому интересно

По всей видимости, при переносе старые DNS-серверы были сохранены, поэтому какое-то время никто доменов вообще указали на IP (я думаю, как только происходит передача, старый регистратор стирает свои записи). Мне пришлось обновить эти записи, чтобы указать на новые серверы имен и повторно импортировать все записи зон (к счастью, в системе нового регистратора есть хороший инструмент для импорта файлов зон, очень полезный!). По какой-то странной причине локальному серверу имен службы веб-хостинга требовалось гораздо больше времени, чем другим DNS-серверам, для обновления своих записей, поэтому сам сервер не понимал, какие записи он может обслуживать. Если кто-то еще проходит через тот же процесс, вот несколько вещей, которые вам следует сделать, чтобы избежать того, через что прошел я:

1. Убедитесь, что записи зоны функционально идентичны у всех регистраторов. [Но см. Ниже]. К сожалению, одна запись, которая должна была быть записью A, была сохранена как запись CNAME с плохими результатами. Это легко для регистраторов, которые позволят вам экспортировать свои записи в виде файла зоны, и сложно для тех, у кого есть только веб-страница, которую нужно вырезать и вставить.
2. Убедитесь, что новый регистратор определенно настроен как новый хост DNS По какой-то причине в процессе переноса я неправильно настроил домен как DNS-хостинг нового регистратора. Это было во время процесса корзины покупок, а не на этапе настройки после покупки. Очевидно, в этот момент мне нужно было отменить запрос на передачу и начать все сначала, потому что у меня не было возможности изменить его так, чтобы он бы включить активацию.
3. Убедитесь, что при переносе домена вы настроены на получение предупреждения. Я не узнал, что передача произошла, пока один из доменов не перестал работать, потому что я не был настроен в качестве авторизованного контактного лица для этого домена.
4. Превыше всего, постарайтесь не оказаться на полпути через восьмичасовую поездку на автомобиле со своей семьей, когда трансфер наконец-то пройдет. Слава богу, в Dunkin Donuts есть бесплатный Wi-Fi - кто знал? (О, и это действительно сложное тестирование DNS в то время, поскольку я не мог использовать какие-либо прокси-веб-серверы для тестирования DNS-запросов из разных мест, поскольку веб-прокси блокируются программным обеспечением, используемым Dunkin Donuts для обеспечения доступа к Wi-Fi).

Пару вещей я сделал получить право в конце концов:

1. Замена множества записей A записями CNAME. Вероятно, это было бы намного сложнее, если бы мне пришлось отслеживать десятки идентичных A-записей. Кроме того, мне нужно было беспокоиться только о правильном распространении нескольких доменов, поскольку все остальные указывали на другие домены.
2. Сохранение резервной копии файла зоны. Когда записи были потеряны во время передачи, это было очень полезно иметь уже готовый файл зоны с необходимыми мне записями. Единственное изменение, которое я мог бы сделать, - это выполнить окончательное сканирование файла зоны и сравнить его с предварительной передачей старой конфигурации, так как, к сожалению, в файле зоны отсутствовала пара поддоменов.
3. Использование довольно низкого TTL. К сожалению, большинство регистраторов не позволяют вам иметь TTL короче 1/2 часа, но я не понимаю людей, которые предпочитают устанавливать TTL примерно на неделю. Я бы предпочел, чтобы инфраструктура принимала кучу дополнительных запросов, чем какой-нибудь компьютер где-то по прошествии пяти дней все еще указывает не в том месте.