DNS по TCP: соединение, полный ответ и восстановление

Реализации DNS общего назначения должны поддерживать UDP и TCP. RFC 7766 отдельно требует поддержку TCP от авторитетных серверов, рекурсивных серверов и пересылающих запросы серверов, а также от локальных DNS-клиентов.

Локальные DNS-клиенты и рекурсивные резолверы могут выбирать UDP или TCP по условиям эксплуатации. Разрешено отправить запрос по TCP до любых запросов по UDP; обязательной предварительной попытки по UDP нет.

Рекурсивный и авторитетный DNS-серверы должны отвечать тем же транспортом, которым получен запрос. Для TCP ответ должен идти по тому же соединению.

Постоянное TCP-соединение не закрывают сразу после первого ответа: сервер после отправки, клиент после получения. Повторное использование означает передачу нескольких DNS-запросов и ответов по одному соединению.

Клиентам и серверам рекомендуется поддерживать повторное использование TCP-соединения для нескольких DNS-запросов и ответов. Резолверу, у которого уже открыто соединение с нужным сервером, рекомендуется использовать это соединение.

Дополнительная задержка установления TCP-соединения обычно составляет один RTT — время обмена туда и обратно. Повторное использование позволяет распределить эти затраты между несколькими DNS-запросами.

Раздел 9 о TCP Fast Open имеет ненормативный статус. В нём описана возможность передавать данные при установлении соединения и экономить до одного RTT по сравнению с обычным TCP.

Pipelining в DNS означает передачу нескольких запросов по одному TCP-соединению без ожидания уже запрошенных ответов перед отправкой следующего запроса.

Клиентам DNS рекомендуется отправлять запросы без ожидания ответа на предыдущий запрос. При выборе момента отправки очередного запроса рекомендуется одинаково рассматривать TCP и UDP.

DNS-сервер должен быть готов получать несколько запросов подряд без ожидания ответов. Серверу рекомендуется обрабатывать TCP-запросы параллельно и отвечать на все такие запросы, даже если запросы получены с короткими интервалами.

Авторитетным серверам и рекурсивным резолверам рекомендуется поддерживать параллельную подготовку и отправку ответов вне порядка запросов. Локальные DNS-клиенты и рекурсивные резолверы должны обрабатывать ответы, пришедшие не в порядке отправки запросов.

Клиент не должен повторно использовать Message ID запроса, на который ещё ожидается ответ, в том же TCP-соединении. Это предотвращает совпадение идентификаторов одновременно ожидаемых ответов.

Клиент должен сопоставлять ответ с ожидаемым запросом в том же TCP-соединении по Message ID. Если ответ содержит секцию вопроса, должны совпасть также QNAME, QCLASS и QTYPE.

Двухоктетное поле длины и описываемое им DNS-сообщение рекомендуется передавать TCP вместе, например одним вызовом write. Это повышает вероятность передачи одним сегментом, но не гарантирует её.

DNS-сообщение может прийти в нескольких TCP-сегментах. Сервер не должен закрывать соединение только потому, что первое чтение из TCP не содержит DNS-сообщение целиком.

Для DNS-клиента соединение простаивает, когда нет ни запросов на отправку, ни ожидаемых ответов. Для DNS-сервера соединение простаивает после отправки ответов на все запросы, полученные по этому соединению.

DNS-клиенты должны принимать меры для сокращения времени простоя соединений с каждым сервером. Простаивающее соединение рекомендуется закрывать, если время простоя не установлено отдельным механизмом сигнализации.

Для серверного таймаута простоя на уровне приложения рекомендуется значение порядка секунд, без единого точного числа. При наличии ресурсов сервер может держать соединения дольше; при большой нагрузке или атаке допускается нулевой таймаут.

Отсчёт серверного таймаута простоя рекомендуется начинать заново после получения полного DNS-сообщения, а не после получения любой части сообщения.

Упоминание простоя порядка двух минут в разделе 6.1 — цитата прежнего RFC 1035. Собственные рекомендации RFC 7766 о серверном простое находятся в разделе 6.2.3 и говорят о порядке секунд без точного значения.

DNS-клиент должен принимать меры для сокращения числа одновременных TCP-соединений с одним сервером. Рекомендуется не более одного соединения для обычных запросов, одного для передачи зон и одного для каждого используемого протокола поверх TCP. При одновременной передаче нескольких активно используемых зон могут понадобиться дополнительные соединения.

Сервер может ограничивать число TCP-соединений от IP-адреса или подсети. Такие лимиты рекомендуется делать значительно мягче клиентских ориентиров: за одним адресом могут находиться несколько резолверов или клиентов, в том числе за NAT.

В качестве настраиваемых параметров RFC 7766 перечисляет общее число TCP-соединений, максимум на IP-адрес или подсеть, таймаут простоя, число DNS-транзакций на соединение и длительность соединения. Конкретные значения этих параметров документ не рекомендует.

Операторам рекурсивных серверов рекомендуется принимать соединения только от ожидаемых клиентов, например с помощью ACL, и отклонять соединения от неизвестных источников.

Обычно закрытие простаивающего соединения начинает DNS-клиент, но сервер может закрыть соединение по своему таймауту простоя. При необычных условиях, включая защиту от атаки, сбой или перезапуск, соединение может закрыть любая сторона.

Если TCP-соединение закрылось до получения всех ожидаемых ответов, DNS-клиенту рекомендуется повторить запросы, оставшиеся без ответа. Конкретный алгоритм повторов RFC 7766 не задаёт.

Если клиент закрыл TCP-соединение или соединение прервалось до отправки всех ответов, DNS-сервер не должен пытаться отправлять оставшиеся ответы. Сервер может сохранить эти ответы в кэше.

Рекурсивный и авторитетный DNS-серверы должны отвечать тем же транспортом, которым получен запрос. Для TCP ответ должен идти по тому же соединению.

Клиент должен сопоставлять ответ с ожидаемым запросом в том же TCP-соединении по Message ID. Если ответ содержит секцию вопроса, должны совпасть также QNAME, QCLASS и QTYPE.