Коротко. DNS-сервер — это сервис, который переводит доменное имя в IP-адрес. Типов несколько: рекурсивный резолвер принимает запрос от вашего устройства и ищет ответ; корневые и TLD-серверы подсказывают, куда идти дальше; авторитативный хранит записи конкретного домена. В настройках сети вы прописываете адрес рекурсивного — например, 1.1.1.1 или 8.8.8.8. Он же кэширует ответы, поэтому правки DNS видны не сразу.
Что такое DNS-сервер простыми словами
Компьютеры соединяются друг с другом по IP-адресам вида 93.184.215.14 или 2606:2800:21f:cb07:6820:80da:af6b:8b2c. Люди набирают в адресной строке слова. DNS-сервер — это посредник, который превращает одно в другое.
Слово «сервер» здесь означает две разные вещи, и путаница между ними — источник половины вопросов:
- Бытовое значение. «Мой DNS-сервер» — это адрес, вписанный в настройки сетевого адаптера или роутера:
192.168.1.1,8.8.8.8, адрес провайдера. Технически это рекурсивный резолвер. - Инженерное значение. В резолюции участвуют четыре роли — корневой, TLD, авторитативный и рекурсивный сервер. У каждой свои данные и своя зона ответственности.
Дальше в статье разобраны обе трактовки: сначала роли, потом практика — как найти свой резолвер, сменить его и что делать, когда он молчит. Если нужен разбор самого протокола DNS, типов записей и того, как устроен запрос на уровне пакета, он в отдельном материале: что такое DNS и как он работает.
Что DNS-сервер делает и чего не делает
Делает: отдаёт записи зоны — A и AAAA (адреса), MX (почта), TXT (SPF, DKIM, верификации), NS (делегирование), CNAME (псевдонимы), SRV, CAA. Кэширует чужие ответы. Может фильтровать — отдавать «пусто» вместо адресов рекламных и вредоносных доменов.
Не делает:
- Не хранит сайт. DNS отдаёт только адрес. Контент лежит на веб-сервере, это разные машины и часто разные компании.
- Не пропускает через себя трафик. После получения IP браузер соединяется с сайтом напрямую. Смена DNS-сервера не меняет маршрут пакетов и не ускоряет загрузку самой страницы — только время до первого соединения, обычно десятки миллисекунд.
- Не отвечает за доступность сайта. Если домен резолвится, а сайт не открывается — проблема не в DNS. Проверять надо связность и веб-сервер: ping, трассировку, заголовки ответа.
Иерархия DNS: почему серверов несколько
Единая база всех доменов мира была бы неуправляемой. Вместо неё — дерево с пустым корнем наверху, где каждый уровень знает только, кому делегирован следующий:
. (root — корень)
|
com / org / ru (TLD — домены верхнего уровня)
|
example.com (домен второго уровня)
|
www.example.com (поддомен)Полное имя всегда заканчивается точкой: www.example.com. — обычно её не пишут, но резолвер добавляет сам. Именно эта точка и есть корень.
Ключевой принцип: верхние уровни не знают адресов сайтов. Корневой сервер не знает IP вашего домена и никогда не узнает — он знает только, где искать зону .ru. Зона .ru не знает IP вашего сайта — она знает, каким серверам делегирован ваш домен. И только авторитативный сервер домена отдаёт настоящий адрес.
Root-серверы: 13 имён, а не 13 машин
Самое распространённое заблуждение о DNS — что весь интернет держится на тринадцати компьютерах. Это не так.
Тринадцать — это количество имён: от a.root-servers.net до m.root-servers.net. За каждым именем стоит один IPv4- и один IPv6-адрес, а за каждым адресом — не одна машина, а множество площадок по всему миру, объявляющих один и тот же префикс по BGP. Технология называется anycast: пакет уходит на ближайший к вам узел, вы никогда не узнаете, на какой именно.
Тринадцать в названии — это тринадцать имён и тринадцать адресов, а не тринадцать серверов. Физических площадок больше тысячи, их число постоянно растёт. Актуальную карту публикует root-servers.org.
Убедиться в этом можно прямо из терминала. Корневые серверы отвечают на служебный запрос об идентификаторе площадки (RFC 4892) — запустите его из разных сетей или с мобильного интернета и сравните ответы:
# Идентификатор конкретного anycast-узла, который вам ответил
dig @j.root-servers.net id.server CHAOS TXT +short
# Старая форма того же запроса, её понимают не все операторы
dig @j.root-servers.net hostname.bind CHAOS TXT +shortОдин и тот же адрес 192.58.128.30 в Москве, Франкфурте и Сан-Паулу ответит разными идентификаторами — это разные машины.
Почему всё-таки 13
Ограничение историческое. По RFC 1035 ответ DNS по UDP не мог превышать 512 байт. При запуске резолвер должен получить список всех корневых серверов сразу — с именами и склеенными адресами (glue). Тринадцать записей с учётом сжатия имён были максимумом, который влезал в этот пакет.
Расширение EDNS0 (RFC 6891) давно сняло лимит в 512 байт, но схему из тринадцати букв оставили ради совместимости: её знают наизусть миллионы конфигураций и встроенных резолверов. Менять её незачем — масштабирование давно идёт не числом имён, а числом anycast-площадок за каждым.
Кто ими управляет и как часто их спрашивают
Корневую зону координирует IANA, а сами серверы держат двенадцать независимых организаций — среди них Verisign (две буквы из тринадцати), ICANN, RIPE NCC, Netnod, NASA, ISC, несколько университетов и исследовательских центров. Ни одна из них не владеет корнем целиком: это сознательно рассредоточенная конструкция.
Суммарная нагрузка — десятки миллиардов запросов в сутки; операторы публикуют помесячную статистику по регламенту RSSAC-002. При этом на конкретный домен корневые серверы почти не работают: делегирование зоны .com отдаётся с TTL 172800 секунд (двое суток), и всё это время резолвер обходится без корня. К корню он идёт только при холодном старте или после истечения кэша.
# Спросить корневой сервер напрямую, без рекурсии.
# В ответ придёт не адрес, а отсылка к серверам зоны .com
dig +norecurse @a.root-servers.net A example.com
# Список всех корневых серверов, как его видит ваш резолвер
dig NS . +shortTLD-серверы: кто отвечает за зоны .ru, .com и .io
TLD-сервер обслуживает один домен верхнего уровня и знает про него ровно одно: каким авторитативным серверам делегирован каждый домен второго уровня внутри зоны.
- gTLD — общие зоны:
.com,.net,.org,.info. - ccTLD — национальные:
.ru,.рф,.de,.kz. Правила регистрации задаёт администратор зоны, и они сильно различаются: где-то нужны документы, где-то нет. - new gTLD — зоны новой волны:
.io,.app,.dev,.shop. У части из них есть особенности вроде обязательного HTTPS: зоны.appи.devцеликом включены в список предзагрузки HSTS, и сайт в них физически не открыть по HTTP.
Реестр зоны и её DNS-серверы — разные вещи. Реестр хранит юридические данные о владельце (их показывает WHOIS), TLD-серверы отдают техническое делегирование. Проверить и то и другое:
# Какие серверы обслуживают зону .ru
dig NS ru. +short
# Спросить сервер зоны .ru о делегировании конкретного домена.
# Ответ придёт в секции AUTHORITY: NS-записи, а не адрес сайта
dig +norecurse @a.dns.ripn.net NS example.ru
# То же для .com
dig +norecurse @a.gtld-servers.net NS example.comTLD-сервер не знает A-записи вашего сайта и не может её отдать. Если домен «не резолвится», а
dig +norecurseк TLD показывает корректные NS — проблема ниже по цепочке, на авторитативных серверах, а не в зоне.
Авторитативные DNS-серверы: источник истины о домене
Авторитативный сервер — единственный, кто отвечает о домене «по существу», а не пересказывает чужой ответ. Когда вы прописываете у регистратора ns1.example-dns.com и ns2.example-dns.com, вы назначаете именно их.
Отличить авторитативный ответ от кэшированного можно по флагу aa (authoritative answer) в заголовке:
# Найти авторитативные серверы домена
dig NS example.com +short
# Спросить один из них напрямую — в строке flags появится aa
dig A example.com @ns1.example-dns.com | grep -E 'flags|ANSWER SECTION' -A2
# Опросить сразу все авторитативные серверы домена и сравнить SOA.
# Расхождение serial означает, что зона не доехала до части серверов
dig +nssearch example.comPrimary, secondary и hidden primary
- Primary (master). Хранит оригинал зоны. Все правки делаются здесь, и только здесь.
- Secondary (slave). Копирует зону с primary через передачу AXFR (целиком) или IXFR (только изменения). Обычно primary шлёт уведомление NOTIFY (RFC 1996), и secondary забирает свежую версию за секунды, не дожидаясь таймера refresh.
- Hidden primary. Primary не опубликован в NS-записях и недоступен извне: снаружи видны только secondary. Схема снижает поверхность атаки — публичные серверы работают только на чтение.
SOA: паспорт зоны
Запись SOA есть у каждой зоны и задаёт правила её репликации и отрицательного кэширования:
dig SOA example.com +short
# ns1.example-dns.com. hostmaster.example.com. 2026081201 7200 3600 1209600 3600| Поле | Значение в примере | Что делает |
|---|---|---|
| MNAME | ns1.example-dns.com. | Primary-сервер зоны. Именно ему шлют динамические обновления. |
| RNAME | hostmaster.example.com. | Почта администратора. Первая точка заменяет собаку. |
| Serial | 2026081201 | Версия зоны. Secondary забирает зону, только если serial вырос. |
| Refresh | 7200 | Как часто secondary проверяет serial, если не пришёл NOTIFY. |
| Retry | 3600 | Пауза перед повтором после неудачной проверки. |
| Expire | 1209600 | Через сколько secondary перестанет отвечать, потеряв связь с primary. |
| Minimum | 3600 | TTL отрицательного ответа: сколько кэшируется NXDOMAIN (RFC 2308). |
Последнее поле объясняет частую ситуацию: вы добавили поддомен, а он «не появляется» ещё час. Резолвер закэшировал не запись, а её отсутствие — ровно на minimum секунд.
Glue-записи
Если NS-серверы домена живут внутри него самого (ns1.example.com обслуживает example.com), возникает замкнутый круг: чтобы узнать адрес ns1.example.com, надо спросить example.com, а для этого нужен адрес ns1. Круг разрывают glue-записи — адреса NS-серверов, которые публикуются в родительской зоне вместе с делегированием. Их задают в панели регистратора отдельным пунктом, обычно он называется «регистрация DNS-серверов» или «child nameservers». Забытые или устаревшие glue — типовая причина того, что домен не резолвится нигде, хотя NS прописаны верно.
Держите NS у двух независимых операторов и в разных сетях. Оба сервера у одного провайдера — единая точка отказа: DDoS или авария у него делает домен невидимым целиком, и никакой TTL не спасёт после истечения кэша.
Рекурсивные и кэширующие DNS-серверы
Рекурсивный резолвер — тот самый сервер, чей адрес стоит в настройках вашей сети. Записей вашего домена он не хранит. Его работа — принять запрос, обойти цепочку root → TLD → авторитативный, собрать ответ, положить его в кэш и отдать клиенту.
Откуда он берётся:
- Провайдерский. Выдаётся автоматически по DHCP. Ближе всех географически, но чаще других страдает от перегрузок и фильтрации.
- Публичный. Cloudflare, Google, Quad9, Яндекс, AdGuard. Anycast, стабильный, но видит все ваши запросы.
- Корпоративный. Разрешает внутренние имена, недоступные снаружи, и обычно обязателен в VPN-сетях.
- Локальный. Служба на самом устройстве или dnsmasq на роутере.
Кэш и TTL: почему изменения видны не сразу
Каждая запись приходит с временем жизни. Пока TTL не истёк, резолвер отдаёт ответ из памяти, не беспокоя авторитативный сервер. Посмотреть обратный отсчёт можно двумя запросами подряд:
# Первый запрос — TTL максимальный
dig A example.com @1.1.1.1 +noall +answer
# example.com. 300 IN A 93.184.215.14
# Через 60 секунд тот же запрос — TTL уменьшился, ответ из кэша
dig A example.com @1.1.1.1 +noall +answer
# example.com. 240 IN A 93.184.215.14Если во втором ответе TTL снова максимальный — вас обслужил другой узел резолвера, у которого своего кэша по этой записи ещё не было. Для anycast-сервисов это норма.
Планируете переезд или смену IP — снизьте TTL записи до 300 секунд минимум за сутки до переключения. TTL действует «задним числом»: резолверы, успевшие закэшировать запись со старым значением 86400, будут держать её сутки, что бы вы ни поменяли потом. Вернуть прежнее значение можно через сутки после переезда.
Кэшируется и отрицательный ответ. NXDOMAIN живёт столько, сколько указано в поле minimum записи SOA, — поэтому только что созданный поддомен иногда «не видно» дольше, чем изменённый.
Forwarder и stub-resolver: DNS внутри вашей сети
Stub-resolver — библиотека в операционной системе. Она не обходит дерево, а просто отправляет запрос на настроенный сервер и ждёт ответа. Её настройки на Linux лежат в /etc/resolv.conf, на Windows — в свойствах адаптера.
Forwarder — сервер, который сам не рекурсирует, а пересылает запросы вышестоящему резолверу и кэширует ответы. Именно так работает домашний роутер: устройства видят его как DNS-сервер 192.168.1.1, а он под капотом ходит к провайдеру. В компаниях forwarder решает задачу split-horizon: внутренние имена вроде gitlab.corp.local он резолвит сам, всё остальное отдаёт наружу.
Отдельная тонкость Linux: если в системе работает systemd-resolved, файл /etc/resolv.conf будет указывать на 127.0.0.53 — это локальная заглушка, а не настоящий сервер. Реальные адреса надо смотреть иначе:
# Настоящие серверы, которые использует systemd-resolved
resolvectl status
# Только адреса, по интерфейсам
resolvectl dns
# Статистика кэша: сколько попаданий и промахов
resolvectl statisticsТипы DNS-серверов: сравнительная таблица
Роли различаются по трём признакам: какие данные сервер хранит, отвечает ли он окончательно и кэширует ли чужое.
| Тип сервера | Что хранит | Отвечает окончательно | Кэширует | Кто управляет |
|---|---|---|---|---|
| Корневой (root) | Делегирование зон верхнего уровня | Нет, только отсылка к TLD | Нет | 12 организаций, координация IANA |
| TLD | NS и glue доменов второго уровня своей зоны | Нет, только отсылка к домену | Нет | Оператор реестра зоны |
| Авторитативный primary | Оригинал зоны: A, AAAA, MX, TXT, NS, CNAME | Да, флаг aa | Нет | Владелец домена или его DNS-хостинг |
| Авторитативный secondary | Копию зоны, полученную через AXFR или IXFR | Да, флаг aa | Нет | Тот же владелец, часто другой оператор |
| Рекурсивный резолвер | Ничего своего, только кэш чужих ответов | Нет, флага aa не будет | Да, по TTL | Провайдер, публичный оператор, компания |
| Forwarder | Кэш, иногда локальную зону | Только по своей локальной зоне | Да | Администратор сети, роутер |
| Stub-resolver | Небольшой кэш операционной системы | Нет | Да, недолго | Операционная система устройства |
Практический вывод из таблицы: домен ломается на уровне авторитативных серверов и делегирования, а «лечится» чаще всего на уровне резолвера и его кэша. Диагностика идёт сверху вниз — от корня к домену, а не наоборот.
Полный путь DNS-запроса: от браузера до ответа
Что происходит между нажатием Enter и первым байтом страницы:
- Браузер смотрит собственный кэш DNS — у Chrome и Firefox он свой, отдельный от системного.
- Операционная система проверяет файл hosts (
/etc/hostsна Linux и macOS,C:\Windows\System32\drivers\etc\hostsна Windows). Запись в нём имеет приоритет над любым DNS-сервером — про это забывают, когда тестовая правка hosts остаётся на месяцы. - Проверяется кэш stub-resolver операционной системы.
- Промах — запрос уходит на рекурсивный резолвер из настроек сети.
- Резолвер смотрит свой кэш. Есть запись — отдаёт сразу, на этом всё заканчивается. В реальности так закрывается подавляющее большинство запросов.
- Промах — резолвер идёт к корневому серверу: «где зона .com?» Получает список TLD-серверов.
- Спрашивает TLD-сервер: «кому делегирован example.com?» Получает NS-записи и glue.
- Спрашивает авторитативный сервер: «дай A для www.example.com». Получает адрес с флагом aa.
- Кэширует ответ на время TTL и отдаёт его клиенту.
- Браузер открывает TCP-соединение по полученному IP. DNS в этом уже не участвует.
Увидеть шаги 6–8 целиком позволяет режим трассировки — резолвер обходится стороной, dig сам идёт от корня:
dig +trace www.example.comСокращённый вывод, адреса и тайминги у вас будут другими:
. 518400 IN NS a.root-servers.net.
;; Received 1174 bytes from 198.41.0.4#53(a.root-servers.net) in 24 ms
com. 172800 IN NS a.gtld-servers.net.
;; Received 576 bytes from 192.5.6.30#53(a.gtld-servers.net) in 32 ms
example.com. 172800 IN NS a.iana-servers.net.
;; Received 576 bytes from 199.43.135.53#53(a.iana-servers.net) in 28 ms
www.example.com. 86400 IN A 93.184.215.14
;; Received 60 bytes from 199.43.135.53#53(a.iana-servers.net) in 28 msЧитается снизу вверх по строкам «Received … from»: они показывают, какой сервер ответил на каждом шаге. Если трассировка обрывается на TLD — сломано делегирование. Если доходит до авторитативных, но ответа нет — проблема в самой зоне.
Где находится DNS-сервер и как узнать свой
Физически рекурсивный резолвер стоит либо в сети провайдера, либо в дата-центрах публичного оператора, либо прямо у вас — в роутере. Корневые и TLD-серверы размещены на сотнях anycast-площадок по миру, и «место» у них не одно. Практический вопрос звучит иначе: какой адрес сейчас использует моё устройство. Ответ добывается одной командой.
Windows
:: Полная информация об адаптерах, нужное поле — DNS-серверы
ipconfig /all
:: Только адреса DNS, короче и нагляднее
netsh interface ipv4 show dnsservers
:: Что лежит в кэше прямо сейчас
ipconfig /displaydns
:: Сбросить кэш DNS
ipconfig /flushdnsТо же самое в PowerShell, комментарии там начинаются с решётки:
# Адреса DNS-серверов по всем интерфейсам
Get-DnsClientServerAddress -AddressFamily IPv4
# Содержимое клиентского кэша
Get-DnsClientCacheЕщё быстрее — запустить nslookup без аргументов: первые две строки Default Server и Address покажут используемый сервер.
macOS
# Все резолверы, которые видит система
scutil --dns | grep nameserver
# Адреса для конкретного интерфейса
networksetup -getdnsservers Wi-Fi
# Список интерфейсов, если Wi-Fi называется иначе
networksetup -listallnetworkservices
# Сбросить кэш
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponderLinux
# Современные системы с systemd-resolved
resolvectl status
resolvectl dns
# Классический файл. Внимание: при systemd-resolved
# здесь будет заглушка 127.0.0.53, а не реальный сервер
cat /etc/resolv.conf
# Если systemd-resolved нет, а есть NetworkManager
nmcli dev show | grep DNS
# Сброс кэша
resolvectl flush-cachesРоутер, телефон, служебная проверка
Если на всех устройствах виден адрес вида 192.168.0.1 или 192.168.1.1 — это ваш роутер в роли forwarder, а настоящий вышестоящий резолвер прописан в его веб-панели, в разделе WAN или «Интернет». На Android адрес виден в свойствах Wi-Fi-сети, на iOS — в настройках сети, пункт «Настройка DNS».
Отдельный приём: узнать, какой узел резолвера реально вас обслужил. Google отдаёт свой исходящий адрес по служебному имени:
# Через какой узел Google DNS ушёл ваш запрос
dig @8.8.8.8 o-o.myaddr.l.google.com TXT +short
# Обратная запись адреса резолвера — быстрый способ понять, чей он
dig -x 8.8.8.8 +short
dig -x 1.1.1.1 +shortПроверить, что именно отдаёт ваш текущий резолвер по конкретному домену, и сравнить это с ответами других операторов удобнее в браузере — через онлайн-проверку DNS.
Как сменить DNS-сервер
Смена резолвера — операция на минуту и обратимая. Менять его имеет смысл, когда провайдерский сервер медленно отвечает, отдаёт устаревшие записи или подмешивает свои страницы вместо ошибок. Полный разбор со скриншотами по каждой системе — в отдельной статье: как сменить DNS-сервер. Короткая версия ниже.
# Windows, PowerShell от имени администратора
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 1.1.1.1,9.9.9.9
# Вернуть автоматическое получение от провайдера
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ResetServerAddresses# macOS
sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 9.9.9.9
# Вернуть как было
sudo networksetup -setdnsservers Wi-Fi empty
# Linux с NetworkManager. Имя соединения возьмите из nmcli con show
sudo nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 9.9.9.9"
sudo nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
sudo nmcli con up "Wired connection 1"Самое правильное место для смены — роутер: настройка применится ко всем устройствам сразу, включая телевизор и умные розетки, где менять DNS вручную негде.
Чаще всего выбирают из этих операторов. Адреса стоит сверять с документацией — операторы иногда добавляют новые:
| Оператор | Основной адрес | Запасной | Особенность |
|---|---|---|---|
| Cloudflare | 1.1.1.1 | 1.0.0.1 | Заявленный приоритет — приватность и низкая задержка. Есть вариант 1.1.1.2 с фильтрацией вредоносных доменов. |
| Google Public DNS | 8.8.8.8 | 8.8.4.4 | Самый распространённый, удобен как эталон при диагностике. |
| Quad9 | 9.9.9.9 | 149.112.112.112 | Блокирует домены из списков угроз, без коммерческой фильтрации. |
| Яндекс DNS | 77.88.8.8 | 77.88.8.1 | Российские узлы. Есть режимы «Безопасный» и «Семейный» на отдельных адресах. |
| AdGuard DNS | 94.140.14.14 | 94.140.15.15 | Режет рекламу и трекеры на уровне DNS, включая приложения. |
| OpenDNS | 208.67.222.222 | 208.67.220.220 | Категорийная фильтрация, настраивается в личном кабинете. |
Сравнение по скорости, фильтрации и приватности — в материале про публичные DNS-серверы.
Не ставьте оба адреса одного оператора: 8.8.8.8 и 8.8.4.4 отказывают вместе. Смысл второго адреса — резерв на случай аварии у первого, поэтому берите его у другой компании. И помните, что резолвер видит список всех доменов, которые вы открываете, — выбирая оператора, вы выбираете, кому этот список достаётся.
DNS-сервер не отвечает: как исправить
Диагностика строится на одном приёме: сравните ответ двух разных резолверов. Если через 1.1.1.1 домен резолвится, а через ваш — нет, проблема в резолвере или сети. Если не резолвится нигде — проблема в домене.
# Базовая пара запросов, с которой начинается любая диагностика
dig A example.com # через ваш текущий резолвер
dig A example.com @1.1.1.1 # через заведомо рабочий публичный
# Проверить, что резолвер вообще жив и доступен
dig @1.1.1.1 example.com +time=3 +tries=1
# Если UDP молчит, попробовать тот же запрос по TCP
dig A example.com @1.1.1.1 +tcp| Признак | Вероятная причина | Проверка | Что делать |
|---|---|---|---|
| Сайты не открываются, но по IP-адресу доступны, пинг идёт | Резолвер недоступен или перегружен | dig @1.1.1.1 example.com отвечает, dig example.com — нет | Прописать другой резолвер, перезагрузить роутер |
| Ошибка ERR_NAME_NOT_RESOLVED в браузере, в терминале всё работает | Кэш браузера или расширение с собственным DNS | Открыть сайт в приватном окне и другом браузере | Очистить кэш браузера, отключить расширения, проверить настройку DoH внутри браузера |
| Ответ SERVFAIL | Сбой валидации DNSSEC или отказ авторитативного сервера | dig example.com +cd — если с этим флагом ответ приходит, дело в DNSSEC | Владельцу домена: починить подписи или снять DS-запись у регистратора. Пользователю: временно взять резолвер без валидации |
| Ответ REFUSED | Резолвер не обслуживает вашу сеть, сработал ACL | Тот же запрос с другого адреса или через мобильный интернет | Использовать резолвер провайдера или публичный |
| NXDOMAIN на домен, который точно существует | Отрицательный кэш или домен снят с делегирования | dig SOA example.com, whois example.com, срок регистрации | Дождаться истечения minimum из SOA; при истёкшей регистрации — продлить домен |
| Домен резолвится в старый IP-адрес | Не истёк TTL, ответ отдаётся из кэша | Сравнить ответы разных операторов, посмотреть значение TTL | Дождаться TTL, сбросить локальный кэш, проверить распространение |
| Часть пользователей видит сайт, часть — нет | Зона доехала не до всех авторитативных серверов | dig +nssearch example.com — сравнить serial в SOA | Обновить зону на primary, дождаться передачи на secondary |
| Работает через 8.8.8.8, но не через провайдерский | Фильтрация, авария или устаревший кэш у провайдера | Сравнить оба ответа и TTL | Сменить резолвер; если фильтрация постоянная — использовать шифрованный DNS |
| Все запросы уходят в таймаут, включая публичные резолверы | Порт 53 закрыт в сети или фильтруется | Тот же запрос с флагом +tcp, проверка из другой сети | Настроить DoH или DoT, они работают по 443 и 853 |
| Windows: «Не удалось найти DNS-адрес сервера» после смены настроек | Старая запись в системном кэше | ipconfig /displaydns — искать домен в выводе | ipconfig /flushdns, при упорстве — перезапуск службы DNS Client |
Три случая, которые чаще всего диагностируют неправильно
Ошибка в hosts. Строка, добавленная год назад для теста, пережила и переезд, и смену хостинга. DNS-сервер здесь ни при чём: файл hosts проверяется раньше любого резолвера. Начинайте с него, если «у всех работает, а у меня нет».
Домен просрочен. Регистратор снимает делегирование, и NXDOMAIN приходит абсолютно везде. Никакая смена DNS не поможет. Проверяется за секунду через WHOIS — смотрите дату окончания регистрации.
Изменения «не применились». Чаще всего они применились, просто ещё не разошлись: старый TTL держит запись у части резолверов. Посмотреть срез по разным операторам и регионам можно через проверку распространения DNS. Подробный разбор сценариев, когда домен не резолвится, — в статье почему домен не резолвится и как это чинить.
Безопасность DNS: DNSSEC, DoH и DoT
Исходный DNS создавался без защиты: ответ приходит открытым текстом и без подписи. Три технологии закрывают разные части проблемы, и их постоянно путают.
- DNSSEC — подпись данных. Авторитативный сервер подписывает записи (RRSIG), рекурсивный проверяет цепочку доверия от корневого ключа через DS-записи родительских зон. Защищает от подмены ответа. Не шифрует ничего: содержимое запроса видно по-прежнему.
- DoT, DNS over TLS (RFC 7858) — шифрование транспорта на выделенном порту 853. Виден сам факт использования DNS, но не содержимое.
- DoH, DNS over HTTPS (RFC 8484) — то же шифрование, но внутри обычного HTTPS на порту 443, неотличимо от веб-трафика. Работает в обход системных настроек, если включено внутри браузера, — частая причина «я сменил DNS, а ничего не изменилось».
Важная граница: DoH и DoT скрывают запросы от провайдера и случайных наблюдателей, но не от самого резолвера. Оператор публичного DNS видит всё так же. Приватность здесь — вопрос доверия к выбранной компании, а не к протоколу.
# Проверить, подписана ли зона: ищите записи RRSIG в ответе
dig example.com +dnssec
# Полная валидация цепочки доверия утилитой из состава BIND
delv example.com
# Есть ли DS-запись у родительской зоны — без неё DNSSEC не работает
dig DS example.com +shortНа стороне владельца домена работают ещё две меры. Ограничение частоты ответов (Response Rate Limiting) мешает использовать авторитативный сервер как усилитель в DDoS-атаке: короткий запрос порождает длинный ответ, и злоумышленник подставляет чужой адрес отправителя. Anycast и серверы у двух операторов дают устойчивость к перегрузке. Резолверы, в свою очередь, защищаются от подмены ответов рандомизацией исходного порта и регистра имени, а также сокращением имени в запросах к верхним уровням (QNAME minimisation, RFC 9156): корневому серверу незачем знать полное имя, достаточно зоны.
Перед включением DNSSEC убедитесь, что DNS-хостинг и регистратор поддерживают его оба: подпись создаётся на стороне хостинга, а DS-запись публикуется через регистратора. Ошибка на любом из шагов даёт SERVFAIL у всех валидирующих резолверов — домен пропадает не частично, а целиком.
Как проверить DNS-сервер онлайн
Терминал под рукой не всегда, а сравнить ответы из разных сетей с одного компьютера вообще невозможно. Для этого есть браузерные проверки:
- Проверка DNS-записей — A, AAAA, MX, TXT, NS, CNAME, SOA по домену. Первое, куда стоит смотреть при любой проблеме с доменом.
- Проверка распространения DNS — один и тот же домен опрашивается у резолверов в разных странах. Показывает, докатились ли изменения и где ещё висит старый кэш.
- WHOIS домена — владелец, регистратор, дата окончания регистрации и текущие NS. Отвечает на вопрос «домен вообще ещё жив».
- Проверка MX и диагностика почты — MX, SPF, DKIM и DMARC, когда письма перестали доходить.
- Поиск поддоменов — какие имена в зоне вообще существуют и куда указывают.
- Ping и трассировка — когда имя резолвится, но соединения нет: проблема уже не в DNS.
- Мониторинг — постоянная проверка NS и записей домена с уведомлением, если они изменились или перестали отвечать. Закрывает главный риск: сбой DNS замечают по жалобам клиентов, а не по алерту.
- Сбои у операторов — быстрый ответ на вопрос «это только у меня или у всех».
Частые вопросы
Что такое DNS-сервер простыми словами?
Это справочная служба интернета. Вы называете ей доменное имя, она возвращает IP-адрес, по которому браузер откроет сайт. Без неё сайты пришлось бы открывать по числовым адресам.
Где находится DNS-сервер?
Тот, которым вы пользуетесь, — обычно в сети провайдера или в дата-центрах публичного оператора вроде Cloudflare и Google. В домашней сети его роль часто играет роутер, пересылающий запросы дальше. Авторитативные серверы вашего домена находятся у DNS-хостинга, чьи имена прописаны у регистратора.
Как узнать, какой DNS-сервер использует мой компьютер?
Windows — ipconfig /all, поле «DNS-серверы». macOS — scutil --dns. Linux — resolvectl status. Если видите 192.168.x.x — это ваш роутер, настоящий вышестоящий сервер прописан в его панели. Адрес 127.0.0.53 на Linux — локальная заглушка systemd-resolved, а не реальный сервер.
Почему корневых серверов именно 13?
Тринадцать — это количество имён и адресов, а не машин. Ограничение пришло из RFC 1035: ответ по UDP не мог превышать 512 байт, и тринадцать записей с адресами были максимумом, который в него помещался. Расширение EDNS0 давно сняло лимит, но схему сохранили ради совместимости. Физических площадок за этими адресами больше тысячи.
Хранит ли рекурсивный резолвер записи моего домена?
Нет. Он только кэширует ответы, полученные от ваших авторитативных серверов, и держит их до истечения TTL. Оригинал зоны есть только на авторитативных серверах.
Влияет ли смена DNS-сервера на скорость сайта?
На скорость загрузки страницы — практически нет: после получения адреса браузер идёт к сайту напрямую. Ускоряется только первый шаг, обычно на десятки миллисекунд, и заметно это на сайтах с множеством сторонних доменов. Реальные причины сменить резолвер — стабильность, отсутствие подмены ответов и фильтрация рекламы.
Что делать, если DNS-сервер не отвечает?
Сравнить ответ своего резолвера и публичного: dig A example.com против dig A example.com @1.1.1.1. Если публичный отвечает — прописать другой резолвер и сбросить локальный кэш. Если не отвечает никто — проблема в домене: проверяйте делегирование, срок регистрации и авторитативные серверы.
Нужны ли NS-серверы у двух разных провайдеров?
Для проекта, чей простой стоит денег, — да. Два сервера одного оператора отказывают вместе, и после истечения кэша домен исчезает целиком. Разные операторы в разных сетях снимают эту единую точку отказа.
Чеклист
- Знаете, какой резолвер использует ваше устройство, и умеете проверить это одной командой.
- В настройках прописаны два адреса от разных операторов, а не пара от одного.
- NS-серверы домена размещены у двух независимых провайдеров.
- Glue-записи у регистратора актуальны, если NS живут внутри самого домена.
- Значения TTL осознанны: 300 секунд перед переездом, обычные значения — после.
- Serial в SOA одинаков на всех авторитативных серверах — проверено через
dig +nssearch. - Файл hosts не содержит забытых тестовых строк.
- Дата окончания регистрации домена известна, продление не завязано на один почтовый ящик.
- Если включён DNSSEC — DS-запись у регистратора соответствует ключам на DNS-хостинге.
- Настроен мониторинг NS и ключевых записей: о сбое DNS вы узнаёте из уведомления, а не от клиентов.