Перебои с доступом к публичным DNS-резолверам Google (8.8.8.8, 8.8.4.4 и др.) и Cloudflare (1.1.1.1, 1.0.0.1) в России

В последние годы российский сегмент интернета претерпевает фундаментальные изменения. Одним из наиболее ощутимых для бизнеса и технических специалистов последствий этих процессов стали массовые перебои с доступом к публичным DNS-резолверам Google — адресам 8.8.8.8 и 8.8.4.4, которые долгие годы служили универсальным «телефонным справочником» интернета для миллионов серверов и пользователей по всему миру.

Проблема носит системный характер с 22 августа 2026: ограничения фиксируются у большинства крупных операторов связи, включая «Ростелеком», МТС, «Билайн», МГТС, «Дом.ру» и многих других. При этом, как показывают наблюдения, блокировка затрагивает не только защищённые протоколы DNS-over-HTTPS (DoH) и DNS-over-TLS (DoT), но в ряде случаев и обычные незашифрованные запросы к 8.8.8.8 и 8.8.4.4.

Техническая картина блокировок

Механизм ограничений выглядит следующим образом: в мобильных и фиксированных сетях операторов фиксируется блокировка DoT для Cloudflare на TCP-порту 853 — при попытке соединения система отправляет лишь один пакет, после чего возникает ошибка. Аналогичные меры применяются к DNS-over-HTTPS от Google: блокируется доступ к домену dns.google через IP-адреса 8.8.8.8 и 8.8.4.4 на порту 443, при этом попытки соединения обрываются тайм-аутом.

По сообщениям источников, отслеживающих блокировки, за 22–23 августа было собрано более трёх тысяч проверок в 66 сетях, и у крупных операторов фиксируется непостоянная блокировка части DoH-сервисов, а у нескольких небольших провайдеров защищённый DNS выключен целиком. При этом важно отметить, что некоторые альтернативные DNS-сервисы, такие как Yandex.DNS (77.88.8.8 и 77.88.8.1), AdGuard и азиатские публичные резолверы, по состоянию на текущий момент остаются доступными.

Почему это критично для бизнеса

Для многих компаний использование DNS-серверов Google давно стало стандартом де-факто, закреплённым в конфигурациях серверного ПО, скриптах развёртывания и инструкциях по настройке инфраструктуры. И если для обычного пользователя смена DNS — вопрос нескольких кликов, то для серверной инфраструктуры, особенно работающей с внешними интеграциями, последствия могут быть гораздо серьёзнее.

Особенно уязвимыми оказываются серверы, которые используют 8.8.8.8 и 8.8.4.4 для внешних соединений с платёжными системами — ЮKassa, Робокасса, — а также с GEO-сервисами, API сторонних поставщиков и другими критически важными внешними ресурсами. Когда DNS-резолвер перестаёт отвечать, сервер не может преобразовать доменное имя платёжного шлюза в IP-адрес, что приводит к ошибкам при обработке транзакций, сбоям в работе геолокационных сервисов и общему замедлению всех сетевых операций, зависящих от DNS.

Что происходит с защищёнными протоколами

Особого внимания заслуживает блокировка защищённых протоколов DNS — DoH и DoT. Эти протоколы шифруют DNS-запросы, что скрывает от провайдера информацию о том, какие сайты посещает пользователь. Именно эта особенность делает DoH и DoT нежелательными с точки зрения регулирования — они скрывают SNI (Server Name Indication), что затрудняет контроль трафика.

В результате пользователи защищённых DNS-сервисов могут столкнуться с нестабильностью соединения или полной потерей доступа, пока не изменят настройки на стандартные незашифрованные запросы. Однако важно понимать, что даже обычные (незашифрованные) запросы к 8.8.8.8 и 1.1.1.1 в некоторых сетях также проходят с перебоями или не проходят вовсе.

Альтернативные публичные DNS-серверы

В условиях нестабильной работы Google Public DNS и Cloudflare DNS критически важно иметь под рукой список альтернативных публичных резолверов. Ниже приведён актуализированный перечень глобальных DNS-серверов:

Часть 2. Как заменить DNS-серверы на различных операционных системах

Ниже приведены подробные инструкции для наиболее популярных операционных систем.

Ubuntu 18

В Ubuntu 18 управление сетевыми настройками осуществляется через службу netplan. Для изменения DNS-серверов необходимо отредактировать конфигурационный файл:

1. Подключитесь к серверу по SSH.
2. Откройте файл конфигурации netplan:
   bash

   sudo nano /etc/netplan/01-netcfg.yaml

