Чи завжди запити 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-адрес.

Читальний зал Інституту ДАНС ІнфоСек | 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 (DNSSEC) та IPv6 збільшує розміри відповідей, а отже, і використання TCP. Необхідність в більшому використанні TCP також зумовлена ​​захистом, який він забезпечує від підробляння адреси та, отже, експлуатації DNS при атаках відображення / посилення. Зараз він широко використовується в обмеженні швидкості реакцій [ RRL1 ] [ RRL2 ]. Крім того, нещодавно працювали над рішеннями конфіденційності DNS, такими як [ DNS-over-TLS] - ще одна мотивація переглянути вимоги DNS-над-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.