Всегда ли DNS-запросы передаются по UDP?

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

По сути, DNS-запросы когда-либо используют TCP (если так, какой сценарий это может произойти)? Опять же, я говорю только о запросах. Могут ли они путешествовать по TCP? Если длина доменов не может превышать 253 байта, а пакеты UDP могут достигать 512 байтов, разве запросы не всегда будут передаваться как UDP? Я не думал, что разрешимый запрос может быть достаточно большим, чтобы потребовать использования TCP. Если DNS-сервер когда-либо получал запрос на домен размером более 253 байт, сервер отбросит его / не попытается разрешить? Я уверен, что я сделал некоторые ложные предположения здесь.

В некоторых случаях я работаю с группой безопасности над тем, чтобы включить запросы DNS в их инструмент мониторинга безопасности, и по разным причинам мы решили, что мы будем захватывать этот трафик с помощью стандартного захвата пакетов на DNS-серверах и контроллерах домена. Основным требованием является сбор всех DNS-запросов, чтобы они могли определить, какой клиент пытался разрешить любой данный домен. Исходя из этого требования, мы не занимаемся захватом ответов DNS или другого трафика, такого как передача зон, что также обусловлено тем фактом, что нам необходимо максимально ограничить объем журнала. Таким образом, мы планируем захватывать только DNS-запросы, предназначенные для DNS-сервера и отправленные через UDP. Для большего контекста (вид области вопроса ползет здесь), теперь поднято, что нам, возможно, потребуется расширить безопасность ' s видимость, чтобы они могли отслеживать активность, такую ​​как скрытые каналы, работающие через DNS (что также потребовало бы перехватывать ответы DNS, а затем и трафик TCP). Но даже в таком сценарии я думал, что любой исходящий трафик DNS будет в форме запросов / запросов, и что они всегда будут передаваться по UDP, даже если они исходят из злонамеренного источника (из-за моих рассуждений в первом абзаце). Так что это поднимает некоторые дополнительные вопросы:

• Разве мы не смогли бы захватить половину разговора с подходом, который я обрисовал? Или клиент отправит DNS-трафик не в форме запроса? (может быть, как какой-то ответ на ответ DNS-сервера, и, возможно, в конечном итоге выходит через TCP)

• Можно ли изменить DNS-запросы для использования TCP? Будет ли DNS-сервер принимать и отвечать на запросы DNS, поступающие через TCP?

Не уверен, что это актуально, но мы ограничиваем запросы DNS только авторизованными DNS-серверами и блокируем весь остальной трафик, исходящий через порт 53. Я определенно новичок, поэтому извините, если мой вопрос не соответствует требованиям, и дайте мне знать как я должен изменить.

Обычные DNS-запросы используют UDP-порт 53, но более длинные запросы (> 512 октетов) получат «усеченный» ответ, что приводит к диалогу TCP 53 для облегчения отправки / получения всего запроса. Кроме того, DNS-сервер связывается с портом 53, но сам запрос отправляется на случайный порт с высоким номером (49152 или выше), отправленный на порт 53. Ответ будет возвращен на тот же порт с порта 53.

Сетевые порты, используемые DNS | Документы Microsoft

Таким образом, если вы планируете выполнять некоторые проверки безопасности DNS-запросов из вашей сети, вам необходимо принять во внимание вышесказанное.

Что касается трафика без поиска, учтите, что DNS также использует передачу зон (тип запроса AXFR) для обновления других DNS-серверов новыми записями. Человек, находящийся в средней атаке, может начать с такой передачи, DDOS будет использовать первичный сервер имен, чтобы он был слишком занят, чтобы ответить вторичному серверу, запрашивающему обновленные записи. Затем хакер подделывает тот же первичный сервер для передачи «отравленных» записей вторичному, который перенаправляет популярные домены DNS на скомпрометированные хосты.

Таким образом, аудит безопасности должен уделять пристальное внимание типу запроса AXFR, а ваши DNS-системы должны принимать обмены AXFR только с определенных IP-адресов.

Читальный зал InfoSec Института SANS | sans.org

Это началось как комментарий к ответу Джорджа, но это стало длинным. Общая картина несколько сложна, так как требует понимания некоторой истории.

• Изначально RFC 1035 вызывал ограничение в 512 байт, чтобы избежать фрагментации UDP. Фрагментированные дейтаграммы UDP и TCP были выбраны в качестве параметров последней инстанции, чтобы минимизировать накладные расходы на транзакции DNS. При передаче по зонам всегда используется TCP, поскольку по своей природе передачи по зонам занимают> 512 байт. (начинать с UDP вообще было бы пустой тратой)

• Повторить TCP на усечение широко поддерживается, как это было указано в RFC 1123 с 1989 года.

