Почему Google DNS 8.8.8.8 не резолвит YouTube: NXDOMAIN

Скорее всего причина в региональной фильтрации или в путевой модификации ответов DNS (ISP / действия Роскомнадзора) или в особенностях маршрутизации/кэширования Google в России — а не в проблеме авторитетных NS или массовом сбое DNSSEC. То, что OpenDNS (208.67.222.222/208.67.220.220) резолвит youtube.com, указывает на вмешательство в канал между вашими запросами к 8.8.8.8 и авторитетными серверами; проверить это помогают dig +trace, запросы к авторитетным NS и тесты UDP/TCP/DoH. Временные обходы — переключение на OpenDNS/Cloudflare/Quad9 или включение DoH/DoT; более надёжно — VPN или собственный резольвер с защищёнными каналами.

Содержание

• Блокировка YouTube и 8.8.8.8: основные причины
• Если DNS не работает: пошаговая диагностика (dig +trace, авторитетные NS, UDP/TCP)
• Обход: временные и постоянные варианты
• Чеклист: что сделать прямо сейчас
• Авторитетные NS и DNSSEC — когда это не Google
• Долгосрочные рекомендации для организаций и продвинутых пользователей
• Источники
• Заключение

Блокировка YouTube и 8.8.8.8: основные причины

Коротко: NXDOMAIN от 8.8.8.8 для существующего домена (youtube.com) — это маркер внешнего вмешательства в разрешение, а не типичный признак сбоя авторитетных серверов. По словам Google Public DNS, если домен существует, получение NXDOMAIN от их сервера обычно значит, что запросы блокируются или искажаются на пути к авторитетным зонам или при возврате ответа: https://developers.google.com/speed/public-dns/faq.

Какие конкретно механизмы приводят к такой картине?

• Региональная фильтрация / вмешательство регулятора (Roskomnadzor) или провайдеров. В России отмечались тесты и массовые меры по блокировке публичных DNS и перенаправлению на российские резолверы — это может выражаться в дропе UDP, сбросах TCP/DoH и в подмене ответов (NXDOMAIN для заблокированных доменов) (см. SecurityLab): https://www.securitylab.ru/news/524256.php. Анализ национального DNS также говорит о фрагментации, которая делает возможными такие эффекты: https://www.internetsociety.org/resources/internet-fragmentation/russias-national-dns/.

• Путевая модификация и подмена ответов (DNS spoofing / interception). Некоторые сетевые фильтры вместо таймаута возвращают отрицательный ответ (NXDOMAIN) — это применяют для незаметной блокировки. Подробности и примеры обсуждались в сообществе и в issue с техническими наблюдениями: https://github.com/net4people/bbs/issues/81.

• Геолокация ответов и удаление/изменения кэша. Google Public DNS использует механизмы, влияющие на то, какие IP вернёт резольвер (EDNS client subnet и anycast). Если в 2024–2025 годах Google изменил локальную инфраструктуру или её связность в регионе, запросы могут идти через пути, где трафик блокируют или через точки, где кэши были очищены — результатом может быть либо таймаут, либо некорректный / отрицательный ответ. Об этом — обзор инцидентов в 2024–2025 гг.: https://blog.sigmavpn.pro/blog/youtube-ne-rabotaet-v-rossii-26082025-prichiny-sboev-segodnya.

• Проблемы с авторитетными NS или DNSSEC — маловероятны в вашем случае, потому что OpenDNS успешно резолвит youtube.com. Если авторитетные серверы действительно отдавали NXDOMAIN, то ни один сторонний резолвер не смог бы дать корректный ответ. Проверять это всё же надо (см. раздел про диагностику).

Итог: NXDOMAIN от 8.8.8.8 при корректном ответе от OpenDNS — сильный признак региональной или путевой фильтрации подменой/отбрасыванием запросов, а не «поломки» зоны youtube.com или повсеместного DNSSEC-сбоя.

Если DNS не работает: пошаговая диагностика (dig +trace, авторитетные NS, UDP/TCP)

Что именно проверить и как — публичный план действий, который даст однозначный диагноз.

1. Сравните резолверы (быстро и просто)

dig @8.8.8.8 youtube.com A +short
dig @208.67.222.222 youtube.com A +short

Если первый даёт пустой результат / NXDOMAIN, а второй — IP, это уже локализует проблему на пути к Google Public DNS или на стороне Google-anycast в вашей сети.

