DNS: тихий убийца, о котором никто не думает до аварии.

Сервер работает. Приложение отвечает. База данных живая. Но сайт недоступен уже два часа, и служба поддержки захлёбывается в тикетах. Вы смотрите в мониторинг — всё зелёное. Смотрите в логи nginx — тишина, запросов нет вообще. И тут доходит: проблема не в сервере. Проблема в том, что до сервера никто не добирается.

DNS. Опять DNS.

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

КАК РАБОТАЕТ DNS — БЕЗ ВОДЫ

DNS — это телефонная книга интернета. Вы знаете имя, DNS знает номер. Браузер знает домен, DNS говорит IP.

Когда пользователь вводит example.com, начинается цепочка:

1. Браузер смотрит в локальный кэш. Если уже резолвил недавно — берёт оттуда.
2. Если нет — спрашивает у системного резолвера (роутер, DNS провайдера, или 1.1.1.1 если вы его прописали).
3. Резолвер не знает — идёт к корневым серверам. Их 13 групп, они знают всё верхнего уровня.
4. Корневые серверы говорят: «За .com отвечают вот эти серверы.»
5. TLD-серверы .com говорят: «За example.com отвечают вот эти nameserver’ы.»
6. Nameserver’ы домена возвращают финальный IP.
7. Браузер наконец-то подключается к серверу.

Весь этот квест занимает 20–150 миллисекунд. При первом запросе. Потом ответ кэшируется.

Вот здесь появляется TTL — Time To Live. Это число секунд, на которое ответ оседает в кэше. TTL = 3600 означает, что час все будут получать закэшированный ответ, не дёргая ваши nameserver’ы. Звучит как оптимизация — и это правда. Но именно TTL становится главной проблемой в момент, когда нужно что-то срочно изменить.

ТИПЫ DNS-ЗАПИСЕЙ: ЧТО ЗА ЧТО ОТВЕЧАЕТ

Большинство знает только A-запись и на этом останавливается. Это как знать только первую передачу — ехать можно, но медленно и неправильно.

A-запись связывает домен с IPv4-адресом. Самая базовая. example.com → 192.0.2.1 (IP зарезервирован для документации по RFC 5737).

AAAA-запись — то же самое для IPv6. В 2026 году игнорировать IPv6 — это намеренно отрезать часть аудитории.

CNAME-запись — псевдоним. www.example.com указывает на example.com, а не напрямую на IP. Удобно: меняете один A-record, все CNAME автоматически подхватывают. Важный нюанс: CNAME нельзя ставить на корневой домен (apex). Только на поддомены. Иначе сломаете MX и NS. Некоторые DNS-провайдеры обходят это через собственные расширения — ALIAS или ANAME — но это уже их внутренняя магия.

MX-запись говорит, куда доставлять почту для домена. Без неё письма просто теряются где-то в интернете. У MX есть приоритет — чем меньше число, тем выше приоритет. Несколько MX-записей с разными приоритетами дают резервирование почты.

TXT-запись — свалка всего текстового. Верификация домена у Google, AWS, Cloudflare. SPF, DKIM, DMARC. Всё это живёт в TXT. Неструктурированно, зато гибко.

NS-запись указывает, какие nameserver’ы отвечают за зону. Это самая критичная запись с точки зрения безопасности: если злоумышленник изменит NS — он получает полный контроль над вашим DNS.

PTR-запись — обратная DNS. IP → домен. Почтовые серверы обязательно проверяют PTR при получении письма. Нет PTR — письмо в спам или отклонено. Настраивается не у регистратора, а у хостинг-провайдера.

CAA-запись ограничивает, какие центры сертификации могут выпускать SSL-сертификаты для домена. Одна строчка — и посторонний CA не выпустит сертификат на ваш домен, даже если докажет контроль над доменом другими методами.

SRV-запись описывает конкретный сервис: протокол, хост, порт, приоритет. Используется в VoIP, корпоративных мессенджерах, некоторых игровых серверах.

SOA — Start of Authority. Служебная запись с метаданными зоны: основной nameserver, email администратора, серийный номер для синхронизации secondary серверов. Трогают редко, но знать нужно.

КАК DNS УБИВАЕТ СЕРВИСЫ — РЕАЛЬНЫЕ СЦЕНАРИИ

Это не теория. Это то, что происходит регулярно.

DNS-провайдер лёг. Ваш сервер в идеальном состоянии. Но DNS-зона хостится у регистратора, у которого ночью случился сбой. Никто не может зарезолвить домен. Для пользователей сайт мёртв — хотя он живой и ждёт соединений. В октябре 2021 года ошибка конфигурации BGP положила Facebook, Instagram и WhatsApp более чем на семь часов. Технически серверы работали. Но BGP-маршруты до DNS-серверов Facebook были отозваны, DNS перестал отвечать, и миллиарды пользователей увидели пустой экран.