• EDNS (0) определено в RFC 6891 (2013), а до этого существовал в качестве предлагаемого стандарта, начиная с 1999 года . Он определяет механизм, в котором клиенты и серверы могут согласовывать размеры UDP, превышающие 512. Из-за новизны EDNS (0) многие аппаратные устройства делают предположения о структуре пакетов DNS, которые вызывают отбрасывание совместимых пакетов. Наиболее частой причиной является предположение, что сообщения DNS размером более 512 байт являются недействительными, но это одно из нескольких.

Если мы разобьем это на наблюдаемое поведение:

1. DNS-запросы обычно начинаются с UDP, если заранее не известно, что ответ будет слишком большим для начала. (зонные трансферы)
2. Ответ может инициировать повтор TCP в клиенте, если усеченный ответ виден. Это довольно хорошо поддерживается.
3. UDP - ответ больше 512 байт может быть виден , если клиент использовал EDNS (0) рекламировать большую полезную нагрузку, и принимающий сервер поддерживает. Это произойдет только в том случае, если аппаратное обеспечение, находящееся между ними, не мешает и не приводит к отбрасыванию или искалечению пакета.
4. Клиент может выбрать повторную попытку запроса EDNS (0) с меньшей объявленной полезной нагрузкой, если ответ не виден, но особенности могут отличаться в разных реализациях.
   • Важно отметить, что ответ, который в конечном итоге проходит через него, может быть слишком большим, чтобы соответствовать запрошенному размеру, что приводит к поведению № 2 выше. (вы пытаетесь повторить TCP)
   • Клиентская сторона может вспомнить размер, который в итоге привел к успеху. Это позволяет избежать ненужных запросов при повторном тестировании. Делать иначе было бы весьма расточительно, особенно если для конечного результата требовался запасной вариант TCP.

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

Там является RFC 7766, DNS транспорта через TCP - Требования к реализации .

1. Введение

Большинство транзакций DNS [ RFC1034 ] происходит через UDP [ RFC768 ]. TCP [ RFC793 ] всегда используется для полных зонных передач (с использованием AXFR) и часто используется для сообщений, размеры которых превышают исходное ограничение протокола 512 байт протокола DNS. Растущее развертывание DNS Security (DNSSEC) и IPv6 увеличило размеры ответов и, следовательно, использование TCP. Необходимость расширения использования TCP также обусловлена ​​защитой, которую он обеспечивает от подделки адресов и, следовательно, от использования DNS при атаках с отражением / усилением. В настоящее время он широко используется в ограничении скорости отклика [ RRL1 ] [ RRL2 ]. Кроме того, недавняя работа над решениями по обеспечению конфиденциальности DNS, такими как [ DNS-over-TLS] является еще одной мотивацией для пересмотра требований DNS-over-TCP.

Раздел 6.1.3.2 [RFC1123] гласит:

  DNS resolvers and recursive servers MUST support UDP, and SHOULD
  support TCP, for sending (non-zone-transfer) queries.

Однако некоторые разработчики используют приведенный выше текст для обозначения того, что поддержка TCP является необязательной функцией протокола DNS.

Большинство операторов DNS-серверов уже поддерживают TCP, и конфигурация по умолчанию для большинства программных реализаций - поддержка TCP. Основной аудиторией этого документа являются те разработчики, чья ограниченная поддержка TCP ограничивает совместимость и препятствует развертыванию новых функций DNS.

Поэтому в этом документе обновляются основные спецификации протокола DNS, так что отныне поддержка TCP является ОБЯЗАТЕЛЬНОЙ частью полной реализации протокола DNS.

Существует несколько преимуществ и недостатков более широкого использования TCP (см. Приложение A ), а также подробности реализации, которые необходимо учитывать. Этот документ решает эти проблемы и представляет TCP в качестве допустимой транспортной альтернативы для DNS. Он расширяет содержание [ RFC5966 ] с дополнительными соображениями и уроками, извлеченными из исследований, разработок и внедрения TCP в DNS и других интернет-протоколах.

Хотя этот документ не предъявляет особых требований к операторам DNS-серверов, он предлагает некоторые предложения операторам, чтобы обеспечить оптимальную поддержку TCP на их серверах и в сети. Следует отметить, что отказ от поддержки TCP (или блокировка DNS через TCP на сетевом уровне), вероятно, приведет к сбою разрешения и / или тайм-аутам на уровне приложения.

Вы не должны фильтровать TCP / 53 в любом направлении. Например, nsupdateзапросы могут использовать TCP, как только запрос становится слишком большим (что может произойти быстро). Таким образом, вы должны позволить UDP и TCP для порта 53 (в IPv4 и V6!) Течь во всех направлениях.

Также все больше и больше работы в направлении DNS через TLS, поэтому TCP потребуется в обоих направлениях. См. RFC7858.