Как работает DNS в Linux: коротко, по делу и с практикой

За годы работы я понял одну простую истину: пользователи приходят к тебе с проблемой, ты чинишь DNS, они уходят счастливые. Классика жанра. Поэтому сегодня разберём DNS в Linux от А до Я, с прикольчиками, лайфхаками и реальными кейсами из окопов.

DNS простыми словами (для тех, кто в танке)

Содержание: показать

DNS — это телефонная книга интернета. Люди помнят имена типа google.com, а сети нужны IP-адреса вроде 142.250.185.206. Linux берёт доменное имя и начинает квест: кого спросить, кому верить и где это всё закэшировать, чтобы в следующий раз не бегать.

Если DNS сломан — приложения, браузеры и сервисы начинают вести себя как обиженные дети: тупят, виснут, выдают непонятные ошибки. А ты сидишь и думаешь: «Какого чёрта? Интернет же работает!» Спойлер: интернет работает, DNS — нет.

Как Linux резолвит имена (анатомия боли)

Типовая цепочка резолвинга выглядит так:

/etc/hosts — локальная база данных, куда админы любят писать всякую дичь
systemd-resolved / dnsmasq / nscd — локальные кэширующие резолверы
/etc/resolv.conf — конфиг с указанием DNS-серверов
Внешний DNS (Google, Cloudflare, корпоративный и т.д.)

Важно: на современных системах /etc/resolv.conf часто является симлинком на /run/systemd/resolve/stub-resolv.conf или что-то подобное. Если ты его редактируешь напрямую, а потом всё «само ломается» — не удивляйся. NetworkManager или systemd-resolved просто переписывают его обратно, как заботливая мамочка, которая не доверяет твоим решениям.

Практика: проверяем DNS в Linux (5 боевых примеров)

Пример 1: Базовая диагностика с dig

Самый простой способ понять, жив ли DNS:

dig google.com

Если ответ есть, в секции ANSWER SECTION видишь IP — DNS работает. Если SERVFAIL, таймаут или connection timed out; no servers could be reached — начинаем копать глубже.

Профи-трюк: Смотри на время ответа (Query time). Если больше 500ms — либо DNS тормозит, либо сеть лагает, либо ты пингуешь сервер на Марсе.

Пример 2: Трассировка DNS-запроса

Хочешь понять, через какие серверы идёт запрос? Используй +trace:

dig +trace example.com

Это покажет весь путь от корневых DNS-серверов до конечного авторитативного. Идеально для дебага делегирования доменов и поиска того самого звена, где всё сломалось.

Пример 3: Проверка конкретного DNS-сервера

Подозреваешь, что корпоративный DNS глючит? Проверь напрямую:

dig @8.8.8.8 google.com
dig @192.168.1.1 google.com

Первая команда спрашивает Google DNS, вторая — твой роутер. Сравниваешь результаты и понимаешь, кто виноват.

Пример 4: Проверка обратной зоны (PTR-записи)

Нужно узнать, какое имя привязано к IP? Обратный DNS:

dig -x 8.8.8.8

Ответ должен быть что-то типа dns.google. Если пусто — обратная зона не настроена. Для почтовых серверов это катастрофа, для остального — просто грустно.

Пример 5: Проверка всех типов записей

Хочешь увидеть ВСЁ, что знает DNS о домене?

dig ANY example.com

Получишь A, AAAA, MX, TXT, NS и всё остальное скопом. Правда, некоторые DNS-серверы игнорируют ANY-запросы из-за DDoS-атак, но попытка не пытка.

systemd-resolved: друг или враг?

На современных дистрибутивах (Ubuntu 18.04+, Fedora, Arch) DNS-резолвинг часто делает systemd-resolved. Это демон, который кэширует запросы, поддерживает DNSSEC, умеет в split-DNS (разные DNS для разных интерфейсов) и вообще крутой пацан.

Но есть нюанс: он слушает на 127.0.0.53:53, а не на обычном 127.0.0.1:53. Некоторые старые приложения не понимают этой магии и начинают орать.

Проверить статус:

systemctl status systemd-resolved
resolvectl status

Вторая команда покажет, какие DNS-серверы используются для каждого интерфейса. Очень удобно для дебага VPN, где DNS должен идти через туннель, а не мимо.