3. В блоке nameservers укажите новые DNS-серверы. Например:
   yaml

   network:
     ethernets:
       eth0:
         addresses:
           - 123.123.123.123/24
         gateway4: 123.123.123.123
         nameservers:
           addresses:
             - 77.88.8.8
             - 9.9.9.9
     renderer: networkd
     version: 2

4. Сохраните файл (Ctrl+O, затем Ctrl+X).
5. Примените изменения:

   sudo netplan apply

6. Проверьте результат:

   systemd-resolve --status | grep 'DNS Servers' -A2

Debian / Ubuntu 20 (systemd-resolved)

В современных версиях Ubuntu и Debian управление DNS осуществляется через systemd-resolved:

1. Подключитесь к серверу по SSH.
2. Откройте файл конфигурации:

   sudo nano /etc/systemd/resolved.conf

3. В строке DNS добавьте IP-адреса через пробел:

   DNS=77.88.8.8 9.9.9.9

4. Сохраните файл и закройте редактор.
5. Перезапустите службу:

   sudo systemctl restart systemd-resolved

6. Проверьте настройки:

   systemd-resolve --status | grep 'DNS Servers' -A2

CentOS

В CentOS настройка DNS выполняется через редактирование конфигурационного файла сетевого интерфейса:

1. Подключитесь к серверу по SSH.
2. Определите название сетевого интерфейса:

   ip address

   Обратите внимание на имя интерфейса (например, eth0 или ens3).
3. Откройте файл конфигурации интерфейса:

   sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0

4. Найдите или добавьте строки с DNS-серверами:

   DNS1=77.88.8.8
   DNS2=9.9.9.9

   При необходимости можно добавить DNS4, DNS5 и так далее.
5. Сохраните файл и закройте редактор.
6. Перезапустите сетевую службу:

   systemctl restart network

7. Проверьте настройки:

   cat /etc/resolv.conf

AlmaLinux

AlmaLinux — это форк CentOS. Настройка DNS в AlmaLinux может выполняться несколькими способами. Способ через NetworkManager предпочтителен для постоянного изменения:

1. Подключитесь к серверу по SSH.
2. Определите имя соединения:

   nmcli connection show

3. Установите DNS-серверы для нужного соединения (например, eth0) или воспользуйтесь текстовой утилитой nmtui:

   sudo nmcli connection modify eth0 ipv4.dns "77.88.8.8 9.9.9.9"

4. Перезагрузите соединение для применения изменений:

   sudo nmcli connection reload

5. Проверьте настройки:

   cat /etc/resolv.conf

Также доступны альтернативные способы (временное редактирование /etc/resolv.conf + systemctl restart NetworkManager или традиционное редактирование файла интерфейса, аналогично CentOS).

Windows Server

Настройка DNS в Windows Server выполняется через графический интерфейс:

1. Подключитесь к серверу по RDP.
2. Нажмите Win+R, введите ncpa.cpl и нажмите OK.
3. Правой кнопкой мыши кликните по активному сетевому подключению и выберите Свойства.
4. Выберите IP версии 4 (TCP/IPv4) и нажмите Свойства.
5. Отметьте пункт Использовать следующие адреса DNS-серверов.
6. Укажите предпочитаемый и альтернативный DNS-серверы, например:
   • Предпочитаемый: 77.88.8.8
   • Альтернативный: 9.9.9.9
7. Нажмите OK для сохранения.
8. Для проверки откройте PowerShell и выполните:
   powershell

   ipconfig /all

Компаниям, чья ИТ-инфраструктура, интеграции с внешними API, GEO-сервисами или платежными шлюзами завязаны на адреса 8.8.8.8 и 8.8.4.4, необходимо оперативно скорректировать сетевые настройки.

Основные рекомендации

Приоритетный вариант.
Переключите серверное оборудование на DNS-резолверы вашего хостинг-провайдера или оператора связи. Актуальные IP-адреса можно запросить в технической поддержке провайдера.

Резервный контур.
Для подстраховки стоит прописать альтернативные варианты. Из локальных стабильно работает Яндекс.DNS (77.88.8.8), из зарубежных на данный момент доступен Quad9 (9.9.9.9).

Под аналогичные блокировки ТСПУ попадают и другие популярные иностранные сервисы, включая Cloudflare (1.1.1.1) и OpenDNS. При проектировании отказоустойчивой архитектуры ключевым критерием выбора резолвера становится не минимальный пинг, а гарантированная доступность внутри РФ. Своевременный аудит сетевых конфигураций на серверах позволит избежать сбоев в работе бизнес-критичных приложений.