# DNS

> Распределённая иерархическая система, которая сопоставляет доменные имена с IP-адресами и другими данными.

Источник: https://llmdocs.ru/wiki/dns/ · обновлено 2026-11-09 · лицензия CC BY-SA 4.0

- **Полное название**: Domain Name System
- **Уровень модели OSI**: прикладной
- **Порт**: 53 (UDP и TCP)
- **Создан**: 1983
- **Автор**: Пол Мокапетрис
- **Стандарт**: RFC 1034, RFC 1035 (1987)
- **Защищённые варианты**: DNSSEC, DNS over TLS, DNS over HTTPS, DNS over QUIC
**DNS** (англ. *Domain Name System* — система доменных имён) — распределённая иерархическая база данных, которая переводит понятные человеку имена вроде `example.com` в IP-адреса и хранит другие сведения о доменах: почтовые серверы, текстовые записи, псевдонимы. DNS — одна из базовых служб интернета: практически любое сетевое соединение начинается с DNS-запроса.

## История

В ранней сети ARPANET соответствие имён и адресов хранилось в одном файле `HOSTS.TXT`, который вручную обновлял Сетевой информационный центр в Стэнфорде, а все узлы периодически его скачивали. С ростом сети такая схема перестала работать. В 1983 году Пол Мокапетрис описал систему доменных имён в RFC 882 и RFC 883, а в 1987 году их заменили RFC 1034 и RFC 1035, которые остаются основой протокола.[1][2] Пережитком старой схемы является файл `/etc/hosts`, который по-прежнему проверяется до обращения к DNS.

## Устройство

Пространство имён DNS — дерево. Его вершина — **корневая зона** (обозначается точкой), ниже — домены верхнего уровня (`ru`, `com`, `org`), затем домены второго уровня (`example.com`) и так далее. Каждая часть дерева может быть **делегирована** отдельной организации: владелец домена сам управляет его зоной и может делегировать поддомены дальше.

Корневую зону обслуживают 13 логических корневых серверов с именами от `a.root-servers.net` до `m.root-servers.net`. Ими управляют 12 организаций, а физически каждый «сервер» — это сотни узлов по всему миру, объединённых технологией anycast.[3]

Различают два типа серверов:

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

## Разрешение имени

Когда браузер запрашивает `docs.example.com`, происходит следующее (если ответа нет в кешах):

1. Приложение обращается к системному резолверу, тот — к рекурсивному серверу.
2. Рекурсивный сервер спрашивает корневой сервер и получает список серверов зоны `com`.
3. Сервер зоны `com` отвечает, какие серверы авторитетны для `example.com` (записи NS).
4. Авторитетный сервер `example.com` возвращает запись A или AAAA для `docs.example.com`.
5. Ответ кешируется на время, указанное в поле **TTL**, и возвращается клиенту.

Обычно запросы идут по [UDP](https://llmdocs.ru/wiki/udp.md); [TCP](https://llmdocs.ru/wiki/tcp.md) используется для больших ответов и передачи зон между серверами.

## Типы записей

| Тип | Назначение | Пример значения |
|---|---|---|
| A | IPv4-адрес | `192.0.2.10` |
| AAAA | IPv6-адрес | `2001:db8::10` |
| CNAME | псевдоним другого имени | `www → example.com.` |
| MX | почтовый сервер с приоритетом | `10 mail.example.com.` |
| NS | авторитетные серверы зоны | `ns1.example.net.` |
| TXT | произвольный текст (SPF, проверка владения) | `"v=spf1 -all"` |
| SOA | параметры зоны | серийный номер, таймеры |
| CAA | какие центры сертификации могут выпускать сертификаты | `0 issue "letsencrypt.org"` |
| SRV | расположение сервиса | приоритет, вес, порт, узел |

Подробнее — в статье [DNS-записи (A, AAAA, CNAME, MX, TXT)](https://llmdocs.ru/wiki/dns-records.md). Звёздочка в имени (`*.example.com`) задаёт **wildcard-запись**, которая отвечает за все поддомены без собственной записи.

## Инструменты

```bash
dig example.com A +short          # адрес
dig example.com MX                # почтовые серверы с полным ответом
dig +trace docs.example.com       # пройти всю цепочку от корня
dig @1.1.1.1 example.com          # спросить конкретный резолвер
nslookup example.com              # кросс-платформенный аналог
```

## Безопасность

Классический DNS не шифрует и не подписывает данные, поэтому запросы видны всем на пути и могут быть подменены (атака «отравление кеша»).

- **DNSSEC** (RFC 4033–4035, 2005) добавляет цифровые подписи записей и цепочку доверия от корня; корневая зона подписана в 2010 году.[4] DNSSEC защищает от подмены, но не скрывает содержимое запросов.
- **DNS over TLS** (DoT, RFC 7858, порт 853) шифрует запросы с помощью [TLS](https://llmdocs.ru/wiki/tls.md).[5]
- **DNS over HTTPS** (DoH, RFC 8484) передаёт запросы внутри [HTTPS](https://llmdocs.ru/wiki/http.md) и неотличим от обычного веб-трафика.[6]
- **DNS over QUIC** (DoQ, RFC 9250) использует [QUIC](https://llmdocs.ru/wiki/quic.md).[7]

## См. также

- [IP-адрес и подсети (CIDR)](https://llmdocs.ru/wiki/ip-cidr.md)
- [TLS](https://llmdocs.ru/wiki/tls.md)
- [Let's Encrypt и ACME](https://llmdocs.ru/wiki/lets-encrypt-acme.md)
- [CDN](https://llmdocs.ru/wiki/cdn.md)

## Источники

1. [RFC 1034 — Domain Names: Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034)
2. [RFC 1035 — Domain Names: Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035)
3. [Root Servers — IANA](https://www.iana.org/domains/root/servers)
4. [RFC 4033 — DNS Security Introduction and Requirements](https://www.rfc-editor.org/rfc/rfc4033)
5. [RFC 7858 — DNS over TLS](https://www.rfc-editor.org/rfc/rfc7858)
6. [RFC 8484 — DNS Queries over HTTPS (DoH)](https://www.rfc-editor.org/rfc/rfc8484)
7. [RFC 9250 — DNS over Dedicated QUIC Connections](https://www.rfc-editor.org/rfc/rfc9250)