Хак для отключения systemd-resolved (если он достал):

systemctl disable --now systemd-resolved
rm /etc/resolv.conf
echo &quot;nameserver 8.8.8.8&quot; &gt; /etc/resolv.conf
echo &quot;nameserver 1.1.1.1&quot; &gt;&gt; /etc/resolv.conf
chattr +i /etc/resolv.conf

Последняя команда делает файл иммутабельным, чтобы никто его не переписал. Жёстко, но эффективно.

Pi-hole: DNS, который режет рекламу и нервы маркетологам

Pi-hole — это локальный DNS-сервер с фильтрацией на уровне сети. Он не только резолвит домены, но и блокирует рекламу, трекеры, телеметрию и всякий мусор ещё до того, как они попадут в браузер. Представь: ни одна реклама на YouTube, ни один баннер на сайтах, ни одна аналитика не улетает в Google. Это не просто DNS, это философия.

Почему админы и параноики любят Pi-hole:

Минимальная нагрузка — работает даже на Raspberry Pi Zero
Простая установка — один скрипт и готово
Веб-интерфейс с крутой статистикой (кто, куда, когда запрашивал)
Работает как DNS для всей сети — настроил один раз, забыл навсегда
Блокировка на уровне DNS = работает для всех устройств (даже Smart TV и IoT-шлака)

Установка (классика на Debian/Ubuntu):

curl -sSL https://install.pi-hole.net | <a class="wpil_keyword_link" href="https://it-apteka.com/tag/bash/"   title="Bash" data-wpil-keyword-link="linked"  data-wpil-monitor-id="221">bash</a>

Скрипт задаст несколько вопросов, сгенерирует пароль для админки и даст IP веб-интерфейса. После установки просто указываешь Pi-hole как DNS-сервер на роутере (или вручную на клиентах) — и вся сеть начинает дышать свободнее. Реклама? Нет. Трекеры? Мимо. Счастье? Почти.

Профи-фишка: Pi-hole можно использовать в связке с Unbound (рекурсивный DNS), чтобы вообще не зависеть от внешних DNS-провайдеров. Параноидальный режим активирован.

MikroTik DNS: быстро, просто, сердито (для сетевиков)

Если у тебя в сети есть MikroTik — у тебя уже есть DNS-сервер. Многие об этом не задумываются, а зря. RouterOS из коробки умеет кэшировать запросы, раздавать DNS по DHCP и вообще быть приличным резолвером для небольших сетей.

MikroTik DNS умеет:

Кешировать DNS-запросы (TTL настраиваемый)
Раздавать свой IP как DNS-сервер через DHCP
Пробрасывать запросы на внешние DNS (Google, Cloudflare, свой корпоративный)
Добавлять статические записи (локальные хосты без отдельного DNS-сервера)

Базовая настройка DNS на MikroTik через CLI:

/ip dns set servers=8.8.8.8,1.1.1.1 allow-remote-requests=yes cache-size=2048KiB

После этого роутер начинает принимать DNS-запросы от клиентов, кэшировать их и проксировать на Google/Cloudflare. Просто, эффективно и без лишнего шаманства с BIND или dnsmasq.

А если добавить статические записи для локальной сети:

/ip dns static add name=server.local address=192.168.1.10
/ip dns static add name=nas.home address=192.168.1.20
/ip dns static add name=printer.office address=192.168.1.30

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

Лайфхак: Можно настроить регулярное обновление DNS-кэша через скрипт, чтобы роутер забывал устаревшие записи. Или вообще настроить фильтрацию через regexp (да, MikroTik и такое умеет).

Типовые ошибки, которые я вижу постоянно (и ты тоже увидишь)

Клиенты используют разные DNS — один хост смотрит в 8.8.8.8, другой в корпоративный, третий в DNS роутера. Результат: одни видят внутренние домены, другие нет. Хаос.
DNS через VPN без split-DNS — подключился к VPN, и все DNS-запросы пошли через туннель. Локальные ресурсы недоступны, скорость падает, всё тормозит. Настройка split-DNS решает это за минуту.
systemd-resolved и NetworkManager дерутся за власть — каждый пишет свой /etc/resolv.conf, перезаписывая друг друга. В итоге DNS работает через раз. Решение: выбрать одного господина и отключить второго.
Забытый /etc/hosts с кривыми записями — кто-то когда-то добавил 192.168.1.100 google.com для теста, забыл удалить. Теперь Google не открывается, а ты час ищешь проблему.
TTL на нуле — изменил DNS-запись на домене, а она не обновляется. Смотришь TTL — 86400 секунд (сутки). Ждёшь. Пьёшь кофе. Повторяешь.

