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

Возможные причины иногда недоступных доменов

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

Могли ли быть другие причины? Это поддомен, как в sub.example.com и я заставляю его работать с подстановочным знаком DNS запись. Может ли это быть причиной? Может какой-нибудь старый DNS серверы не понимают таких вещей? Другая причина, о которой я могу думать, - это временные проблемы в Интернете, например, некоторые хосты не могут получить доступ к другим? Или несколько DNS сервера фильтруют записи по какому-то критерию?

UPD Настройка проста, без балансировщиков нагрузки, без кластеров, без циклического перебора. DNS серверы. И я говорю об общедоступном сервере. Пользователи - это пользователи Интернета. Я управляю обоими example.com и sub.example.com. Они в одном DNS зона.

UPD А может все-таки из-за регистратора доменов. Его серверы отвечают тайм-аутом:

>nslookup sub.example.com ns.domain.registrar.com
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  52.16.198.15

Name:    sub.example.com
Address:  51.59.10.10

Полагаю, не все DNS-серверы допускают таймауты, не так ли?

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

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

После того, как вы разрешите IP-адрес веб-сайта, попробуйте ввести IP-адрес вместо имени домена в своем браузере. Выполните ping-тесты и трассировку для этого IP-адреса. Отвечает ли IP-адрес? Отвечает ли он постоянно в течение определенного периода времени (ping -t x.x.x.x в Windows) или он постоянно меняется? Если вы можете получить сайт с IP-адресом, а не с именем хоста, это ваш DNS. Если вы не можете этого сделать, у вас проблемы с подключением. Если это прерывисто для доменного имени или IP-адреса, вероятно, у вас есть проблема с периодической балансировкой нагрузки (например, циклические DNS-серверы или неправильно настроенная кластеризация) или у вас есть проблема с прерывистым подключением, такая как проблема уровня 1 или 2 .

Еще кое-что, что можно добавить в ваш набор инструментов, - это веб-сайт-зеркало под названием isitdownrightnow.com, который специально разработан, чтобы помочь выделить проблему с вашей системой или, если это более глобальная проблема.

Часть этой информации, которую я предоставил, - это просто слепая съемка в темноте, поскольку это постоянный процесс устранения неполадок, а информация пока ограничена. Если вы можете опубликовать дополнительную информацию в виде комментариев, я уверен, что мы поможем вам разобраться.

На будущее я просто добавлю несколько советов из своего опыта:

  • для правильной диагностики проблемы вам лучше иметь доступ к DNS-серверу
  • соответствующие DNS-серверы являются SOA-s и кэширующие серверы имен, которые используют пользователи
  • полезно иметь как Unix, так и Windows боксы для диагностики.
  • DHCP-сервер играет в этом большую роль, если он предоставляет DNS-серверы пользователям
  • Конфликты IP могут вызывать странные эффекты (подозреваются все устройства в локальной сети)

В ящиках Unix вы используете

dig SOA example.com @8.8.8.8
dig SOA sub.example.com @my.domain.name.registrar
dig sub.example.com @sub.example.com
...

На ящиках Windows вы используете

ipconfig.exe /displaydns >logfile.txt
ipconfig.exe /flushdns         <=WITHOUT THIS YOU GET DISTORTED REALITY 
nslookup sub.example.com
nslookup sub.example.com other.name.server
nslookup.exe -q=soa sub.example.com

Я не совсем понял, кто такой SOA (Source Of Authority) для example.com и для вашего sub.example.com, и отличаются ли они от кэширующего DNS (-ов), который используют ваши пользователи - в противном случае все три или более должны быть dig-головник. DHCP может предоставить вашим пользователям несколько DNS-адресов, и у них могут быть разные мнения о записях (кэшах).

Как в unix, так и в Windows вы можете создавать cron вакансии / запланировать задачи войти dig результаты один раз в минуту в какой-то файл журнала, а затем grep с его помощью можно собрать несколько трудноуловимых аномалий. (Это помогло мне доказать в одном случае, что наши серверы действительно иногда не могут пинговать друг друга в локальной сети!)