DNS, TLS и прокси за 8 минут

Половина инцидентов «сайт не открывается» сводится к DNS или сертификату. DevOps-инженер должен уметь быстро проверить и то и другое.

DNS: как имя превращается в адрес

1. Приложение спрашивает системный резолвер (/etc/resolv.conf, systemd-resolved).
2. Тот обращается к рекурсивному резолверу (провайдера, облака, 8.8.8.8, 77.88.8.8).
3. Рекурсивный резолвер, если ответа нет в кеше, идёт от корня: корневые серверы знают серверы зоны .ru, те знают авторитативные серверы example.ru, а авторитативный сервер отвечает адресом.
4. Ответ кешируется на время TTL на всех уровнях.

Типы записей

Запись	Назначение
A / AAAA	имя в IPv4 / IPv6 адрес
CNAME	псевдоним: имя указывает на другое имя
MX	почтовые серверы домена
TXT	произвольный текст: SPF, DKIM, DMARC, подтверждение владения, ACME
NS	авторитативные серверы зоны
SOA	параметры зоны, в том числе TTL отрицательного кеширования
PTR	обратная запись: адрес в имя
SRV	сервис, порт и вес (используется в некоторых протоколах и в Kubernetes)
CAA	какие удостоверяющие центры могут выпускать сертификаты домена

CNAME нельзя ставить на вершину зоны (example.ru), где уже есть SOA и NS, и нельзя совмещать с другими записями для того же имени. Для вершины облачные DNS предлагают ALIAS или ANAME.

TTL и миграции

TTL говорит, сколько секунд кешировать ответ. При переезде на новый адрес TTL понижают заранее: если был 86400, за сутки до переезда ставят 300, после переезда старый ответ живёт в кешах максимум 5 минут. Отрицательные ответы (NXDOMAIN) тоже кешируются, по полю из SOA: если сервис запросили до создания записи, он может «не видеть» её до истечения этого времени.

Инструменты

dig example.ru A +short          # адрес
dig @77.88.8.8 example.ru        # спросить конкретный резолвер
dig example.ru NS                # кто авторитативный
dig +trace example.ru            # пройти путь от корня
dig -x 203.0.113.10              # обратная запись

TLS

TLS шифрует соединение и подтверждает, что сервер тот, за кого себя выдаёт. В TLS 1.3 рукопожатие занимает один круг (1-RTT): клиент сразу предлагает ключевой обмен, сервер отвечает сертификатом и своей частью ключа.

Сертификат связывает публичный ключ с именами (поле SAN, Subject Alternative Name) и подписан удостоверяющим центром (CA). Клиент доверяет корневым CA из своего хранилища. Цепочка: сертификат сервера, промежуточный сертификат, корень. Сервер должен отдавать сертификат вместе с промежуточными (fullchain.pem): браузер иногда сам достраивает цепочку, а curl, Java и мобильные клиенты нет, отсюда «в браузере работает, в приложении ошибка».

SNI: клиент в начале рукопожатия сообщает имя хоста, чтобы сервер с одним IP выбрал нужный сертификат.

Let's Encrypt и ACME

Бесплатные сертификаты на 90 дней с автоматическим продлением по протоколу ACME (certbot, acme.sh, cert-manager в Kubernetes). Проверка владения:

• http-01: CA запрашивает файл по http://домен/.well-known/acme-challenge/..., нужен открытый 80 порт.
• dns-01: нужно создать TXT-запись _acme-challenge.домен. Единственный способ получить wildcard *.example.ru, работает для внутренних сервисов без доступа из интернета.
• tls-alpn-01: проверка на 443 порту.

Индустрия сокращает срок жизни сертификатов: по решению CA/Browser Forum максимальный срок публичных сертификатов снижается поэтапно с 2026 года. Вывод один: продление должно быть полностью автоматическим, а истечение должно ловить мониторинг, а не пользователи.

В России часть госсервисов и банков использует сертификаты НУЦ Минцифры. Их корень не входит в стандартные хранилища большинства браузеров и ОС, его ставят отдельно.

mTLS

Взаимный TLS: сервер тоже проверяет сертификат клиента. Используют для связи сервисов внутри (часто через сервис-меш, который выпускает сертификаты сам), для партнёрских API и доступа устройств.

Полезные проверки

openssl s_client -connect example.ru:443 -servername example.ru </dev/null
openssl x509 -in cert.pem -noout -subject -enddate -ext subjectAltName
curl -vI https://example.ru

Прямой и обратный прокси

• Прямой (forward) прокси действует от имени клиента: корпоративный выход в интернет, фильтрация, кеш. Клиент знает о прокси (HTTPS_PROXY).
• Обратный (reverse) прокси действует от имени серверов: nginx перед приложением, TLS-терминация, балансировка. Клиент думает, что говорит с самим сервисом.
• Прозрачный прокси перехватывает трафик без настроек на клиенте.

Для HTTPS прямой прокси обычно создаёт туннель методом CONNECT и не видит содержимого, если не делает перехват TLS с собственным корнем.

Частые ошибки

• Сертификат без промежуточного в цепочке.
• Продление по cron, которое тихо сломалось три месяца назад.
• TTL сутки при плановом переезде.
• CNAME на вершине зоны.
• Не указали -servername в openssl s_client и смотрите сертификат по умолчанию.

Что спросят на собесе

• Что происходит при резолвинге имени и что такое TTL.
• Какие записи DNS знаете, что такое CNAME и его ограничения.
• Как проходит TLS-рукопожатие и зачем промежуточные сертификаты.
• Как получить wildcard-сертификат Let's Encrypt.
• Чем прямой прокси отличается от обратного.