2. Сделайте последовательный трассинг резолвинга

dig +trace youtube.com

Альтернатива: попытаться трассировать через конкретный сервер (иногда помогает выявить, где обрывается рекурсия):

dig +trace @8.8.8.8 youtube.com

Интерпретация: если trace обрывается на этапе рекурсивного резолвера или на шаге в сторону TLD/authoritative — смотрим, где именно ответ теряется.

3. Запросите авторитетные NS напрямую

dig NS youtube.com +short
# взять один из NS и спросить напрямую:
dig @ns1.google.com youtube.com A +short

Если авторитетный NS возвращает нормальные A-записи — значит зона в порядке, проблема на уровне рекурсивного резолвера/межсетевого фильтра.

4. Проверка UDP vs TCP
   UDP часто дропается фильтрами. Принудительно через TCP:

dig @8.8.8.8 youtube.com +tcp

Если TCP работает, а UDP — нет, то вероятен UDP-фильтр/дроп. SecurityLab и отчёты сообщества отмечали подобную модель (UDP-drops, RST для TCP/DoH): https://www.securitylab.ru/news/524256.php и https://github.com/net4people/bbs/issues/81.

5. Проверка DoH/DoT (шифрованный DNS)
   Попробуйте DoH-запрос к Google:

curl 'https://dns.google/resolve?name=youtube.com&type=A'

Если DoH возвращает нормальные записи, а обычный 8.8.8.8 — нет, значит блокируют классический DNS по UDP/TCP, но не HTTPS-канал. Если TLS-соединение DoH/DoT обрывают на ClientHello — это признак DPI/блокировки TLS-сессий.

6. Диагностика сети: ping/traceroute/tcpdump

• traceroute/mttr до 8.8.8.8 и до IP-адресов, которые даёт OpenDNS.
• tcpdump/tshark чтобы увидеть, приходят ли ответы от 8.8.8.8 и есть ли RST.
• Проверка из другой сети / через VPN: если проблема исчезает — это региональное ограничение.

7. Проверка DNSSEC

dig +dnssec youtube.com @8.8.8.8

DNSSEC-проблемы обычно дают SERVFAIL/validation errors, а не NXDOMAIN для корректного домена. Это ещё один признак, что DNSSEC здесь вряд ли виноват.

Если нужна помощь с интерпретацией вывода, соберите результаты команд (время, провайдер, регион) — это ключевая телеметрия для понимания, на каком шаге происходит вмешательство. См. обсуждения о поведении dig +trace в подобных ситуациях: https://stackoverflow.com/questions/53688690/dig-trace-does-not-do-a-trace.

Обход: временные и постоянные варианты

Коротко о вариантах — от самых простых до более устойчивых.

Временные (быстрый результат)

• Смените DNS на OpenDNS (208.67.222.222 / 208.67.220.220) — в вашем случае это уже работает.
• Попробуйте Cloudflare (1.1.1.1 / 1.0.0.1) или Quad9 (9.9.9.9) — быстрый тест.
• Включите DoH/DoT в браузере или системе: часто обходит простые DNS-фильтры (см. Google DoH и общие рекомендации): https://developers.google.com/speed/public-dns/faq.
• Используйте VPN/прокси — самый надёжный способ получить доступ, если блокировка идёт на уровне провайдера/регулятора.

Постоянные/продвинутые (устойчивость и контроль)

• Настройте свой резольвер (Unbound) с форвардом на DoT/DoH-эндпоинт вне региона — устойчиво и безопасно.
• Используйте мультирезолверную стратегию и failover в роутере: primary — DoH к внешнему провайдеру, fallback — альтернативный резольвер.
• Для организаций: мониторинг резолвинга из нескольких гео-точек и alerting (чтобы быстро детектировать и переключать маршруты). Аналитика по национальной архитектуре DNS поможет понять риски: https://www.internetsociety.org/resources/internet-fragmentation/russias-national-dns/.

Важно: даже если DNS решается через альтернативный резольвер, поток к самим серверам YouTube может блокироваться IP‑уровнем или через DPI; в таких случаях нужен VPN или прокси.

Чеклист: что сделать прямо сейчас

1. Быстрая проверка:

• Выполните dig @8.8.8.8 youtube.com A +short и dig @208.67.222.222 youtube.com A +short.

2. Трассировка:

• dig +trace youtube.com и dig +trace @8.8.8.8 youtube.com — зафиксируйте шаг, где обрыв.