TTL не снизили перед миграцией. Переезжаете на новый сервер. TTL у A-записи — 86400 (сутки, как по умолчанию у многих регистраторов). Вы обновили запись, но половина мира ещё 24 часа ходит на старый IP. Если старый сервер уже выключен — для этой половины вас нет. Решение простое и известное: за двое суток до миграции снижаете TTL до 300. После переезда — возвращаете обратно.

Нет автоматического failover. Основной сервер упал. Резервный поднят и ждёт. Но DNS всё ещё указывает на мёртвый IP, потому что переключение настраивали «потом». «Потом» наступило в пятницу вечером.

Угон домена. Злоумышленник получает доступ к аккаунту регистратора — через слитый пароль, фишинг, или уязвимость в панели. Меняет NS-записи на свои. Теперь он управляет вашим DNS. Может перенаправить трафик, выпустить SSL-сертификат на ваш домен, перехватить почту. Ваши серверы живы, ваш код не тронут, но фактически сервис под его контролем. В 2019 году именно так работала кампания Sea Turtle — акторы с предположительно иранской аффилиацией взламывали регистраторов и DNS-провайдеров, после чего перехватывали трафик правительств и телекомов в более чем 13 странах. Cisco Talos назвала это «первым публично подтверждённым случаем компрометации самого DNS-регистратора».

Отравление кэша. Атакующий подменяет DNS-ответы в кэше резолвера. Пользователи получают поддельный IP и идут на сервер злоумышленника, думая что на ваш. Атака известна с 1990-х. Решается DNSSEC — но многие до сих пор не включили.

Subdomain takeover. Удалили сервис — S3 bucket, Heroku приложение, GitHub Pages — но CNAME-запись в DNS забыли убрать. Запись висит и указывает на несуществующий ресурс. Злоумышленник регистрирует этот ресурс на своё имя, и ваш поддомен теперь показывает его контент. Атака тривиальная, обнаруживается сканерами автоматически. Проверяется просто: найдите все CNAME-записи в зоне и убедитесь, что каждая из них реально куда-то ведёт.

DNS amplification. Ваш сервер с открытым резолвером может стать оружием в чужих руках. Работает так: атакующий хочет положить жертву, но вместо прямой атаки использует ваш DNS как усилитель. Отправляет маленький запрос (60 байт) с поддельным IP жертвы — DNS работает по UDP, где нет handshake и IP легко подделать. Ваш резолвер честно отвечает большим пакетом (3000+ байт) — но не атакующему, а жертве, потому что именно её IP стоит в запросе.

Вот откуда коэффициент усиления до 50x: соотношение размера ответа к запросу. Атакующий потратил 1 Мбит своего трафика — жертва получила 50 Мбит. Особенно большие ответы дают запросы типа ANY и TXT-записи для доменов с DNSSEC — криптографические подписи сильно раздувают размер пакета.

Если у вас открытый резолвер — ваш сервер участвует в атаках на чужие ресурсы. Хостинг получает абузы, репутация IP падает, канал забивается чужим трафиком. Миллионы открытых резолверов по всему интернету регулярно используются именно так. Проверьте есть ли у вас открытый резолвер:

dig @ВАШ_IP example.com

Если ответил — закройте рекурсию для внешних адресов в настройках bind/unbound, или заблокируйте порт 53 на файрволе для всех кроме своих сетей.

Открытый резолвер — это DNS-сервер, который отвечает на рекурсивные запросы от любого IP в интернете, а не только от своих клиентов. Нормальный резолвер обслуживает только свою сеть. Открытый — отвечает всем подряд, что и делает его оружием для amplification-атак.

Закрывается тремя способами. Через nftables — самый простой, не требует трогать DNS-сервер:

nft add rule inet filter input udp dport 53 \
    ip saddr != { 127.0.0.1, 10.0.0.0/8, 192.168.0.0/16 } drop

Через bind — запретить рекурсию на уровне конфига:

# /etc/named.conf
options {
    recursion yes;
    allow-recursion { 127.0.0.1; 10.0.0.0/8; };
};

Через unbound:

# /etc/unbound/unbound.conf
server:
    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.1/32 allow
    access-control: 10.0.0.0/8 allow

Если вы не запускаете публичный DNS-сервер — закройте порт 53 на файрволе для всех внешних адресов и не думайте об этом больше.

О ЧЁМ ОБЫЧНО НЕ ПИШУТ

DNSSEC существует с 2005 года. Добавляет цифровую подпись к DNS-ответам — резолвер может проверить, что ответ настоящий, а не подделка. В 2026 году значительная часть доменов всё ещё работает без DNSSEC. Аргументы «сложно настроить» давно устарели: Cloudflare включает DNSSEC одной кнопкой.

