Когда Google Public DNS не может разрешить домен, это часто происходит из-за проблемы с этим доменом или его полномочными серверами имен. Следующие шаги могут помочь определить причину проблемы, чтобы администраторы домена могли решить ее самостоятельно.
Прежде чем приступить к этим шагам, проверьте домен в dns.google , как описано на общей странице устранения неполадок , что может направить вас к конкретному диагностическому шагу ниже. В противном случае попробуйте выполнить все следующие шаги, пока не найдете причину.
Шаг 1. Проверьте наличие проблем с проверкой DNSSEC.
Если веб-поиск dns.google для домена показывает "Status": 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 :
$ dig +short example.com NS ns1.example.com ns2.example.com $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com A ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com TXT ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com DNSKEY ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com com DNSKEY ...
Эти запросы для различных типов записей указывают:
-
+dnssec - Включите DNSSEC, особенно возвращая требуемые записи для проверки DNSSEC, когда они доступны. Это может значительно увеличить размер результата. Это эмулирует поведение Google Public DNS.
-
+bufsize=1400 - Ограничьте допустимый размер буфера UDP. Это имитирует поведение Google Public DNS на момент проведения Дня флага DNS 2020.
-
+timeout=1 - Установите время ожидания в одну секунду. Это эмулирует поведение Google Public DNS.
-
@ns1.example.com - Какой полномочный сервер запрашивать — оставьте знак
@, но в противном случае замените полномочный сервер вашего собственного домена, как показано в первой команде.
Наблюдайте за выходом; вы видите строку вроде:
-
;; Truncated, retrying in TCP mode. - Это указывает на то, что ответ был больше запрошенного размера буфера UDP, поэтому он был усечен, и в ответ клиент переключился на TCP. Ваши авторитетные серверы должны быть способны обрабатывать DNS-трафик через TCP-порт 53. (См. RFC 7766 , в котором требуется, чтобы «реализации ДОЛЖНЫ поддерживать как UDP, так и TCP-транспорт».)
-
;; MSG SIZE rcvd: 2198 - Для любого числа выше 1400? Это еще раз указывает на большой отклик.
-
;; Query time: 727 msec - Для любого числа выше 500? Медленные ответы (особенно те, которые занимают около 1 секунды или больше) могут быть отброшены Google Public DNS. Это особенно вероятно, если какое-то время было потрачено на попытку UDP, за которой последовала попытка TCP. Географическое расположение сервера и клиента может сильно повлиять на задержку.
-
;; connection timed out; no servers could be reached - Особенно, если только для некоторых запросов, это указывает на проблему, из-за которой ваш сервер не может своевременно отвечать на запросы DNS.
Вы можете попробовать следующие варианты запроса:
- Добавление параметра
+tcp. - Это заставляет
digнемедленно использовать TCP, таким образом вы можете проверить, обрабатывает ли ваш полномочный сервер TCP-запросы напрямую. - Удаление параметра
+bufsize=1400. - Это восстановит поведение
digпо умолчанию (размер буфера равен 4096). Если ваши запросы терпят неудачу с этой настройкой, но работают без нее, это намек на то, что ваш сервер плохо обрабатывает отказоустойчивость TCP. Использование UDP для передачи больших ответов работает только иногда. Лучше всего поддерживать транспорт TCP для DNS. - Повторение на каждом сервере имен.
- В приведенном выше примере есть два полномочных сервера имен (
ns1иns2). Некоторые проблемы вызваны тем, что разные серверы возвращают разные ответы. Убедитесь, что все они отвечают одинаково, повторив одни и те же запросы на всех авторитетных серверах.
Если ответы на все запросы были небольшими (1400 байт или меньше), быстрыми (предпочтительно 500 миллисекунд или быстрее) и надежными (стабильно работают по TCP и UDP), то размер ответа вас не беспокоит; прочтите другие разделы по устранению неполадок. Даже если вы отвечаете быстро, запросы из географически удаленных мест могут выполняться медленнее.
Если какая-либо из этих проверок не удалась (большая? медленная? ненадежная?), основной порядок действий состоит в том, чтобы: а) убедиться, что ваш сервер отвечает с усечением UDP, когда его ответ превышает запрошенный размер буфера UDP, и б) что он может обрабатывать Повторная попытка запроса TCP, которая последует. Несколько инструментов могут помочь вам диагностировать проблемы с надежностью DNS:
- DNSViz
- Отладчик DNSSEC
- Тестер соответствия EDNS
- DNS Checker — обязательно снимите флажок «CD» (отключить проверку DNSSEC)
Если эти инструменты обнаруживают какие-либо ошибки или предупреждения, обязательно устраните их. Также не забудьте прочитать все остальные инструкции по устранению неполадок на этом сайте.
Шаг 5. Проверьте, разрешают ли домен другие общедоступные преобразователи.
Если вы не нашли причину проблемы после выполнения описанных выше шагов, выполните следующие команды в командной строке, заменив example.test. с рассматриваемым доменом (с сохранением конечных точек):
Окна
nslookup example.test. resolver1.opendns.com.
nslookup example.test. dns.quad9.net.
nslookup example.test. one.one.one.one.
макОС или линукс
dig example.test. '@resolver1.opendns.com.'
dig example.test. '@dns.quad9.net.'
dig example.test. '@one.one.one.one.'
Эти команды используют преобразователи DNS OpenDNS, Quad9 и Cloudflare 1.1.1.1. Если вы получаете ошибки разрешения от двух из них, а также от Google Public DNS, проблема, вероятно, связана с доменом или его серверами имен.
Если вы получите успешный результат от более чем одного общедоступного распознавателя, может возникнуть проблема с общедоступным DNS Google. Если о подобных проблемах для домена (или его TLD) в системе отслеживания проблем не сообщалось, вы должны сообщить нам о проблеме , включая вывод команды и текст страницы диагностики или снимки экрана в свой отчет.