3. Авторитетные NS:

• dig NS youtube.com +short → dig @<AUTH_NS> youtube.com A.

4. UDP vs TCP:

• dig @8.8.8.8 youtube.com +tcp — если работает, значит UDP дропят.

5. Попробуйте DoH:

• curl 'https://dns.google/resolve?name=youtube.com&type=A'.

6. Быстрый обход:

• Поменяйте DNS на OpenDNS/1.1.1.1/9.9.9.9 в настройках устройства или роутера; перезапустите/сбросьте DNS-кэш (ipconfig /flushdns в Windows).

7. Если нужно — включите VPN и проверьте, восстанавливается ли доступ.
8. Сохраните логи (dig, traceroute, tcpdump) и при необходимости отправьте провайдеру или опубликуйте в профильных сообществах для подтверждения массовости инцидента.

Авторитетные NS и DNSSEC — когда это не Google

Как понять, что проблема в авторитете или DNSSEC?

• Прямой запрос к авторитетному NS даёт окончательный ответ. Если dig @<AUTH_NS> youtube.com A возвращает нормальные записи — зона жива. Тогда Google Public DNS и другие рекурсивные резолверы просто не получают/не передают эти данные корректно.
• При ошибках DNSSEC обычно вы увидите SERVFAIL и отсутствие валидной сигнатуры или RRSIG — а не NXDOMAIN. Поэтому поведение NXDOMAIN + успешный ответ от OpenDNS фактически исключает DNSSEC-проблему как первопричину.

Если же авторитетный NS действительно отдаёт NXDOMAIN — это редкий, но возможный сценарий (ошибка в зоне или преднамеренное изменение), и в этом случае все рекурсивные резолверы покажут такую же картину.

Долгосрочные рекомендации для организаций и продвинутых пользователей

• Внедрите зашифрованные каналы к upstream (DoH/DoT) и отказоустойчивый набор резолверов.
• Разверните внутренний кеш‑резолвер (Unbound) с форвардом на DoT/DoH вне юрисдикции, где возможна фильтрация.
• Настройте мониторинг разрешения критичных доменов из нескольких гео‑точек (внешние мониторинговые сервисы или собственные агенты).
• Документируйте инциденты: логи запросов, временные метки, провайдер, регионы — это важно для расследования и подачи жалоб/запросов к провайдерам и регулятору.
• Обновляйте политику доступа для пользователей: если цель — бизнес‑доступ к зарубежным сервисам, опишите стабильные обходные пути и правила безопасности (VPN с логированием, допустимые DoH-поставщики и т.п.).

Источники

• Обсуждение и технические наблюдения по блокировкам DNS: https://github.com/net4people/bbs/issues/81
• Разбор сбоев YouTube в России (август 2025) и рекомендации по диагностике: https://blog.sigmavpn.pro/blog/youtube-ne-rabotaet-v-rossii-26082025-prichiny-sboev-segodnya
• Новость о тестировании блокировки публичных DNS (SecurityLab): https://www.securitylab.ru/news/524256.php
• История и контекст блокировки YouTube в России (Wikipedia): https://ru.wikipedia.org/wiki/Блокировка_YouTube_в_России
• FAQ Google Public DNS — как интерпретировать NXDOMAIN и рекомендации по DoH/DoT: https://developers.google.com/speed/public-dns/faq
• Анализ фрагментации DNS в России (Internet Society): https://www.internetsociety.org/resources/internet-fragmentation/russias-national-dns/
• Техническое обсуждение соответствия IP-адресов YouTube и поведения резолверов (Habr): https://habr.com/ru/articles/571570/
• Поведение dig +trace и типичные нюансы диагностики: https://stackoverflow.com/questions/53688690/dig-trace-does-not-do-a-trace

Заключение

Если 29 декабря nslookup на 8.8.8.8 возвращал ‘server can’t find youtube.com: NXDOMAIN’, а OpenDNS резолвит нормально, то, скорее всего, это следствие региональной/путевой фильтрации или особенностей маршрутизации и кэширования Google в России — не общий сбой авторитетных NS и не обычный DNSSEC‑проблем. Для точного диагноза используйте dig +trace, запросы к авторитетным NS и тесты UDP/TCP/DoH; для быстрого обхода — OpenDNS/Cloudflare/DoH или VPN; для долгосрочной устойчивости — DoT/DoH, собственный резольвер и мониторинг.