Бред DNS Поиск

Question

Я недавно перенес свой домен на нового регистратора, и после его завершения обновил свои серверы имен, чтобы они указывали на совершенно другие.

Это было около 12 часов назад. С тех пор у меня возникали всевозможные странные проблемы при попытке доступа к моему веб-сайту, большинство из которых, как я полагаю, связано с задержками распространения DNS из-за кэширования DNS. Я понимаю, что вам обычно приходится ждать 24 часа, чтобы убедиться, что изменение записей DNS полностью распространено, НО я не уверен, почему это происходит:

1) Используя Ubuntu на моем ноутбуке, подключенном к моему домашнему Wi-Fi, я не могу получить доступ к своему веб-сайту. Chrome показывает ошибку поиска DNS: error: -105 (ERR_NAME_NOT_RESOLVED)

2) Используя Wi-Fi моего телефона, я не могу получить доступ к своему веб-сайту (поиск DNS не удается, Chrome дает тот же результат на моем телефоне). Тем не менее, используя мои данные 4G, я могу просматривать сайт отлично.

Теперь эти два смысла для меня: Может быть, мой провайдер кэширует поиск DNS (хотя я не уверен, почему он это сделает, если поиск не удается).

3) Мой ноутбук выходит из строя при выполнении ping на моем сайте. ОДНАКО dig работает нормально - иногда! Если я запускаю dig www.mywebsite.com это не получается, но если я dig http://www.mywebsite.com это работает! (что-то подобное происходит с nslookup: это работает только с http://)

Кто-нибудь может объяснить, что здесь происходит?

Answer 1

У меня возникла та же проблема (работает через VPN, мобильный и другой Wi-Fi, но не через мой Wi-Fi), и я думаю, что это, как упоминалось в @milli, связано с кэшированием TTL (время жизни) DNS-записей.

Мой DNS-хост имеет функцию снижения записи TTL до 5 минут при смене серверов и т.д. Возможно, вы сможете найти и включить эту функцию или связаться с вашим DNS-хостом для получения информации, если они поддерживают это.

Этот сайт имеет дополнительную информацию: https://www.dnswatch.info/articles/dns-update

Answer 2

Да, для смены регистратора может потребоваться до 24 часов, хотя большинство из них быстрые (у большинства регистраторов на их веб-сайтах уходит несколько минут). Если на вашем старом DNS-хостинге использовался стандартный 2-дневный TTL (время жизни) или он больше не является полномочным, может потребоваться до 48 часов после изменения, чтобы записи NS сбрасывались из кэшей повсюду, особенно случай, когда старое место не отвечает авторитетно ... TTL по умолчанию для записей NS на верхних уровнях com, net и org (и большинства других) составляет 2 дня и вступает в действие в последнем случае ..

И вы, возможно, проверили свой сайт, прежде чем вносить изменения, верно? Это означает, что ваш провайдер только что кэшировал старый набор записей NS и, вероятно, переключится на него дольше всех.

В любом случае, у меня отлично работает

$ dig www.mywebsite.com

; <<>> DiG 9.9.3 <<>> www.mywebsite.com
;; global options: +cmd
;; Got answer: ;; ->>HEADER<<- opcode: QUERY,status: NOERROR, id: 11939
;; flags: qr rd aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.mywebsite.com.             IN      A

;; ANSWER SECTION:
www.mywebsite.com.      10800   IN      A     216.250.121.107

(Да, я не могу проверить это, если вы не введете настоящие DNS-имена ...)

Кроме того, dig это инструмент для устранения неполадок DNS. Он понимает только доменные имена, а не URI. И он не ведет себя так же, как код распознавателя DNS в системе, которую использует веб-браузер.