Может ли DNS работать по протоколу TCP?

Question

deepseek-v3.2 · Accepted Answer

**Да, DNS может и должен работать по протоколу TCP.** Хотя это часто вызывает вопросы, поскольку в большинстве случаев мы наблюдаем работу DNS по **UDP**, **TCP является обязательной и полноценной частью DNS-протокола.** Это не просто альтернатива или резервный вариант, но критически важный механизм для обеспечения корректной работы службы.

### Краткий исторический контекст и стандарты

DNS был стандартизирован в RFC 1034 и RFC 1035 в 1987 году. Эти документы четко указывают, что DNS использует как **UDP** (порт 53), так и **TCP** (порт 53).

**UDP** используется по умолчанию для большинства обычных запросов (`A`, `AAAA`, `MX`, `CNAME` и т.д.) и ответов. Это обусловлено низкими накладными расходами на установление соединения, высокой скоростью и меньшей нагрузкой на серверы при огромном количестве коротких запросов.

**TCP** используется в определенных, обязательных случаях, предусмотренных протоколом.

### Основные сценарии использования DNS по TCP

**1. Трансфер зон (Zone Transfer) - AXFR и IXFR**
Это самый классический и обязательный пример. Механизм репликации данных между первичным (**master**) и вторичными (**slave**) DNS-серверами использует исключительно TCP.
```bash
# Пример запроса полной трансфера зоны (AXFR) через dig с указанием TCP
dig @primary.ns.example.com example.com AXFR +tcp
```
Причина: данные зоны (список всех ресурсных записей домена) могут быть очень объемными (десятки тысяч записей). TCP обеспечивает надежную, последовательную доставку большого объема данных без потерь и гарантирует целостность информации.

**2. Ответы, превышающие 512 байт (ограничение UDP)**
RFC 1035 устанавливает, что ответы по UDP должны укладываться в **512 байт** (включая заголовок). Если ответ превышает этот размер (например, при большом количестве записей в ответе, использовании DNSSEC с расширенными записями RRSIG), сервер устанавливает флаг **TC (Truncated)** в заголовке ответа и обрезает данные.
```bash
# UDP запрос, который может привести к обрезанию (truncation)
dig @ns.example.com example.com ANY
# Ответ будет содержать флаг "Truncated"
```
Клиент, увидев флаг **TC**, обязан повторить запрос, используя **TCP**, чтобы получить полный, необрезанный ответ.
```bash
# Повтор запроса по TCP для получения полного ответа
dig @ns.example.com example.com ANY +tcp
```

**3. Протокол DNS Security Extensions (DNSSEC)**
DNSSEC добавляет в ответы дополнительные крипографические записи (**RRSIG**, **DNSKEY**, **DS**), что значительно увеличивает размер пакета. Вероятность превышения лимита 512 байт становится очень высокой, поэтому использование TCP для DNSSEC-ответов практически является нормой.

**4. Современные тенденции и RFC 8877**
Со временем ограничение 512 байт стало серьезной проблемой. В 2020 году был опубликован **RFC 8877**, который официально разрешает использование **UDP-пакетов размером более 512 байт** при поддержке механизма **EDNS0 (Extension Mechanisms for DNS)**. EDNS0 позволяет клиенту и серверу договориться о большем буфере (`UDP buffer size`) в процессе обмена.
```bash
# Dig по умолчанию использует EDNS0 и указывает буфер, например, 4096 байт
dig @ns.example.com example.com +bufsize=4096
```
Если оба участника поддерживают EDNS0 и согласовали достаточный размер, обмен может успешно происходить по UDP даже для больших ответов. Однако если EDNS0 не поддерживается или согласование не удалось, TCP остается единственным надежным вариантом.

**5. Устойчивость к атакам и фильтрация трафика**
*   **Атаки на основе фрагментации UDP пакетов:** TCP менее подвержен некоторым типам DoS-атак.
*   **Фильтрация трафика:** В некоторых корпоративных сетях администраторы могут блокировать UDP-трафик на порт 53, но разрешать TCP для обеспечения работы критичных сервисов, таких как трансфер зон.

### Технические особенности реализации

*   **Порт:** Оба протокола используют один и тот же порт **53**.
*   **Форматы сообщений:** Формат сообщения DNS (заголовок, вопрос, ответ, authority, additional) идентичен для UDP и TCP. Различие лишь в транспорте.
*   **Транспортная разница:** В TCP перед каждым DNS-сообщением добавляется двухбайтный поле, указывающее **длину этого сообщения**, что позволяет корректно разграничить данные в потоке.

```python
# Примерное представление структуры DNS сообщения в TCP потоке
# +---------------------+
# | 2 байта: Длина сообщения (L) |
# +---------------------+
# | L байтов: Данные DNS сообщения |
# +---------------------+
```

### Практические примеры использования TCP в диагностике

Инструменты типа `dig` позволяют явно указать протокол.

```bash
# Запрос по TCP (ключ +tcp)
dig example.com A +tcp
# Запрос по UDP (ключ +notcp)
dig example.com A +notcp
# Проверка поддержки EDNS0 и размера буфера
dig example.com +bufsize=4096 +edns=0
```

### Итог

*   **DNS — это протокол уровня приложений, который исторически и стандартно использует как UDP, так и TCP.**
*   **UDP** — это предпочтительный протокол для повседневных запросов из>>за своей эффективности.
*   **TCP** является **обязательным** для:
    1.  Трансфера зон (AXFR/IXFR).
    2.  Получения ответов размером более 512 байт, когда EDNS0 не может помочь.
    3.  Обеспечения надежности при передаче больших объемов данных (DNSSEC).
    4.  Соблюдения требований RFC стандартов.

Знание этого разделения важно для DevOps/SRE инженеров при настройке DNS-серверов (BIND, PowerDNS, Unbound), диагностике проблем с разрешением имен, обеспечении безопасности и репликации данных, а также при планировании сетевой инфраструктуры (фильтрация, балансировка нагрузки). Отказ или блокировка TCP на порту 53 может привести к критическим сбоям в работе DNS-инфраструктуры.

Может ли DNS работать по протоколу TCP?

Комментарии (1)

Краткий исторический контекст и стандарты

Основные сценарии использования DNS по TCP

Технические особенности реализации

Практические примеры использования TCP в диагностике

Итог