Назад | Перейти на главную страницу

Почему это изменение DNS сайта не удалось в некоторых частях США

Задний план

Мы переключили общие хосты с местной мамы и попсы на crystaltech. Сайт был полностью скопирован и готов к смене DNS. Сайт «мама и папа» не предлагал никаких инструментов для самостоятельного управления DNS, поэтому нам пришлось позвонить по телефону и рассчитать время последнего перемещения базы данных с их изменением DNS.

Что произошло Из Орегона через Comcast и со старого хоста в Орегоне через регионального провайдера оптоволокна. Старый хост обновил свои DNS-серверы, чтобы они указывали на наш новый IP-адрес. Они изменили его с 207.x.x.x на 67.x.x.x

В Орегоне я сбросил свой DNS на моем компьютере с Windows 7 на двух компьютерах, и менее чем через 30 секунд доменное имя site.com заработало, как ожидалось. Ping tracert подтвердил, что доменное имя разрешается на новый IP-адрес на новом хосте.

Во Флориде клиент сообщал, что доменное имя разрешается на старый сайт. (Мы размещаем страницы с надписью «мы перемещаем» на старом хост-сервере.) Ее Mac отправил эхо-запрос на доменное имя, и оно разрешилось на старый хост. Мы перезагрузились, затем сбросили DNS в терминале. Через 6 часов ее компьютер все еще не может разрешить новый IP-адрес.

Одна машина в офисе во Флориде может правильно получить доступ к новому сайту. Другие машины в районе Южного Флориды не могут получить доступ к сайту. Звонок в службу технической поддержки AT&T подтвердил, что ping и tracert из его области (той же сети) разрешаются правильно.

Что, черт возьми, не так?

Почему мой клиентский Mac не использует серверы имен для получения IP-адреса? IP-адрес отличается, и только зарегистрированный сервер имен знает его.

Это AT&T? Это OSX? Это старый DNS хоста? Это новый хост DNS? Это потому, что TTL старого хоста на их DNS-сервере составлял 72 часа?

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

связанные вопросы

Как сменить веб-хостинг и минимизировать время простоя для электронной почты

Как сменить веб-хостинг для моего небольшого сайта с минимальным временем простоя

https://superuser.com/questions/96425/convince-my-bosss-mac-the-website-has-moved

Если вы оставили время жизни DNS на 3 дня, естественно, потребуется до трех дней, чтобы новые записи были предоставлены повсюду, поскольку любой, кто запросил запись за секунду до изменения, (правильно) кэширует их на следующие три дней. Вам следует определенно понизьте TTL примерно до пяти минут в следующий раз, когда будете делать ход (и я немного удивлен, что ваша новая хостинговая компания не упомянула вам об этом - одна из многих причин, чтобы у кого-то был опыт в подобных вещах. управлять ходом).

Однако, даже если вы отказались от TTL, есть некоторые интернет-провайдеры, которые используют рекурсивные резолверы, не соответствующие стандартам, которые переопределяют TTL для всех записей, которые они обслуживают, поэтому они не совпадают с TTL для записей, установленными авторитетные DNS-серверы. Это зло, и я бы хотел делать неприятные вещи людям, которые их так настраивают, но они такие, какие есть. Лучшее решение этой проблемы:

  1. Имейте отдельное имя хоста, на которое отвечает новый веб-хост, и перенастройте веб-хост, с которого вы переходите, для выполнения 302 (временного) перенаправления на это имя, чтобы любые запросы, которые поступают на старый сервер, перенаправлялись на новый сервер. . Это удобно, но вам нужно навсегда оставить временное имя (потому что люди могут ссылаться на временное имя), которое становится некрасивым и не очень хорошо работает для HTTPS (вам нужен подстановочный знак или отдельный сертификат SSL для другого название).
  2. Используйте DNAT для перенаправления трафика со старого веб-хоста на новый. Это требует значительного сотрудничества со стороны вашего старого веб-хоста, и вы дважды платите за весь трафик на старый веб-хост (один идет на сервер, а другой - обратно на новый сервер), но это полностью прозрачно для пользователей и отлично работает с HTTPS.

Как давно был перевод? Вы всегда должны выделять 2 дня на то, что хостинговые компании часто и ошибочно называют «распространением DNS». Фактически это называется истечением срока действия кеша.

DNS кэшируется на многих уровнях, что может быть трудно диагностировать.

Но да, время TTL в 72 часа, безусловно, имело бы огромный эффект. Было бы неплохо, если бы старый провайдер DNS изменил TTL на 8 часов (или меньше) за несколько дней до переезда.

[править] Изменена первая строка в соответствии с комментарием ниже. [править]