EDNS UDP size: объявленная ёмкость клиента не подтверждает возможности пути
Фотография конкретного исполнения не приложена.
EDNS позволяет запросившей стороне указать максимальный UDP payload, который её сетевой стек способен принять и собрать. Это не доказательство, что весь путь до сервера пропустит ответ такого размера. RFC 6891 прямо различает возможности получателя и возможный меньший path MTU.
Фрагментация, потеря одного фрагмента либо правила промежуточного устройства способны нарушить получение большого ответа. Поэтому увеличение advertised size не является универсальным исправлением DNS-тайм-аутов. Параметр выбирают по наблюдаемому пути и поведению конкретной реализации, не превращая старый пример размера в обязательную норму для всех сетей.
В проекте сохраняют размер запроса, фактический ответ и предусмотренный fallback. Маленький A-ответ не создаёт достаточной нагрузки для проверки этой границы. Нужно учитывать изменение состава данных и разные маршруты, которыми пользуются реальные узлы инфраструктуры, а не только административная рабочая станция.
В приёмке используют согласованные ответы разных размеров и наблюдают завершение запроса, а не только отправленный EDNS-параметр. Проверяют, как клиент восстанавливается при недоступной UDP-передаче нужного размера. Правильно объявленный предел клиента не подтверждает отсутствие фильтрации или успешную сборку фрагментов на всём пути.
Основание — Selected IETF DNS RFCs, exact numbers and sections cited; Linux/glibc manual where explicitly stated, разделы RFC6891 §6.2.3 Requestor payload size. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Реальные зоны, resolver и HTTP-клиенты не испытывались. Это проектные критерии; номера RFC обозначают документы, а не подтверждённую поддержку всех возможностей конкретным устройством.