Инициатива DNS flag day 2020 для решения проблем с фрагментацией и поддержкой TCP
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Сегодня ряд крупных 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 указан как желательный, но не обязательный для работы. Новые RCF 7766 и RCF 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
===========
Источник:
OpenNet.RU
===========
Похожие новости
- Главная ссылка к новости (https://dnsflagday.net/2020/...)
- OpenNews: Крупнейшие DNS-сервисы и серверы прекратят поддержку проблемных реализаций DNS
- OpenNews: Атака NXNSAttack, затрагивающая все DNS-резолверы
- OpenNews: DNS Push-уведомления получили статус предложенного стандарта
- OpenNews: Почти половина трафика на корневые DNS-серверы вызвана активностью Chromium
- OpenNews: Выпуск DNS-сервера KnotDNS 3.0.0
Похожие новости:
- Уязвимости в PowerDNS Authoritative Server
- [DNS, IPv6, Интернет вещей, Сетевые технологии] Конференция ENOG17 состоится online
- Выпуск DNS-сервера KnotDNS 3.0.0
- В Chrome для Android включена поддержка DNS-over-HTTPS
- Почти половина трафика на корневые DNS-серверы вызвана активностью Chromium
- Обновление DNS-сервера BIND 9.11.22, 9.16.6, 9.17.4 с устранением 5 уязвимостей
- [Системное администрирование, Сетевые технологии, Серверное администрирование] Что происходит, когда вы обновляете свой DNS (перевод)
- [Реверс-инжиниринг] Модифицируем Last Epoch — От dnSpy до Ghidra
- [*nix, Виртуализация] Дружим Docker и dnscrypt-proxy
- [Информационная безопасность, Сетевые технологии, Системное администрирование] SIGRed — новая критическая уязвимость в Windows Server. Как защититься?
Теги для поиска: #_dns
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:37
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Сегодня ряд крупных 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 указан как желательный, но не обязательный для работы. Новые RCF 7766 и RCF 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-серверах отвечают следующие параметры: options {
edns-udp-size 1232; max-udp-size 1232; };
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:37
Часовой пояс: UTC + 5