Назад | Перейти на главную страницу

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

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

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

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

Не уверен, что это актуально, но мы ограничиваем 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-адресов.

Читальный зал информационной безопасности Института 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 Transport over TCP - Требования к реализации.

  1. Введение

Большинство DNS [RFC1034] транзакции выполняются через UDP [RFC768]. TCP [RFC793] всегда используется для передачи полной зоны (с использованием AXFR) и часто используется для сообщений, размер которых превышает исходный предел протокола DNS в 512 байт. Растущее развертывание безопасности DNS (DNSSEC) и IPv6 привело к увеличению размеров ответов и, следовательно, к увеличению использования TCP. Необходимость более широкого использования TCP также обусловлена ​​защитой, которую он обеспечивает от подмены адресов и, следовательно, использования DNS в атаках отражения / усиления. Сейчас он широко используется в разделе «Ограничение скорости ответа» [RRL1] [RRL2]. Кроме того, недавняя работа над решениями для обеспечения конфиденциальности DNS, такими как [DNS-поверх-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 есть несколько преимуществ и недостатков (см. Приложение), а также детали реализации, которые необходимо учитывать. Этот документ решает эти проблемы и представляет TCP как допустимую транспортную альтернативу для DNS. Он расширяет содержание [RFC5966] с дополнительными соображениями и уроками, извлеченными из исследований, разработок и внедрения TCP в DNS и других Интернет-протоколах.

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

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

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