Google DNS не работает

Обновлено: 21.11.2024

Если DNS.GOOGLE работает, но вы не можете получить доступ к сайту или его отдельной странице, попробуйте одно из возможных решений:

Кэш браузера.
Чтобы удалить кеш и получить актуальную версию страницы, обновите страницу в браузере с помощью комбинации клавиш Ctrl+F5.

Антивирус и брандмауэр. Убедитесь, что антивирусные программы (McAfee, Антивирус Касперского или аналог) или фаервол, установленные на вашем компьютере, не блокируют доступ к DNS.GOOGLE.

Кэш DNS.
Очистите кеш DNS на своем компьютере и повторите попытку доступа к сайту.
Посмотрите обучающее видео ↓

VPN и альтернативные службы DNS.
VPN: например, NordVPN;
Альтернативный DNS: OpenDNS или Google Public DNS.

Плагины для браузера.
Например, расширение AdBlock вместе с рекламой может блокировать содержимое сайта. Найдите и отключите аналогичные плагины для своего сайта.

Dns.google форум

или просто добавьте свой комментарий "2 цента"
идентификация не требуется, для комментариев "2 цента" применяются ограничения

Отчеты Twitter

@feanneart Почему приложение Youtube не работает на моем iphone (оно постоянно говорило, что я не в сети), если я не использую OpenDNS? (DNS моих интернет-провайдеров по умолчанию, DNS Google и DNS Cloudflare не работали.) Аналогичные проблемы с IG & Карты Google на iphone. Все эти приложения отлично работают на моем ipad & macbook, использующий тот же Wi-Fi, читать источник
77 дней назад 5 января 2022 г.

@argamingpk1 @iFireMonkey Использовать Google DNS или Cloudflare DNSGoogle DNS — 8.8.8.8 & 8.8.4.4Cloudflare DNS — 1.1.1.1 и amp; 1.0.0.1 Надеюсь, это решит многие проблемы. читать источник
106 дней назад

@ShieldVoC RT @CoogieEx: @VerizonSupport более недели испытывает проблемы с DNS из Хьюстона. Многие приложения не подключаются при использовании данных Verizon, но читали источник
124 дня назад

@HibiKage Как ни странно, мой телефон также не может подключиться к сторонним DNS (Google, Cloudflare, NextDNS). Я просто предполагаю, что это вызвано текущим отключением, прочитайте источник
170 дней назад < бр />

Когда Google Public DNS не может разрешить домен, это часто происходит из-за проблемы с этим доменом или его полномочными серверами имен. Следующие шаги могут помочь определить причину проблемы, чтобы администраторы домена могли решить ее самостоятельно.

Прежде чем приступить к этим шагам, проверьте домен dns.google, как описано на общей странице устранения неполадок, что может привести к конкретному шагу диагностики ниже. В противном случае попробуйте выполнить все следующие шаги, пока не найдете причину.

Шаг 1. Проверьте наличие проблем с проверкой DNSSEC

Если веб-поиск домена в dns.google показывает "Статус": 2 (SERVFAIL) и запросы без DNSSEC завершаются успешно, возможно, проблема с DNSSSEC связана с серверами имен домена или его реестром доменов верхнего уровня (TLD) (которые публикует записи DS для проверки DNSSEC зарегистрированных доменов).

Смена регистратора или службы DNS

Проблемы с DNSSEC могут возникнуть после того, как домен переключится с регистратора или службы DNS, поддерживающей DNSSEC, на не поддерживающую. Если предыдущая служба оставляет устаревшие записи DS в реестре TLD, а новая служба не создает новые записи DNSKEY с соответствующими записями DS в реестре TLD, проверяющие преобразователи, такие как Google Public DNS, не могут разрешить домен.

В этом случае попросите регистратора домена удалить устаревшие записи DS из реестра TLD.

Ответы DNSSEC слишком велики

Еще одной причиной проблем с DNSSEC могут быть ответы DNSSEC, которые слишком велики для размещения в одном IP-пакете, создавая фрагментированные ответы, которые могут быть отброшены. Если DNSViz показывает ошибки «ответ не получен, пока размер полезной нагрузки UDP не будет уменьшен», сбои DNSSEC могут быть вызваны очень большими ответами. Размер ответа можно уменьшить одним или несколькими из следующих действий:

Настройте «минимальные ответы» для авторитетных серверов имен.
Сократите количество активных записей DNSKEY до двух или трех
Используйте 1280- или 2048-битные записи DNSKEY (RFC 6781, StackExchange)
Переход с подписей RSA на подписи ECDSA меньшего размера (RFC 8624)

Также проверьте наличие других проблем с DNSSEC, о которых сообщают инструменты на шаге 2.Примеры включают неверные записи об отказе в существовании NSEC или NSEC3, доказывающие отсутствие поддоменов (они могут быть в PowerDNS с зонами, хранящимися во внешних базах данных) или подписи RRSIG с истекшим сроком действия (с нарушенными процессами подписи, настроенными вручную).

Шаг 2. Проверьте официальные серверы имен

Если у Google Public DNS (или любого открытого преобразователя) возникает проблема с разрешением домена, DNSViz показывает вызывающие ее проблемы с доменом и сервером имен. Перейдите на веб-страницу DNSViz и введите проблемное доменное имя. Если у DNSViz нет исторических данных или есть только данные, которым больше дня (например, как показано на странице здесь), нажмите большую кнопку «Анализ», чтобы открыть меньшую кнопку «Анализ» ниже (если она еще не видна) и нажмите ее тоже . Когда анализ завершится, нажмите «Продолжить», чтобы отобразить результаты. Нажмите на красные ошибки и желтые предупреждения на левой боковой панели, чтобы просмотреть подробные сведения, или наведите указатель мыши на объекты на диаграмме, чтобы отобразить эту информацию в контексте.

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