DNS передаётся открытым текстом. Всегда. Ваш провайдер видит каждый домен, который вы резолвите. Корпоративный файрвол — тоже. Любой, кто сидит между вами и резолвером, видит полный список доменов — без всякого взлома, просто пассивным прослушиванием трафика.

DNS over TLS (DoT) и DNS over HTTPS (DoH) решают это по-разному, но с одной целью — зашифровать DNS-запрос так, чтобы его не мог прочитать никто по дороге.

Почему это важно? DNS — единственный протокол, который нельзя заблокировать. Порт 53 открыт везде — иначе не работает ничего. Именно поэтому незашифрованный DNS — это дыра, которую все игнорируют.

Провайдер, хостинг, корпоративный файрвол, или просто кто-то в той же сети видит каждый домен к которому обращается ваш сервер. Запросы к внешним API, к репозиториям пакетов, к системам мониторинга — всё это разведка без единого взлома, просто пассивным прослушиванием.

Незашифрованный DNS можно подменить по дороге. Пакет выглядит как легитимный DNS-ответ — резолвер принял, пользователь пошёл не туда. Именно так работает man-in-the-middle на DNS. С DoT/DoH подмена невозможна: соединение зашифровано и аутентифицировано сертификатом.

И наконец: провайдеры и корпоративные сети блокируют домены именно через DNS. DoH обходит это, потому что запрос неотличим от обычного HTTPS-трафика.

DoT работает на порту 853 и оборачивает обычный DNS в TLS-соединение. Чисто и понятно, но легко блокируется файрволом — достаточно закрыть порт 853.

DoH работает на порту 443 — том же, что и обычный HTTPS. DNS-запрос выглядит как обычный веб-запрос. Заблокировать его, не сломав весь HTTPS, практически невозможно.

Браузеры — Firefox, Chrome, Edge — поддерживают DoH из коробки. Firefox по умолчанию использует Cloudflare 1.1.1.1, игнорируя системный DNS. Chrome и Edge работают иначе: они обновляют системный DNS до DoH если провайдер его поддерживает, но системный резолвер не игнорируют. На сервере нужно настраивать явно в любом случае.

На Linux-сервере DoT проще всего включить через systemd-resolved:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net
DNSOverTLS=yes

Или через stubby для более гибкой настройки:

apt install stubby          # Debian/Ubuntu
dnf install stubby          # RHEL/Fedora

# /etc/stubby/stubby.yml — основные параметры:
# resolution_type: GETDNS_RESOLUTION_STUB
# dns_transport_list: GETDNS_TRANSPORT_TLS
# tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
# upstream_recursive_servers: 1.1.1.1, 9.9.9.9

После этого stubby слушает на 127.0.0.1:53 и проксирует все запросы через TLS. В /etc/resolv.conf прописываете nameserver 127.0.0.1 — и весь системный DNS идёт зашифрованным.

DNS-туннелинг — передача произвольных данных внутри DNS-пакетов. Файрвол закрывает всё, кроме DNS на порт 53. Но DNS-трафик разрешён — иначе ничего не работает. И именно через него malware передаёт команды и эксфильтрирует данные. Обнаружить сложно: DNS-запросы выглядят нормально, просто их очень много и они странно длинные.

Регистратор и DNS-провайдер — разные вещи. Вы купили домен у регистратора, и он же хостит вашу DNS-зону по умолчанию. Это удобно, но создаёт единую точку отказа. Если регистратор лежит — лежит и DNS. Разумнее: домен у регистратора, DNS-зона у Cloudflare или другого специализированного провайдера с нормальным SLA.

Anycast — когда один IP-адрес обслуживается из множества точек по всему миру одновременно. Cloudflare, Google Public DNS, и другие крупные DNS-провайдеры работают именно так. Запрос из Сингапура идёт в ближайший датацентр, а не через Атлантику. Резолвинг занимает единицы миллисекунд. Сеть Cloudflare в 2026 году охватывает 300+ городов в 100+ странах. Собственный nameserver на одном VPS в Германии такого не обеспечит.

Zone transfer (AXFR) — механизм синхронизации DNS-зоны между primary и secondary nameserver’ами. Нужная вещь, но если не ограничить по IP — любой желающий скачает полный список всех ваших DNS-записей одной командой. Все поддомены, все внутренние сервисы, все IP — готовая карта инфраструктуры для разведки перед атакой. Проверяется так:

dig @ns1.example.com example.com AXFR

Если вернул записи — у вас открытый zone transfer. В настройках nameserver’а ограничьте AXFR только IP ваших secondary серверов.

Split-horizon DNS — когда один и тот же домен возвращает разные ответы в зависимости от того, кто спрашивает. Внутри сети db.example.com → 10.0.0.5 (внутренний IP). Снаружи — NXDOMAIN, как будто такого домена не существует. Используется чтобы скрыть внутреннюю структуру инфраструктуры от внешнего мира: снаружи видны только публичные сервисы, внутренние — невидимы. Реализуется через bind views или через отдельный внутренний DNS-сервер с собственными зонами.

КАК НАСТРОИТЬ DNS ПРАВИЛЬНО

TTL — первое, о чём думают в последнюю очередь. Правило простое: для стабильных записей держите 3600. За 48 часов до любых изменений снижайте до 300. После завершения — возвращайте. Это единственный способ быстро переключить трафик без многочасового ожидания.

Два nameserver’а — минимум, не оптимум. Один NS — единая точка отказа. Регистраторы требуют минимум два, но лучше больше, в разных сетях и географических регионах. Cloudflare даёт два NS бесплатно — но за счёт anycast они обслуживаются из 300+ точек по всему миру, что надёжнее чем четыре обычных NS на разных VPS.

2FA у регистратора — не опция. Угон домена через скомпрометированный аккаунт регистратора происходит регулярно. 2FA закрывает большинство таких случаев. Если у вашего регистратора нет 2FA — смените регистратора.

CAA-запись — одна строчка, которая закрывает целый класс атак. Пример:

example.com. CAA 0 issue "letsencrypt.org"

Теперь только Let’s Encrypt может выпустить сертификат на ваш домен. Любой другой CA откажет — даже если кто-то докажет контроль над доменом другими способами.

SPF, DKIM, DMARC — обязательная тройка если есть почта. SPF говорит, с каких серверов разрешена отправка. DKIM подписывает письма криптографически. DMARC указывает, что делать с письмами, которые не прошли проверку — отклонить, поместить в карантин, или просто залогировать. Без всего этого ваши письма летят в спам, а злоумышленники могут рассылать фишинг от имени вашего домена.

PTR-запись настройте если гоняете почту через свой сервер. Проверяется так:

dig -x ВАШ_IP +short

Должно вернуть имя вашего почтового сервера. Настраивается в панели хостинг-провайдера, не у регистратора.

Мониторинг DNS-записей — то, о чём забывают все. Мониторинг сервера настроен. Мониторинг SSL-сертификата настроен. А вот что A-запись домена внезапно изменилась — никто не узнает, пока пользователи не начнут жаловаться. UptimeRobot, Zabbix, или любой специализированный DNS-монитор решают это за пять минут настройки.

Registry lock — защита домена от несанкционированного трансфера к другому регистратору. Без него достаточно получить доступ к аккаунту — и домен можно перевести за несколько часов. Registry lock требует ручного подтверждения любого трансфера через отдельный канал. Доступен у большинства крупных регистраторов, часто бесплатно. Для продакшн-доменов — обязателен.

БЫСТРЫЙ АУДИТ: ПРОВЕРЬТЕ ПРЯМО СЕЙЧАС

Откройте терминал и прогоните свой домен через несколько проверок:

# Текущие DNS-записи
dig example.com A
dig example.com MX
dig example.com NS
dig example.com CAA
dig example.com TXT

# Обратная DNS для почтового сервера
dig -x ВАШ_IP +short

# Проверка DNSSEC
dig example.com +dnssec

# Открытый резолвер — не должен отвечать
dig @ВАШ_IP example.com

# Открытый zone transfer — не должен возвращать записи
dig @ns1.example.com example.com AXFR

# Распространение изменений по миру
# dnschecker.org или whatsmydns.net

Что должно быть:
— A-запись указывает на правильный IP
— TTL разумный (не 86400 по умолчанию)
— Минимум два NS из разных сетей
— CAA-запись есть
— MX настроен, PTR совпадает с именем сервера
— SPF, DKIM, DMARC в TXT-записях
— DNSSEC включён
— 2FA у регистратора активна
— Registry lock включён
— Zone transfer закрыт для внешних IP
— Открытого резолвера нет
— Все CNAME-записи ведут на живые ресурсы
— Мониторинг DNS-записей настроен

ИТОГ

DNS решает одну задачу: привести пользователя к вашему серверу. Если DNS сломан — не важно, насколько хорош сервер. Никто до него не доберётся.

При этом DNS — одна из самых недооценённых частей инфраструктуры. Настроили при запуске, забыли. А он тем временем становится точкой отказа, вектором атаки, и источником суточных задержек при миграции.

Час на аудит. TTL, NS, CAA, SPF/DKIM/DMARC, 2FA у регистратора, мониторинг записей. Это не сложно. Это просто редко делают — до первой аварии.