Я испытываю симптомы, похожие на симптомы другой вопрос. То есть люди жалуются на недоступность доменного имени. А потом через некоторое время вдруг начинает работать. Но я сомневаюсь, что это из-за ненадежности 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, который специально разработан, чтобы помочь выделить проблему с вашей системой или, если это более глобальная проблема.
Часть этой информации, которую я предоставил, - это просто слепая съемка в темноте, поскольку это постоянный процесс устранения неполадок, а информация пока ограничена. Если вы можете опубликовать дополнительную информацию в виде комментариев, я уверен, что мы поможем вам разобраться.
На будущее я просто добавлю несколько советов из своего опыта:
В ящиках 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
с его помощью можно собрать несколько трудноуловимых аномалий. (Это помогло мне доказать в одном случае, что наши серверы действительно иногда не могут пинговать друг друга в локальной сети!)