Тема
Полномочия делегирования DNS
В фасете «Тема» значение «DNS» объединяет статьи по конкретной теме или предмету наблюдения. Здесь собраны связанные публикации, источники, участники рынка и последствия для инфраструктуры. Страница помогает сравнить повторяющиеся сигналы, затронутые организации, непрерывность услуг, закупки, конкуренцию, соблюдение требований и вопросы стратегического планирования, а также понять, почему тема важна операторам, заказчикам, инвесторам и специалистам по политике.
Истории
В Панаме пять корневых идентификаторов и шесть зарегистрированных экземпляров
В апрельской публикации LACNIC за 2026 год названы пять идентификаторов корневых серверов в Панаме. Позднее полученные записи операторов дают сумму в шесть экземпляров. Это разные единицы учёта и даты. График времени ответа ставит ещё один вопрос: какой маршрут и какой экземпляр…
Истории
Два сигнала APNIC о корневом ключе измеряют разное
С 11 октября корневая зона DNS должна начать подписываться ключом KSK-2024. В последних измерениях APNIC рядом с этой датой стоят два процента: один основан на сигналах от резолверов, другой — на тестах конечных систем за проверяющими DNSSEC резолверами. У этих показателей разные…
История
Кто мог подать заявку на домен верхнего уровня? Первый перечень RFC 920
В октябре 1984 года цифра в 500 узлов обозначала общее ожидание для домена верхнего уровня, а 50 узлов на следующем уровне — лишь очень мягкую рекомендацию. Между этими числами RFC 920 описал не арифметический порог, а порядок допуска: какие категории имели право на существование…
История
Кэш сменил адрес назначения, но не корень: перенаправление InterNIC проектом AlterNIC в 1997 году
Резолвер в сети одного оператора вернул адрес AlterNIC для `www.internic.net`. Запись кэша показывает путь: дополнительные данные DNS превратились в локальный ответ. Это доказывает смену назначения у одного резолвера, но не переход контроля над публичным корнем.
ICANN
Заявка на `.mcp` превращает участие в протоколе в условие получения домена
В предварительную группу конкурирующих заявок на `.mcp` вошли пять участников. Charleston Road Registry, работающая под брендом Google Registry, предлагает допускать к регистрации доменов второго уровня только четыре категории участников Model Context Protocol (MCP). В заявке…
Лидеры
Tina Dam и тест корневой зоны, который не мог одобрить доменное имя
Перед добавлением интернационализированного домена верхнего уровня в корень ICANN задала намеренно узкий вопрос: повлияют ли кодированные метки на серверы и резолверы, передающие запросы DNS дальше? Лабораторный тест ответил на него только в смоделированной среде. Он не мог…
ICANN
Пять заявителей `.agent` встречаются как минимум в одиннадцати группах ICANN
В первой CSV-выгрузке ICANN по раунду 2026 в группу `.agent` вошли 13 заявителей. Пять из этих заявительских организаций присутствуют как минимум в одиннадцати пронумерованных группах файла. Поэтому спор за одну строку можно рассматривать и через более широкий портфель заявок.
История
Одна регистрация резервировала набор вариантов, а не одну метку: RFC 3743
При регистрации доменного имени с китайскими, японскими или корейскими символами объект управления может быть шире видимой строки. В 2004 году Joint Engineering Team (JET) предложила объединять выбранные варианты символов в один пакет резервирования, закреплённый за одним…
ICANN
Показатель ICANN в 56,4% указывает на связь, а не на общего владельца
В новом докладе OCTO при ICANN говорится, что у 56,4% ограниченной выборки новых gTLD-доменов, попавших в списки репутационных угроз в 2025 году, был хотя бы один технически связанный домен. Это может расширить направление расследования, но не доказывает общего владельца или…
ICANN
Справочник UCAS помогает проверке, но не заменяет решение реестра
5 октября ICANN сообщила о публикации справочных правил второго уровня для Unified Canadian Aboriginal Syllabics (UCAS). Проект рассчитан на сосуществование с французскими IDN в одной зоне, однако сама публикация не подтверждает одобрение таблицы реестра или её внедрение.
Облачные сервисы Европы и Ближнего Востока
Genesis Cloud: что документированный дизайн пиринга и DNS дал — и не дал — для передачи данных ИИ-нагрузок
Документированная схема удалённого пиринга через DE-CIX реальна и публично анонсирована, а вендор приписывает ей конкретные улучшения задержки. Но 10-гигабитный канал — это осознанная граница пропускной способности, а наблюдаемое состояние маршрутизации в 2026 году не…
IETF
Запись в реестре протоколов сохранилась. Работающего сервиса из этого не следует.
IANA по-прежнему перечисляет пространство имён `dchk1`, метку `DCHK1` и профиль BEEP. Это точные и важные записи. Но если по ним объявить сервис развернутым, институциональный реестр превратится в телеметрию, которой он никогда не был. RFC 5144 полезен именно тогда, когда…
IETF
Ответ был авторитетным. Описание резолвера всё равно могло ошибаться: RFC 9606
RFC 9606 позволяет DNS-резолверу публиковать выбранные свойства приватности и фильтрации в общей форме. Защищённое происхождение такой карточки ещё не является наблюдением за каждой обработанной резолвером записью.
IETF
Номер алгоритма зарегистрировали. Путь валидации — нет: RFC 9558
Запись DNSSEC может быть безупречной по формату, но для конкретного пользователя так и не стать доказательством: его резолвер просто не умеет выполнить указанный алгоритм.
IETF
Ключ остался дома, а публикация ушла наружу: RFC 9526
Смена домашнего префикса может оставить сразу несколько правд: новый адрес уже подписан, старый ещё находится в кэше, внешний сервер раздаёт предыдущую серию, а внутри дома имя продолжает работать. RFC 9526 показывает, почему эти состояния нельзя сводить к одному «DNS доступен».
IETF
Сервис объявил OHTTP. Но ключ всё ещё мог пометить клиента: RFC 9540
RFC 9540 позволяет через DNS обнаружить цель Oblivious HTTP, связанный шлюз и его ключевую конфигурацию. Одновременно документ проводит важную границу: корректное объявление, действительный сертификат и успешный шифрованный обмен не исключают, что уникальный ключ, путь или…
История
DNS находила точное имя, но не искала то, что имел в виду пользователь: RFC 3467
Система может безошибочно разрешить строку и всё же привести не к тому объекту. RFC 3467 провела границу между точным DNS-запросом и поиском, который должен работать с человеческой неопределённостью.
Облачные сервисы мира
Пер-префиксное расхождение в сервисных слоях DATAMATIX AS210973: что говорит каждый /24
Аналитическая справка о Пер-префиксное расхождение в сервисных слоях DATAMATIX AS210973: что говорит каждый /24 объясняет событие, доступные открытые подтверждения, участвующие организации, региональный контекст, рыночные риски и возможные последствия для инфраструктуры. В…
IETF
Идентификатор совпал. Хэш RRset и происхождение кэша никто не сохранил
Резолвер сравнил два 16-битных значения и отказался от полной загрузки. Позже журнал подтвердил только равенство коротких чисел. Он не мог показать, какой именно большой RRset стоял за каждым числом и относились ли они к одной эпохе.
IETF
Ответ пришёл от сети. Принадлежность ответа приёмнику не была доказана.
Дочерняя зона подписала запрос SIG(0), но получила неподписанный ответ о неизвестном ключе. Автоматика начала повторную загрузку ключа. В построенном примере подлинность запроса защищала родителя, а отсутствие обратного доверия оставляло ребёнка открытым для ложного сигнала о…