Всегда ли 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-сервера, и, возможно, в конечном итоге происходит передача по TCP)
Можно ли изменить DNS-запросы для использования TCP? Будет ли DNS-сервер принимать и отвечать на DNS-запрос, поступающий по TCP?
Не уверен, актуален ли он, но мы ограничиваем DNS-запросы к авторизованным DNS-серверам и блокируем весь остальной исходящий трафик через порт 53. Я определенно новичок , извините, если мой вопрос не соответствует требованиям, и дайте мне знать, как мне изменить.
Обычные запросы DNS используют порт 53 UDP, но более длинные запросы (> 512 октетов) получат «усеченный» ответ, что приведет к диалог TCP 53 для облегчения отправки / получения всего запроса. Кроме того, DNS-сервер связывается с портом 53, но сам запрос исходит из случайного порта с большим номером (49152 или выше), отправляемого на порт 53. Ответ будет возвращен на этот же порт с порта 53.
Сетевые порты Используется DNS | Microsoft Docs
Итак, если вы планируете отслеживать DNS-запросы из вашей сети, вам необходимо принять во внимание вышеизложенное.
Что касается трафика без поиска, учтите, что DNS также использует передачу зон (тип запроса AXFR) для обновления других DNS-серверов новыми записями. Атака «человек в середине» может начать с такой передачи, выполняя DDOS-атаки на первичный сервер имен, так что он слишком занят, чтобы отвечать на вторичный запрос об обновленных записях. Затем хакер подделывает тот же первичный сервер для передачи «отравленных» записей вторичному серверу, который перенаправляет популярные домены DNS на скомпрометированные хосты.
Таким образом, ваш аудит безопасности должен уделять пристальное внимание типу запроса AXFR, а ваши системы DNS должны принимать обмены AXFR только с определенных IP-адресов.
Не следует фильтровать TCP / 53 ни в каком направлении.
Например, запросы nsupdate могут использовать TCP, как только запрос становится слишком большим (что может произойти быстро). Таким образом, вы должны позволить UDP и TCP для порта 53 (в IPv4 и V6!) Течь во всех направлениях.
Также все больше и больше идет работа над DNS через TLS, поэтому TCP потребуется в обоих направлениях. См. RFC7858.
Там есть RFC 7766, DNS-транспорт по TCP - требования реализации .
- Введение
Большинство DNS [ RFC1034 ] транзакции выполняются через UDP [ RFC768 ]. TCP [ RFC793 ] всегда используется для передачи полной зоны (с использованием AXFR) и часто используется для сообщений, размер которых превышает размер протокола DNS. исходный предел в 512 байт. Растущее развертывание безопасности DNS (DNSSEC) и IPv6 увеличили размер ответа и, следовательно, использование ПТС. Потребность в увеличении использования TCP также была вызвана обеспечивает защиту от подмены адресов и, следовательно, использование DNS в атаках отражения / усиления. Сейчас широко используется в ограничении скорости ответа [ RRL1 ] [ RRL2 ]. Кроме того, недавняя работа над решениями конфиденциальности DNS, такими как [ DNS-over-TLS ] - еще один стимул для пересмотра DNS-over-TCP. требований.
Раздел 6.1.3.2 [RFC1123] гласит:
DNS-преобразователи и рекурсивные серверы ДОЛЖНЫ поддерживать UDP и ДОЛЖНЫ поддержка TCP для отправки запросов (без передачи зон).Однако некоторые разработчики посчитали, что приведенный выше текст означает что поддержка TCP является дополнительной функцией протокола DNS.
Большинство операторов DNS-серверов уже поддерживают TCP, а конфигурация по умолчанию для большинства программных реализаций - поддержка TCP. Основная аудитория этого документа - разработчики чья ограниченная поддержка TCP ограничивает взаимодействие и препятствует развертывание новых функций DNS.
Таким образом, в этом документе обновляются основные спецификации протокола DNS. таким образом, поддержка TCP отныне является ОБЯЗАТЕЛЬНОЙ частью полного DNS. реализация протокола.
Существует несколько преимуществ и недостатков более широкого использования TCP (см. Приложение A ), а также детали реализации, которые требуют быть рассмотренным. В этом документе рассматриваются эти проблемы и представлены TCP в качестве допустимой транспортной альтернативы для DNS. Расширяет содержание из [ RFC5966 ], с дополнительными соображениями и извлеченными уроками от исследований, разработок и внедрения TCP в DNS и в другие Интернет-протоколы.
Хотя этот документ не содержит особых требований для операторов DNS-серверы, чтобы встретиться, он предлагает операторам некоторые предложения по помочь обеспечить поддержку TCP на их серверах и в сети. оптимальный. Следует отметить, что отсутствие поддержки TCP (или блокирование DNS через TCP на сетевом уровне), вероятно, приведет к сбой разрешения и / или таймауты на уровне приложения.
Это началось как комментарий к ответу Джорджа, но получилось длинным. Общая картина несколько сложна, поскольку требует некоторого понимания истории.
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 байт являются недопустимыми, но это одно из нескольких.
Если мы разберем это на наблюдаемое поведение:
- DNS-запросы обычно запускаются как UDP, если заранее не известно, что ответ будет слишком большим для начала. (зональные передачи)
- Ответ может инициировать повторную попытку TCP в клиенте, если замечен усеченный ответ. Это довольно хорошо поддерживается.
- Ответ UDP размером более 512 байт может быть виден, если клиент использовал EDNS (0) для объявления большей полезной нагрузки, и принимающий сервер поддерживает это. Это произойдет только , если оборудование, находящееся между ними, не мешает и не приводит к отброшенному или искаженному пакету.
- Клиент может решить повторить запрос EDNS (0) с меньшая заявленная полезная нагрузка, если ответ не виден, но особенности будут различаться в зависимости от реализации.
- Важно отметить, что окончательный ответ может быть слишком большим, чтобы соответствовать запрошенному размеру, что приводит к поведению № 2, описанному выше. (Старая попытка TCP)
- Клиентская сторона может запомнить размер, который в конечном итоге привел к успеху. Это позволяет ему не тратить лишние запросы на повторное исследование. Поступить иначе было бы довольно расточительно, особенно если конечный результат требует отката TCP.
Вы также должны помнить, что RFC 7766 допускает повторное использование соединения через TCP , и возможно возникновение конвейерной обработки запросов через ПТС в дикой природе. Некоторые инструменты не обнаруживают DNS-запросы помимо тех, которые были впервые замечены в сеансе TCP, примером чего является dnscap.