Только сегодня вечером я работал над своим веб-сервером и вдруг обнаружил, что у меня больше нет доступа к моему веб-сайту (который работал очень хорошо в тот же вечер). После большого количества возни с тестированием и диагностикой, ни одна из которых не смогла подтвердить фактическую ошибку, я переключил DNS IPv6 на 2620: 0: ccc :: 2 и 2620: 0: ccd :: 2 на 2001: 4860 : 4860 :: 8844 и 2001: 4860: 4860 :: 8888 (от OpenDNS до Google) и, о чудо (!), Мой сайт вернулся.
Для любопытных: мой сайт : insurgent.info . Это просто, навигация паршиво не существует, древовидные хаггеры опасны (или, по крайней мере, это так), и, да, этот вопрос, вероятно, должен быть где-то там, где его нет.
Обновление 16.05.18: проблема определенно связана не только со службой DNS: только сегодня мне приходилось менять службу IPv6 три раза (мой DNS IPv4 покрывается моим провайдером через защищенный от DNSSEC клиент-распознаватель IPv4) и каждый раз Я мог просматривать мою веб-страницу один раз, может быть, максимум два раза, пока все мои попытки не заканчивались. Эта проблема настолько обострилась этим вечером, что я даже не смог использовать свой ноутбук для обновлений, установки пакетов или чего-либо еще, связанного с Интернетом. Я абсолютно не понимаю, что происходит, поскольку журналы для named и httpd не показывают никаких проблем, и ноутбук, и ПК с Windows используют один и тот же маршрутизатор, без атак или других проблем в журналах.
У меня нет брандмауэра на ноутбуке, потому что на маршрутизаторе очень всеобъемлющий брандмауэр и DoS Defense; плюс у меня нет открытых портов в интернет, кроме тех, которые должны быть, а в MySQL отключены удаленные подключения.
Я точно знаю, что сайт виден другим людям, - единственный человек, который не может просматривать сайт, - это я сам; то есть: кажется, что это были только соединения с моего фиксированного адреса IPv4 и подсети IPv6, которые блокируются либо из-за проблем с конфигурацией, либо из-за какого-то (автоматического?) черного списка на стороне службы DNS.
Кто-нибудь получил какие-либо идеи по этому поводу, пожалуйста, поскольку у меня совершенно нет идей о том, что еще может быть причиной этой проблемы?
Какие ответы отправлял OpenDNS? Это были ошибки SERVFAIL? Их фактическая блокировка обычно хорошо видна (перенаправляет на другой сайт), если домен не использует DNSSEC.
grawity 5 лет назад
0
Абсолютно ничего, - я в конечном итоге получил сбой загрузки из-за тайм-аута страницы с Waterfox (Firefox fork) и IE, оба. Тогда то же самое произошло только сейчас (с Google Public DNS). Я снова перешел на другую бесплатную службу DNS (мой провайдер, к сожалению, не предоставляет адреса распознавателя IPv6, только IPv4), и я полностью ожидаю, что в течение нескольких часов я снова не смогу получить доступ к своему веб-сайту. без изменения IPv6-адресов другой службы DNS. Я не понимаю, что происходит с этим ... и нет, DNSSEC не настроен для сайта, пока.
Y Treehugger Cymru 5 лет назад
0
Я также проверил сайт с помощью dig и nslookup, как отлично, так и других, прокси или веб-проверки сайтов; не говоря уже о том, что журналы не показывают никаких проблем. Мне удалось зайти на сайт не более 5 минут назад, но теперь все попытки (в том числе по IP-адресу) терпят неудачу (сервер слишком долго не отвечает), и такая ситуация будет сохраняться до тех пор, пока я не перейду на другую службу DNS, пока OpenDNS и Google Public DNS останется полностью непригодным для использования.
Y Treehugger Cymru 5 лет назад
0
Просто нашел это: https://wiki.archlinux.org/index.php/Resolv.conf, где говорится о ** поиске имени хоста, задержанном с IPv6 **. Я только что добавил _options single-request_ в свой _resolv.conf_ и сумел восстановить и отобразить веб-сайт, используя Google Public DNS. Это только еще предстоит увидеть, сейчас, остается ли оно и видимым ...
Y Treehugger Cymru 5 лет назад
0
1 ответ на вопрос
0
Y Treehugger Cymru
После нескольких тестов и нескольких часов работы моего веб-сайта и его доступности (не только для остального Интернета!) Я склонен думать, что проблема, с которой я столкнулся, действительно была вызвана тем, что мой сервер имен BIND пытался одновременно возвращать записи с IPv4 и IPv6, когда я пытался просмотреть сайт.
Как указано на: https://wiki.archlinux.org/index.php/Resolv.conf, решение, предоставленное для поиска имени хоста, отложено с использованием IPv6, то есть добавление одиночного запроса опций в файл resolv.conf работает (для я, по крайней мере).
Примечание: эта поправка будет иногда удаляться, особенно после обновления системы. Использование следующего в качестве пользователя root должно предотвратить это, но может привести к ошибкам NetworkManager:
chattr + i /etc/resolv.conf // чтобы установить атрибут только для чтения
chattr -i /etc/resolv.conf // чтобы удалить атрибут только для чтения
Если вы намеренно отключили все подключения IPv4 в своей сети, было бы полезно упомянуть, что ...
grawity 5 лет назад
0
Это было не так: мне пришлось отключить DHCP для IPv4 и IPv6, потому что я не мог найти способ заставить DHCP уважать IP-адреса, которые были выделены сетевым адаптерам. Конфигурация VLAN тоже была проблематичной. Мне пришлось повторно включить DHCP на стороне IPv6, и я оставил настройку адаптера VLAN IPv6 (на компьютере с Windows) в автоматическом режиме для IP-адреса и DNS, поскольку кажется, что эти параметры могут быть переопределены ноутбуком Linux Конфигурации адаптера.
Y Treehugger Cymru 5 лет назад
0
Чтобы объяснить более четко: VLAN настроена на маршрутизаторе, но должна быть включена на интерфейсе драйвера ПК с Windows. Результатом этого является то, что на компьютере с Windows имеется три адаптера, в том числе один, который влияет на VLAN на ноутбуке с Linux, который, в свою очередь, может быть перезаписан (если все настроено на автоматический режим) из-за конфигурации адаптера VLAN для Linux ,
Y Treehugger Cymru 5 лет назад
0
Я думаю, вы, возможно, неправильно поняли использование _options single-request_. Насколько я понимаю, он используется в ситуациях, когда имеются как склеивающие записи IPv4 **, так и ** IPv6, чтобы предотвратить конфликт, вызванный возвратом записей сервером DNS для обоих случаев, когда запрос веб-сайта или службы просто прерывается или возвращает ошибку _servfail_ или _server not found_.
Y Treehugger Cymru 5 лет назад
0