Проверка DNS

Бесплатная проверка DNS-записей для любого домена, хоста или IP: все записи прямо с DNS-серверов домена, а рядом — то, что хранится в кэше Google и Cloudflare, чтобы вы видели, когда изменение дошло до всех.

Обновлено: 21 октября 2026 г.

Источники: авторитативные DNS-серверы домена, найденные начиная с корневого сервера · Google Public DNS · Cloudflare 1.1.1.1

Домен, хост, URL, email или IP-адрес3 источника, запрос заново

Домен, хост, URL, адрес почты или IP. Каждая проверка заново опрашивает серверы: ничего не берётся из нашего кэша.

Тип записи

Попробуйте

Как мы проверяем 4 шага · около 1 с

Корень13 корневых серверов
TLDсерверы реестра
DNS-серверсерверы самого домена
Ответвсе типы записей
Google8.8.8.8
Cloudflare1.1.1.1

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

Что показывает проверка DNS

Проверка DNS (DNS lookup) запрашивает у системы доменных имён всё, что в ней хранится для имени: IP-адреса сайта (A и AAAA), его почтовые серверы (MX), DNS-серверы (NS), текстовые записи (TXT) и не только. Эта проверка обращается сразу к трём источникам: к собственным авторитативным DNS-серверам домена, где хранятся актуальные данные, и к двум самым загруженным публичным резолверам в мире — Google Public DNS и Cloudflare 1.1.1.1, — которые отдают копии из кэша миллионам людей.

Если ответы расходятся, вы нашли обычную причину, по которой изменение в DNS «не работает»: у резолвера осталась старая запись, и он будет отдавать её, пока не истечёт TTL записи. Результат покажет, у какого именно резолвера, что он ещё отдаёт и сколько осталось до обновления.

Проверка DNS: записи с DNS-серверов домена рядом с кэшем Google и Cloudflare, путь от корня и DNSSEC — Проверка DNS для github.com: путь от корня, все типы записей и то, что отдают Google и Cloudflare. Выберите номер, чтобы узнать, что показывает каждая часть.

Типы DNS-записей с пояснениями

Зона домена содержит записи разных типов, и у каждой есть имя, TTL и значение. Вот те, что показывает проверка DNS-записей:

Тип	Что содержит	Пример значения
A	IPv4-адрес имени: куда подключаются браузеры.	203.0.113.20
AAAA	IPv6-адрес имени.	2001:db8::20
CNAME	Псевдоним: это имя на самом деле другое имя, и проверять нужно его. Не может соседствовать с другими записями, поэтому её нельзя создать на корне домена.	www.example.com → example.com
MX	Почтовый сервер домена с приоритетом: первым пробуется наименьшее число. Единственная MX-запись с 0 и «.» означает, что домен не принимает почту.	10 mail.example.com
NS	DNS-серверы, на которых хранятся записи домена.	ns1.example.net
TXT	Произвольный текст: SPF, DMARC и DKIM для почты, а также токены, которые подтверждают домен для Google, Microsoft и других.	v=spf1 include:_spf.example.net -all
SOA	Начальная запись зоны (start of authority): её основной сервер, контакт, серийный номер и таймеры обновления, повтора, истечения и негативного кэширования.	ns1.example.com hostmaster.example.com 2026102001 7200 3600 1209600 300
CAA	Какие центры сертификации могут выпускать сертификаты для домена.	0 issue "letsencrypt.org"
HTTPS	Как подключаться ещё до первого запроса: поддержка HTTP/3, порты и подсказки адресов. Её запрашивают Chrome, Firefox и системы Apple.	1 . alpn=h3,h2
SRV	Где работает сервис (приоритет, вес, порт, хост), под именами вроде _sip._tcp.	10 5 5060 sip.example.com
PTR	Имя за IP-адресом: обратный DNS.	20.113.0.203.in-addr.arpa → host.example.com
DSDNSKEY	DNSSEC: открытые ключи зоны (DNSKEY) и их отпечаток в родительской зоне (DS), которые связывают подписи в цепочку до корня.	2371 13 2 3299…

Как работает DNS-запрос?

Ваше устройство не ищет по всему интернету. Оно спрашивает один резолвер — обычно вашего провайдера или публичный, например Google или Cloudflare, — а резолвер идёт по перенаправлениям вниз по имени, пока не ответит сервер, у которого есть ответ:

