RFC 1035

RFC 1035 — это документ из серии Request for Comments (RFC), опубликованный в ноябре 1987 года, который определяет спецификацию протокола DNS (Domain Name System) — системы доменных имён. RFC 1035 является одним из фундаментальных стандартов Интернета, описывающим формат сообщений, типы записей, алгоритмы разрешения имён и механизмы кэширования. Вместе с RFC 1034 (концепции и общая архитектура DNS) и RFC 1033 (руководство по администрированию) он составляет основу современной DNS.

История

До появления DNS в начале 1980-х годов для сопоставления имён хостов с IP-адресами использовался файл HOSTS.TXT, который централизованно распространялся через сетевой информационный центр (SRI-NIC). С ростом сети ARPANET этот подход перестал справляться с нагрузкой: обновления файла происходили с задержками, а объём данных рос экспоненциально. В 1983 году Пол Мокапетрис (Paul Mockapetris) разработал концепцию распределённой иерархической системы доменных имён, которая была описана в RFC 882 и RFC 883. В 1987 году эти документы были переработаны и заменены на RFC 1034 и RFC 1035, которые остаются действующими стандартами (с последующими уточнениями и расширениями, такими как RFC 3597, RFC 6891 и другие).

Структура и формат сообщений

RFC 1035 определяет единый формат сообщений DNS, используемый как для запросов (queries), так и для ответов (responses). Сообщение состоит из пяти разделов, каждый из которых может быть пустым:

1. Заголовок (Header) — фиксированная 12-байтовая структура, содержащая:

• Идентификатор (ID) — 16-битное поле для сопоставления запросов и ответов.
• Флаги (QR, Opcode, AA, TC, RD, RA, Rcode) — определяют тип сообщения (запрос/ответ), код операции (стандартный запрос, инверсный запрос, статус сервера), авторитетность ответа, усечение, рекурсию и код ошибки.
• Счётчики (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) — количество записей в каждом из последующих разделов.

1. Вопрос (Question) — содержит запрашиваемое доменное имя (в формате последовательности меток с указанием длины), тип записи (A, AAAA, MX, CNAME и т. д.) и класс (обычно IN — Internet).

1. Ответ (Answer) — одна или несколько ресурсных записей (RR), удовлетворяющих запросу.

1. Авторитетные записи (Authority) — записи, указывающие на авторитетные серверы домена (NS-записи).

1. Дополнительные записи (Additional) — записи, которые могут быть полезны для обработки ответа (например, A-записи серверов имён из раздела Authority).

Типы ресурсных записей (RR)

RFC 1035 определяет следующие основные типы записей:

• A (Address) — IPv4-адрес (32 бита). Класс IN.
• NS (Name Server) — авторитетный сервер имён для домена.
• CNAME (Canonical Name) — каноническое имя (псевдоним).
• SOA (Start of Authority) — начало зоны: содержит информацию о первичном сервере, почтовом адресе администратора, серийном номере зоны, таймерах обновления и сроках жизни записей (TTL).
• MB, MG, MR — экспериментальные почтовые записи (впоследствии заменены MX).
• NULL — запись без данных (используется для тестирования).
• WKS (Well-Known Service) — описание доступных сетевых сервисов (устарел).
• PTR (Pointer) — указатель для обратного разрешения (из IP-адреса в доменное имя).
• HINFO (Host Information) — информация о хосте (ОС, аппаратное обеспечение).
• MINFO (Mailbox Information) — информация о почтовом ящике.

Впоследствии стандарт был расширен другими RFC: MX (RFC 974, позже RFC 1035), TXT (RFC 1464), AAAA (RFC 3596), SRV (RFC 2782) и другими.

Алгоритм разрешения имён

RFC 1035 описывает два основных режима работы DNS-клиента и сервера:

Рекурсивное разрешение

Клиент (резолвер) отправляет запрос рекурсивному серверу (например, DNS-серверу провайдера). Сервер самостоятельно выполняет последовательность запросов к корневым серверам, серверам доменов верхнего уровня (TLD) и авторитетным серверам, пока не найдёт ответ. Результат возвращается клиенту. Этот режим упрощает работу клиентского ПО, но создаёт нагрузку на рекурсивные серверы.

Итеративное разрешение

Сервер отвечает клиенту либо собственным авторитетным ответом, либо ссылкой на следующий сервер (NS-запись). Клиент последовательно опрашивает серверы, двигаясь по иерархии. Этот режим используется между серверами (например, корневой сервер отвечает ссылкой на сервер домена .ru).

Кэширование и TTL

Каждая ресурсная запись содержит поле TTL (Time to Live) — время в секундах, в течение которого запись может быть закэширована. RFC 1035 рекомендует кэшировать положительные ответы (A, NS и т. д.) на время TTL, а отрицательные ответы (NXDOMAIN) — на время, указанное в SOA-записи зоны. Кэширование позволяет снизить нагрузку на авторитетные серверы и ускорить разрешение.

Усечение (Truncation)

Если размер ответа превышает 512 байт (максимальный размер UDP-пакета в классической DNS), сервер устанавливает флаг TC (Truncation) в заголовке. Клиент должен повторить запрос через TCP-соединение. Впоследствии, с появлением расширения EDNS (RFC 6891), максимальный размер UDP-пакета был увеличен до 4096 байт, что снизило необходимость в TCP.

Обратное разрешение (Reverse DNS)

Для преобразования IP-адреса в доменное имя используется специальная зона in-addr.arpa (для IPv4) и ip6.arpa (для IPv6). Запросы к этой зоне содержат PTR-записи. RFC 1035 определяет формат таких запросов: IP-адрес записывается в обратном порядке октетов (например, 192.168.1.1 → 1.1.168.192.in-addr.arpa).

Безопасность и ограничения

Изначально RFC 1035 не предусматривал механизмов аутентификации и защиты от подмены данных. Это привело к уязвимостям, таким как отравление кэша (cache poisoning) и атаки типа «человек посередине». Впоследствии были разработаны расширения DNSSEC (DNS Security Extensions, RFC 4033–4035), которые добавляют цифровые подписи к записям. Однако DNSSEC не является обязательным и внедрён не повсеместно.

Кроме того, RFC 1035 не поддерживает:

• IPv6-адреса (добавлены в RFC 3596).
• Международные доменные имена (IDN) — поддержка добавлена в RFC 5890–5891.
• Динамические обновления (RFC 2136).
• Запись типа SRV (RFC 2782).

Влияние и наследие

RFC 1035 остаётся одним из наиболее цитируемых и реализованных стандартов Интернета. Все современные DNS-серверы (BIND, Unbound, PowerDNS, Knot DNS, Microsoft DNS) и клиентские резолверы (в операционных системах, браузерах, маршрутизаторах) реализуют его спецификацию. Несмотря на возраст, документ продолжает использоваться в неизменном виде для базовых операций, а все расширения оформлены как отдельные RFC, дополняющие, но не заменяющие RFC 1035.

Источники

• RFC 1035 — Domain Names — Implementation and Specification (P. Mockapetris, 1987)
• RFC 1034 — Domain Names — Concepts and Facilities (P. Mockapetris, 1987)
• RFC 1033 — Domain Administrators Operations Guide (M. Lottor, 1987)
• RFC 3597 — Handling of Unknown DNS Resource Record Types (A. Gustafsson, 2003)
• RFC 6891 — Extension Mechanisms for DNS (EDNS(0)) (J. Damas, M. Graff, P. Vixie, 2013)