ICANN начинает процесс отказа от доменного имени .SU, оставшегося со времён СССР

ICANN начинает процесс отказа от доменного имени .SU, оставшегося со времён СССР

ICANN сообщила оператору доменной зоны .su о планах по её постепенному прекращению в течение пяти лет, пишет Domain Name Wire. Доменная зона .su, которая до сих пор доступна для регистрации и насчитывает порядка 100 000 доменов, находится под управлением Российского института развития общественных сетей.

6 февраля организация Public Technical Identifiers (PTI), отвечающая за работу Internet Assigned Numbers Authority (IANA) при ICANN, направила закрытое письмо администратору домена, уведомив о планах по поэтапному отказу от .su к 2030 году. Это решение основано на политике, разработанной Country Code Names Supporting Organization (ccNSO) и одобренной советом ICANN в 2022 году. Согласно этой политике, если страна или территория исключаются из стандарта ISO 3166-1, соответствующий доменный код должен быть аннулирован после переходного периода, который по умолчанию составляет пять лет. Однако операторы доменов могут запросить продление ещё на пять лет.

Доменная зона .su была исключена из стандарта ISO 3166-1 ещё в 1992 году, но ICANN откладывала действия до завершения разработки формальной политики ccNSO. Теперь, спустя более двух лет после её утверждения, ICANN приступила к реализации. Согласно письму PTI, официальное уведомление о начале процесса удаления планировалось опубликовать 13 февраля, что сделало бы решение публичным и запустило бы пятилетний отсчёт. Однако на данный момент уведомление, судя по всему, ещё не было отправлено.

После официального старта процесса домен .su будет назначен к удалению к 2030 году, если оператор и PTI не договорятся о продлении срока. В письме также упоминается возможность изменения политики, что позволило бы сохранить .su, но для этого потребуется одобрение через ccNSO.

Решение PTI принимается в контексте текущих геополитических событий, связанных с Россией, что может привлечь к ICANN дополнительное внимание. Кроме того, ситуация с .su может стать прецедентом для других доменных зон. Например, Великобритания планирует передать контроль над Британской территорией в Индийском океане Маврикию, что может привести к исключению IO из списка ISO и запуску процесса отказа от популярного домена .io.

Теперь, когда PTI начала процесс, интересно будет наблюдать, вызовет ли реальная угроза удаления какие-либо изменения в политике или подходах к управлению доменными зонами.

Read more

🔄 Своя Dropbox-альтернатива: Syncthing

🔄 Своя Dropbox-альтернатива: Syncthing

🧠 Зачем? Облачные сервисы — удобно, но: * не хочется платить Google/Dropbox за хранение своих файлов * хочется моментально синхронизировать фото, документы и заметки между устройствами * и делать это на своём сервере, без отправки данных «в облако» 👉 Решение — Syncthing: децентрализованный, зашифрованный, open source-синк между любыми устройствами. 🚀 Что ты получишь? * 📂 Автосинк папок между сервером,

🎧 Свой подкаст-сервер за 5 минут: Podgrab

🎧 Свой подкаст-сервер за 5 минут: Podgrab

✨ Зачем? Подкасты — отличный способ учиться, развлекаться и быть в курсе мира. Но что, если: * Хочется слушать подкасты офлайн * Хочется архивировать любимые шоу * Не устраивают сторонние сервисы, реклама и трекеры Решение: Podgrab — простой подкаст-граббер, который автоматически скачивает новые выпуски с любого RSS. А в связке с Audiobookshelf ты получаешь полноценный медиасервер.

Безопасное управление конфигурациями в Ansible: Полное руководство по использованию rescue и always

Безопасное управление конфигурациями в Ansible: Полное руководство по использованию rescue и always

Введение: Почему это важно В мире DevOps и системного администрирования существует простое правило: всё ломается. Особенно в самый неподходящий момент. Когда вы изменяете конфигурацию критического сервиса (например, Nginx), цена ошибки может быть очень высока — от простого даунтайма до потери данных. Ansible предлагает элегантное решение для безопасного внесения изменений через механизм

Использование ~/.ssh/authorized_keys для управления входящими SSH-соединениями

Использование ~/.ssh/authorized_keys для управления входящими SSH-соединениями

Файл ~/.ssh/authorized_keys позволяет настроить команды, которые будут выполняться при входящих SSH-соединениях. Это полезный инструмент для управления доступом и обеспечения безопасности, особенно при работе с резервным копированием данных. Настройка резервного копирования с использованием authorized_keys В данном примере рассматривается использование authorized_keys для настройки резервного копирования базы данных Bacula