1
Запрос к корневому серверу
Если в кэше ничего нет, резолвер начинает с одного из 13 корневых серверов, от a до m, которыми управляют 12 организаций. Корень не знает example.com, но знает, кто обслуживает .com. Загруженный резолвер это уже знает и пропускает этот шаг.
2
Перенаправление к TLD
Серверы .com тоже не хранят записи example.com. Они направляют резолвер к собственным DNS-серверам домена — тем, что указаны в его NS-записях.
3
Авторитативный ответ
DNS-серверы домена отвечают с установленным флагом AA (authoritative answer): это запись в том виде, в каком её опубликовал владелец.
4
Кэширование на время TTL
Резолвер хранит ответ столько, сколько указано в TTL, и отдаёт ту же копию с уменьшающимся TTL всем, кто спрашивает, пока это время не истечёт.

Этот инструмент сам проходит этот путь из сети Cloudflare, поэтому вы видите каждый шаг. Затем он спрашивает Google и Cloudflare, что хранится у них в кэше.

Путь от корня

Кореньa.root-servers.net16 ms · перенаправление: серверы .com (13)
перенаправление · glue · DS
.COMa.gtld-servers.netVerisign · 150 ms · перенаправление: ns1–ns2.example.com
перенаправление · glue
DNS-серверns1.example.comexample.com · 203.0.113.53 · 20 msавторитативный ответ (AA) · 11 типов по одному TCP-соединению
свежий ответ · AA
Ответ8 записей, 7 типовNOERROR · 31 мс · пустых: 4 (CNAME, HTTPS, DNSKEY, DS)

что резолверы отдают сейчас
Google Public DNS8.8.8.8те же записи · самая старая копия обновится через 2:58
Cloudflare DNS1.1.1.1те же записи · самая старая копия обновится через 4:04

Тот же путь, каким его рисует результат: проверка example.com

Почему я всё ещё вижу старую DNS-запись?

Потому что её закэшировал резолвер. У каждой записи есть TTL (time to live, время жизни) в секундах, и резолвер, получивший запись, отдаёт свою копию, пока это время не истечёт, а потом спрашивает снова. Изменение записи у вашего DNS-хостинга сразу меняет авторитативный ответ; резолверы, у которых уже есть старая запись, хранят её до истечения срока.

Поэтому изменение занимает столько, сколько TTL старой записи, а не фиксированные 24–48 часов, и часто меньше: TTL — это максимум, а Google Public DNS хранит записи не дольше примерно шести часов. Отсутствующая запись тоже кэшируется: ответ «такого имени нет» или «нет записи этого типа» хранится в течение меньшего из двух значений — TTL записи SOA и её последнего поля, MINIMUM. Кэшируется даже сбой — на срок до 5 минут.

Что можно сделать

Проверьте авторитативный ответ здесь. Если собственные DNS-серверы домена показывают новое значение, изменение внесено; отстают только кэши.
Снизьте TTL перед запланированным изменением — как минимум за один старый TTL, чтобы кэши быстро избавились от старого значения. Потом поднимите его обратно.
Попросите Google и Cloudflare сбросить копию: у обоих есть публичная страница, которая обновляет имя в их кэше (Google, Cloudflare).
Очистите кэш компьютера: в Windows выполните ipconfig /flushdns.

Авторитативныйns1.example.com · флаг AA
Собственный DNS-сервер домена. Его ответ — это текущая запись: измените её здесь, и остальные подтянутся.
Из кэша8.8.8.8 · TTL уменьшается
Копия резолвера, которую он отдаёт, пока не истечёт TTL. Именно её видит большая часть мира, и поэтому кажется, что изменение «не работает».
Ваш собственный кэшваш компьютер · ваш роутер
Ваш компьютер и роутер тоже хранят копии. Очистка сбрасывает первую; копия роутера истечёт сама.

nslookup и dig: команды для проверки DNS

Те же проверки из терминала: nslookup есть в Windows, macOS и Linux, dig — в macOS и большинстве систем Linux, а Resolve-DnsName — в PowerShell в Windows. Результат выше даёт команды именно для вашей проверки.

Что проверить	nslookup	dig
A-записи	nslookup example.com	dig example.com
Почтовые серверы	nslookup -type=MX example.com	dig example.com MX
Текстовые записи	nslookup -type=TXT example.com	dig example.com TXT
Запрос к одному резолверу	nslookup example.com 8.8.8.8	dig @8.8.8.8 example.com
Обратный DNS	nslookup 8.8.8.8	dig -x 8.8.8.8
Только значения	—	dig +short example.com
Путь от корня	—	dig +trace example.com

«Non-authoritative answer» (в русской Windows — «Не заслуживающий доверия ответ») в выводе nslookup означает, что ответ пришёл от резолвера, а не от собственных DNS-серверов домена. Чтобы получить авторитативный ответ, укажите в качестве сервера один из DNS-серверов домена: nslookup example.com ns1.example.net.

