Тема
Полномочия делегирования DNS
В фасете «Тема» значение «DNS» объединяет статьи по конкретной теме или предмету наблюдения. Здесь собраны связанные публикации, источники, участники рынка и последствия для инфраструктуры. Страница помогает сравнить повторяющиеся сигналы, затронутые организации, непрерывность услуг, закупки, конкуренцию, соблюдение требований и вопросы стратегического планирования, а также понять, почему тема важна операторам, заказчикам, инвесторам и специалистам по политике.
Истории
RIPE NCC сохранил проверки неработающих делегирований и прекратил письма
В 2009 году техническое наблюдение не прекратилось. RIPE NCC продолжил периодически проверять неработающие DNS-делегирования, но отказался от массовых уведомлений по электронной почте. Этот исторический случай показывает, почему обнаружение, доставка сигнала, внимание оператора…
ICANN
У блокировки autistici.org есть точное время, но нет публичной записи решения
RDAP реестра `.org` показывает `serverHold` и момент изменения домена. Однако открытые материалы не отвечают, кто превратил американское санкционное решение в действие на уровне реестра, на каком основании это сделали, почему раньше окончания лицензии на сворачивание операций и…
ICANN
Как ICANN превращает политику в обязательство — и где заканчивается обжалование
ICANN координирует уникальные интернет-идентификаторы не одним регуляторным актом, а цепочкой уставных документов, одобренных сообществом политик, договоров с реестрами и регистраторами, процедур контрактного контроля и механизмов подотчётности. Практическая сила этой конструкции…
Облачные сервисы мира
Genesis Cloud: почему видимость маршрута не равна непрерывности облачного сервиса
Аналитическая справка о Genesis Cloud: почему видимость маршрута не равна непрерывности облачного сервиса объясняет событие, доступные открытые подтверждения, участвующие организации, региональный контекст, рыночные риски и возможные последствия для инфраструктуры. В категории…
ICANN
Как устроена и оспаривается власть ICANN
ICANN действует не как единый регулятор с одним источником полномочий. Ее операционная власть складывается из нескольких уровней: учредительных документов, процедур выработки политик, договоров с регистраторами и реестрами, а также отдельных механизмов подотчетности. Поэтому…
Истории
В опыте APNIC с двумя серверами повторов стало меньше, но для причинного вывода нужна квитанция воспроизводимости
В более позднем опыте с двумя авторитетными DNS-серверами APNIC зарегистрировала меньше запросов, чем в предыдущем опыте с одним. Разница в опубликованных агрегатах реальна, но её причина не установлена. Для практического решения двум режимам нужны общие часы, сопоставимые группы…
История
RFC 2065: обычный DNS-сервер доставлял ответ, а доверие несла подпись
В январе 1997 года RFC 2065 предложил усилить DNS так, чтобы каждый узел доставки не становился судьёй ответа. Резолвер с поддержкой защиты мог получить подписанные записи через сервер, не умеющий их проверять, и самостоятельно исследовать доказательство. Не менее важной была…
Истории
Anycast-узел AFRINIC в Уганде — это две службы, а не одна
Аналитическая справка о Anycast-узел AFRINIC в Уганде — это две службы, а не одна объясняет событие, доступные открытые подтверждения, участвующие организации, региональный контекст, рыночные риски и возможные последствия для инфраструктуры. В категории Аналитика: Истории этот…
ICANN
Интеграции ICANN с альтернативными системами имен нужен проверяемый вывод
В первоначальном отчете ICANN предлагает обязать реестр заранее подготовить план отключения интеграции между gTLD и альтернативной системой имен. Такой план особенно важен потому, что дополнительный сервис, по оценке авторов, не входит в пять функций, сохраняемых аварийным…
Истории
Тест ccTLD у AFRINIC не определяет доступность сайтов по IPv6
Проверка серверов реестра полезна, но её результат нельзя переносить на все сайты ниже по иерархии. Рекурсивный резолвер способен выбрать другой транспортный путь, который объяснение AFRINIC не учитывает.
IETF
DNS ANY следует выводить из эксплуатации по назначению, а не только по коду запроса
Сервер может перестать отвечать на неоднозначный запрос за один выпуск. Задачи, ради которых клиенты его отправляли, так не исчезают. Для настоящего вывода из эксплуатации нужны явные замены, проверка результата и исключения с владельцем и сроком окончания.
IETF
Смена сервера ULD должна доказать, что локальные службы сохранились
После замены маршрутизатора сеть может выглядеть исправной: интернет доступен, новый сервер обнаружения отвечает, клиенты выбрали его по правилам. Но одна переговорная панель или принтер исчезают из списка. Это не обязательно ошибка выбора. Это другая, менее заметная проблема…
IETF
Старые подписи покупают время, но не восстанавливают DNSSEC-ключ
После отказа закрытого ключа зона может выглядеть совершенно здоровой: авторитетные серверы продолжают отдавать заранее подписанные данные, сроки RRSIG ещё не истекли, а проверяющий резолвер отвечает `Secure`. Это не восстановление, а отсрочка. Чтобы вернуть именно функцию…
IETF
DANCE 14 сводит четыре результата TLSA к двоичному решению сервера
Одинаковый `handshake_failure` может скрывать четыре разные точки остановки DNS. Не существует имя клиента; существует имя, но не запись TLSA; ответ не аутентифицирован из-за неподписанной зоны; проверка DNSSEC завершилась неудачей. В редакции DANCE 14 эти случаи перечислены…
IETF
EDE 33 может показать NTA, но не доказать, что она изменила ответ
В сообщении EDE 33 отсутствует одно важное сравнение: что тот же валидатор решил бы без Negative Trust Anchor. Проект DNSOP делает локальное исключение DNSSEC заметным для клиента, но прямо разрешает посылать код и тогда, когда исключение не оказало существенного влияния на…
Истории
У RIPE NCC было четыре устаревших IPv6 glue-записи. Осталось три: корневую зону не исправляют одним пакетом
Для `.ps` адрес glue в корне уже совпадает с текущим адресом сервера имён. Для `.ne`, `.sd` и `.tj` расхождение сохраняется. Разный исход показывает реальную единицу работы: у каждой делегации собственное разрешение, проверка и завершение.
История
Gihan Dias и два имени Шри-Ланки в корневой зоне
Провести сеть в страну — не то же самое, что дать стране место в системе имён на её собственных письменностях. Биография Gihan Dias соединяет эти две задачи: от электронной почты по коротким телефонным сеансам до сингальского и тамильского доменов верхнего уровня.
Истории
LACNIC подписывает 150 файлов обратного DNS без манифеста партии
Подпись отвечает за один файл. Чтобы ответить за всю поставку, нужна подписанная опись. В публичном каталоге LACNIC первый уровень проверки есть, а второй приходится восстанавливать по мгновенному виду веб-страницы.
История
Demi Getschko и код страны, появившийся раньше бразильского TCP/IP
18 апреля 1989 года домен `.br` уже оказался в корневой зоне DNS. Бразильские научные сети к тому времени обменивались почтой через BITNET, HEPnet и другие системы, но первый международный трафик TCP/IP по линии FAPESP пошёл лишь в январе 1991 года. История Demi Getschko…
Истории
Карта ccTLD AFRINIC насчитывает 27 зон. Для трёх нужна сверка адресов.
Публичный итог AFRINIC подтверждается, но не одним поиском по именам. В 24 делегированиях реестр виден в имени сервера. Для .so, .ng и .ml связь с NS2 обнаруживается только после сопоставления адреса с опубликованными anycast-префиксами.