Всё работает. Серверы отвечают. Контейнеры зелёные. Но пользователи пишут: "Сайт не открывается". Вы проверяете со своего ноутбука — тоже не открывается. Пингуете IP — отвечает. Что происходит? DNS перестал резолвить ваш домен. Кто-то случайно удалил A-запись, или DNS-провайдер лежит, или TTL кэш выдаёт старый IP после миграции.
DNS — это телефонная книга интернета. Если в ней нет вашего номера, вас не найдут, даже если вы дома и трубка работает. И в отличие от серверных ошибок, DNS-проблемы коварны: обычный HTTP-мониторинг их ловит, но не может объяснить причину. Вы видите "Connection timeout", а реальная проблема — в DNS. Ниже — конкретные сценарии, типы записей и подходы к мониторингу DNS как критического слоя наблюдаемости.
Почему DNS ломается чаще, чем кажется
DNS кажется простой вещью: домен → IP-адрес. Но на практике это распределённая система с кэшированием, TTL, несколькими уровнями серверов и сложными зависимостями. Вот реальные сценарии, которые ломают DNS:
Истёкший домен. Забыли продлить — регистратор ставит parking page или вовсе удаляет DNS-записи. Автоматическое продление не сработало из-за истёкшей карты. Самая обидная причина: домен стоит $12/год, а downtime обходится в тысячи.
Случайное удаление записи. Новый DevOps-инженер чистил неиспользуемые записи и зацепил продакшн A-запись. Или Terraform state рассинхронизировался и удалил записи при apply. Без мониторинга это обнаруживается через часы.
Неудачная миграция DNS-провайдера. Перенесли NS-записи на Cloudflare, но не перенесли все DNS-записи. Основной домен работает, а api.example.com — нет, потому что CNAME остался на старом провайдере.
Сбой DNS-провайдера. Даже крупные провайдеры падают. Dyn DNS attack 2016, Cloudflare incidents — когда ваш DNS-провайдер лежит, все ваши домены недоступны, независимо от состояния серверов.
TTL слишком высокий при миграции. Вы сменили IP сервера, но TTL стоял 86400 (24 часа). Половина пользователей всё ещё идёт на старый IP, где ничего нет. А вы думаете, что миграция прошла успешно.
Какие DNS-записи мониторить
A и AAAA записи
Основные записи, которые связывают домен с IP-адресом. A — для IPv4, AAAA — для IPv6. Мониторьте, что они резолвятся в правильный IP. Если IP изменился без вашего ведома — это либо DNS hijacking, либо кто-то ошибся в конфигурации. DNS-мониторинг AtomPing проверяет resolved IP при каждом цикле.
MX записи
Определяют, куда доставляется почта для вашего домена. Сломанные MX-записи = почта не доходит. Причём отправитель может не получить bounce — письмо просто уходит в void. Если вы используете Google Workspace, Microsoft 365 или собственный почтовый сервер — MX-мониторинг обязателен. Бесплатный MX Lookup покажет текущее состояние.
CNAME записи
Алиасы, которые указывают один домен на другой. Типичное использование: www.example.com → CNAME → example.com, или cdn.example.com → CNAME → d123.cloudfront.net. Если CDN сменил эндпоинт, а вы не обновили CNAME — статика перестаёт загружаться.
TXT записи (SPF, DKIM, DMARC)
Критичны для email deliverability. SPF определяет, какие серверы могут отправлять почту от имени вашего домена. DKIM подписывает письма. DMARC задаёт политику при несовпадении. Если TXT-записи удалены или изменены — ваши письма начнут попадать в спам. И вы узнаете об этом через дни, когда клиенты скажут "не получаю ваши email".
NS записи
Определяют, какие nameservers отвечают за ваш домен. Если NS-записи сменились без вашего участия — это серьёзный инцидент безопасности (возможный domain hijacking). Мониторинг NS-записей — ваш canary для обнаружения несанкционированных изменений.
DNS resolution time: скрытый фактор производительности
Каждый раз, когда пользователь заходит на ваш сайт, браузер сначала резолвит DNS. Обычно это занимает 20-50ms. Но если DNS-сервер перегружен или далеко — resolution time может вырасти до 200-500ms. Это добавляется к каждому первому запросу и напрямую влияет на TTFB.
Факторы, влияющие на DNS resolution time:
Географическое расположение DNS-серверов. Если ваши NS-серверы только в США, а пользователи в Европе — каждый resolution делает трансатлантический round-trip. Используйте Anycast DNS (Cloudflare, Route53) для минимального latency.
TTL настройки. Низкий TTL (60с) означает частые DNS-запросы. Высокий TTL (3600с) кэширует ответ, но замедляет failover. Баланс: 300-600с для продакшна, 60с перед запланированной миграцией.
Количество записей в зоне. Огромные DNS-зоны с тысячами записей могут замедлять ответ. Если у вас много поддоменов — рассмотрите делегирование подзон.
DNS monitoring + HTTP monitoring: комбинация, которая работает
DNS-мониторинг не заменяет HTTP-мониторинг — они дополняют друг друга. HTTP-проверка скажет "сайт не отвечает". DNS-проверка скажет "потому что домен не резолвится". Вместе они дают полную картину и сокращают MTTR (Mean Time to Resolution).
Типичный workflow при инциденте:
Сценарий A: HTTP ❌, DNS ✅ — Домен резолвится, но сервер не отвечает. Проблема на стороне сервера: упавший процесс, полный диск, firewall. Смотрите логи приложения.
Сценарий B: HTTP ❌, DNS ❌ — Домен не резолвится. Проблема в DNS: удалённая запись, DNS-провайдер лежит, истёкший домен. Проверяйте DNS-конфигурацию.
Сценарий C: HTTP ✅, DNS ⚠️ (wrong IP) — Домен резолвится в неправильный IP, но тот сервер тоже отвечает (старый сервер). Данные устаревшие, но пользователь видит "рабочий" сайт. Без DNS-мониторинга вы этого не поймаете.
Сценарий D: HTTP ⚠️ (slow), DNS ⚠️ (slow) — Высокий DNS resolution time вносит вклад в общий latency. Мониторинг DNS response time покажет: деградация идёт с уровня DNS, а не сервера.
Как настроить DNS-мониторинг
Настройка DNS-мониторинга в AtomPing занимает 3 минуты на домен:
Шаг 1. Создайте DNS-проверку, укажите домен и тип записи (A, MX, CNAME, TXT). Для основного домена начните с A-записи.
Шаг 2. Укажите ожидаемое значение: конкретный IP для A-записи, hostname для MX. Мониторинг будет алертить, если resolved value изменится.
Шаг 3. Настройте интервал (1-5 минут) и регионы проверки. Multi-region DNS checks покажут, если запись резолвится по-разному в разных частях мира.
Шаг 4. Подключите алерты: Slack, Telegram, email. DNS-инциденты критичны — настройте немедленное уведомление, без задержки.
DNS-мониторинг для email: не теряйте письма
Email-инфраструктура полностью зависит от DNS. Если MX-записи указывают не туда — входящая почта пропадает. Если SPF/DKIM/DMARC TXT-записи некорректны — исходящая почта попадает в спам. Проблема в том, что email-сбои проявляются медленно: вы не получите ошибку сразу, а узнаете через дни, когда клиент скажет "я отправлял вам три письма".
Минимальный набор DNS-проверок для email:
MX-запись — проверяйте, что значения совпадают с вашим email-провайдером. Для Google Workspace: aspmx.l.google.com и т.д. Используйте MX Lookup для текущей проверки.
SPF (TXT-запись) — v=spf1 include:_spf.google.com ~all. Если кто-то удалит или изменит — ваши письма пойдут в спам.
DKIM (TXT-запись) — длинная TXT-запись с публичным ключом. Если она пропадёт — подпись писем перестанет проверяться.
Безопасность DNS: мониторинг как защита от hijacking
DNS hijacking — атака, при которой злоумышленник меняет DNS-записи, чтобы перенаправить трафик на свой сервер. Это позволяет перехватывать данные, показывать фишинговые страницы или красть credentials. Атака на DNS регистратор или NS-записи — один из самых опасных векторов.
DNS-мониторинг — ваш первый рубеж обороны. Если A-запись внезапно изменилась на IP, который вам не принадлежит — мониторинг отправит алерт за минуты. Без мониторинга вы можете узнать о hijacking через часы или дни, когда пользователи начнут жаловаться.
Дополнительные меры: включите DNSSEC на уровне регистратора (защита от подмены ответов), используйте registrar lock (защита от несанкционированного трансфера), и мониторьте NS-записи — изменение nameservers без вашего участия — красный флаг.
Чек-лист DNS-мониторинга
1. A/AAAA-запись основного домена — проверка каждые 1-3 минуты, ожидаемый IP зафиксирован.
2. A-запись API-домена (если отдельный) — то же, что для основного.
3. MX-записи — проверка, что email routing корректен.
4. SPF TXT-запись — защита от попадания в спам.
5. NS-записи — канарейка для обнаружения hijacking.
6. Auto-renewal включён для домена — не дайте ему истечь.
7. TTL установлен в 300-600с — разумный баланс кэширования и гибкости.
8. Registrar lock включён — защита от несанкционированного трансфера.
DNS — невидимый, но критический компонент вашей инфраструктуры. Он работает тихо и ломается тихо. Единственный способ гарантировать, что ваши домены резолвятся правильно — мониторить DNS активно и непрерывно. Три минуты на настройку сейчас — и вы навсегда исключаете целый класс инцидентов, которые невозможно диагностировать обычным HTTP-мониторингом.
FAQ
What is DNS monitoring?
DNS monitoring continuously checks that your domain names resolve correctly to the right IP addresses. It verifies DNS record accuracy (A, AAAA, CNAME, MX, TXT), measures resolution time, and alerts you when records change unexpectedly or resolution fails. Without DNS monitoring, a misconfigured record can make your entire site unreachable even while servers are running perfectly.
Why does DNS monitoring matter if my site is already monitored?
HTTP monitoring checks your server — DNS monitoring checks the path to your server. If DNS breaks, HTTP checks fail too, but the root cause is invisible. DNS monitoring tells you immediately: 'The domain isn't resolving' vs 'The server is down.' This distinction saves 30-60 minutes of debugging during incidents.
How often should I check DNS records?
Every 1-5 minutes for critical domains. DNS changes propagate gradually, so frequent checks catch propagation issues early. For secondary domains or internal services, every 5-10 minutes is sufficient. AtomPing checks DNS as part of every monitoring cycle.
What DNS records should I monitor?
At minimum: A records (IPv4 address), AAAA records (IPv6), MX records (email delivery), and CNAME records (aliases). Also monitor TXT records if you rely on SPF/DKIM/DMARC for email authentication, and NS records to verify your nameservers haven't changed.
Can DNS issues cause email delivery problems?
Yes, absolutely. MX records direct email to your mail servers. If MX records are wrong, deleted, or pointing to a dead server, incoming email silently disappears or bounces. SPF/DKIM TXT records affect deliverability — if they're misconfigured, your outgoing emails land in spam. DNS monitoring catches these before you lose important messages.
What is DNS propagation and why does it cause outages?
When you change a DNS record, the update doesn't happen instantly worldwide. Each DNS resolver caches records based on the TTL (Time to Live) value. Propagation is the time it takes for all resolvers globally to pick up the new record. During propagation, some users see the old IP, others the new one. If you cut over too fast, users hitting the old IP get errors.