ANY не означает «все записи»: сервер может ответить одним типом или заглушкой с текстом «RFC8482», а 1.1.1.1 такие запросы отклоняет. Этот инструмент запрашивает каждый тип отдельно. dig, который поставляется с macOS, не знает записей HTTPS: запрашивайте вместо них TYPE65.

Ошибки DNS: NXDOMAIN, SERVFAIL и REFUSED

Каждый ответ DNS содержит код ответа. Пустой результат — не всегда ошибка, а код подсказывает, где искать:

Ответ	Что значит	Что проверить
NOERROR	Имя существует, и записи этого типа получены.	Ничего; сравните значения.
NODATA	Имя существует, но записи этого типа у него нет: это NOERROR с пустым ответом, а не отдельный код.	Добавьте запись у DNS-хостинга, если она должна быть.
NXDOMAIN	Имени не существует вовсе, как и любых имён под ним.	Написание; что домен зарегистрирован и не истёк, а для поддомена — что его создали.
SERVFAIL	Резолвер не смог получить корректный ответ: отказали DNS-серверы или не прошла проверка DNSSEC.	Вердикт DNSSEC и то, что DNS-серверы домена отвечают.
REFUSED	Сервер не отвечает на этот вопрос: он не авторитативен для домена и не выполняет для вас рекурсию.	Что NS-записи указывают на серверы, где размещена зона.
Timeout	Ответа нет вовсе.	Не упали ли DNS-серверы, не заблокированы ли они и верен ли их адрес.

DNSSEC: защищён, не подписан или неисправен?

DNSSEC подписывает записи зоны, чтобы резолвер мог доказать, что они не подделаны. Родительская зона публикует запись DS — отпечаток ключа домена, а домен публикует свои ключи в записях DNSKEY, так что подписи выстраиваются в цепочку до корня. И Google Public DNS, и Cloudflare 1.1.1.1 проверяют DNSSEC.

DNSSEC: защищён
Защищён
Зона подписана, и валидирующий резолвер Google проверил подписи: его ответ содержал бит AD (authenticated data) — его подтверждение того, что ответ прошёл проверку.
DNSSEC: не подписан
Не подписан
В родительской зоне нет записи DS: зона не подписана. Она разрешается как обычно; просто её ответы нельзя доказать подлинными.
DNSSEC: неисправен
Неисправен
Проверка не проходит, поэтому валидирующие резолверы отвечают SERVFAIL и домен недоступен для их пользователей, хотя с отключённой проверкой данные на месте. Типичная причина — DS в родительской зоне, не совпадающий ни с одним ключом зоны, после переезда к новому DNS-хостингу.

Почта в DNS: проверка MX- и TXT-записей

Почта для домена идёт на его серверы MX, а получатели проверяют TXT-записи, прежде чем ей доверять: SPF перечисляет серверы, которым разрешено отправлять почту от имени домена, в одной записи, которая может вызвать не более 10 DNS-запросов; DMARC в _dmarc говорит, что делать с письмами, не прошедшими проверку, и если у поддомена его нет, он ищется выше по имени (RFC 9989, с мая 2026 года); MTA-STS в _mta-sts просит отправителей доставлять почту по TLS. Результат читает их все и называет почтового провайдера, стоящего за MX-хостами.

Для более глубокой проверки отдельной записи используйте проверку MX, проверку SPF и проверку DMARC.

API для проверки DNS

Два бесплатных эндпоинта с CORS для браузеров. /api/dns-query запрашивает один тип у одного резолвера и сохраняет поля нашего прежнего API; /api/dns-lookup отдаёт полную проверку этой страницы потоком строк JSON.

Один тип от одного резолвера

$ curl -X POST https://dnsrobot.net/api/dns-query \
    -H "Content-Type: application/json" \
    -d '{"domain": "google.com", "recordType": "MX", "dnsServer": "8.8.8.8"}'
{
  "status": "success", "responseTime": 4,
  "resolvedIPs": ["10 smtp.google.com"],
  "dnsServer": "8.8.8.8", "recordType": "MX", "domain": "google.com", …
}

Полная проверка потоком

$ curl "https://dnsrobot.net/api/dns-lookup?domain=google.com"
{"t":"start","name":"google.com","kind":"name","types":["A","AAAA","CNAME","MX",…]}
{"t":"hop","hop":{"zone":".","server":"a.root-servers.net","ms":16,"outcome":"referral",…}}
{"t":"answers","source":"google","server":"dns.google","sets":[{"type":"A",…}]}
{"t":"answers","source":"auth","server":"ns1.google.com","sets":[…]}
{"t":"dnssec","verdict":"unsigned",…}
{"t":"done","ms":57}

Вопросы о проверке DNS

Что такое проверка DNS?

Проверка DNS (по-английски DNS lookup, в обиходе — «проверка днс») запрашивает у системы доменных имён записи имени: IP-адреса сайта, его почтовые серверы, DNS-серверы, текстовые записи и не только. Ваше устройство выполняет такой запрос каждый раз, когда вы открываете сайт. Этот инструмент показывает все типы записей сразу — с собственных DNS-серверов домена и из публичных резолверов Google и Cloudflare.

Как проверить DNS-записи домена?

Введите домен в поле выше и выберите «Все»: инструмент запросит у авторитативных DNS-серверов домена каждый тип записи (A, AAAA, CNAME, MX, NS, TXT, SOA, CAA, HTTPS, DNSKEY и DS) и покажет рядом с каждым копию из кэша Google и Cloudflare. Выберите один тип, чтобы увидеть только его, или скопируйте команды dig и nslookup, чтобы выполнить ту же проверку самостоятельно.

Можно ли выполнить nslookup онлайн?

Да: эта страница и есть nslookup онлайн, только подробнее. nslookup спрашивает у одного сервера один тип записи; здесь вы получаете все типы сразу, авторитативный ответ и кэш двух резолверов, TTL и путь от корня. Результат также показывает точные команды nslookup, dig и Resolve-DnsName для вашей проверки, чтобы запустить их в терминале.

Сколько времени обновляются DNS-записи после изменения?

Столько, сколько TTL старой записи. DNS-серверы домена сразу отдают новое значение, но резолверы, закэшировавшие старое, хранят его, пока не истечёт TTL: 300 секунд — это пять минут, 86400 — сутки. Результат показывает, сколько осталось копиям Google и Cloudflare. Снизьте TTL за день до запланированного изменения.

Что значит «Non-authoritative answer» (не заслуживающий доверия ответ)?

Это ответ из кэша резолвера, а не от собственных DNS-серверов домена. nslookup пишет «Non-authoritative answer» (в русской Windows — «Не заслуживающий доверия ответ») всякий раз, когда вы спрашиваете резолвер, то есть почти всегда. Обычно такой ответ верен, но может быть устаревшим, пока не истечёт его TTL. Авторитативный ответ приходит от DNS-серверов зоны с флагом AA; этот инструмент получает его, спускаясь от корня.

Что означает NXDOMAIN?

NXDOMAIN означает, что такого имени в DNS нет. Для домена проверьте написание и то, что он зарегистрирован и не истёк: его статус покажет проверка WHOIS. Для поддомена это значит, что запись так и не создали или удалили. Имя, которое существует, но не имеет записи запрошенного типа, получает вместо этого NOERROR с пустым ответом — его часто называют NODATA.

Что означает SERVFAIL?

SERVFAIL означает, что резолвер не смог получить корректный ответ. Либо DNS-серверы домена не работают или неправильно настроены, либо не прошла проверка DNSSEC, и тогда валидирующие резолверы, такие как Google и Cloudflare, отвергают ответ. Этот инструмент различает эти два случая: если данные приходят с отключённой проверкой, вердикт DNSSEC — «Неисправен».

Что такое TTL в DNS?

TTL (time to live, время жизни) — это сколько секунд резолвер может хранить запись в кэше, прежде чем спросить снова. У каждой записи он свой. Короткий TTL, например 300 секунд, позволяет изменениям быстро распространяться, но требует больше запросов; длинный, например 86400 секунд (сутки), дешевле, но изменения идут медленно. Копии в кэше ведут обратный отсчёт, поэтому TTL у Google и Cloudflare здесь меньше.

Как сделать обратный DNS-запрос по IP?

Введите IP-адрес в поле выше. Инструмент превратит его в обратное имя (8.8.8.8 становится 8.8.8.8.in-addr.arpa), запросит запись PTR, а затем проверит имя в прямом направлении: если оно разрешается обратно в тот же IP, обратный DNS подтверждён — именно это проверяют почтовые серверы. Из терминала: nslookup 8.8.8.8 или dig -x 8.8.8.8.

Как узнать DNS-серверы домена?

Проверьте домен в поле выше и посмотрите NS-записи или путь справа: там видны DNS-серверы, на которые ссылается TLD домена, и отметка, если собственные NS-записи домена указывают другие. Результат также называет компанию, которая их обслуживает, например Cloudflare, AWS Route 53 или регистратора домена.

Как проверить TXT-запись домена?

Введите домен в поле выше и выберите тип TXT или «Все». Результат покажет каждую TXT-запись и объяснит её простым языком: каким серверам SPF разрешает отправлять почту и сколько из 10 DNS-запросов он тратит, какому сервису принадлежит токен подтверждения. DMARC и MTA-STS он читает в разделе «Почта». Из терминала: nslookup -type=TXT example.com или dig example.com TXT.