Тема
Полномочия делегирования DNS
В фасете «Тема» значение «DNS» объединяет статьи по конкретной теме или предмету наблюдения. Здесь собраны связанные публикации, источники, участники рынка и последствия для инфраструктуры. Страница помогает сравнить повторяющиеся сигналы, затронутые организации, непрерывность услуг, закупки, конкуренцию, соблюдение требований и вопросы стратегического планирования, а также понять, почему тема важна операторам, заказчикам, инвесторам и специалистам по политике.
Истории
В реестре AuthDNS RIPE NCC — 43 узла, но нет учёта охвата сетей доступа
Цель RIPE NCC сформулирована не как пополнение карты: AuthDNS должен появляться в крупных сетях доступа, у их пиринговых соседей или на площадках IXP, откуда можно дотянуться до недостаточно обслуживаемой аудитории. Публичный список подтверждает работу 43 размещённых узлов, но…
Облачные сервисы Европы и Ближнего Востока
Genesis Cloud: почему DNS, реестр, маршруты и пиринг не доказывают единую цепочку контроля
Публичная инфраструктура Genesis Cloud распадается на несколько разных уровней доказательств: домен и DNS, регистрационные объекты, заявленная политика маршрутизации, наблюдаемые анонсы и декларации участников пиринга. Доступный пакет текущих снимков не подтверждает значения этих…
ICANN
Как миссия ICANN превращается в договорную власть
ICANN не является универсальным интернет-регулятором. Его практическое влияние возникает через ограниченную миссию, выработанные сообществом политики и договоры с реестрами и регистраторами — а способ оспаривания зависит от конкретного инструмента и положения заявителя.
ICANN
Как ICANN превратил продление .COM в договорное решение
Продление соглашения о реестре .COM показывает, как власть в системе доменных имён действует не одним распоряжением, а последовательностью институциональных переходов: публичное обсуждение формирует контекст, Совет ICANN принимает решение, уполномоченные должностные лица…
ICANN
Власть ICANN: от устава и контрактов к контролю и средствам исправления
ICANN управляет доменной системой не одним источником публичной власти, а связкой уставных полномочий, институциональных процедур, контрактных обязанностей и узких механизмов подотчётности. Это различие определяет, кто может оспорить решение и какой результат вообще способен дать…
ICANN
Как устроена власть ICANN: от корпоративной миссии до технического последствия
Практическая власть ICANN не вытекает из единого публичного мандата. Она собирается из корпоративных документов, многосторонних процедур, договоров с операторами доменов и регистраторами, технических соглашений после перехода управления функциями IANA и отдельных каналов проверки…
IETF
Shumon Huque и pin расширения, обещавший доказательство, а не вечный DANE
Проверяемое состояние может измениться, не превращаясь в неизвестность. Именно такую границу проводит RFC 9102: сервер вправе отказаться от TLSA или защищённого делегирования, но пока действует pin, он обязан показать клиенту подтверждённое DNSSEC новое состояние. Обещание…
ICANN
Как ICANN превращает координацию интернет-идентификаторов в систему договорного контроля
ICANN не является универсальным государственным регулятором Интернета. Его влияние складывается из нескольких разных механизмов: уставных полномочий самой организации, договоров с реестрами и регистраторами, делегированных операционных обязанностей и процедур подотчётности. Чтобы…
IETF
Сервис ответил. Ключ Onion — ещё нет: RFC 9799
Выданный сертификат показывает итог, но скрывает развилку, на которой центр сертификации выбрал источник CAA. RFC 9799 допускает два пути — зашифрованный дескриптор и подписанный набор внутри ACME — и одновременно требует отдельного доказательства владения ключом, породившим имя…
Облачные сервисы мира
almazcloud.network и AS210328: что действительно можно подтвердить по открытым данным
Проверка публичных реестров, маршрутизации, DNS, веб-присутствия и профильных сетевых баз показывает прежде всего границы доказуемого: наличие конечных точек проверки ещё не подтверждает ни работу сети, ни предоставление облачных услуг клиентам.
IETF
Paul Mockapetris и бит авторитетного ответа, который не охватывал весь пакет
DNS-сервер может быть авторитетным для первого имени, добавить цель псевдонима из кэша и приложить адреса для следующего шага. Бит AA при этом правдив; ошибается хранилище, которое объявляет авторитетным весь ответ.
IETF
Типы DNS 69 и 70 передают смысл внешнему реестру, но не называют его версию
При разборе инцидента два инженера могут проверить один и тот же подписанный RRset и получить одинаковые байты, но разное историческое значение кода. Причина находится не в DNSSEC, а по другую сторону институциональной границы: таблица, которая объясняет код, меняется по…
Институты Европы и Ближнего Востока
Интернет-инфраструктура Foundation: где заканчивается реестр .se и начинается система IP-ресурсов
Название The Internet Infrastructure Foundation в каталоге указывает на инфраструктурную организацию, но само по себе не доказывает ни юридическую идентичность, ни полномочия. Проверка публичных записей ведёт к более узкой и практически важной картине: Internetstiftelsen связана…
Истории
AFRINIC называет панель NS2 «реальным временем». Все 12 связанных измерений — остановленные разовые тесты
Страница может обновиться только что, а показать наблюдение многомесячной давности. Именно это различие теряется на публичной панели NS2 AFRINIC: интерфейс обещает мониторинг anycast «в реальном времени», хотя все подключённые к нему измерения RIPE Atlas были однократными и уже…
Истории
Резервный план DNS — ещё не второй резолвер
Домашний случай, опубликованный 9 сентября в блоге APNIC, даёт точный критерий отказоустойчивости: запасной сервис должен работать, попасть в настройки клиентов, пройти контролируемое переключение и позволить восстановить прежнее состояние.
Истории
Обновлению K-root в RIPE NCC нужны три акта приёмки, а не единый статус пакета
RIPE NCC заменяет оборудование с истёкшим жизненным циклом на трёх основных площадках K-root. Однако глобальная доступность сервиса не отвечает на главный вопрос управления проектом: завершена, проверена и принята ли работа отдельно в Амстердаме, Лондоне и Токио?
Институты: тенденции мира
Практическая власть ISC: операционные контуры и проверяемость подотчётности
Публичные материалы Internet Systems Consortium показывают, как консорциум соединяет программное обеспечение, инфраструктуру и операционные практики в критически важных интернет-зависимостях. Но видимая техническая роль сама по себе не отвечает на вопрос о пределах власти. Для…
IETF
Запись `_for-sale` сообщает о продаже, но не подтверждает полномочия продавца
Машиночитаемая отметка в DNS помогает начать переговоры о доменном имени. Но она не отвечает, кто вправе связать владельца обязательствами, действует ли указанная сумма и состоится ли передача. RFC 10023 стандартизирует сигнал обнаружения. Задача управления — не позволить…
IETF
Стандарты IETF как операционная зависимость: кто управляет непрерывностью Интернета
Стандарты IETF не управляют сетями напрямую. Но, задавая совместимые конечные автоматы, правила восстановления и контуры безопасности, они распределяют ответственность за непрерывность между разработчиками протоколов, операторами сетей, измерительными системами и институтами…
IETF
DNSOP приняла проблему нескольких алгоритмов, а не метку UNIVERSAL
Решение о принятии черновика часто пересказывают одним словом — «поддержан». В итоговом письме DNSOP за этим словом сразу следует ограничение: предложенный механизм считают сложным, и эту сложность предстоит разбирать рабочей группе. Именно две части вместе фиксируют новое…