Вы набираете google.com — и через полсекунды видите страницу. Но компьютеры не понимают слов. Им нужны числа — IP-адреса. Кто-то должен перевести google.com в 142.250.74.46. Этот «кто-то» — DNS.

И когда DNS ломается — ломается всё. Сайты не открываются, API не отвечают, apt update не может скачать пакеты. При этом сервер жив, интернет есть, пинг по IP работает. Просто система не может перевести имена в адреса — и становится слепой.

Аналогия с телефонной книгой — классика, но она точная. Вы не запоминаете номер телефона каждого знакомого — вы ищете по имени. DNS делает то же самое для компьютеров. Только вместо одной книги — тысячи серверов по всему миру, которые хранят разные части этого гигантского справочника. Что происходит, когда вы набираете ping google.com? Вот путь запроса — упрощённо, но по существу:

1. Локальный кеш. Система сначала проверяет, не спрашивала ли она про google.com недавно. Если да — ответ уже в кеше, DNS-сервер не нужен.

2. Файл /etc/hosts. Потом система заглядывает в этот файл — локальную «записную книжку». Если там есть строка 142.250.74.46 google.com — вопрос решён, дальше не идём.

3. DNS-сервер. Если в кеше и в hosts ничего нет — система отправляет запрос на DNS-сервер, который прописан в настройках. Обычно это сервер вашего провайдера или публичный (8.8.8.8 от Google, 1.1.1.1 от Cloudflare).

4. Рекурсивный поиск. DNS-сервер, если сам не знает ответ, спрашивает корневые серверы → серверы зоны .com → серверы google.com. Каждый уровень отвечает: «я не знаю точный адрес, но вот кто знает». Как спросить дорогу у прохожего, который отправляет вас к другому прохожему — пока не найдётся тот, кто знает.

5. Ответ. IP-адрес возвращается вашей системе, кешируется (чтобы не спрашивать снова через секунду), и запрос уходит по назначению.

Всё это — за миллисекунды. Вы даже не замечаете.

Теория — это хорошо. А теперь — руки. Главный инструмент для диагностики DNS — команда dig:

dig google.com

Вывод выглядит громоздко, но нас интересует одна секция — ANSWER SECTION:

;; ANSWER SECTION:
google.com.     245     IN      A       142.250.74.46

Переведём на человеческий:

• google.com. — домен, который мы спросили.
• 245 — TTL (time to live) — сколько секунд ответ можно кешировать. Через 245 секунд нужно спросить снова.
• A — тип записи. A — это IPv4-адрес.
• 142.250.74.46 — собственно, ответ.

Если хотите только ответ, без лишнего шума:

dig +short google.com
# 142.250.74.46

Элегантно. Одна строка — один IP.

Есть и более простая альтернатива — nslookup:

nslookup google.com
# Server:     127.0.0.53
# Address:    127.0.0.53#53
#
# Non-authoritative answer:
# Name:   google.com
# Address: 142.250.74.46

nslookup проще для быстрой проверки, dig — для серьёзной диагностики. На собеседованиях обычно спрашивают про dig — он считается «профессиональным» инструментом.

А теперь — реальная диагностика. Коллега говорит: «Сайт не открывается». Вы помните алгоритм из прошлого урока: ping 8.8.8.8 работает, а ping example.com — нет. Значит, проблема в DNS. Что делать дальше?

# 1. Проверить, резолвится ли домен
dig example.com

# 2. Если не резолвится — попробовать другой DNS-сервер
dig @8.8.8.8 example.com

# 3. Если через 8.8.8.8 работает — проблема в вашем DNS-сервере
# 4. Если и через 8.8.8.8 не работает — проблема в самом домене

Конструкция @8.8.8.8 говорит dig: «спроси не мой DNS-сервер, а конкретно Google DNS». Это как позвонить другому справочному бюро, когда первое не отвечает. Если через Google DNS домен резолвится, а через ваш — нет — значит, проблема локальная. Ваш DNS-сервер либо лежит, либо неправильно настроен. Где вообще настраивается, какой DNS-сервер использовать? В современном Linux это может быть в нескольких местах (и это, честно говоря, бардак):

# Посмотреть текущий DNS-сервер
resolvectl status

# Или по старинке
cat /etc/resolv.conf

В /etc/resolv.conf вы увидите что-то вроде:

nameserver 127.0.0.53

Это не опечатка — 127.0.0.53 это локальный DNS-резолвер systemd-resolved. Он принимает ваши запросы и пересылает на настоящий DNS-сервер. Чтобы увидеть, куда он пересылает:

resolvectl status

Там будет реальный адрес — например, 8.8.8.8 или DNS вашего провайдера.

И наконец — /etc/hosts. Помните, мы упоминали его в начале? Это простейший «DNS» — текстовый файл с парами «IP — имя»:

cat /etc/hosts

127.0.0.1       localhost
127.0.1.1       my-server
192.168.1.50    db-server
192.168.1.51    cache-server

Система проверяет этот файл до обращения к DNS-серверу. Это значит, что запись в /etc/hosts перебивает DNS. Зачем это нужно?

• Разработка: хотите, чтобы myapp.local указывал на 127.0.0.1? Одна строка в hosts — и готово, никакого DNS не нужно.
• Тестирование: нужно проверить сайт на новом сервере, не переключая DNS? Пропишите IP нового сервера в hosts — и браузер пойдёт туда.
• Внутренняя сеть: у вас пять серверов в локальной сети. Вместо того чтобы запоминать IP, пропишите имена в hosts: db-server, cache-server, web-server.

# Добавить запись
sudo nano /etc/hosts

# Дописать:
192.168.1.50    db-server

После этого ping db-server будет работать — система найдёт имя в /etc/hosts и подставит IP, даже без DNS.

Подведём итог. DNS — это невидимый, но критически важный слой интернета. Когда он работает — вы его не замечаете. Когда ломается — не работает вообще ничего, и это особенно сбивает с толку, потому что «пинг по IP ходит, а сайты не открываются». Теперь вы знаете, как это диагностировать: dig — спросить DNS-сервер, @8.8.8.8 — спросить другой, /etc/hosts — обойти DNS полностью.

В следующем уроке — SSH. Как подключаться к удалённому серверу, как будто вы сидите прямо за ним. Это навык, без которого в серверном мире не делается вообще ничего.