Если что-то «то работает, то нет» — проверь DNS. Если всё «вдруг заработало само» — это был кэш. Если вообще ничего не работает — сначала проверь DNS, потом ищи другие причины.

/etc/hosts: старый, но опасный инструмент

Файл /etc/hosts — это как записная книжка бабушки: старомодная, но иногда полезная. Здесь можно вручную прописать соответствие IP-адреса и доменного имени, минуя DNS.

Пример:

# Локальные хосты
192.168.1.10    server.local
192.168.1.20    nas.home

# Блокировка рекламы (хардкорный метод)
0.0.0.0    ads.example.com
0.0.0.0    tracker.analytics.com

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

Реальный кейс из жизни: Разработчик прописал в /etc/hosts тестовый IP продакшн-домена, забыл, через неделю деплоит на прод и удивляется, почему у него всё работает, а у всех остальных нет. Провёл 3 часа в дебаге, пока не вспомнил про hosts.

dnsmasq: лёгкий и универсальный

Если Pi-hole кажется избыточным, а BIND — слишком громоздким, есть золотая середина: dnsmasq. Это лёгкий DNS/DHCP сервер, который умеет кэшировать запросы, раздавать адреса и работать как локальный резолвер.

Установка:

apt install dnsmasq

Базовый конфиг (/etc/dnsmasq.conf):

# Прослушиваем только локальный интерфейс
listen-address=127.0.0.1

# Внешние DNS
server=8.8.8.8
server=1.1.1.1

# Размер кэша
cache-size=1000

# Локальные домены
address=/local.dev/192.168.1.10

Перезапуск:

systemctl restart dnsmasq

И вуаля — у тебя свой локальный DNS-сервер с кэшем. Легко, быстро, без заморочек.

DNSSEC: параноидальный режим включён

DNSSEC — это механизм подписи DNS-записей, который защищает от подделки ответов (DNS spoofing, cache poisoning и прочие прелести). В теории звучит круто, на практике — головная боль.

Проверить, поддерживает ли домен DNSSEC:

dig +dnssec example.com

Если в ответе есть RRSIG записи — DNSSEC работает. Если нет — либо не настроен, либо сломан.

Моё мнение: DNSSEC — это как антивирус на сервере. В идеальном мире он должен быть, но в реальности он чаще создаёт проблемы, чем решает. Настраивай, если действительно нужно (финансы, государство, высокая безопасность), иначе забей.

Как понять, что проблема именно в DNS (чеклист)

Ping по IP работает, по домену — нет
```
ping 8.8.8.8  # работает
ping google.com  # не работает
```
DNS сломан. Точка.
nslookup/dig показывают ошибку
```
nslookup google.com
# ;; connection timed out; no servers could be reached
```
DNS-сервер недоступен или неправильно указан.
Разные результаты на разных машинах — одна машина резолвит домен, другая нет. Скорее всего, используют разные DNS-серверы или разные /etc/hosts.
Браузер говорит «DNS_PROBE_FINISHED_NXDOMAIN» — либо домен не существует, либо DNS его не видит.
Curl/wget работает по IP, но не по домену — классика жанра. DNS не резолвит.

Вывод: DNS — это не просто сервис, это искусство

DNS — это фундамент сети, без которого весь интернет превращается в набор бессмысленных IP-адресов. Pi-hole делает его умным и блокирует весь рекламный шлак. MikroTik — удобным и встроенным прямо в роутер. Linux даёт гибкость и кучу инструментов для любых извращений.

Понимая, как всё это связано, ты перестаёшь паниковать при словах «сайт не открывается» и начинаешь методично чинить. А паника — это для пользователей. Мы с тобой выше этого 😉

P.S. Если после прочтения у тебя всё ещё не работает DNS — попробуй перезагрузить роутер. Серьёзно. Это работает в 50% случаев, и никто не знает почему.

Author: over_dude

Поделитесь: