Основное направление
DNS
В фасете «Основное направление» значение «DNS» группирует публикации по основной предметной области. В одном месте собраны статьи, открытые источники, институты, компании, люди, региональные риски, операционные зависимости и рыночный контекст. Страница объясняет границы области, основных участников и источники, на которые стоит опираться при сравнении сигналов. Она помогает увидеть, как одна тема проявляется в событиях, профилях, изменениях рынка и долгосрочных инфраструктурных решениях.
IETF
Алгоритму присвоили номер. Цепочка доверия не появилась
RFC 9563 закрепил за подписями SM2 и дайджестами SM3 идентификаторы DNSSEC. Это устраняет неоднозначность формата, но не доказывает консенсус IETF, пригодность криптографии, поддержку валидаторов или успешное аутентифицированное разрешение имени.
IETF
Резервный сервер ответил. Ключ из кеша не подошёл: RFC 8901
Второй авторитетный DNS-провайдер может продолжить отвечать после отказа первого, но валидирующий резолвер всё равно не примет ответ. RFC 8901 описывает DNSSEC-резервирование как договор синхронизации между подписантами, а не как количество серверов.
История
Gihan Dias и два имени Шри-Ланки в корневой зоне
Провести сеть в страну — не то же самое, что дать стране место в системе имён на её собственных письменностях. Биография Gihan Dias соединяет эти две задачи: от электронной почты по коротким телефонным сеансам до сингальского и тамильского доменов верхнего уровня.
Досье
Уязвимости BIND: почему выпуск исправления — только начало ремонта DNS
Публичные бюллетени ISC описывают две разные цепочки отказа в BIND: исчерпание ресурсов стека при чрезмерной рекурсии и отказ в обслуживании DNSSEC из-за чрезмерной вычислительной нагрузки. Обе истории показывают одну и ту же управленческую проблему: публикация исправления…
IETF
James Gould и сигнал редактирования, который не доказывает политику
Пустое место в ответе RDAP выглядит просто, но может иметь разное происхождение. Значение могло никогда не существовать, а могло быть скрыто от клиента с данным уровнем доступа. RFC 9537, соавтором которого стал James Gould, позволяет серверу структурированно заявить о втором…
Досье
Частные имена с публичным подтверждением
Внутренний DNS не обязан публиковать перечень служебных имён, чтобы подтвердить право отвечать за них. RFC 9704 разделяет эти задачи. Но организация всё равно должна решить, что раскрывает имя резолвера, насколько широко выдано согласие и кто отвечает за его обновление.
IETF
Suzanne Woolf и метка сервера, которая не является идентичностью машины
Идентификатор в DNS-ответе легко принять за точное имя ответившего компьютера. В сети с anycast, балансировщиками и значениями, назначаемыми оператором, это слишком сильный вывод. RFC 4892, написанный при участии Suzanne Woolf, предлагает более строгий подход: сначала связать…
IETF
Sara Dickinson и обещание резолвера, которое не доказывает шифрование
Значок замка рядом с настройкой DNS говорит правду, но только о своём участке: канал от клиента до выбранного рекурсивного резолвера защищён. Он ничего не сообщает о сроке хранения запроса, доступе сотрудников, сопоставлении сеансов, фильтрации ответа и данных, ушедших дальше.…
ICANN
Allison Mankin и выборка коллизий имён, которая не доказывала причину
Корневой сервер DNS способен точно зафиксировать имя, тип запроса и время. Но из этой строки нельзя сразу узнать приложение-источник, ответственного владельца или последствия будущего делегирования. Соавторство Allison Mankin в RFC 8023 связано именно с дисциплиной такого…
Досье
Ключ был известен, но доверять ему было рано
Самоподписанное DNS-обновление приносит родителю новый ключ и одновременно требует удалить старый. Подпись доказывает владение новым закрытым ключом, но не право менять делегирование дочерней зоны. К объявленному окончанию последнего обсуждения DNSOP 7 сентября именно переход от…
Досье
Последняя точка исчезла — граница доверия сдвинулась
Для DNS `example.co.uk` и `example.co.uk.` могут вести к одному узлу. Для приложения эти две записи способны открыть разные контуры безопасности. В день завершения последнего обсуждения DNSOP свежая уязвимость curl превращает мелкую пунктуацию в вопрос порядка: нормализуется ли…
IETF
Минимизация QNAME — это контракт последовательности запросов, а не переключатель приватности
Резолвер может сообщать о включённой минимизации QNAME, но при разном состоянии кэша раскрывать разные имена, затраты и причины сбоев. Проверять нужно не флаг, а ограниченную последовательность, которую задают известные делегации, отрицательные ответы и откаты совместимости.
Досье
DNS получил сигнал. Но решение всё ещё оставалось за родительской зоной: граница делегирования в RFC 9859
RFC 9859 ускоряет начало проверки сопровождения делегирования. Она не превращает уведомление в решение родительской стороны и не делает ответ доказательством опубликованной записи DS.