Веб-страница intoDNS сообщает о проблемах, не связанных с DNSSEC, с доменом, введенным на главной странице, а также показывает предложения по их устранению.

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

Шаг 3. Проверьте наличие проблем с делегированием

Google Public DNS — это "родительско-ориентированный" преобразователь, который использует только серверы имен, возвращенные в ссылках из родительского домена. Если имена серверов имен и связующие адреса в TLD устарели или неверны, это может вызвать проблемы с делегированием.

Если DNSViz или intoDNS выдают предупреждения о несоответствиях между серверами имен, делегированными в TLD, и серверами, присутствующими в самом дочернем домене, возможно, их необходимо устранить, прежде чем Google Public DNS сможет разрешить домен. Если эти инструменты сообщают, что зарегистрированный домен не существует (NXDOMAIN), проверьте, не истек ли срок действия домена и не приостановлена ли его регистрация по какой-либо причине.

Проблемы с делегированием также могут быть вызваны невозможностью разрешить имена серверов имен для домена. Проверьте записи A и AAAA для серверов имен на dns.google, чтобы узнать, есть ли проблемы с доменами серверов имен.

Шаг 4. Проверьте наличие больших ответов

Для передачи большей части трафика DNS использует UDP. Большие дейтаграммы UDP подвержены фрагментации, а фрагментированный UDP страдает от ненадежной доставки. Это было в центре внимания DNS Flag Day 2020, целью которого было повышение надежности DNS во всем мире. Google Public DNS участвовал в этих усилиях и ограничивает размер ответов UDP, которые он может принимать по UDP. Попробуйте выполнить запрос, подобный приведенным ниже, с помощью собственной командной строки или Google Cloud Shell:

Эти запросы для различных типов записей указывают:

Наблюдайте за выводом; вы видите строку вроде:

<р>;; Усечено, повторная попытка в режиме TCP. Это указывает на то, что ответ был больше запрошенного размера буфера UDP, поэтому он был усечен, и в ответ клиент переключился на TCP. Ваши авторитетные серверы должны быть способны обрабатывать трафик DNS через TCP-порт 53. (См. RFC 7766, который требует, чтобы «реализации ДОЛЖНЫ поддерживать как UDP, так и TCP-транспорт».) ;; MSG SIZE rcvd: 2198 Для любого числа выше 1400? Это еще раз указывает на большой отклик. ;; Время запроса: 727 мс Для любого числа выше 500? Медленные ответы (особенно те, которые занимают около 1 секунды или больше) могут быть отброшены Google Public DNS. Это особенно вероятно, если какое-то время было потрачено на попытку UDP, за которой последовала попытка TCP. Географическое расположение сервера и клиента может сильно повлиять на задержку. ;; время соединения истекло; нет доступа к серверам. Особенно, если только для некоторых запросов, это указывает на проблему, из-за которой ваш сервер не может своевременно отвечать на DNS-запросы.

Вы можете попробовать следующие варианты запроса:

Добавление параметра +tcp. Это заставляет dig немедленно использовать TCP, таким образом вы можете проверить, обрабатывает ли ваш полномочный сервер TCP-запросы напрямую. Удаление параметра +bufsize=1400. Это восстановит поведение dig по умолчанию (размер буфера равен 4096). Если ваши запросы терпят неудачу с этой настройкой, но работают без нее, это намек на то, что ваш сервер плохо обрабатывает отказоустойчивость TCP. Использование UDP для передачи больших ответов работает только иногда. Лучше всего поддерживать транспорт TCP для DNS. Повторение на каждом сервере имен. В приведенном выше примере есть два полномочных сервера имен ( ns1 и ns2 ). Некоторые проблемы вызваны тем, что разные серверы возвращают разные ответы.Убедитесь, что все они отвечают одинаково, повторив одни и те же запросы на всех авторитетных серверах.

Если ответы на все запросы были небольшими (1400 байт или меньше), быстрыми (предпочтительно 500 миллисекунд или быстрее) и надежными (стабильно работают по TCP и UDP), размер ответа вас не беспокоит; прочтите другие разделы по устранению неполадок. Даже если вы отвечаете быстро, запросы из географически удаленных мест могут выполняться медленнее.

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

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

Шаг 5. Проверьте, разрешают ли домен другие общедоступные преобразователи

Если вы не нашли причину проблемы после выполнения описанных выше шагов, выполните следующие команды в командной строке, заменив example.test. с рассматриваемым доменом (с сохранением конечных точек):

Окна

macOS или Linux

Эти команды используют преобразователи DNS OpenDNS, Quad9 и Cloudflare 1.1.1.1. Если вы получаете сбои разрешения от двух из них, а также от Google Public DNS, проблема, скорее всего, связана с доменом или его серверами имен.

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

Если не указано иное, содержимое этой страницы предоставляется по лицензии Creative Commons Attribution 4.0, а образцы кода — по лицензии Apache 2.0. Подробнее см. в Правилах сайта Google Developers. Java является зарегистрированным товарным знаком Oracle и/или ее дочерних компаний.

Читайте также: