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

Да, DNS может работать по TCP, и это обязательная часть стандарта

Абсолютно верно, DNS (Domain Name System) может и обязана работать по протоколу TCP в дополнение к более известному UDP. Это не опциональная возможность, а требование оригинального RFC-стандарта (RFC 1035). Широко распространено заблуждение, что DNS использует только UDP-порт 53. На самом деле, она использует оба протокола на порту 53.

Чтобы понять, почему нужны оба протокола, давайте разберем их роли на практике.

Почему основным протоколом является UDP?

По умолчанию большинство "простых" DNS-запросов (разрешение имени example.com в IP-адрес) используют UDP. Причины:

• Низкие накладные расходы и высокая скорость: UDP не требует установления соединения (handshake), что делает запросы и ответы очень быстрыми.
• Идеально для небольших пакетов: Традиционный DNS-ответ с одной или несколькими записями A/AAAA легко помещается в максимальный размер датаграммы UDP.
• Меньшая нагрузка на сервер: Серверу не нужно поддерживать состояние соединения для тысяч одновременных запросов.

Пример простого DNS-запроса по UDP на Go:

package main

import (
    "fmt"
    "net"
)

func main() {
    // Конфигурируем резолвер для использования конкретного DNS-сервера
    resolver := &net.Resolver{
        PreferGo: true,
        Dial: func(ctx context.Context, network, address string) (net.Conn, error) {
            d := net.Dialer{}
            // Указываем использование UDP
            return d.DialContext(ctx, "udp", "8.8.8.8:53")
        },
    }

    ips, err := resolver.LookupIPAddr(context.Background(), "google.com")
    if err != nil {
        panic(err)
    }
    for _, ip := range ips {
        fmt.Println(ip)
    }
}

В каких случаях DNS принудительно переключается на TCP?

Согласно стандарту, существует две основные причины для использования TCP:

1. Размер ответа превышает 512 байт.

    *   По UDP максимальный размер полезной нагрузки без фрагментации — 512 байт (ограничение, установленное в RFC 1035).
    *   Если ответ (например, содержащий множество TXT-записей, крупные SRV-записи или большое количество IP-адресов) превышает этот лимит, сервер обрезает пакет и устанавливает в заголовке ответа специальный флаг **`TC (Truncated) = 1`**.
    *   Клиент, увидев флаг `TC=1`, обязан **повторить запрос, используя протокол TCP**, который может передавать данные любого объема.
    *   В современных реализациях часто используется **EDNS0 (Extension Mechanisms for DNS)**, который позволяет клиенту и серверу договориться о поддержке UDP-пакетов большего размера (например, 4096 байт), что уменьшает необходимость в TCP. Однако поддержка EDNS0 не является повсеместной.

1. Зоны AXFR и IXFR (передача зон).

    *   Вторичные (slave) DNS-серверы запрашивают у первичных (master) полную (**AXFR**) или инкрементальную (**IXFR**) копию всей зоны (например, всех записей домена `example.com`).
    *   Объем передаваемых данных огромен (может составлять мегабайты), поэтому эти операции **всегда** выполняются по надежному соединению TCP.

Пример обработки усеченного ответа и перехода на TCP (логика):

func resolveWithFallback(domain string) ([]string, error) {
    // 1. Сначала пробуем запрос по UDP
    udpAnswers, truncated, err := makeDNSQueryOverUDP(domain)
    if err != nil {
        return nil, err
    }

    // 2. Проверяем флаг TC (Truncated) в ответе
    if truncated {
        fmt.Println("Ответ усечен (TC=1), повторяем запрос по TCP")
        // 3. Повторяем тот же запрос, но используя TCP
        tcpAnswers, err := makeDNSQueryOverTCP(domain)
        if err != nil {
            return nil, err
        }
        return tcpAnswers, nil
    }

    return udpAnswers, nil
}

Ключевые технические отличия в реализации

• Соединение: TCP требует установки соединения (SYN, SYN-ACK, ACK) перед обменом данными и его корректного закрытия. UDP работает без установления соединения.
• Формат сообщения: В TCP первые два байта DNS-сообщения указывают его длину (в байтах). Это позволяет корректно читать поток данных. В UDP длина сообщения определяется размером полученной датаграммы.
• Надежность: TCP гарантирует доставку, целостность данных и порядок пакетов. UDP не дает таких гарантий — пакеты могут быть потеряны, продублированы или прийти в неправильном порядке.

Вывод для разработчика

Понимание двойственной природы DNS (UDP/TCP) критически важно:

• При разработке сетевого софта или мониторинга: Нельзя блокировать TCP-порт 53 на firewall, разрешая только UDP. Это приведет к невозможности получения крупных ответов и сбоям в передаче зон.
• При написании DNS-клиента или резолвера: Корректная реализация должна проверять флаг TC и уметь повторять запрос по TCP. Пакет net в Go делает это автоматически.
• В архитектуре высоконагруженных DNS-серверов: Необходимо учитывать нагрузку как от миллионов коротких UDP-запросов, так и от меньшего количества, но ресурсоемких долгоживущих TCP-соединений для AXFR или больших ответов.

Таким образом, DNS — это протокол прикладного уровня, который использует и UDP, и TCP в качестве транспорта, выбирая наиболее подходящий в зависимости от задачи, что является классическим примером эффективного и гибкого дизайна сетевых протоколов.