HOME    FORUMS    MEMBERS    RECENT POSTS    LOG IN  
Баннер 1   Баннер 2

ANTICHAT — форум по информационной безопасности, OSINT и технологиям

ANTICHAT — русскоязычное сообщество по безопасности, OSINT и программированию. Форум ранее работал на доменах antichat.ru, antichat.com и antichat.club, и теперь снова доступен на новом адресе — forum.antichat.xyz.
Форум восстановлен и продолжает развитие: доступны архивные темы, добавляются новые обсуждения и материалы.
⚠️ Старые аккаунты восстановить невозможно — необходимо зарегистрироваться заново.
Вернуться   Форум АНТИЧАТ > ИНФО > Мировые новости. Обсуждения.
   
Ответ
 
Опции темы Поиск в этой теме Опции просмотра

  #1  
Старый 01.10.2020, 23:47
Suicide
Познавший АНТИЧАТ
Регистрация: 24.04.2009
Сообщений: 1,730
Провел на форуме:
30140275

Репутация: 3256


По умолчанию

Сегодня ряд крупных DNS-сервисов и производителей DNS-серверов проведут совместное мероприятие DNS flag day 2020, призванное сфокусировать внимание на решении проблем с IP-фрагментацией при обработке DNS-сообщений большого размера. Это второе подобное мероприятие, в прошлом году "DNS flag day" был сосредоточен на корректной обработке запросов EDNS.

Участники инициативы DNS flag day 2020 призывают зафиксировать рекомендованные размеры буферов для EDNS до значений на уровне 1232 байтов (размер MTU 1280 минус 48 байт для заголовков), а также перевести обработку запросов по TCP в разряд обязательно поддерживаемых на серверах. В RFC 1035 обязательной помечена только поддержка обработки запросов по UDP, а TCP указан как желательный, но не обязательный для работы. Новые RFC 7766 и RFC 5966 явно относят TCP к числу обязательных возможностей, необходимых для корректной работы DNS. В рамках проводимой инициативы предлагается форсировать переход от отправки запросов по UDP к применению TCP в случаях, когда установленного размера буфера EDNS недостаточно.

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

Начиная с сегодняшнего дня участвующие в инициативе провайдеры DNS, включая CloudFlare, Quad 9, Cisco (OpenDNS) и Google, постепенно поменяют размер буфера EDNS с 4096 до 1232 байт на своих DNS-серверах (изменение EDNS будет растянуто на 4-6 недель и со временем будет охватывать всё большее число запросов). Ответы на UDP-запросы, не укладывающиеся в новое ограничение, будут отправляться по TCP. Производители DNS-серверов, включая BIND, Unbound, Knot, NSD и PowerDNS выпустят обновления с изменением размера буфера EDNS по умолчанию с 4096 до 1232 байт.

В конечном счёте, вводимые изменения могут привести к проблемам с резолвингом при обращении к DNS-серверам, DNS-ответы которых по UDP превышают 1232 байт, и которые не могут отправить ответ по TCP. Проведённый в Google эксперимент показал, что изменение размера буфера EDNS практически не повлияет на уровень сбоев - при буфере в 4096 байт число урезаемых запросов UDP составляет 0.345%, а число недостижимых повторных ответов по TCP - 0.115%. При буфере в 1232 байт эти показатели составляют 0.367% и 0.116%. Перевод поддержки TCP в разряд обязательных возможностей DNS приведёт к проблемам при взаимодействии с около 0.1% DNS-серверов. Отмечается, что в современных условиях без TCP работа данных серверов и так нестабильна.

Администраторам авторитетных (authoritative) DNS-серверов следует убедиться, что их сервер отвечает по TCP на сетевом порту 53 и данный TCP-порт не блокируется межсетевым экраном. Авторитетный DNS-сервер также не должен отправлять UDP-ответы, размер которых превышает запрошенный размер буфера EDNS. На самом сервере размер буфера EDNS должен быть установлен в 1232 байт. К резолверам предъявляются примерно такие же требования - обязательная возможность ответа по TCP, обязательная поддержка отправки повторных запросов по TCP при получении урезанного ответа UDP и установка буфера EDNS в 1232 байт.

За настройку размера буфера EDNS в разных DNS-серверах отвечают следующие параметры:

BIND

options {

edns-udp-size 1232;

max-udp-size 1232;

};

Knot DNS

max-udp-payload: 1232

Knot Resolver

net.bufsize(1232)

PowerDNS Authoritative

udp-truncation-threshold=1232

PowerDNS Recursor

edns-outgoing-bufsize=1232

udp-truncation-threshold=1232

Unbound

edns-buffer-size: 1232

NSD

ipv4-edns-size: 1232

ipv6-edns-size: 1232

 
Ответить с цитированием

  #2  
Старый 02.10.2020, 11:28
altblitz
Постоянный
Регистрация: 05.06.2009
Сообщений: 706
Провел на форуме:
2764047

Репутация: 759


Отправить сообщение для altblitz с помощью ICQ
По умолчанию

Цитата:
Сообщение от Suicide  
Suicide said:

Сегодня ряд крупных DNS-сервисов и производителей DNS-серверов проведут совместное мероприятие
DNS flag day 2020
, призванное сфокусировать внимание на
решении
проблем
с IP-фрагментацией при обработке DNS-сообщений большого размера. Это второе подобное мероприятие, в прошлом году "DNS flag day"
был сосредоточен
на корректной обработке запросов EDNS.
...
На стороне клиента размер буфера EDNS будет постоянным, а большие ответы сразу будут отправляться клиенту по TCP. Исключение отправки больших сообщений по UDP также решит проблемы с отбрасыванием больших пакетов на некоторых межсетевых экранах и позволит блокировать
атаки
по отравлению кэша DNS, основанные на манипуляции фрагментированными UDP-пакетами (при разбиении на фрагменты, второй фрагмент не включает заголовок с идентификатором, поэтому может быть подделан для чего достаточно только чтобы совпадала контрольная сумма).
01.10.2020
Таки заметно, в неделю эту, что на сайтах где контент, images/audio/video загружается с десятка и более сторонних сайтов,

перестали загружаться линки. Пусть они исправят их по-правильному!



Хотя, может и стоит оно того, чтобы изменить DNS servers в конфигурации?
 
Ответить с цитированием
Ответ





Здесь присутствуют: 1 (пользователей: 0 , гостей: 1)
 


Быстрый переход




ANTICHAT.XYZ